Automation Requirement Framework

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. ...