Five technical questions that decide readiness

The first question is whether the process follows clear rules. If a person can write down exactly how a decision is made, a system can follow it. If the decision relies on judgement and context, automation will either get it wrong or need a person to check every case, which removes most of the benefit.

The second is the quality of the inputs. Structured data such as a form, a database record or a standard file is easy to work with. Unstructured input such as free text emails, scanned documents and photographs is harder. Modern AI based tools can read many of these, which widens what is possible, but they still need a checking step and a measured error rate before you rely on them for anything that affects money or customers.

The third is how the automation connects to the systems involved. Some systems offer an API, which is a stable, documented way for one piece of software to talk to another. Others offer no such connection, and the only option is software that operates the screen the way a person would, clicking through fields and buttons. That approach is often called robotic process automation. It can work, but it is fragile, because a small change to a screen layout after a software update can stop it working without warning.

The fourth is the exception rate. If most cases follow the standard path and a few do not, automation handles the majority and people handle the rest. If a large share of cases are exceptions, you end up with a system that still needs constant human attention, and often more coordination than before.

The fifth is stability. A process that is about to change, because of a system replacement, a reorganisation or new regulation, is not ready. Automating it means paying to build something that will have to be rebuilt.

The business side of the same decision

Technical readiness is only half the picture. The business case needs three inputs that are often left out. The first is volume, meaning how many times the process runs and how long each run takes now. A process that runs twenty times a year is rarely worth automating however tedious it is. The second is the cost of error, since automating something where mistakes are expensive can be more valuable than automating something that is merely slow. The third is the ongoing cost.

Every automation needs an owner, monitoring and maintenance. Somebody must know when it fails, and there must be a manual fallback for the day it does. If nobody has been assigned that responsibility, the automation will quietly break and the team will quietly return to doing the work by hand, which is how many automation projects end up abandoned.

A simple scoring approach

We score each candidate process from one to five on volume, clarity of rules, quality of inputs, stability of the systems involved, exception rate and cost of error. The scores are not a formula that gives a final answer. They make the discussion concrete. A process with high volume, clear rules and clean inputs is a strong candidate. A process with high volume but a high exception rate probably needs to be redesigned first. A process with low scores across the board is best left manual, and it is useful to record that as a deliberate decision.

Two illustrative cases

Consider two processes that both look like automation candidates. The first is entering supplier invoices into an accounting system. If most invoices arrive in a small number of standard formats, the fields are predictable and the rules for coding them are clear, this scores well. The exceptions, such as invoices with no purchase order or unusual tax treatment, can be routed to a person, and the volume makes the saving real.

The second is triaging customer complaints. It runs often and feels repetitive, but every case depends on context, the wording is unstructured and the right response varies with the customer’s history. It scores poorly on rule clarity and input quality. A better first step is to standardise how complaints are logged and categorised, which improves the data and may allow limited automation later.

Both examples are common patterns rather than specific client cases, and they show why the scoring is more useful than instinct. The second process is more annoying to staff, but the first is the better investment.

What to do with the processes that score low

A low score does not mean the process is a lost cause. It usually points to a specific piece of work. Where rules are unclear, the answer is to agree and document them. Where inputs are messy, the answer is to standardise how information is captured at the start. Where the process has too many exceptions, the answer is to understand why they occur and remove the causes. Where staff do the work differently from one another, an SOP that sets out the agreed way often delivers the largest single gain, and it is a prerequisite for automation later.

Fix the process before you automate it

One pattern is consistent. Processes that have been mapped and simplified automate well, and processes that have not been mapped tend to carry their confusion into the automation. Steps that only existed to work around an old limitation get automated along with everything else. That is why we start with the current state map and remove unnecessary steps before deciding what to automate.

How GroowFuse does this

We run automation readiness assessments as part of our digital transformation and process improvement work. We map the processes, score them against these criteria, and deliver a ranked roadmap that shows what to automate now, what to redesign first and what to leave alone, with the reasoning written down. We are vendor agnostic, so tooling recommendations follow from the requirements and not from a preferred supplier.

