Automation does not save unresolved processes

Unclear processes only become faster through automation

Automation speeds up the existing process. It does not resolve unclear rules, contradictory data, missing responsibilities, or undocumented exceptions.

A process can only be reliably automated when its purpose, inputs, decisions, handovers, exceptions, quality criteria, and responsibilities are sufficiently clarified. Technical implementation follows this clarification. It does not replace it.

Starting point

In February 2022, the typical automation wish of many small and medium-sized enterprises was not about autonomous AI agents. It was about much more down-to-earth issues:

• Form data should be automatically transferred to a CRM.
• An email sequence should start after a request.
• Tasks should be created depending on a status.
• Data from different systems should be merged.
• Reports should be updated automatically.
• Recurring approvals and reminders should generate less manual work.

The technical hurdle decreased. Numerous platforms promised to connect applications without deep programming. This shifted the bottleneck.

The question "Can this be technically connected?" was no longer the deciding factor. It became more important: "Is the process so clear from a business perspective that it should be reliably connected?"

Problems arose precisely there.

A form could automatically write a request into the CRM. However, it remained unclear which fields were mandatory, how duplicates were handled, when a request was considered qualified, and who followed up on missing information.

An email could be sent automatically. However, it remained unclear whether the message was suitable for every request, which exceptional cases required a different tone, and how contradictions between the website, sales, and actual performance were avoided.

Automation took work away. At the same time, it made it clear that a significant part of the previous process was not based on clear rules, but on tacit experiential knowledge.

What lies behind the problem

The visible process is not the actual process

Companies often describe a process in a few steps:

1. Request comes in.
2. Request is being checked.
3. Offer is created.
4. Customer receives feedback.

However, numerous decisions lie between these steps:

• Is the request complete?
• Does it fit the target audience?
• Which service is affected?
• Which documents are needed?
• Who can provide the technical assessment?
• What is the priority of the process?
• What is the deadline?
• What happens in case of queries?
• When does a request become an offer and when a rejection?

As long as these decisions only exist in people's heads, the process is not fully described. Automation can then either only connect superficial steps or it has to make assumptions that no one consciously decided on beforehand.

Exceptions are treated as malfunctions instead of part of the process

Many processes work under normal circumstances. Problems arise with variations:

• a mandatory field is missing,
• a data record already exists,
• two departments are affected,
• a customer uses an unclear designation,
• a deadline was missed,
• a system is not reachable,
• the responsible person is absent,
• a decision requires a higher approval.

These cases are not a rare technical malfunction if they occur regularly. They are part of the process.

Those who do not consider them before automation create two parallel worlds. The standard case runs automatically. Everything else lands in a manual intermediate space that is difficult to understand.

Bad data spreads faster

Automation can transfer information losslessly. It cannot create its technical quality retrospectively.

Inconsistent designations, missing mandatory fields, outdated contact details, or contradictory status values are not cleaned up by interfaces. They are transferred to other systems and become the basis for new steps there.

This increases the scope of an error.

An incorrect status can trigger an inappropriate email. A duplicate address can create two records. Inconsistent service descriptions can falsify reporting and responsibility.

The more systems are connected, the more important data rules become before the connection.

Responsibility is delegated to the system

A typical phrasing is: "Then it runs automatically."

This often does not describe who is responsible, but only that no human performs every step anymore.

It must still be clarified:

• Who owns the process?
• Who decides on rules?
• Who checks data quality?
• Who reacts to errors?
• Who is allowed to change the automation?
• Who recognizes that the process is no longer technically suitable?
• Who informs affected persons in case of an incident?

Automation reduces individual activities. It does not eliminate responsibility.

Speed is confused with impact

An automated process can be faster and still have a worse effect.

A response can be sent within seconds, but be poorly formulated. A lead can appear in the CRM immediately, but be misclassified. A report can be updated daily, but not support a relevant decision.

Time savings are just one possible effect. Further criteria are:

• Quality,
• error rate,
• Editability of exceptions,
• Traceability,
• Customer experience,
• Data protection,
• Maintenance effort,
• Vendor dependency,
• workload of the involved roles.

Automation only makes sense when the overall effect is better than the previous process.

Strategic Classification

Process modeling is not intended to transfer every detail into a complicated diagram. It creates a common, verifiable representation of the process.

The Business Process Model and Notation was developed precisely for this connection. It is intended to describe business processes in such a way that business managers, analysts, and technical implementers can understand the same structure.

For small and medium-sized enterprises, a reduced model is often sufficient. What matters are not all symbols of a standard, but the right questions:

