What Actually Happens When We Audit Your Operations

What does a digital transformation audit actually involve?

Most owners expect a slide deck. A consultant walks in, asks what modules you want, nods, and comes back two weeks later with a proposal for an ERP or a custom app. That is not an audit. That is a sales pitch wearing an audit's clothes.

A real audit does not start with software at all. It starts with picking one process that everyone in the business already complains about, and following it, step by step, with the people who actually do the work. Not the people who describe the work in a meeting room.

The goal is narrow on purpose: understand how one decision actually gets made today, including all the informal steps nobody puts in the SOP. Once you can see that clearly, you know whether the fix is a system, a redesign, or just moving one approval from one person's desk to another's.

What happens on day one, before anything is documented?

On day one, we watch. We do not open a laptop and we do not ask "what are your requirements." We pick a process, usually the one that comes up first when we ask the owner "what wastes the most of your time every week," and we sit with the people who run it.

For a manufacturer, that is often the purchase order cycle: a store executive raises an indent, it needs approval, a vendor quote comes in, someone checks stock, someone checks budget, and eventually material arrives or it doesn't. For a trading business it might be the credit approval on a new order. For a service business, it's often the handover between sales and delivery.

We are not looking for the process as written down. We are looking for the process as it happens, including the WhatsApp message that actually triggers the approval, the phone call that skips two steps in the SOP, and the spreadsheet that only one person knows how to update.

This is why an audit needs time on-site or on a live call with the actual team, not a questionnaire emailed to the ops head. A questionnaire gets you the process as the ops head believes it works. Shadowing gets you the process as it actually works, and those two are rarely the same.

How do we trace one decision end to end?

We pick a single, real instance of the decision, follow it from the moment it was triggered to the moment it was closed, and log every handoff, wait, and rework in between.

Here is a worked example from a typical mid-sized manufacturer. A purchase indent is raised by the stores team on a Monday morning because stock of a component has dropped below the reorder level.

• The indent sits in a physical register until the purchase executive checks it, which happens once a day, usually in the afternoon.
• The purchase executive sends a WhatsApp message to two vendors asking for quotes. One replies same day, the other takes two days.
• Once both quotes are in, the purchase executive needs the plant head's approval for anything above a certain value. The plant head is often on the shop floor and not reachable by email, so this waits until he is free or someone catches him in person.
• The plant head approves verbally. Nobody records the approval anywhere except a tick mark in the register.
• The purchase order is typed up and emailed to the vendor, sometimes a day after the verbal approval, because the purchase executive was pulled into something else.
• Material arrives seven to nine days after the original indent, depending on how many of these steps queued up behind other work that week.

None of this shows up in the org chart or the SOP document. It only shows up when you trace one real indent from start to finish and write down every wait, not just every step. That is the difference between an audit and a workflow diagram. A workflow diagram shows what should happen. A trace shows what does happen, and where the seven to nine days actually goes.

We've written separately about what firefighting actually costs you each month if you want to put a number against delays like this one. This audit step is where that number comes from, decision by decision, not as an estimate.

What does the audit produce at the end?

The audit ends with a written map of how the process actually runs today, where it stalls, who genuinely holds each decision, and a recommendation on what to do about it, which is sometimes "redesign this before you digitise it" and sometimes "don't touch this one, it isn't the bottleneck."

That last part matters more than owners expect. Every business has three or four processes that feel painful but aren't actually costing much, because the pain is felt daily even though the delay is small. And it usually has one or two processes that feel routine but are quietly costing weeks a month, because the delay is invisible until you trace it. An audit's job is to tell you which is which, so budget goes to the right one first.

The output is not a feature list. It is a decision map: who decides, what information they need to decide, where that information currently sits, and how long it takes to reach them. Software, if it's needed at all, gets designed against that map. Not the other way round.

	Checklist audit	Process trace audit
What it looks at	Systems, tools, tech maturity score	One real decision, followed step by step
Who it talks to	IT head, ops head, in a meeting room	The people who actually do the work
What it produces	A maturity score and a tool wishlist	A map of where the decision actually stalls
What it catches	Missing software	Missing information, unclear ownership, dead steps
What it misses	The informal workaround nobody documents	Almost nothing, because it starts from the workaround

How long does an audit take and what does it cost?

A proper audit on one core process usually takes between one and two weeks, most of it spent on-site or on live calls with the team doing the work, not in a report-writing phase. The output is a short, specific document, not a hundred-page assessment nobody reads.

We scope this by process, not by company size, because a 200-person manufacturer with one messy purchase cycle needs less time than a 40-person trading firm with three tangled approval chains across sales, credit and dispatch. The right question to ask any partner quoting you an audit is not "how much" but "how many processes will you actually trace, and with whom." If the answer is a workshop and a questionnaire, you are buying a checklist, not an audit.

What happens after the audit? Do we have to buy the software?

No. The audit stands on its own. You get the decision map and the recommendation whether or not you engage anyone to build anything.

Some recommendations don't need software at all. Moving an approval from a verbal tick-mark to a WhatsApp confirmation with a timestamp costs nothing and closes half the delay in the example above. Other recommendations do need a system, usually where the volume of decisions is too high for a manual fix to hold, or where the same information needs to reach three departments at once.

Either way, the decision to build comes after the map exists, not before. We understand how your business actually works first, then we design the system. If an audit ends with a proposal to automate the process exactly as it runs today, including its dead steps and its WhatsApp workarounds, that is the sign to ask more questions before signing anything.

See the full Digital Transformation for Growing Businesses hub for how this fits into a wider transformation engagement, or look at the digital transformation service directly if you already know which process you want traced first.

What to do before you call anyone

Pick the one process in your business that everyone complains about but nobody has actually timed end to end. Write down, from memory, how long you think it takes from trigger to close. Then ask the person who does it daily the same question. If the two answers are far apart, that gap is exactly what an audit is for, and you now have the one process to bring to the first conversation.