If you are weighing up where automation would actually pay back in your business, a free 30 minute consultation through groowfuse.com is a good place to start.

Mapping the current state means documenting the second one. It sounds like an admin exercise. In practice it is the most valuable piece of analysis in the whole project, because everything that follows, including requirements, automation choices and software selection, depends on it.

Why the official process is never the real one

Processes drift. A step is added after a mistake and never removed. A spreadsheet appears because the system does not quite do what someone needs. One person learns a shortcut and everyone nearby copies it. Exceptions that were rare become routine, and the handling of them lives in people’s heads. None of this is careless. It is what happens when a business grows faster than its documentation.

The result is that if you ask three people how an order is processed you often get three different answers, each one correct for that person. Only by following real work from beginning to end do you see the whole thing.

What a useful current state map captures

A good map shows who does each step, what triggers it, which system or document they use, what information goes in and out, where decisions are made, and where work is handed from one person or team to another. It also shows exceptions, meaning what happens when something is missing, wrong or late. Most of the hidden cost lives in the exception paths, so a map that only shows the happy path is not much use.

Swimlane diagrams are the usual format, with one lane for each person or team. BPMN 2.0, which is now an international standard published as ISO/IEC 19510, gives a shared set of symbols for events, tasks and decisions. You do not need the full notation to get value, but using consistent symbols means that a business analyst, a developer and a vendor can all read the same diagram without a translator.

Touch time and wait time

The most useful measurement in current state mapping is the difference between touch time and elapsed time. Touch time is how long someone actually works on an item. Elapsed time is how long the item takes to get through the process from start to finish. In many business processes the gap is large, because items spend most of their life waiting in an inbox, a queue or a folder for someone to pick them up.

Consider an illustrative example. A purchase approval takes six minutes of real work, but it waits in the approver’s inbox for two days on average. If someone proposes automating the six minutes, they are working on the wrong problem. The delay is the queue, and it will not shrink until the business changes who approves, when, or what needs approval at all.

Measuring the two separately changes the conversation. It moves the discussion from working faster to waiting less, and it shows where a change in the process will pay back before any money is spent on technology.

Handoffs and rework loops

Every handoff is a place where information can be lost, delayed or re-entered. Mapping the current state makes these visible. Typical findings include the same data entered in two systems, a form that is sent back three times for the same missing field, and a step where someone exports a report, edits it by hand and sends it on. Each of these is a candidate for redesign, and none of them appears on an org chart.

How to gather the map

Do not ask people how the process should work. Ask them to walk you through the last three real cases from start to finish. Ask what they did first, what they opened, who they asked, and what they did when something did not match. Follow one real item, such as a single order or invoice, through every team that touches it. Note each moment someone opens a spreadsheet, sends a message to check something, or says it depends.

Then play the map back to the people who do the work, not only to their managers. Corrections at that stage are the most valuable ones.

An illustration of what the map turns up

A common pattern in order processing shows why this matters. The official process says an order is confirmed once payment clears. In practice, one person on the team checks a separate stock spreadsheet before confirming anything, because the system’s stock figures are not fully trusted. That step is not written down anywhere. If a new system is specified from the official process, it will not include a stock check, and the business will discover the gap when orders are confirmed for items that are not available.

A current state map would have caught it in the first week, because the person doing the check would have mentioned opening the spreadsheet as soon as they were asked to walk through a real order.

Common mistakes when mapping

Maps go wrong in predictable ways. They are drawn in a meeting room without watching the work, so they show the ideal path. They go into too much detail on one step and skip the handoffs entirely. They are produced by one person and never reviewed by the team, so errors survive. And they record steps but not time, so the map cannot show where the delay is. Each of these is avoidable with a clear scope, a set of real cases to follow and a review with the people who do the work.

What the map is used for

A current state map has three uses. It shows where the waste is, so you can decide what to fix, what to automate and what to leave alone. It becomes the input for requirements, because you cannot specify a new system without knowing what the old one really does. And it is the baseline that lets you prove an improvement. Without a measured starting point, any claim about time saved or errors reduced is an estimate.

