ERP Business Analyst in Chicago

Interviewing a plant that runs around the clock

Plenty of manufacturers and food processors in the Chicago area run more than one shift, and many distribution centers in the suburbs pick and load well into the night. Each shift develops its own habits. Requirements gathered only from day-shift managers miss the workarounds that keep the night running: hand-written move tickets, substitutions made when a component is short, and pallets relabeled at the dock.

I schedule short, focused video interviews with leads from every shift, often at the start or end of their working time, and ask them to show rather than describe: a phone camera on the board they schedule from, the paperwork that travels with a job, the screen they check before loading a trailer. Each conversation becomes a set of numbered requirements and open questions.

Many floor teams in the region include people more comfortable in Spanish, Polish or another language. The engagement runs in English. Where floor input is better gathered in another language, a bilingual supervisor or HR colleague on your team joins the session and checks that what I wrote matches what was meant. Labels, work instructions and screens that need translation are flagged as requirements, with the translated wording supplied or reviewed by native-speaking colleagues in your company or by a local partner.

Customer compliance manuals as a source of requirements

Suppliers in the Midwest often sell to national retailers, automotive and equipment makers, and food service distributors. Each of those customers publishes a vendor manual or routing guide describing exactly how orders must be confirmed, labeled, packed and shipped, and what the supplier is charged when something is wrong. These documents are some of the most precise requirement sources a business has, and they are often ignored during ERP selection.

I read each manual and extract the system rules hiding inside it: which electronic documents are exchanged and when, what goes on a carton or pallet label, how advance ship notices must match the physical load, how releases and forecasts change, and how penalties and deductions are recorded. Each rule becomes a requirement with the customer named, so the vendor cannot answer with a vague yes.

Deductions deserve their own attention. If chargebacks arrive as short payments, finance needs a way to log, dispute and analyze them by cause. I write that process as part of requirements gathering rather than leaving it for after go-live, when it usually becomes a spreadsheet.

Time clocks, biometric data and the payroll boundary

Plants and warehouses need labor hours in two places: on jobs, for costing, and in payroll. The ERP often sits in the middle. Many Chicago businesses use a separate time and attendance system, a payroll provider and sometimes a staffing agency for temporary workers, each holding part of the employee record.

Illinois has a specific law on biometric information, which matters if your time clocks use fingerprints, hand geometry or face scans. I am not a lawyer, and what the statute demands of your business is a question for counsel. What I do is document exactly where biometric templates are captured and stored, which systems only receive hours and employee numbers, and which integrations must never carry anything more. Those boundaries go into the requirements as explicit statements, with a note that your employment counsel should confirm them before design is final.

Local paid leave and wage rules can also differ inside the metro area. Those calculations normally belong to the payroll provider, not the ERP, and I write the requirement that way: the ERP receives approved hours and cost rates, and payroll remains the system of record for pay. Check current obligations with your payroll and legal advisors.

Acquisitions and the master data problem

The region has a long tradition of growth by acquisition. A distributor buys smaller competitors in neighboring states; an investor-backed platform rolls up several family machine shops. Each acquired business arrives with its own item numbers, customer codes, units of measure, price lists and ways of describing the same product. Putting them into one ERP without a plan creates duplicates that never go away.

Before configuration starts, I write master data requirements alongside process requirements. That includes the target item numbering scheme, rules for matching duplicate customers and suppliers, how units of measure convert, which price agreements survive and who owns each master record after go-live. I then define cleansing tasks for each acquired company, with sample records checked by people who know them.

This is also where reporting requirements get settled. Owners usually want to compare acquired branches like for like, which only works if product categories, cost elements and customer groups are defined the same way everywhere. My data migration service carries those rules into the actual load.

What you receive, and how it connects to testing

The core deliverable is a business requirements document organized by process: quote and order, planning and production, purchasing and receiving, warehouse and shipping, finance, and reporting. Every requirement has an owner, a priority and a source, whether that is an interview, a customer manual or a legal review point. Alongside it sits a fit-gap matrix scoring the shortlisted platforms.

I then write UAT scripts directly from the requirements, so nothing is tested that was not required and nothing required goes untested. For a Chicago food plant that might mean a mock recall on a real ingredient lot; for a fabricator, a custom job quoted, released, run with a substitution and shipped partially; for a distributor, an order from a retailer whose routing guide demands a specific label and ship notice.

The country-level view of tax, vendor and control requirements is on my US ERP business analyst page, and the wider Chicago context is on the Chicago ERP consultant page. If you would rather have an independent person lead the whole project, see the Chicago freelance ERP consultant page.