> " especially if you’re innovating in a more regulated industry" One of the things that needs to be simultaneously innovated upon are all the regulations that

> " especially if you’re innovating in a more regulated industry" One of the things that needs to be simultaneously innovated upon are all the regulations that exist in various industries: - why are they there? - can they be reworded to work better? - do they still make sense? - how do they interact with other regulations (possibly even conflicting ones)? - how can multiple regulations be collapsed into fewer/simpler ones? And more. Here's a "Philosophy of Automation" as given to me by someone (https://antipaucity.com/2013/06/07/automation-gp/#.Wd4r1hNSzgo https://antipaucity.com/2013/06/07/automation-gp/#.Wd4r1hNSz...) involved in the IBM user groups back in the late 80s. It's as relevant here and now (and in this context) as it was then: Automation is not a technical problem it is a people problem. When you initially automate, you convert your process flow documents into executable code that consistently runs on a prearranged schedule, or through a monitor, or an error message. These executable processes enforce your process rules every time. You cannot automate processes that are all over the place. When you automate your processes they will be transformed. Because you automate your processes automation never ends. Automate as close to the source as possible. Problems with automated processes occur infrequently but are more difficult to solve than manual processes. The combining of problem, change, and asset management with automated process management and root cause analysis, improves quality and allows you to consistently meet your service levels. All automation code is throwaway code. Automation is very exciting. Automation is very rewarding. Everyone is on the automation team.