ERP Business Analyst in Sydney

Head office says one thing, the warehouse does another

Greater Sydney is large and spread out, and many businesses grow by adding a site wherever space and labor are available. The result is headquarters in or near the city, a branch in Parramatta or the Hills District, and operational sites in places such as Wetherill Park, Smithfield, Eastern Creek or Moorebank. Each location develops its own habits: a different way of receiving goods, raising credits, approving overtime or recording returns.

When an ERP project starts, head office often describes the process as it was designed years ago. The sites describe what actually happens. If requirements are written only from the head office view, the new system will be configured for a process nobody follows, and users at the sites will rebuild their spreadsheets within weeks.

I avoid this by running separate remote workshops with each location before any combined session. Each team walks through its own documents and screens, and I record the steps, the exceptions and the workarounds. Only then do I bring process owners together to compare versions. The aim is not to force one site's way on everyone but to make a deliberate choice for every difference. The wider picture of Sydney's industries is on my Sydney ERP consultant page.

Turning New South Wales rules into system requirements

Several obligations that affect an ERP are set at state level, and a Sydney business works under New South Wales rules for them. Payroll tax is one example: whether related businesses are grouped, and how wages are split across entities, affects what data the payroll and finance systems must hold. Long service leave is another, because entitlements follow state legislation and the system needs accurate service history to support them. Builders and subcontractors face state security of payment rules that shape how payment claims and responses are issued and tracked.

I do not interpret these rules for you. That stays with your accountant, payroll provider or legal advisor. What I do is make sure the questions are asked early and the answers become requirements: which fields must be captured, which reports must exist, which deadlines need reminders and which system owns each record. Without that step, these needs tend to surface during testing, when they are expensive to add.

Each item goes into an obligations list with an owner, the advisor who confirmed it and the requirement it produced. Country-wide matters such as GST and Single Touch Payroll are handled on the Australia ERP business analyst page.

Approval rules for a Sydney head office and its entities

Sydney is home to many group head offices, and with that comes layered authority. A purchase that a site manager can approve alone in one entity may need finance sign-off in another. Credit notes, stock write-offs, price overrides and supplier changes often have informal rules that live in someone's memory or an old email. When the ERP arrives, those rules have to become explicit workflow, or approvals either block every transaction or wave everything through.

I capture this as a delegation of authority matrix: each transaction type, the value bands or conditions that change the approver, the role at each site or entity, and what happens when that person is away. I check it against how approvals actually happen today, which often reveals that some limits are routinely bypassed because they no longer fit the business.

The matrix then feeds requirements for approval workflow, audit trails and reporting on overrides. It also gives auditors and the board a clear statement of control. Where a group runs shared finance from Sydney for entities elsewhere, I add recharge and intercompany approval rules. My approval workflow approach covers how these rules are tested before go-live.

Requirements that work for a multilingual workforce

Sydney's workforce is linguistically diverse, especially in warehousing, manufacturing, cleaning, food production and aged care across western and south-western Sydney. Many supervisors and floor staff speak a language other than English at home. That has practical consequences for an ERP project that requirement documents often ignore.

First, process reviews must be accessible. If only managers can read the process maps, errors on the floor go unnoticed until go-live. I keep maps visual, labels short and language plain, so staff can point to a step and say it is wrong. Second, requirements should state which screens, labels, pick lists and instructions need to be available in other languages or rely on icons and barcodes instead of text. Third, training needs must be recorded as requirements, not left as an afterthought.

The engagement runs in English. Any translated text, training material or local-language labels are written or checked by bilingual people on your team or by a partner you appoint. My job is to make sure the requirement exists, has an owner and is tested with the people who will use it. Good process mapping is the starting point.

What the finished requirements pack contains

At the end of the analysis you receive a pack that vendors, partners and your own team can work from. The core is a business requirements document organized by process area, with every requirement numbered, prioritized as essential, important or optional, and linked to the site or entity it applies to. Process maps sit alongside it, together with the variant register recording what was standardized and what remains different by design.

The pack also includes the New South Wales obligations list with advisor confirmations, the delegation of authority matrix, a list of reports and dashboards each role needs, and an inventory of current systems and spreadsheets with a note of what each one does today. Sample documents, such as delivery dockets, invoices, payment claims or timesheets, are attached so vendors can see real formats.

Because each requirement is traceable, the same pack later drives the fit-gap review and the test scripts, so nothing agreed in a Sydney workshop is lost between selection and go-live. If you already have a draft, I can review it instead. For the full method, see ERP business analysis, or get in touch to discuss your sites and timing.