Most companies want to automate the thing that irritates them most.<\/strong><\/p>\n Usually that is the most complicated process, with the most exceptions, crossing the most departments.<\/p>\n Which makes it the worst place to start.<\/strong><\/p>\n Three reasons:<\/strong><\/p>\n It is hardest to build<\/strong>, so it takes longest and costs most.<\/p>\n It has the most exceptions<\/strong>, so it is most likely to disappoint.<\/p>\n It is your first attempt<\/strong>, so you will make first-attempt mistakes on the highest-stakes project.<\/p>\n Start with the dullest high-volume task instead.<\/strong> You learn the tooling, prove the value, and build credibility for the harder ones.<\/p>\n Five questions per process. Answer them honestly.<\/p>\n How often does it run?<\/strong> Daily is excellent. Weekly is good. Monthly is marginal. Quarterly is not worth it.<\/p>\n How long does one run take?<\/strong> Multiply by frequency.<\/p>\n How rule-based is it?<\/strong> Can you state the logic, or does somebody decide?<\/p>\n How structured is the input?<\/strong> Consistent format, or whatever arrives.<\/p>\n How stable is it?<\/strong> Unchanged for a year, or changing monthly.<\/p>\n A process that is frequent, long, rule-based, structured and stable is your first candidate.<\/strong><\/p>\n FIGURE 1: SCORING A PROCESS<\/p>\n Frequency \u00d7 duration<\/p>\n Rule-based<\/p>\n Structured input<\/p>\n Stable<\/p>\n Minutes per run \u00d7 runs per month \u00d7 the cost of that time.<\/strong><\/p>\n Then subtract:<\/strong><\/p>\n Build cost.<\/strong> Time or money.<\/p>\n Licence cost<\/strong>, if any.<\/p>\n Maintenance.<\/strong> For as long as it runs. This is the part people leave out.<\/strong><\/p>\n A rough guide:<\/strong> if the annual saving is not several times the annual cost including maintenance, it is marginal.<\/p>\n Marginal automations get abandoned<\/strong> when whoever built them leaves \u2014 and then you have paid for the build and get nothing.<\/p>\n Time is the obvious one. Three others often matter more.<\/strong><\/p>\n Errors avoided.<\/strong> A person entering four hundred records makes mistakes. The cost of one wrong entry reaching a customer can exceed a year of time saved.<\/p>\n Delay removed.<\/strong> A process that runs overnight instead of when somebody gets to it. For order processing or stock allocation, hours matter.<\/strong><\/p>\n Things that start getting done.<\/strong> The reconciliation nobody had time for. The supplier review that never happened. Automation often adds work that was being skipped<\/strong> rather than only removing work being done.<\/p>\n That third one is frequently the largest benefit<\/strong> and it never appears in the business case.<\/p>\n Processes with judgement at the centre.<\/strong> Automate the gathering, leave the deciding.<\/p>\n Rare processes.<\/strong> Twice a month does not clear the fixed cost.<\/p>\n Unstable processes.<\/strong> Changing monthly means reworking monthly.<\/p>\n Contested processes.<\/strong> If two departments disagree about how it works, that is not a technology problem<\/strong> and automating it will not settle it.<\/p>\n Processes that should not exist.<\/strong> Ask before you build.<\/p>\n FIGURE 2: FIRST PROJECT OR NOT<\/p>\n A good first project<\/p>\n A bad first project<\/p>\n These come up repeatedly, and for good reason.<\/strong><\/p>\n Reading supplier invoices, receipts or forms<\/strong> into your system.<\/p>\n Why it works first:<\/strong> high volume, dull, and instantly verifiable<\/strong> \u2014 the document is right there, so you can see whether the result is right.<\/p>\n Low risk to adopt<\/strong>, because errors are visible immediately.<\/p>\n Records from one place into another<\/strong>, on a schedule or on an event.<\/p>\n Why it works:<\/strong> entirely mechanical, and somebody is currently doing it by hand.<\/p>\n Check first:<\/strong> does an API, an import function or a direct URL already do it? This question is asked too rarely.<\/strong><\/p>\n Getting information to the person who needs it<\/strong>, without somebody remembering.<\/p>\n Why it works:<\/strong> low risk \u2014 nothing is created or changed, only communicated. And it often surfaces problems earlier<\/strong>, which is worth more than the time saved.<\/p>\n Once one works:<\/strong><\/p>\n Do a similar one.<\/strong> Reuse what you learned and what you built.<\/p>\n Then something adjacent.<\/strong> A different process, same systems.<\/p>\n Then something harder.<\/strong><\/p>\n Do not jump to the complicated one after a single success.<\/strong> Two or three straightforward automations build both capability and credibility.<\/p>\n Five checks.<\/strong><\/p>\n Is the process documented and agreed?<\/strong> Including exceptions.<\/p>\n Does an existing system setting already do it?<\/strong> Check properly.<\/p>\n Who will own it?<\/strong> Name the person.<\/p>\n How will we know if it fails?<\/strong> If you cannot answer, fix that first.<\/p>\n Have we measured the baseline?<\/strong> Otherwise you cannot say afterwards whether it helped.<\/p>\n A “no” to any of these is a reason to wait<\/strong>, not a reason to proceed carefully.<\/p>\n FIGURE 3: CHOOSING<\/p>\n Score the candidates<\/p>\n Calculate honestly<\/p>\n Pick the dullest high-volume one<\/p>\n Check the five before committing<\/p>\n Automating a process nobody questioned.<\/strong><\/p>\n Before building anything, per step:<\/strong> why does this exist, who uses the output, what would break if we stopped?<\/p>\n Removing three of eight steps saves more than automating all eight<\/strong>, and costs nothing to maintain afterwards.<\/p>\n That is the highest-return work in any automation project<\/strong>, and it happens in a conversation rather than in a build.<\/p>\n Start with the dullest high-volume task<\/strong>, not the most annoying one.<\/p>\n Score candidates on frequency, duration, rules, structure and stability.<\/strong><\/p>\n Calculate the saving including maintenance<\/strong> \u2014 that is what separates a real case from an apparent one.<\/p>\n And count the savings people forget:<\/strong> errors avoided, delay removed, and work that starts getting done because it is no longer manual.<\/p>\n Several processes that could be automated and unsure where to start?<\/p>\n Get in touch. We will score them with you \u2014 and quite often the answer is a process nobody had thought of, or one that should be deleted instead.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" The wrong instinct Most companies want to automate the thing that irritates them most. Usually that is the most complicated process, with the most exceptions, crossing the most departments. Which makes it the worst place to start. Three reasons: It is hardest to build, so it takes longest and costs most. It has the most […]<\/p>\n","protected":false},"author":3,"featured_media":9497,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[27],"tags":[],"class_list":["post-9496","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-automation"],"yoast_head":"\nScoring candidates<\/h2>\n
\n
\n
\n
\n
The saving, calculated honestly<\/h2>\n
The savings people forget to count<\/h2>\n
What to leave alone<\/h2>\n
\n
\n
The three usual first projects<\/h2>\n
Document handling<\/h3>\n
Data movement between systems<\/h3>\n
Notification and routing<\/h3>\n
Sequencing after the first<\/h2>\n
Before you commit<\/h2>\n
\n
\n
\n
\n
The mistake worth naming again<\/h2>\n
The short version<\/h2>\n