How GroowFuse does this

Mapping current state processes is a core part of our process improvement and business analysis work. We follow real cases, document the process as it runs including the exceptions, measure touch time against elapsed time, and hand you a clear set of maps and findings along with a prioritised list of changes. You do not need a business analyst on the payroll to get it done.

If you would like a quick view of where your own processes stand before committing to anything, the Process Health Checker on groowfuse.com is a good starting point.

This article explains how requirements are actually structured, what makes one testable, and how to build a set that a vendor, a developer or an internal team can be held to. It is the core of the requirements gathering work we do for clients, and it is more technical than it looks.

Why requirements fail on the first read

A requirements document is a promise about the future written in the present tense. When a requirement is vague, every reader fills the gap with their own assumptions. The business assumes one thing. The vendor assumes the cheapest reasonable reading. The developer assumes a third. Nobody notices until acceptance testing, which is the most expensive point to find out.

At that stage the conversation stops being technical and becomes commercial. The vendor says what was delivered matches what was written. The business says it is obviously not what was meant. Both are right, and the only fix is a change request priced at the vendor’s rate. A few extra days of careful writing at the start remove most of that argument.

Four kinds of requirement, and why mixing them causes trouble

Business analysts usually separate requirements into layers, and the classification used in the BABOK Guide from the IIBA is a helpful model. Business requirements state why the organisation is doing the work, for example reducing order errors or shortening the monthly close. Stakeholder requirements describe what particular groups need, such as a warehouse lead who must see the picking queue for the day. Solution requirements describe what the system must do, which are the functional requirements, and how well it must do it, which are the non functional requirements. Transition requirements cover what it takes to get from the old way to the new one, including data migration, training and cutover.

Trouble starts when these layers sit in one flat list. A business goal appears next to a button colour, and a data migration task is written as if it were a feature. Reviewers cannot tell what is essential, and nobody can trace a small feature back to the business reason it exists. Keeping the layers separate makes each one easier to write, review and test.

Ask for the need, not the solution

Requirements often arrive as solutions. Someone asks for a dashboard. That sounds like a requirement, but it is a proposed answer to a question that has not been stated. Before writing anything down, ask what decision the dashboard will support, who makes that decision, how often, and what they use today to make it. The answer may be a dashboard. It may equally be a daily email listing the ten orders that are late, which costs a fraction as much to build.

A requirement written as a solution locks the project into one answer and hides the real need. The practical technique is to keep asking why until you reach an outcome someone in the business can measure, and to ask the people who do the work rather than only the manager sponsoring the project. Watching someone perform the task for an hour tells you more than a workshop of ten people describing it.

How to make a requirement testable

A testable requirement has an actor, an action, a condition and a measurable result. Compare two versions of the same requirement. The first says search should be fast. The second says a customer service agent can find any order from the last 24 months by order number or customer email, and the result appears within five seconds with 30 people using the system at the same time.

The second version can be estimated by a vendor, tested by a tester and signed off by the business. The first can only be argued about. The IIBA lists acceptance and evaluation criteria as a formal business analysis technique for exactly this reason: they define what done looks like before anyone starts building.

A simple format for acceptance criteria is given, when, then. Given an order exists in the system, when an agent searches by customer email, then the order appears in the results with its status and dispatch date. If you cannot describe how a requirement would be tested, you do not understand it well enough yet, and writing the test is often the quickest way to find out what is missing.

Non functional requirements are where projects go wrong quietly

Functional requirements describe features and are usually well covered. Non functional requirements describe qualities such as performance, availability, security, audit trails, data retention and accessibility. They are the ones most often left out, and they are the ones that cause surprises after go live.

A system that works well in a demo with five users can slow badly with forty. A process that nobody thought to log has no audit trail when someone asks who approved a change. For businesses in Ireland and the EU that handle personal data, GDPR obligations such as retention periods, access requests and deletion should be written as requirements, not left to whatever the vendor’s default settings happen to be.

Integration deserves particular care. For every connection to another system, record which system is the source of truth, which direction the data flows, how often it moves, what happens when a transfer fails, and who is told. Integrations that sound simple in a meeting are often where a project doubles in size, because each of those questions has an answer somebody must build.

