Software is superb at doing what it is told, instantly, every time, without ever asking whether it should. That is the entire value proposition, and it is also why implementations disappoint. A process that produced inconsistent results by hand produces inconsistent results automatically — at higher volume, faster, with a system's authority behind them.
Nobody sets out to automate a broken process. It happens because a system purchase is a decision organizations know how to make, and a process redesign is not. There is a vendor, a demo, a budget line, a go-live date and a launch cake. There is no equivalent ceremony for finally agreeing what "placed in service" means.
What implementations actually fail on
When a fixed asset implementation goes badly, the post-mortem almost never finds a defect in the software. It finds decisions that were never made.
- Definitions were left open. Capitalization thresholds, useful lives by class, what counts as an addition versus an improvement, when a project is complete. The system needs an answer for each and will gratefully accept whatever it is handed.
- Ownership was never assigned. The workflow the software enforces assumes somebody 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, and mapping without agreed definitions bakes today's ambiguity into the new environment permanently.
- Exceptions were not designed for. The experienced person who has been absorbing every unusual case for nine years is not mentioned anywhere in the requirements document. Her judgement is the undocumented half of your 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, which is nobody's favourite quarter.
Every item on that list is cheap to settle before an implementation and painfully expensive to settle after.
Automation amplifies whatever it finds
Let me be concrete about how this actually goes wrong, because "garbage in, garbage out" is true and far too gentle.
Faster wrong answers
A manual process has friction, and friction is an accidental control. Somebody notices the odd number because they had to touch it. Remove the touching and the odd number posts in silence. The error rate may not change at all; the detection rate collapses.
Inconsistency at scale
If three people apply a threshold three ways, a manual environment produces three visible patterns. An automated environment picks one interpretation, applies it to everything, and produces a beautifully uniform result that is confidently wrong in a single direction.
A new system carrying old debt
Conversions move records, and records carry the decisions embedded in them. Lives assigned by default, in-service dates set for convenience, assets recorded in lumps that should have been componentized — all of it arrives intact, now living on a platform that will be trusted considerably more than the spreadsheet it replaced.
What to settle before you configure anything
None of the work below is glamorous, and it 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, workarounds included. The workarounds are requirements in disguise, every time.
- Name an owner for every handoff. Especially the project-to-asset handoff, which is where most environments leak.
- Decide what reporting has to answer. Work backwards from the questions leadership actually asks to the fields that must therefore 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 with a note explaining why.
- Design the controls you want the system to enforce. Prevention beats detection, but only if somebody has specified what to prevent.
With those six settled, configuration becomes mechanical — almost relaxing. Without them, configuration becomes a series of accounting decisions made under deadline pressure by whoever happens to be in the room, usually an implementation consultant who has no possible way of knowing what your organization intends.
The version of this that works
The successful pattern is boring, and I have made peace with that. 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.
And the stakes are rising, not falling. Everything arriving in this space now — deeper integration, automated reconciliation, AI-assisted review — is an amplifier stacked on an amplifier. Which is genuinely exciting if the process underneath is sound, and a fairly efficient way to industrialise a mistake if it isn't.
Software is an excellent way to make a designed process reliable. It is a terrible 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.
