Automation projects are usually costed as a build.<\/p>\n
They are a build plus maintenance, indefinitely.<\/strong><\/p>\n Screens change. Applications update. A vendor redesigns a portal. A published file gains a column. Each time, something breaks and somebody fixes it.<\/p>\n Companies that budget for this are satisfied.<\/strong> Companies that do not end up with a graveyard of broken automations nobody dares touch.<\/p>\n The single most important thing.<\/strong><\/p>\n An automation that fails and tells nobody is worse than none, because everyone assumes the work is being done.<\/p>\n Four things:<\/strong><\/p>\n Log every run<\/strong> \u2014 started, finished, what it processed, what failed.<\/p>\n Alert a named person on failure.<\/strong> Not a log file. Not a shared inbox.<\/p>\n Alert on silence too.<\/strong> A scheduled job that did not run produces no error at all. Monitor for the absence.<\/p>\n Record what it processed<\/strong>, so when something is wrong you can see what it did and did not touch.<\/p>\n That third point is the one most commonly missed<\/strong>, and it produces the longest-lasting failures \u2014 because there is nothing to notice.<\/p>\n FIGURE 1: MAKING FAILURE VISIBLE<\/p>\n Alert a named person<\/p>\n Alert on silence<\/p>\n Log successful runs too<\/p>\n Enough context to act<\/p>\n Every automation needs a named owner.<\/strong><\/p>\n Not a team. A person, who:<\/p>\n When that person leaves, ownership transfers explicitly.<\/strong><\/p>\n The most common cause of an abandoned automation is that its author moved on and nobody inherited it.<\/strong><\/p>\n Short. One page. It answers what somebody will ask.<\/p>\n What it does<\/strong>, in two sentences.<\/p>\n Why it exists<\/strong> \u2014 what problem it solved.<\/p>\n What it touches<\/strong> \u2014 which systems, which accounts, which folders.<\/p>\n Known fragile points<\/strong> \u2014 which parts are most likely to break.<\/p>\n What to do when it fails<\/strong> \u2014 the first three things to check.<\/p>\n Who owns it.<\/strong><\/p>\n That fits on one page<\/strong>, and it is the difference between a fixable automation and a black box.<\/p>\n Four practices:<\/strong><\/p>\n A dedicated service account<\/strong>, not a person’s login.<\/p>\n Stored in the platform’s credential store<\/strong>, not in the automation.<\/p>\n Expiry tracked.<\/strong> If the account is subject to a password policy, know when it will force a change.<\/p>\n Minimum access.<\/strong> An automation that only reads should not be able to delete.<\/p>\n The proactive part<\/strong>, and what separates well-run automation from constant firefighting.<\/p>\n Keep a dependency list:<\/strong> which automations rely on which systems.<\/p>\n Subscribe to release notes<\/strong> for those systems.<\/p>\n Test after a known update<\/strong>, rather than waiting for the failure.<\/p>\n Without the list<\/strong>, an announced change means checking everything or nothing.<\/p>\n FIGURE 2: AUTOMATIONS THAT SURVIVE<\/p>\n Surviving<\/p>\n Abandoned<\/p>\n The most valuable habit here, and the least common.<\/strong><\/p>\n A scheduled check that compares two systems and reports disagreements.<\/strong><\/p>\n Rows in the source file against records created. Orders in one system against another. Counts, at minimum.<\/p>\n Why:<\/strong> failures are silent. Nothing errors \u2014 the systems just drift apart.<\/p>\n A weekly reconciliation catches that.<\/strong> Without one, you find out at month-end, or when somebody asks about data that never arrived.<\/p>\n Once a year, per automation:<\/strong><\/p>\n Is it still running?<\/strong> Some quietly stopped.<\/p>\n Is it still needed?<\/strong> The process may have changed.<\/p>\n What has it cost to maintain?<\/strong> Hours spent fixing it.<\/p>\n Is the saving still there?<\/strong> Compare against the original baseline.<\/p>\n Switching one off is a valid outcome.<\/strong> An automation that costs more to maintain than it saves should go. That is a good decision.<\/p>\n If it works and you build more, three things change.<\/p>\n You need central scheduling and logging<\/strong> across automations, rather than each managed separately.<\/p>\n You need naming conventions.<\/strong> Twenty automations named inconsistently become unmanageable.<\/p>\n You need shared components.<\/strong> The same login sequence, the same notification format, reused rather than rebuilt \u2014 so when it changes, you fix it once.<\/p>\n Without these, twenty automations is far more than four times the work of five.<\/strong><\/p>\n FIGURE 3: A MAINTENANCE ROUTINE<\/p>\n Alerts to a person<\/p>\n One page per automation<\/p>\n A dependency list<\/p>\n Reconciliation<\/p>\n Expect to spend time on this.<\/strong> Not much per automation, but not zero, and it does not stop.<\/p>\n A rough guide:<\/strong> a few hours a month across a handful of automations, rising with the number and with how fragile they are.<\/p>\n Which is why keeping the fragile parts small matters.<\/strong> An automation that touches one screen breaks less often than one that touches twelve.<\/p>\n Automation is not a build. It is a build plus permanent maintenance<\/strong>, and the maintenance decides whether it pays.<\/p>\n Make failure visible<\/strong>, including the case where a scheduled run simply did not happen.<\/p>\n Give every automation a named owner and one page of documentation.<\/strong><\/p>\n Add reconciliation<\/strong>, because silent drift is the failure you find late.<\/p>\n And review yearly. Switching off something that costs more than it saves is a good decision, not a failure.<\/p>\n Automations that keep breaking, or that nobody dares touch?<\/p>\n Get in touch. The problem is usually ownership, alerting and documentation rather than the automation itself.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" The cost nobody budgets for Automation projects are usually costed as a build. They are a build plus maintenance, indefinitely. Screens change. Applications update. A vendor redesigns a portal. A published file gains a column. Each time, something breaks and somebody fixes it. Companies that budget for this are satisfied. Companies that do not end […]<\/p>\n","protected":false},"author":3,"featured_media":9380,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-9379","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-robotic-process-automation"],"yoast_head":"\nMake failure visible<\/h2>\n
\n
\n
\n
\n
Ownership<\/h2>\n
\n
Documentation that is actually useful<\/h2>\n
Credentials<\/h2>\n
Watching for changes upstream<\/h2>\n
\n
\n
Reconciliation<\/h2>\n
Reviewing what you have<\/h2>\n
Scaling up<\/h2>\n
\n
\n
\n
\n
The realistic picture<\/h2>\n
The short version<\/h2>\n