Most automation projects fail in the description, not in the build.<\/strong><\/p>\n Somebody describes the process. It gets built. Halfway through testing, three things emerge: an exception nobody mentioned, two people doing it differently, and a step that exists for a reason nobody can remember.<\/p>\n None of that is a technical problem.<\/strong> It is a mapping problem, and it is cheaper to solve before anything is built.<\/p>\n The single most useful piece of advice here.<\/strong><\/p>\n If you ask somebody how they do a task, you get the procedure<\/strong> \u2014 the tidy version, in the right order, without the parts they have stopped noticing.<\/p>\n If you watch, you get the process.<\/strong><\/p>\n What watching reveals that asking does not:<\/strong><\/p>\n The step done out of order because it is more convenient.<\/p>\n The check done from memory rather than the sheet.<\/p>\n The spreadsheet somebody keeps because the system does not do something.<\/p>\n The pause while they work out which of two things applies.<\/p>\n That last one is where the judgement is<\/strong>, and it is exactly what you need to identify.<\/p>\n If several people do the task, they are doing it differently.<\/strong><\/p>\n Not because anyone is wrong.<\/strong> Because the procedure left room, and each of them filled it differently.<\/p>\n Which means a decision before you automate:<\/strong> which way is right?<\/p>\n Sometimes both work and you pick one.<\/strong> Sometimes one is better and nobody had noticed. Sometimes the difference reveals a case the procedure never covered.<\/strong><\/p>\n Automating one person’s version and imposing it on everyone<\/strong> is how automation projects become unpopular.<\/p>\n FIGURE 1: WHAT MAPPING MUST FIND<\/p>\n The actual sequence<\/p>\n The exceptions<\/p>\n The judgement points<\/p>\n The disagreements<\/p>\n Four, and the third is the most productive.<\/strong><\/p>\n “Show me how you do this.”<\/strong> Then watch. Do not interrupt.<\/p>\n “What happens when it goes wrong?”<\/strong> The exceptions.<\/p>\n “What is annoying about this?”<\/strong> The best question available.<\/strong> People are honest about friction in a way they are not about compliance \u2014 and friction marks where the process is failing.<\/p>\n “When did this last surprise you?”<\/strong> Surfaces the rare case that would break an automation.<\/p>\n Avoid:<\/strong> “do you follow the procedure?” The answer is yes, and you have learned nothing.<\/p>\n Six things, per step.<\/strong><\/p>\n What happens.<\/strong> The action.<\/p>\n Who does it.<\/strong> By role.<\/p>\n What triggers it.<\/strong> What has to be true for this step to start.<\/p>\n What it needs.<\/strong> Which system, which document, which information.<\/p>\n How long it takes.<\/strong> For your baseline.<\/p>\n What can go wrong.<\/strong> And what happens then.<\/p>\n That last column is the valuable one.<\/strong> It is usually blank in existing documentation and it is where the automation will meet reality.<\/p>\n Mark every place where somebody decides rather than follows.<\/strong><\/p>\n How to spot them:<\/strong> the person pauses, checks something, or says “it depends”.<\/p>\n Then ask what it depends on.<\/strong><\/p>\n Two possible answers:<\/strong><\/p>\n A rule they can state.<\/strong> “If it is over five thousand, it goes to the manager.” That is automatable.<\/strong><\/p>\n Something they cannot fully articulate.<\/strong> “I look at it and it usually seems fine, but sometimes something feels off.” That is judgement, and it should stay with a person.<\/strong><\/p>\n The mistake is encoding the second kind as rules.<\/strong> It works until reality produces a case the rules do not cover \u2014 and it will.<\/p>\n FIGURE 2: TWO KINDS OF DECISION<\/p>\n Automatable<\/p>\n Keep with a person<\/p>\n While you have the process written down, use the opportunity.<\/strong><\/p>\n Per step, three questions:<\/strong><\/p>\n Why does this exist?<\/strong> If nobody knows, investigate before automating.<\/p>\n Who uses the output?<\/strong> A report nobody reads should be deleted.<\/p>\n What would break if we stopped?<\/strong> Sometimes nothing.<\/p>\n This is the cheapest improvement available.<\/strong> Removing three of eight steps saves more than automating all eight, and costs nothing to maintain.<\/p>\n Do it before choosing a tool<\/strong>, not after.<\/p>\n While you are watching, count.<\/strong><\/p>\n How long does one run take?<\/strong><\/p>\n How many runs per week?<\/strong><\/p>\n How often does something go wrong?<\/strong><\/p>\n How long from trigger to completion?<\/strong><\/p>\n Without these you cannot say afterwards whether it helped<\/strong> \u2014 and “it feels faster” is not a result you can take to anyone.<\/p>\n Show the map to the people who do the work.<\/strong><\/p>\n Two things happen:<\/strong><\/p>\n They correct it.<\/strong> You missed something, or misunderstood a step.<\/p>\n They tell you about a case you never saw.<\/strong> The one that happens twice a year and would have broken everything.<\/p>\n Then get the decision-maker to agree it<\/strong> \u2014 particularly on the points where people were doing it differently.<\/p>\n A map nobody has agreed is a map of one person’s version.<\/strong><\/p>\n FIGURE 3: THE MAPPING SEQUENCE<\/p>\n Watch it done<\/p>\n Record the exceptions<\/p>\n Mark the judgement points<\/p>\n Agree it<\/p>\n Less than people fear and more than they budget.<\/strong><\/p>\n A single straightforward process:<\/strong> a day or two, including watching and writing up.<\/p>\n A process crossing departments:<\/strong> a week, mostly because of scheduling and disagreement.<\/p>\n Compared to a build that starts on a wrong description<\/strong>, either is cheap.<\/p>\n One page per process, showing:<\/strong><\/p>\n The steps in order, with who does each.<\/p>\n The exceptions, and what happens for each.<\/p>\n The judgement points, marked.<\/p>\n The systems touched.<\/p>\n The baseline numbers.<\/p>\n Not a formal notation.<\/strong> Something a colleague can read and recognise.<\/p>\n If a person who does the work reads it and says “yes, that is it” \u2014 it is good enough.<\/strong><\/p>\n Watch, do not ask.<\/strong> The procedure is the tidy version; the process is what happens.<\/p>\n Watch more than one person<\/strong>, because they are doing it differently and you need to decide which way is right.<\/p>\n Ask what is annoying about it.<\/strong> The most productive question available.<\/p>\n Mark the judgement points<\/strong> and leave those with people. Encoding judgement as rules works until it does not.<\/p>\n And question every step while you are there.<\/strong> Removing a step beats automating it.<\/p>\n Not sure your documented process matches what actually happens?<\/p>\n Get in touch. We start every automation by watching the work \u2014 it is the cheapest part of the project and it decides the rest.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" Why this comes first Most automation projects fail in the description, not in the build. Somebody describes the process. It gets built. Halfway through testing, three things emerge: an exception nobody mentioned, two people doing it differently, and a step that exists for a reason nobody can remember. None of that is a technical problem. […]<\/p>\n","protected":false},"author":3,"featured_media":9494,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[27],"tags":[],"class_list":["post-9493","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-automation"],"yoast_head":"\nWatch, do not ask<\/h2>\n
Watch more than one person<\/h2>\n
\n
\n
\n
\n
The questions that work<\/h2>\n
What to write down<\/h2>\n
Finding the judgement points<\/h2>\n
\n
\n
Question every step<\/h2>\n
Measure the baseline<\/h2>\n
Get it agreed<\/h2>\n
\n
\n
\n
\n
How long it takes<\/h2>\n
What good output looks like<\/h2>\n
The short version<\/h2>\n