The words, without the jargon

Software that operates your existing systems the way a person does — opening screens, reading fields, and typing into them — used where two systems have no way to exchange data directly.

The word 'robotic' is unhelpful; there is no robot. It is a program driving a screen. It suits high-volume, rule-based work in systems you cannot change, and it is more fragile than a proper connection between two systems because it depends on a layout it does not control.

See also: Robotic Process Automation

Software that reads documents — invoices, claims forms, statements — and pulls structured data out of them without a person retyping it.

Distinct from RPA: RPA moves data between systems, IDP gets data out of documents in the first place. The two are often used together. Accuracy depends heavily on how consistent your documents are, which is worth testing on your real paperwork rather than a vendor's samples.

See also: AI Solutions

Paying an external company to run an entire business function for you — support, data entry, claims handling — rather than employing people to do it in-house.

Traditional BPO reduces cost by moving work somewhere cheaper. Automation reduces it by removing the work. The two are often sold as the same thing; they are not, and the second scales better because the saving does not depend on wage differences persisting.

See also: IT Solutions Outsourcing

A defined way for two pieces of software to exchange information directly, without a person or a screen in between.

Whether a system has one is the single biggest factor in what it costs to connect it to anything else. If it does, integration is straightforward. If it does not, the work becomes automation driving a screen — cheaper to build, more expensive to keep running.

Software the business still depends on that is old enough to be difficult to change, and often old enough that nobody remaining knows exactly how it works.

'Legacy' is not an insult and does not mean 'should be replaced'. A system that works, is understood, and costs little to run is fine however old it is. It becomes a problem when it blocks something else — and the honest question is what it is blocking, not how old it is.

Connecting two systems so information moves between them automatically instead of somebody copying it across.

Where a real integration is possible it is almost always better than automating a screen: faster, more reliable, and cheaper to maintain. The catch is that it needs cooperation from both systems, which vendor-locked and older software frequently will not give.

Moving your existing records out of spreadsheets or an old system and into a new one, in a state the new system can actually use.

Routinely the largest single line in a software quote and the one most often left out of cheaper ones. The cost is not in the moving; it is in reconciling fifteen years of records where the same customer appears four different ways.

See also: What software costs in Kenya

The smallest version of a system that is genuinely useful in production, built first so that what gets built next is informed by real use.

Often misused to mean 'cheap and unfinished'. A proper MVP is production-quality but narrow: it does one thing properly rather than five things badly. If a proposed MVP does not solve a real problem on the day it launches, it is a prototype being sold as a first phase.

Operating the old and new systems side by side for a period, then switching over once the new one is proven — rather than stopping one and starting the other.

Real work that a low estimate has usually skipped. It costs more in the short term because two systems are being maintained at once, and it is the difference between a difficult week and a business-stopping one.

The accumulated cost of shortcuts taken during earlier development, paid back as extra time on every subsequent change.

Not automatically a failure — deliberately taking a shortcut to hit a deadline can be the right call. It becomes a problem when nobody tracked what was borrowed. The symptom is small changes taking surprisingly long, and the cause is usually decisions made years earlier.

A permanent record of who changed what and when, kept automatically by the system rather than assembled afterwards.

What turns a document into evidence. It has to be designed in from the start — retrofitting one onto a system that was not built for it is expensive, and the records it produces only cover the period since it was added.

The percentage of time a system is available and working, usually measured monthly or annually.

The numbers are less impressive than they look. 99.9% allows about 8.7 hours of downtime a year; 99% allows over three days. Also check whether planned maintenance is excluded from the calculation, because it very often is.

See also: Infrastructure Management

Renting computing capacity from a provider rather than buying and housing your own servers.

Cheaper to start with and more expensive at scale than owning hardware, which is the opposite of how it is usually pitched. The real advantages are that capacity can change quickly and that somebody else handles the hardware failing at three in the morning.

The phase before any building, where the actual current process is documented and the scope of work is pinned down in writing.

The reason a firm quotes a range before discovery and a fixed figure after. If someone gives you a firm price without it, they have either guessed or built the variation into the contract. Discovery can be scoped and paid for as its own small piece of work.

A written commitment to specific, measurable service levels — how quickly issues are responded to, how much downtime is acceptable — with defined consequences if they are missed.

The consequences are the part that matters. An SLA with no remedy attached is a statement of intent. Check what happens when it is missed, and whether the measurement is of response time or of resolution time, which are very different promises.

Paying a provider to run and maintain part of your technology on an ongoing basis, rather than only to build it and hand it over.

Worth establishing exactly what is covered before signing: monitoring only, monitoring and fixes, or fixes and improvements. The three cost very differently and are all described with the same phrase.

See also: Infrastructure Management