People expect the difficulty to be in the software. It is not.<\/p>\n
The difficulty is describing the process precisely enough that a robot can follow it<\/strong> \u2014 including every exception nobody wrote down.<\/p>\n A person doing a task handles odd cases automatically. The file that arrives late. The record with a blank field. The month the archive contained two files instead of one.<\/p>\n None of that is in the written procedure<\/strong>, because the person absorbed it and stopped noticing.<\/p>\n Most of the project is discovering those cases.<\/strong><\/p>\n Sit with the person who does it. Watch several times.<\/p>\n Write down:<\/strong><\/p>\n The exceptions are the valuable part.<\/strong> Ask directly: “when does this not go smoothly?” and “what was the last thing that surprised you?”<\/p>\n Watch more than one person if several do it.<\/strong> They will be doing it differently, and you need to decide which way is correct before automating either.<\/p>\n FIGURE 1: WHERE THE EFFORT GOES<\/p>\n Documenting the process<\/p>\n Building it<\/p>\n Testing on real data<\/p>\n Maintaining it<\/p>\n Not the whole process, usually.<\/strong><\/p>\n A process might be twelve steps, of which nine are mechanical and three need judgement.<\/p>\n Automate the nine. Leave the three.<\/strong> The robot prepares; a person decides.<\/p>\n That is often a better outcome than full automation<\/strong> \u2014 faster to build, more reliable, and judgement stays where it belongs.<\/p>\n And check each step for a better method.<\/strong> Does this step need a browser, or is there a direct URL? Does this need screen automation, or is there an API? Every step you can do without a screen is a step that will not break when a layout changes.<\/strong><\/p>\n Activities on a canvas, in sequence.<\/p>\n Two practices that matter more than any technique:<\/strong><\/p>\n Name things clearly.<\/strong> Not “Click1” or “HTTP Request3”. “Download the daily archive”. “Find the newest CSV”. Somebody else has to read this.<\/p>\n Log at each meaningful step.<\/strong> When it fails at three in the morning, the log is what tells you where.<\/p>\n And structure it in stages<\/strong> \u2014 download, extract, validate, send \u2014 rather than one long sequence. Each stage can then have its own error handling, and a failure tells you which stage rather than just that something went wrong.<\/p>\n Only relevant where screen automation is genuinely required.<\/strong><\/p>\n A selector is how the automation finds an element on screen.<\/strong> It is where RPA breaks.<\/p>\n Fragile:<\/strong> relies on position, or on a value that changes each session \u2014 “the third button”, or a generated ID.<\/p>\n Stable:<\/strong> uses something meaningful and unchanging \u2014 a name, an automation ID, a label.<\/p>\n Spend time on selectors.<\/strong> It is the difference between surviving an application update and breaking the following week.<\/p>\n And accept that some will break anyway.<\/strong> A vendor redesign can change everything. That is the nature of the technique, which is the argument for using as little of it as possible.<\/p>\n The part that separates a working automation from a liability.<\/strong><\/p>\n Wrap each stage in try-catch<\/strong>, so you know which one failed.<\/p>\n Log the error message and the stack trace.<\/strong> For an unattended job, that is all anyone will have.<\/p>\n Re-throw the error<\/strong> so the job is marked failed. This is the one people get wrong.<\/strong> An automation that catches an error and exits successfully records a false success \u2014 nobody is alerted, and the work silently did not happen.<\/p>\n Decide what happens next.<\/strong> Skip this item and continue? Stop the whole run? It depends on the process, so decide deliberately rather than accepting a default.<\/p>\n Notify a person.<\/strong> Not a log file nobody opens.<\/p>\n FIGURE 2: ERROR HANDLING DONE RIGHT<\/p>\n Right<\/p>\n Wrong<\/p>\n Not with clean data. With real data, including the awkward cases.<\/strong><\/p>\n Test these specifically:<\/strong><\/p>\n Then run it alongside the manual process<\/strong> for a couple of weeks and compare.<\/p>\n This is the step shortened when a project runs late<\/strong>, and it is the one that should not be.<\/p>\n Attended first<\/strong>, if possible. A person triggers it and sees the result.<\/p>\n Move to unattended<\/strong> once it has proven stable, and only with monitoring in place.<\/p>\n Hand over properly:<\/strong><\/p>\n Without that handover you have built a black box<\/strong> that works until it does not, and then nobody can fix it.<\/p>\n FIGURE 3: THE SEQUENCE<\/p>\n Document<\/p>\n Build in stages<\/p>\n Test the failures<\/p>\n Hand over<\/p>\n Automating an undocumented process.<\/strong> Halfway through, you discover it is not what anyone described.<\/p>\n Automating a bad process.<\/strong> It runs faster in the same wrong direction. Fix the process first.<\/p>\n Swallowing errors.<\/strong> Silent failure for weeks.<\/p>\n No owner.<\/strong> Something changes, it breaks, nobody fixes it.<\/p>\n No baseline.<\/strong> Nobody measured the manual version, so nobody can say whether it helped.<\/p>\n Before you start, record:<\/p>\n Time per run.<\/strong> How long the manual version takes.<\/p>\n Frequency.<\/strong> How many times a month.<\/p>\n Error rate.<\/strong> How often the manual process goes wrong.<\/p>\n Afterwards, compare \u2014 including the time spent maintaining the automation.<\/strong> That last part is what people leave out, and it is the difference between a real saving and an apparent one.<\/p>\n Building is the easy part. Documenting the process, including the exceptions, is where the work is.<\/strong><\/p>\n Automate the mechanical steps and leave the judgement.<\/strong> Use the least fragile method available for each step.<\/p>\n Structure it in stages with error handling per stage, and re-throw so failures are visible.<\/strong><\/p>\n And give it an owner before it goes live. An automation nobody maintains breaks quietly.<\/p>\n Thinking about automating a manual process?<\/p>\n Get in touch. We start by watching it done \u2014 the exceptions nobody documented decide whether it can be automated at all.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" The work is not the building People expect the difficulty to be in the software. It is not. The difficulty is describing the process precisely enough that a robot can follow it \u2014 including every exception nobody wrote down. A person doing a task handles odd cases automatically. The file that arrives late. The record […]<\/p>\n","protected":false},"author":3,"featured_media":9310,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-9309","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-robotic-process-automation"],"yoast_head":"\nStep 1 \u2014 Watch it being done<\/h2>\n
\n
\n
\n
\n
\n
Step 2 \u2014 Decide what to automate<\/h2>\n
Step 3 \u2014 Build it<\/h2>\n
Step 4 \u2014 Selectors, if you need them<\/h2>\n
Step 5 \u2014 Error handling<\/h2>\n
\n
\n
Step 6 \u2014 Test properly<\/h2>\n
\n
Step 7 \u2014 Deploy and hand over<\/h2>\n
\n
\n
\n
\n
\n
What makes projects fail<\/h2>\n
Measuring it<\/h2>\n
The short version<\/h2>\n