Defining a process before automating it doesn't require a six-month consulting project. It requires two weeks, four working sessions, and five concrete deliverables. What it doesn't require is the common practice: asking someone to write the procedure, because what you end up with is the ideal version of the process, not the one that actually happens.
This article describes the method we applied, along with its components, so that it can be executed with or without external assistance.
When asked to describe their process, someone describes the main path in its correct version. They omit exceptions because they seem anecdotal, they omit shortcuts because they're unsure if they're acceptable, and they omit unwritten rules because they're self-evident.
The three omissions are exactly what breaks down automation in production.
The question that does work is a different one: «"Tell me about the last case that gave you trouble."». It produces concrete narrative instead of abstract description, and in the narrative, exceptions, shortcuts, and tacit rules appear without needing to ask about them.
Deliverable | What it contains | What is it for? |
|---|---|---|
Decision map | What is decided, by whom, and with what information? | Foundation of any automation |
Data inventory | What data, in what system, who owns it | Reveal contradictions before coding |
Catalog of exceptions | Cases that don't fit and how they are resolved today | Define what is automated and what scales |
Unwritten rules | Criteria that only existed in someone's head | It reduces dependence on people |
Baseline | Cycle time, hands, corrections, cost per case | It allows demonstrating improvement after |
All five of them have one valuable property: They produce value even if the automation project is not carried out.. The fourth one, in particular, is usually the one that has the most immediate impact, because it turns a person's tacit knowledge into an asset of the organization.
Days 1-2: the baseline. Before speaking to anyone, take measurements. How many cases come in, how long each one takes from start to finish—including waiting times, not just active processing—and how many require subsequent correction. Without this data, any future improvements will be questionable.
Days 3-5: the talks. Three or four people carry out the process separately, each asking about problematic cases. Working separately is important: in a group, the official version prevails. This process generates the decision map and most of the exception catalog.
Days 6-7: the data. For each map decision, what information is needed, where does it live, and who is responsible for it? This is where contradictions between systems appear, and it's important to document them, even if they're uncomfortable: each one represents an outstanding decision that someone will have to make.
Days 8-9: the rules. Write down the criteria that emerged in the conversations and return them to those who formulated them for confirmation or correction. This is the step that generates the most resistance and the one that produces the most value.
Day 10: the qualifiers. With all of the above in mind, decide which part of the process can be automated, which part should be prepared for human decision-making, and which part should remain untouched. Only then should you evaluate the technology.
Group interviews. The most senior person describes the official process, and the others nod in agreement. The very information they were looking for is lost.
Ask those in charge instead of the person carrying it out. The person in charge knows the design; the person who executes knows the reality. Both are necessary, and in that reverse order to the usual one.
Document the ideal process. The temptation to fix things while documenting is strong and ruins the work. First, you record what happens; redesign comes later and is a separate phase.
With these five deliverables on the table, subsequent decisions cease to be mere opinion-based discussions:
That is why in TCG-SAF™ the first two stages—Vision and Domains—always precede any construction decision. This is not methodological formality: it is that without these five documents, decisions are still made, only without information and by the wrong person.
There's a simple way to tell if the job is done right: Give the documentation to someone outside the process and ask them to solve five real cases..
If you succeed, the process is defined and can be automated. If you have to ask, what's missing from your question is exactly what was missing from the documentation—and what would have failed in production three months later.
With five deliverables: a decision map, a data inventory including the system and its owner, an exception catalog, unwritten business rules, and a performance baseline. These are obtained in about ten days of work with four sessions and do not require a lengthy consulting project.
Because people describe the main path in its ideal version: they omit exceptions because they seem anecdotal, shortcuts out of prudence, and unwritten rules because they are obvious. These three omissions are precisely what breaks down automation in production.
«"Tell me about the last case that gave you trouble." It produces a concrete narrative instead of an abstract description, and in that narrative, the exceptions, shortcuts, and tacit criteria appear without needing to be asked about them.
Three or four people carry out the process, separately and not as a group, because in a group the official version prevails. Those in charge know the design, and those who execute it know the reality; both are necessary, starting with the latter.
Three: conduct group interviews, ask only those in charge instead of those who carry out the work, and document the ideal process instead of the actual one. The temptation to fix things while documenting is strong and destroys the value of the work: first, record what happens; redesign is a later phase.
Give it to someone outside the process and ask them to solve five real-world cases. If they succeed, the process is defined; if they have to ask questions, what's missing from their question is exactly what would have failed in production.
Do you want a clear picture of your process before investing in technology? In two weeks we deliver the decisions, the data, the exceptions, the unwritten rules, and the baseline. It works whether you automate or not. Let's talk → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
