Automation

split workflow Hopefully you found your project priority based on priority calculation I covered earlier. You also might already have your own buckets and for sure you have found your type - either task or process. There is a difference in automating an action that takes 20 minutes of employee’s time daily and an complex payroll process that spans across hours or even days. Tasks would usually fall into category of (standard) operating procedures (SOPs) and usually end up as a straightforward translation of person’s actions to automation’s actions. Processes, on the other hand, are complex, usually cross-team, efforts that include multiple SOPs representing sequence of steps that are interconnected by the final goal. ...

what do you need this for? I have started working on this due to constantly hearing of or experiencing myself this trival thing called changing requirements. All development today is created using Agile principles of course, although that doesn’t mean we shouldn’t have strong foundation to later improve on it. Yes, improve - not change. I think as analysts / designers / developers we should be as thorough as possible when it comes to first sketch of a solution, after all how do you write your stories / tasks / features if anything is missing. At the same time, software development is a bit different than (process) automation development. You need mapped end-to-end process to even start thinking about designing solution - making shortcuts, simpifying, integrating with existing solutions or even researching accesses required. Automating is more of a waterfall project with some flexibility when it comes to extending or improving on the way. Reducing the risk of any changes during the development makes projects being delivered faster and coders a lot happier. ...

historical background I work in a field that is on the verge of IT and Business - robotic process automation which is fancy (and now standardized) name for a business automation. When such teams were being introduced to organizations about 10 years ago, the RPA software was still immature and many automations were done using battle-tested Office (mostly Excel, Access) macros. It had its disadvantages but allowed for fast development. Currently Microsoft is slowly killing it (due to security risks) and replacing with much safer (and web-enabled) Office Scripts. Main disadvantages for the macros is that environment it is being ran on might be different than development environment - your US colleague’s PC has different settings (decimal separator, encoding, etc.) than your Polish-set machine. RPA software was designed to fix it with ‘robots’ that run on a VM. Robot could’ve done same thing as macro but now RPA team was able to control the environment parameters. ...