ERP Business Analyst in Melbourne

Writing down what long-serving staff simply know

Melbourne has a lot of established businesses where key people have been in the same role for a very long time. They are often the reason the company runs smoothly, and they are also the biggest risk in an ERP project. If their knowledge is not captured, the new system is configured around the documented process, and the real one breaks on day one.

I run knowledge capture as a distinct step. Each key person gets a series of short remote sessions where they walk through a normal day, then through the unusual cases: the customer who pays differently, the product that is always short, the month-end adjustment nobody else understands. Where it helps, they record their screen or film a task on a phone, and I turn the recording into a written procedure with decision points.

Every rule we uncover is then sorted. Some become requirements, some become configuration notes, and some turn out to be workarounds for problems the new system will remove. That sorting matters: it stops old habits being rebuilt in new software. The method is the same one behind my ERP process mapping work, applied with extra care for people who are about to retire or move on.

Victorian obligations as system requirements

A Melbourne business works under national rules and a set of Victorian ones, and an ERP project needs to know which of them depend on system data. Payroll tax in Victoria, for example, relies on accurate wage figures across related entities, so the requirements should say which system holds those figures and how a group view is produced. Some Victorian industries have portable long service leave schemes, which need employee service records the payroll or ERP must keep. Workers compensation insurance relies on remuneration data by type of work.

I do not interpret these rules; your accountant, payroll provider or advisor does. My job is to make sure each one is listed, assigned an owner and translated into what the system must store, calculate or report. A register sets out the obligation in plain words, the data it needs, the system that should hold it and the report that proves it.

National topics such as GST coding, BAS and Single Touch Payroll are covered on the Australia ERP business analyst page. The Victorian register sits beside them in the requirements pack, so vendors see the full picture and your advisors can confirm it in one place.

Awards, enterprise agreements and shift-based costing

Factories in the south-east, warehouses in the west and hospitality groups across the inner suburbs often run shifts under modern awards or enterprise agreements. Penalty rates, overtime, allowances and leave loadings make the true cost of an hour of labor differ by shift, day and role. When the ERP costs production or jobs with a flat hourly rate, margins look healthier on paper than they are.

The requirement is not to run award interpretation in the ERP. That belongs in rostering or payroll software built for it. The requirement is to define what labor cost information the ERP needs back, in how much detail and on what schedule. A manufacturer may need actual labor cost by work order. A warehouse operator may need cost by client contract. A hospitality group may need wage cost by venue and trading period.

I write these as data flow requirements: source system, fields, timing, ownership and the reports they feed. That gives vendors something precise to respond to and avoids a common gap where payroll is implemented separately and nobody connects it to costing. Where a project needs a fuller integration design, it moves into my ERP requirements gathering scope.

Fresh produce and food wholesale around the Epping market

Melbourne's wholesale fruit, vegetable and flower market at Epping, along with the food distributors around it, trade in a way generic ERP demos rarely show. Stock is bought by the crate or pallet and sold by the kilo, the bunch or the tray. Weights vary item by item. Prices can change during the day. Product is graded, regraded and sometimes sold off cheaply before it spoils, and customers claim credits for product that arrives below standard.

Requirements for these businesses need precise wording. Catch weight means the system records the actual weight on each line, not an assumed one. Units of measure must convert reliably between purchase and sale. Pricing rules must handle daily or customer-specific changes without manual overrides on every invoice. Credits must link back to the original sale and, ideally, to the supplier who sent the product.

Trading also begins very early, long before most office staff arrive, so the requirements should cover how orders, picking and dispatch work with a small early crew and how the office reconciles everything later. I test these requirements in vendor demos with real sample orders, as described on my wholesale ERP page.

Fashion labels and the style, color and size grid

Melbourne has a long history in clothing and textiles, and today many fashion and apparel labels design locally, manufacture overseas and sell through their own stores, online and to wholesale accounts. Their requirements are distinctive enough that a generic product list will not do.

Each style comes in several colors and a run of sizes, and the business plans, buys and reports at the style level while stock moves at the size level. Ranges are seasonal, so the system must know which season a style belongs to and when it should be marked down or cleared. Wholesale customers may place indent orders well before production, which need to be tracked against factory orders. Imported garments need landed costs that include freight, duty and agent fees, allocated sensibly across sizes.

I write these as requirements with worked examples: a sample style with its color and size grid, an indent order, a production order and a receipt. Vendors then have to show how their system handles each step. Many platforms can manage variants; fewer handle seasonal ranges, indents and landed cost together without heavy customization. The requirements pack makes that difference visible early, before a contract is signed, and feeds my ERP business analysis deliverables.