Choose an observable bottleneck
Find a process with delays, duplication or missing follow-up that the team can illustrate with cases. Define its start, finish and exceptions. A useful first release completes that journey even if it covers few modules. “Digitise the entire company” cannot be estimated or tested as a concrete outcome.
Model data and responsibilities
Name entities, states and the people allowed to change them. Separate master data from transactions and document the authoritative source. Plan conflicts and corrections early. This prevents different screens from presenting incompatible interpretations of the same order, inventory item or customer.
Deliver an end-to-end slice
Connect interface, rules, data and a necessary integration in a small end-to-end journey. Test with representative users before expanding. Many screens do not mean a process is complete: people must finish the task, inspect its state and recover from errors without depending on a developer.
Budget for operation too
Plan monitoring, support, backups, restoration and training alongside development. Assign owners for incidents and changes. Track deferred work with its reason and dependencies. The next release should respond to usage evidence, not simply the desire to add modules to a catalogue.
Worked example: request to receipt
For an example company, the first release could cover purchase requests, approval and receipt recording. A requester records a need; an authorised person reviews it; operations confirms what arrived. The team defines who may change quantities and how partial deliveries work. The existing ERP retains accounting data and remains its authoritative source. The application tracks process state and a reference to the external document rather than inventing a second accounting ledger. The pilot begins with a bounded group and synthetic cases. After validating the journey, authorised real cases are introduced and the team decides whether to expand modules or improve the process first.
Acceptance checklist for the pilot
Check that a request can pass through all states, a rejection retains its reason and partial receipt does not incorrectly close the order. Test permissions with different accounts rather than only an administrator. Reconcile identifiers with the primary system and simulate its unavailability. Pending work and manual continuation must remain clear. Accept the pilot with an operational owner, an incident procedure and a defined limit on users or processes. List excluded functions, such as complete accounting or advanced planning, separately so nobody assumes they have been delivered as part of this release.
Key takeaways
- One small complete process is worth more than many disconnected screens.