ERP Business Analyst in Los Angeles

Why a county of many cities complicates requirements

Los Angeles County is not one city but dozens of incorporated cities sitting side by side, from Long Beach and Pasadena to Vernon, Burbank and Santa Monica, plus unincorporated areas governed by the county. For a business that delivers goods, sends technicians or runs locations across that map, the address of a transaction can carry real weight.

California sales and use tax combines a statewide rate with district taxes that vary between localities, so neighboring cities may not share the same total rate. Several cities, including the City of Los Angeles, also levy their own business taxes, which can depend on gross receipts and the type of business. How these apply to your company is a question for your tax advisor, not for an ERP vendor or for me.

What I do is make sure the system can hold the data those answers rely on. That usually means validated ship-to addresses, a clear record of which locations you operate from, customer exemption documents stored against the account, and receipts that can be reported by city and by business activity. I write those as specific requirements and add test cases, such as a delivery into a neighboring city with a different rate, so vendors have to show how their tax setup or connected tax engine handles them. The country-wide view of multi-state tax requirements sits on my US ERP business analyst page.

Labor data: where the ERP ends and payroll begins

California labor rules look closely at each working day, not only at the working week. Daily overtime, meal and rest periods, and premiums when breaks are missed all depend on accurate time records. For a Los Angeles manufacturer, warehouse, restaurant group or field service company, that data often starts on the shop floor or in a mobile app long before payroll runs.

Many ERP projects get this boundary wrong. Either the ERP is expected to calculate pay it was never designed for, or labor data is ignored and job costing ends up using estimates. I map where clock-ins, shift assignments, job or work order codes and break records are captured today, then define which system owns each one.

A typical outcome is that a specialist timekeeping tool or the payroll provider handles pay rules, while the ERP receives approved hours by job, work order or location for costing. The requirements spell out that hand-off: what data moves, how often, who approves it and how corrections flow back. Pay rules themselves are confirmed by your employment counsel and payroll provider. That keeps the ERP focused on cost and productivity reporting, and keeps the legal calculation where it can be supported.

Product data for food, cosmetics and consumer goods makers

The industrial cities east and south of downtown, such as Vernon, Commerce and Santa Fe Springs, along with parts of the San Fernando Valley, hold a large base of food processors, cosmetics and personal care makers, supplement producers and consumer goods companies. Their ERP requirements are shaped as much by product data as by transactions.

For these businesses I document how lots are created at receipt and in production, how expiry and best-by dates are set, and how a lot can be traced forward to customers and backward to suppliers when a question comes up. Federal food traceability expectations and customer audits both point in that direction, and your quality lead confirms which apply.

California adds its own layer. Products sold in the state may need warning labels under the state's Proposition Sixty-Five rules, and whether a product needs one is a decision for your compliance advisor. The requirement for the ERP is simpler: store the warning status and text on the item, carry it to labels, packing documents and product data sent to retailers or online channels, and record when it was last reviewed. Writing that into the BRD prevents warnings from living in a separate spreadsheet that no one updates. The wider production flow for this sector is set out under food and beverage ERP.

Privacy requests that reach across CRM and ERP

California's consumer privacy law gives individuals rights to know what personal information a business holds about them, to request deletion or correction, and to limit some uses of it. Whether and how it applies to your company depends on factors your privacy counsel will assess. Consumer brands, clinics, schools and service businesses in Los Angeles often find that it does.

From a requirements point of view, the hard part is that one person's data rarely lives in one place. A customer may exist in the storefront, the CRM, the ERP's customer master, the help desk and the marketing tool. If a request arrives, someone needs to find every record, decide what can be deleted and what must be kept for tax or warranty reasons, and document what was done.

I write requirements that make this workable: a single customer identifier across systems where possible, search and export by person, controlled deletion or anonymization that preserves financial records, and a log of each request and its outcome. These go into the BRD alongside the integration map so vendors and integrators know they have to support them. The legal interpretation stays with your counsel; what I contribute is a system design that does not get in the way of compliance. Related design work is covered under ERP requirements gathering.

What you receive and how it is tested

The end product of the analysis is a set of documents your team owns and can hand to any vendor. The process maps show today's flow and the target flow for each department. The business requirements document groups requirements by process, marks each as essential, important or nice to have, and flags the California and county-specific ones so they are not lost in negotiation.

A fit-gap matrix then records how each shortlisted platform meets each requirement: standard feature, configuration, add-on or custom work. That is where generic demos tend to fall apart, because a vendor's prepared script rarely includes a delivery into a city with a different tax rate, a lot recall query, a shift with a missed break or a customer deletion request.

So I build scripted demonstration scenarios and, later, acceptance test scripts from your own Los Angeles transactions. During implementation those scripts are run before go-live, and failures are logged against the requirement they break. The sessions run over video in the Pacific morning or late afternoon, and floor processes can be observed through a phone walk-through. If you would like to scope this for your company, send me a short outline of your operations and the systems you use today.