ERP Business Analyst in Birmingham

Why Birmingham's specialist trades need their own requirements

Standard ERP templates assume a business that buys a finished item, stores it and sells it in the same unit. Several of Birmingham's established trades do not work that way. A jewelry workshop buys metal by weight, turns it into pieces that are sold individually, and sends filings and scrap back to be refined. A medical supplier may never sell some of its stock outright, lending it instead to a hospital and billing only for what was used in a procedure.

If these rules are not written down before selection, two things tend to happen. The vendor demonstration looks convincing because it uses simple examples, and the gaps only appear in testing, when changing course is expensive. Or the team builds spreadsheets beside the new system, recreating the problem the project was meant to solve.

My role as an ERP business analyst is to make the unusual parts visible early. I map each process from the first document to the last, mark every point where a rule or a calculation is applied, and agree the wording with the person who owns it. The result feeds the ERP requirements gathering stage directly, and gives the wider Birmingham ERP consultant work a sound base for any platform decision.

Jewellery Quarter workshops: weight, fineness and hallmarking

A manufacturing jeweler or precious metal business in the Jewellery Quarter has to answer questions that few ERP demonstrations cover. How much fine metal is on the premises, by alloy and fineness, including work in progress at the bench? How much has been issued to each craftsperson, and how much came back as finished pieces, filings and sweepings? Which pieces are away for hallmarking, and when are they due back?

Requirements for this kind of business usually cover a dual record of each item by piece and by metal weight, metal accounts held with suppliers or refiners where that applies, bench issues and returns with tolerance checks, and pricing that responds to metal prices as they change. Commissions and repairs add customer-owned stones and gold that must be receipted, tracked and returned without mixing them into stock.

Some firms also supply retailers on a sale or return basis, so stock sits in other people's shops while still belonging to the maker. I document how memo stock is issued, counted and invoiced when sold. Questions about how metal transactions are treated for VAT belong with your accountant; my job is to make sure the system can record whatever treatment they confirm and report it clearly.

Medical suppliers near the hospital and university campuses

Birmingham's large hospitals, its universities and the health research activity around them support a network of distributors, service companies and manufacturers of medical equipment and consumables. Their requirements often center on traceability and on stock that the business owns but does not hold.

Instrument and implant sets lent to hospital theaters need records of what went out, what came back, what was used and what needs cleaning, checking or replacing before the next loan. Consignment stock held on a hospital site needs regular usage reports that trigger both a replacement and an invoice. Every item with a lot or serial number has to be traceable to the customer who received it, so that a field safety notice can be acted on quickly.

Selling to the health service may also involve framework agreements, specific product codes on catalogs and supplier portals. Device regulation, registration and classification questions belong with your regulatory lead, and I keep them out of my scope. What I document is how the system records lots, serials, expiry dates, quarantine status and customer deliveries, then I write test cases for recall searches and loan returns so these are proved before go-live, not after.

Working with bilingual teams and product data in more than one script

Birmingham is a city of many communities, and plenty of family-run firms here have staff who are more comfortable discussing detailed processes in Punjabi, Urdu, Bengali, Polish or another language than in English. That matters for business analysis, because the people who know the exceptions are often the ones least likely to speak up in a formal English workshop.

The engagement runs in English. Where it helps, a bilingual member of your team joins sessions to make sure everyone's knowledge is captured, and checks that the terms in the requirements match what staff actually call things on the floor or at the counter. Glossaries of trade terms become part of the BRD, so the implementer configures the system using names your people recognize.

Some businesses also need product descriptions, labels or customer documents in a second language or script. I record those needs as requirements, including which documents need them and who maintains the text. Text in those languages comes from fluent colleagues in your business or from a local partner you trust, and is never assumed from a machine translation.

From workshop notes to sign-off, delivered remotely

The analysis runs remotely over a series of short, focused sessions rather than long workshops that take people away from the bench or the warehouse. Before each session I ask for real documents: job bags, metal books, loan kit lists, delivery notes, recall procedures and the spreadsheets people rely on. These shape the questions and later become the test data.

Deliverables follow a set order. First come current state process maps and a list of problems, then future state maps and prioritized requirements, then the business requirements document itself. The approach is described on my BRD consulting page. Once a shortlist exists, I run a fit-gap review, and before go-live I write UAT scripts built on your own transactions.

For the country-wide picture, including VAT treatment and Making Tax Digital as requirements, see the UK ERP business analyst page. If you would like to start, send me a description of the process that causes you the greatest trouble.