Earlier in the week, we spoke about the differences between dirty and clean consulting, as posed by Dr Richard Claydon, and how it impacted the use of consultants on OSS projects.
The same clean / dirty construct applies to automation projects / tools such as RPA (Robotic Process Automation).
Clean Automation = simply building robotic automations (ie fixed algorithms) that manage existing process designs
Dirty Automation = understanding the process deeply first, optimising it for automation, then creating the automation.
The first is cheap(er) and easy(er)… in the short-term at least.
The second requires getting hands dirty, analysing flows, analysing work practices, analysing data / logs, understanding operator psychology, identifying inefficiencies, refining processes to make them better suited to automation, etc.
Dirty automation requires analysis, not just of the SOP (Standard Operating Procedure), but the actual state-changes occurring from start to end of each iteration of process implementation.
This also represents the better launching-off point to lead into machine-learning (ie cognitive automation), rather than algorithmic or robotic automation.