The most steadfast of our three characters. Processes embody the sentiment “This is how it’s done here.” They are the codification of the operational steps necessary to complete some task or set of tasks. Good processes share some key attributes: they are as simple as possible, well documented, and properly communicated. Good processes can be an ally on the automation journey, while bad ones will most likely be a hindrance. Organizations have some level of processes defined for a dizzying number of areas within their IT environment. Some examples:

• Capacity-planning
• Change management
• Service management
• Performance management
• Problem management
• Security management
• User access management
• Backup and recovery management
• Disaster-recovery management
• Configuration management
• Release management
• Auditing

A few things to consider:

• As an organization transitions into the two upper levels of the framework (those labeled Supervised Autonomy and Full Autonomy), the system is expected to self-align. This means that most processes will need to be automated, so the evaluation of all of an organization’s processes will eventually be required.
• There are many undocumented processes that exist in an organization. These may be embedded in “tribal knowledge” or job descriptions, but they are processes nonetheless and must be considered along the way.
• Breaking down processes into individual components and mapping them to the associated people and technology will be labor intensive, but necessary.
• In addition, processes should be mapped to the framework level at which they can be automated or eliminated.
• Evaluating and updating processes should be performed continuously. The goal is to eventually automate every process, where it makes sense to do so, within an organization.
• The long-term benefits of fixing or eliminating a bad process outweighs the short-term benefits of automating a good one.
• It is impossible to know whether a process is good or bad, if it can’t effectively be measured.