Where The Money Actually Goes In An Automation Project

Businesses budget for the licence and are surprised by the project. The licence is often the smallest number involved, and the costs that overrun are predictable enough to plan for.

Here is the realistic structure.

Understanding the current process

Someone has to establish what actually happens today, which means sitting with the people doing the work rather than asking a manager to describe it.

This is where scope is genuinely decided, and skipping it does not save money -- it defers the cost to a later stage where discovering something unexpected is far more expensive. Expect it to take days, not hours, and expect it to produce changes to what you thought you were buying.

Getting your existing records in

Consistently the most underestimated line, and the one that most often derails a timeline.

Your current records are messier than you think. The same customer under three spellings. Products with no consistent code. Prices in a column that sometimes includes tax and sometimes does not. Dates in two formats because two people typed them.

Migration means extracting, cleaning, deciding what to do with the ambiguities, loading, and then checking. That last step -- somebody actually comparing the new records against the old ones for a sample -- is the one that gets cut when time runs short, and cutting it is how you end up with staff who do not trust the system.

Budget properly for this. If the vendor has quoted a small number for migration, ask exactly what it includes and who does the checking.

Configuration

Making the system match how you work: your services, your tax treatment, your document numbering, your approval rules, your branches.

Some of this is included in most quotes. The parts that are not tend to be the parts specific to you, which are also the parts that matter.

Training

Not the demonstration. Actual training for each group of staff on their own real work, including the awkward cases.

The common failure is to train once, before go-live, when nobody has real questions yet. Better is a short session before, and a second session two or three weeks after, when people have hit real problems and have specific questions. The second session is the one that changes behaviour, and it is the one that gets dropped.

The period where you run both

For a while you will be running the old way and the new way at once, because nobody sensible switches a business over on a single day with no fallback.

This is a real cost: double entry, slower work, and the attention of your best people. It usually lasts a few weeks. Plan for the productivity dip rather than being surprised by it.

Ongoing licence, and what it does at scale

The visible number. Read carefully whether it is per user, per transaction, per branch, or a combination, and work out what it becomes when the business grows.

Also establish what the price does at renewal. Introductory pricing that steps up in year two is common and legitimate, but it should be in your plan.

Somebody owning it afterwards

Every working system has someone who notices when it goes wrong, handles the exceptions, adds the new product line, and trains the new hire.

This is rarely budgeted and it is not free. Usually it lands on whoever was most involved in the project, on top of their existing job. If you do not name this person and allow time for it, the system decays quietly -- new products entered inconsistently, permissions never updated, reports slowly diverging from reality.

The costs people forget entirely

Hardware. Scanners, printers, tablets on the shop floor, a better router.

Connectivity. A system that lives online is only as available as your internet. For some businesses this means a second connection, which is an ongoing cost.

Power. Related, and locally unavoidable. If the system is essential to trading, its availability is now tied to your power arrangement.

The integration nobody mentioned until it turned out the new system had to talk to the old one.

How to hold this together

Ask for the total cost of the first two years, not the first month. Ask which lines are fixed and which vary with usage. Ask what is explicitly excluded.

Then add a contingency, because the discovery stage will find something. It always does, and a project with no contingency handles that discovery by cutting training and migration checking -- the two things that determine whether any of it works.