A worked example: one requirement, from vague to testable

Take a request that appears in many projects: the system should show order status. Start by asking who needs it and why. Suppose the answer is that customer service agents currently phone the warehouse to ask where an order is, and the business wants to stop that. The business objective is now clear: cut the number of internal status calls.

The stakeholder requirement follows: an agent needs to see the current status of any order while speaking to a customer. The solution requirement then becomes specific. The system shows one of five agreed statuses for each order, updated within two minutes of the warehouse changing it, and an agent can see the time of the last change. The non functional requirement adds that the status view loads within three seconds. The transition requirement notes that the five statuses must be agreed with the warehouse before build, and that agents need a short training session before go live.

Each of these can be tested, each traces back to the reason for doing the work, and none of them says how it should be built. That is the standard to aim for.

Common mistakes in requirements documents

There are a handful of problems we see repeatedly. Two teams give requirements that contradict each other, and nobody notices because they were gathered in separate meetings. Requirements describe how something should be built rather than what it must achieve, which limits the vendor’s options and often raises the cost. Requirements have no named owner, so nobody can answer questions about them later. The document is reviewed by managers but never by the people who will use the system. And key assumptions, such as which systems hold the master customer record, are left unwritten because everyone in the room thought they were obvious.

Most of these are easy to catch with a structured review, and they are far cheaper to fix on paper than in a half built system.

Traceability: every requirement needs a reason

A traceability record links each requirement to the business objective it serves, the person who asked for it, its priority and the test that proves it. At the size of a typical mid sized business this can be a single spreadsheet. The value is what it lets you do later.

When scope pressure arrives, you can see which business objective is at risk if something is cut. When someone proposes a new feature, you can ask which objective it serves. You can also spot requirements with no reason attached, which are candidates for removal, and objectives with no requirements against them, which usually mean something has been missed.

Prioritise honestly

The MoSCoW method sorts requirements into must have, should have, could have and will not have this time. It works only if the musts are genuinely limited. A useful test is to ask whether the business could still operate on go live day if this were missing. If the answer is yes, it is not a must.

Record the will not haves as carefully as the rest. Writing down what was deliberately left out prevents the argument three months later about why something was not delivered, and it gives you a ready made list for the next phase.

What skipping this costs

The costs are familiar. Change requests are priced when the business has the least bargaining power. Development is reworked after features are built on a wrong assumption. Go live slips while a dispute over acceptance is settled. Staff adopt spreadsheets beside the new system because it does not quite fit, and the business pays for the tool and the workaround. It is widely accepted in software delivery that a defect costs more to fix the later it is found, and requirements defects are found later than most.

There is also a procurement cost. Without clear requirements you cannot compare vendor proposals fairly, so the decision drifts toward price and the quality of the demo. That is a poor basis for a contract that may run for years.

A practical method you can apply

1. State the business objective in one sentence, with a measure attached, for example reduce order errors from one in twenty to one in forty.
2. Interview the people who do the work, and watch them do it. Include the sponsor, but do not stop there.
3. Separate needs from proposed solutions, and keep asking why until the need can be measured.
4. Write each requirement with acceptance criteria that name an actor, an action, a condition and a result.
5. Capture non functional, integration and transition requirements explicitly, even where the answer is that none apply.
6. Trace each requirement to an objective and a source, then prioritise using MoSCoW.
7. Review the pack with both business and technical people, resolve conflicts between teams, and get a named sign off.

Where GroowFuse fits

We run requirements gathering as a defined piece of work. We interview the right people, map the current process, write requirements with acceptance criteria, resolve the conflicts between teams that always surface, and deliver a signed off requirements pack with traceability that you can hand to any vendor or developer. It is work that needs experience, and for many businesses with 5 to 100 employees it does not justify a permanent hire. That is the gap we fill.

If you have a system, a replacement or a project waiting on requirements nobody has had time to pin down, a free 30 minute consultation is a good way to scope it. You can book one through groowfuse.com.