Software is very good at doing what it is told, quickly, every time, without asking whether it should. That is the whole value proposition, and it is also the reason implementations disappoint. A process that produced inconsistent results manually produces inconsistent results automatically, at higher volume, with a system's authority behind them.
Nobody sets out to automate a broken process. It happens because a system purchase is a decision an organization knows how to make, and a process redesign is not. There is a vendor, a demo, a budget line, and a go-live date. There is no equivalent ceremony for agreeing what "placed in service" means.
What implementations actually fail on
When a fixed asset implementation goes badly, the post-mortem rarely finds a defect in the software. It finds decisions that were never made.
- Definitions were left open. Capitalization thresholds, useful lives by class, what constitutes an addition versus an improvement, when a project is complete. The system needs an answer for each and will accept whatever it is given.
- Ownership was never assigned. The workflow the software enforces assumes someone is responsible for each step. If a step had no owner before, configuration turns that gap into a queue nobody watches.
- Data was converted before it was decided. Conversion forces a mapping. Mapping without agreed definitions bakes today's ambiguity into the new environment permanently.
- Exceptions were not designed for. The experienced person who absorbed every unusual case is not in the requirements document. Their judgement is the undocumented half of the process.
- Reporting requirements arrived last. What leadership needs to see determines what has to be captured. Discovering that after go-live means re-capturing history.
Every item on that list is cheap to settle before an implementation and expensive to settle after.
Automation amplifies whatever it finds
It helps to be concrete about how this goes wrong.
Faster wrong answers
A manual process has friction, and friction is an accidental control. Someone notices the odd number because they had to touch it. Remove the touching and the odd number posts silently. The error rate may not change; the detection rate collapses.
Inconsistency at scale
If three people apply a threshold three ways, a manual environment produces three patterns you can see. An automated environment picks one interpretation, applies it to everything, and produces a uniform result that is confidently wrong in one direction.
A new system carrying old debt
Conversions move records, and records carry the decisions embedded in them. Lives that were assigned by default, in-service dates set for convenience, assets recorded in lumps that should have been componentized — all of it arrives intact, now on a platform that will be trusted more than the spreadsheet it replaced.
What to settle before you configure anything
The work below is not glamorous and takes far less time than most implementation timelines assume.
- Write down the definitions. Thresholds, classes, lives, what triggers capitalization, what "complete" means. One document, agreed by accounting and by the people who commission capital.
- Map the real process, including the exceptions. Not the process as designed — the process as run, with the workarounds. The workarounds are requirements in disguise.
- Name an owner for every handoff. Particularly the project-to-asset handoff, which is where most environments leak.
- Decide what reporting has to answer. Work backwards from the questions leadership asks to the fields that must exist.
- Assess the data honestly. Know what is wrong before conversion, and decide deliberately what gets fixed, what gets carried, and what gets left behind.
- Design the controls you want the system to enforce. Prevention beats detection, but only if you have specified what to prevent.
With those six settled, configuration becomes mechanical. Without them, configuration becomes a series of decisions made under deadline pressure by whoever is in the room — usually an implementation consultant who has no way of knowing what your organization actually intends.
The version of this that works
The successful pattern is boring. Diagnose the environment. Settle the definitions and the ownership. Decide what the future state should be. Then select or configure the software to enforce it, convert data against agreed rules, and train people on the process rather than on the screens.
Software is a good way to make a designed process reliable. It is a poor way to design one. If the process is not right yet, automation is not the next step — it is the step after the next step.