1. What triggers the process?
2. What result should be produced?
3. What inputs are needed?
4. What decisions are made?
5. What rules apply?
6. Which roles are involved?
7. Which systems are used?
8. What exceptions occur?
9. How is quality checked?
10. How does the process end or escalate?

Only when these questions are sufficiently answered can it be decided which steps should be automated.

Automation is then not a layer on top of existing chaos. It becomes part of conscious process design.

Perspective from practice

In practice, a fully documented process is rarely the starting point. Usually, the following exist:

• individual checklists,
• Email templates,
• personal routines,
• Fields in CRM or project management,
• verbal agreements,
• Exceptions that only experienced people know.

Therefore, the first step should not be to model everything. A limited, recurring process with recognizable effort or error potential is more sensible.

Processes that are suitable:

• occur frequently,
• have a clear beginning and a clear result,
• contain several manual handovers,
• generate known errors or waiting times,
• have sufficiently stable rules,
• can be assessed technically by a responsible person.

Processes that depend heavily on individual negotiation, situational creativity, or constantly changing conditions are unsuitable. Automation can support individual auxiliary steps there, but cannot take over the entire process.

The cause-and-effect chain

The test framework for automation capability

1. Clarify purpose and result

The process requires an understandable purpose and a verifiable result.

Not sufficient:

Process requests faster.

Better:

Assign complete requests to the responsible specialist role within one working day and request missing information comprehensibly.

The more precise formulation makes visible which steps and quality criteria are relevant.

2. Capture process and decisions

The actual process is reconstructed with the people involved. Not only activities but also decision points and handovers are recorded.

Points where employees say are particularly important:

• "It depends."
• "Ms. X normally knows that."
• "In this case, we do it differently."
• "Sometimes something is missing there."
• „Then we'll check it manually briefly.“

These sentences mark process knowledge that must be clarified before automation.

3. Standardize data and terms

Inputs must be unambiguous enough for rules to take effect.

These include:

• Mandatory fields,
• allowed values,
• uniform naming,
• Duplicate rules,
• Data source with priority,
• Validity and timeliness,
• Permissions.

The effort for data clarification is often greater than the technical connection. However, it is the basis for reliable results.

4. Define exceptions and fallback paths

Automation does not require its own complex rule for every exception. However, it must recognize when the standard path cannot be safely continued.

Then the process will be:

• stopped,
• characterized,
• assigned to a role,
• provided with the relevant information,
• continue controlled after decision.

A clear fallback path is not a sign of weak automation. It is part of a robust system.

5. Define responsibility and right to change

Every automation requires at least:

• a subject matter process owner,
• a technical responsibility,
• a person or role for errors and exceptions,
• a rule for changes,
• documentation of the systems and accesses used.

Without this mapping, automation becomes an invisible dependency over time.

6. Measure impact before and after implementation

Before automation, a baseline is documented:

• Processing time,
• Waiting time,
• Errors,
• rework,
• Cancellations,
• manual handovers,
• Customer experience,
• maintenance effort.

After implementation, it is not only checked whether the technical process works. It is checked whether the process effect is actually better.

What companies should not do

Companies should not fully automate the most unclear and important process first. High importance increases the consequences of errors. Unclarity increases the probability that rules and exceptions are missing.

The selection based on technical simplicity alone is also problematic. An easily connectable step may generate little benefit and create additional dependencies.

Even an automation that only one person understands is not robust. It may work in the short term, but becomes a risk when changes, failures, or handovers occur.

Finally, companies should not remove manual work simply because it occurs repeatedly. Some manual steps fulfill an important control, relationship, or exception function. Your task must be understood before it is eliminated.

Consequences for companies

The economic benefit of automation does not arise from the largest possible number of automated steps.

It arises from:

• clearer processes,
• fewer avoidable handovers,
• better data,
• controlled exceptions,
• traceable responsibility,
• lower error and rework costs,
• faster processing where speed is actually relevant.

The most important automation step can therefore initially be a process decision.

In 2022, this foundation was already crucial. With the later use of generative AI, it became even more important because results are no longer generated solely by fixed rules, but partly by probabilistic models.

Subject-matter connection

Clarify processes before technical implementation

Structured process and automation consulting organizes purpose, workflow, data, exceptions, roles, and impact before systems are connected or new tools are introduced. SDC Discovery creates a common decision-making basis for this.

Check the automation capability of a process

Author

About Göke Frerichs

Göke Frerichs has been combining digital strategy, communication, technology, and implementation since 1999. As a digital strategist and Smart Digital Creative, he supports owner-managed B2B companies in developing clear and reliable digital systems from individual measures. His perspective is based on many years of consulting and implementation experience in the DACH region and North America.

More about Göke Frerichs