In Openstone's implementation training, the first lesson is not about software features — it is six principles that decide whether the system actually lands. Here is that lesson, published, each principle with the failure mode we keep seeing and how we apply it.
1. Step by step, deepen gradually
Do not move every process onto the system at once. Start with the most painful link; expand once it runs smoothly.
- Failure mode: switching eight modules and twenty document types in one go — the team is overwhelmed in month one, and everything rolls back;
- How we do it: phase by "one acceptable closed loop" — order-to-delivery first, then purchasing and inventory. Every step shows the team a result, which persuades better than one grand timetable, and cuts the risk into controllable pieces.
2. Understand the process, set the standard
The system mirrors the process. Before go-live, settle how the work should actually be done and write it down; configuration merely cements the standard.
- Failure mode: copying "it depends who does it" habits into the system — automating chaos, then watching users route around it three months later;
- How we do it: discovery produces a written process standard (including how exceptions are handled), confirmed with the business owner before configuration begins. A process that is not thought through cannot be saved by beautiful setup.
3. Respect the data, plan for it
Opening data usually takes longer than configuration: item codes, partners, opening balances, open documents — each must be cleaned, de-duplicated and reconciled.
- Failure mode: data preparation starts one week before go-live; dates slip repeatedly and the team loses faith in the project;
- How we do it: data gets dedicated time and a named owner (usually a business-side veteran, not IT); coding and de-duplication rules are fixed first, then the bulk cleaning runs. Delay go-live a few days if needed — opening the books on muddled data makes every downstream report wrong.
4. Train properly, standardise operations
Operation training, dress rehearsals, going live — user fluency decides how fast the system's value is realised.
- Failure mode: one big lecture before launch; on day one the team floods the chat with basic questions;
- How we do it: train by role, each person practising the key operations of their own scenarios; rehearsal surfaces the shaky spots and we patch them. The acceptance bar for training is not "it was covered" but "it was practised".
5. Plan well, coordinate everything
Implementation is a genuinely complex project: people, data, process and system advance in parallel.
- Failure mode: the plan contains one date — "go live in month X" — with no milestones and no owners, so drift cannot be located;
- How we do it: plans land as "who delivers what by when" — diagnosis, design, data, training and cut-over each with milestones and deliverables; reviews check drift against them. A plan's job is not to predict everything but to make drift visible immediately.
6. Review regularly, improve continuously
After go-live, review periodically: which flows never ran, which reports nobody opens, which steps get bypassed.
- Failure mode: launch means "done"; six months later, half the processes have been replaced by offline workarounds;
- How we do it: reviews at one month and three months after launch, looking at actual usage data. System problems usually expose process problems — the review is the doorway to improvement.
These six come from our consultants' training notes and run parallel to the delivery method (diagnose → design → build → go live → operate). If you are weighing an ERP rollout, we are happy to talk it through.