Business Process Automation in New York

Business process automation is the use of software to run multi-step business processes with less manual handling. As a discipline it covers more than the software itself. It covers how an organisation decides where to automate, in what order, and what it expects to get back.

A business process automation programme has four parts: an assessment of where manual effort is concentrated, a decision on sequence, a build, and a measurement against numbers agreed before the build started. Programmes that skip the first and last parts are the ones that disappoint.

Two things it is not.

It is not a single tool. No product automates a business. Automation is a series of decisions about which work should stop being done by people, made in an order that matches the business rather than the software.

It is not a one-off project. The first automation changes how the next process should be designed. Businesses that treat it as a programme, with a sequence and an owner, get considerably more out of it than businesses that treat it as a purchase.

A realistic automation business case counts three things: staff hours removed, errors avoided, and revenue that arrives sooner because a step stopped waiting. It then subtracts the running cost of the automation, which is never zero.

The working version:

Annual return = (hours saved per month × 12 × fully loaded hourly cost) + (annual cost of errors avoided) + (value of faster cycle time) − (annual running and support cost)

Fully loaded cost means salary plus employment costs plus overhead, not the hourly wage. In New York that difference is substantial and leaving it out understates the case considerably.

Three things that get counted wrongly:

Hours saved that are not actually saved. If automation removes six hours a week from a role and nothing changes about what that person does, the business has not saved money. It has created capacity. Capacity is worth something, but it is only worth money if it is redeployed to work that generates revenue or avoids a hire. Say which one it is in the business case.

Running cost treated as zero. Every automation carries hosting, support, monitoring and occasional fixes. A business case that shows no ongoing cost has not been finished.

Errors ignored because they are hard to count. They are usually the biggest number in the case. A credit note issued because an order was keyed wrong, a duplicate payment, a missed renewal, a compliance finding. These have real costs and most businesses have never totalled them.

On payback period. Most single-process automations should pay back within twelve months. If a business case only works over a three-year horizon, the process chosen is probably the wrong one to start with.

Every automation programme reaches this decision, usually more than once.

The question is not which approach is better. It is whether the process is one you want to be the same as everyone else's, or one that is part of why customers choose you. Standardise the first. Build the second.

Most businesses end up with both. A packaged ERP system or CRM system handles the standard work, and custom business applications handle the parts that make the business different. The integration between them is where most of the value is created, and it is also where most programmes underestimate the work.

One caution on licence maths. Compare over five years, not one. Per-user licensing looks inexpensive at twenty users and looks very different at two hundred. Model the cost at the headcount you expect to have, not the one you have now.

Five reasons, in the order we see them.

• The process was broken before it was automated. Automating a bad process makes it produce bad output faster and removes the human judgement that was quietly compensating for the flaws. Fix the process first, then automate it.
• Nobody measured the baseline. The most common cause of a failed automation programme is not technical. It is that nobody measured the process before it was automated, so nobody can say whether it improved. The programme then gets cancelled at the first budget review because it cannot defend itself.
• The hardest process went first. Ambitious first projects take longer, cost more and deliver later, which is exactly the profile that loses executive support before the second project starts.
• No owner after launch. Automations need someone whose job includes them. Rules change, systems update, edge cases appear. An automation with no owner degrades quietly until somebody notices it has been producing wrong output for months.
• It was run as an IT project. Automation changes how people work. The people who do the work need to be involved in designing the replacement, not informed once it is built. Programmes run entirely from IT hit resistance that has nothing to do with the technology.

Firms presenting themselves as a business automation company in New York, or as an automation agency in New York, fall into three groups. They are not interchangeable, and the difference matters more than price.

Connector specialists wire existing tools together. Fast and inexpensive when the tools are mainstream and the volume is modest. Limited when they are not.

Software resellers implement a specific product. Strong on that product, and structurally unable to tell you it is the wrong choice, because their revenue depends on the licence.

Custom builders develop systems to fit the process. More expensive up front, appropriate when the process is genuinely yours.

GO-Globe is in the third group and integrates the first where it fits. We do not resell licences, which means we have no financial reason to recommend one platform over another.

Six questions that separate a business automation company quickly:

• Will you tell me not to automate something? A firm that has never talked a client out of a project is selling, not advising.
• Do you start with an assessment or with a solution? If a proposal arrives before anyone has watched the process being done, it is a product pitch.
• Will you commit to a baseline measurement? Anyone confident in the outcome will agree to be measured against numbers taken before the work starts.
• Who owns this after launch, and what does that cost? Get it in writing at the start.
• Can you show me a business case rather than a feature list? Features describe what the software does. A business case says what changes and what it is worth.
• Do you earn commission on any software you recommend? Not disqualifying, but you should know before you weigh the advice.