What does IT automation cost?

What determines the price?

Two workflows that look almost identical to the user can be very different to automate. A form that creates a case in a modern system with a well-documented API is typically simpler than a process that has to read varying documents, retrieve information from legacy systems and handle many special rules.

The first price parameter is scope. Where does the process start, when is it finished, and which steps must still be carried out by a human? A clear boundary makes estimation, testing and accountability easier. If the project also has to clean up master data, change workflows and replace several systems, it is really a larger change project.

The integrations matter a great deal too. Standardised APIs and webhooks provide stable connections. Missing access, unclear data models or dependence on user interfaces require more analysis and more robust error handling. Finally, security, documentation, logging, approvals and uptime requirements affect the overall effort.

• The number of systems, data sources and integrations.
• Data quality, file formats and variation in input.
• The number of rules, exceptions and manual approvals.
• Requirements for security, traceability, uptime and documentation.
• The need for a user interface, reporting and ongoing administration.

Split the budget into three parts

A usable budget distinguishes between discovery, implementation and operations. Discovery maps the current process, data sources, exceptions and success criteria. The result should be a concrete flow, a scope and a list of the biggest uncertainties. That effort can look like an extra cost, but it reduces the risk of building the wrong solution.

Implementation covers integrations, business rules, any user interface, testing and go-live. Here it is important to agree on what the first version must be able to do. Not everything has to be automatic from day one. If the most frequent cases can be handled safely while rare exceptions are sent for manual review, the company can gain value earlier and learn from actual use.

Operations continue after launch. Systems change their APIs, employees change the process, and errors must be detectable. So budget for monitoring, support, security updates and minor adjustments. An automation without an owner and maintenance gradually becomes less reliable, even if it worked on launch day.

How to build a realistic business case

Start with a baseline. Measure how many cases the process handles, how long the typical steps take, how often errors occur, and how long a case waits between departments. Use a representative period rather than employees’ best guess. Also note seasonal fluctuations and cases that require extra work.

Then calculate the expected effect conservatively. Automation rarely removes all human time. There will still be control, exceptions and maintenance. In return, the value can be greater than the hours saved: shorter response time, fewer interruptions, consistent documentation and less risk of forgotten follow-ups can have noticeable business value.

Compare the annual gain with both the setup and the expected operations. It helps to build three scenarios: conservative, expected and optimistic. If the project only adds up in the optimistic scenario, the process should be scoped down further or investigated more thoroughly before you invest.

What does it take to get a usable estimate?

A serious estimate does not require a long requirements specification, but it does require concrete information. Describe the process step by step, list the systems and accounts involved, and bring examples of input and output without sensitive information. State how often the process runs, who owns it, and which errors are unacceptable.

Also clarify whether the supplier can gain access to test environments and technical documentation. A short technical investigation can be the best first deliverable if a critical integration is uncertain. Once the uncertainty has been reduced, the next phase can be estimated far more accurately.

The cheapest solution is not necessarily the one with the fewest development hours. A solution has to be possible to monitor, explain and change. So choose a first version that is small enough to manage but complete enough to work safely in the real workflow.