ERP system development
in Philadelphia

Launch day is the least interesting part of an ERP project. The month afterwards decides whether the system is used properly or worked around, and most of that month can be planned in advance.

Parallel running is the first decision. Keeping the old system alive alongside the new one is reassuring and expensive: every transaction is entered twice, and people under pressure will enter it properly in only one of them. A short overlap with a stated end date is useful. An open-ended one buys nothing except double work.

Opening balances are where trust is won or lost. If stock counts, outstanding invoices and customer balances do not match what people expect on the first morning, the system is judged wrong and the judgement sticks. That reconciliation is worth more preparation than any training session.

Training should be built around roles rather than around modules. A warehouse supervisor does not need a tour of the finance screens. They need the four things they do every day, in the order they do them, on the real system with real data.

Super-users are the mechanism that scales this. One person per department who learned early, has time allocated, and is allowed to say I do not know and find out. People ask a colleague before they raise a ticket, and that colleague is going to answer either way. Better that they are prepared.

Expect a backlog in week one. Everything paused during cutover arrives at once, into a system nobody is fast in yet. Planning quieter workloads for that week is cheaper than overtime.

Questions need a single route in. Three inboxes and a chat group produce the same question answered differently, and nobody can see what the common problems are.

That log is the most useful artefact of the month. Recurring questions point at a screen that is confusing, a process that was mapped wrongly, or training that missed. Each one is either a fix, a documentation change or a decision that the process itself was wrong.

Change requests should be collected and held rather than acted on immediately. In the first weeks every difference from the old system feels like a defect. After four weeks, most of that list has evaporated, and what remains is the real work.

Approval rules look like configuration. They are a control, and the auditor will read them that way.

The core idea is separation. The person who raises a purchase order should not be the person who approves it, and neither of them should be the person who confirms that the goods arrived. Where one person can do all three, the system permits a loss that nobody would have to work hard to cause.

Small organisations cannot always separate those roles, and pretending otherwise produces a rule everybody bypasses. The honest answer is a compensating check: a second pair of eyes after the fact, on a schedule, with a record.

Thresholds come from the actual distribution of spending. Not from a round number. A limit set too low sends hundreds of routine items to a director who approves them without reading. That is worse than no limit, because it produces a signature that means nothing.

Delegation has to exist before the holiday, not after. Without it, approvals queue for two weeks. The workaround is a shared password. That single habit undoes the whole design.

Changes to master data deserve the same treatment as money. Bank details, supplier addresses and price lists are where fraud actually happens, and a change there is quieter than an invoice.

The audit trail has to be immutable and readable. Who changed what. When. What the value was before. An ERP that overwrites without history cannot answer the only question that matters after an incident.

Expect to be asked for evidence rather than for the policy. Screenshots of the configuration, a list of who holds which role, and a sample of transactions traced end to end.

So the roles and thresholds get documented as part of the build rather than reconstructed later. A matrix written during implementation takes an afternoon. Reconstructing it from a live system takes a week and is never quite right.