First step of Automation: Process Inventory
One of the first steps to initiating a maturity model program is to take an inventory of what processes exist. There are generally more processes than initially thought in any unit and it takes a bit of time to sit down and hash out what they are.
-
proc·ess/ˈpräˌses/
Verb: Perform a series of mechanical or chemical operations on (something) in order to change or preserve it: “the stages in processing the wool”.
Noun: A series of actions or steps taken to achieve an end.
With this definition in mind, how many processes (noun form of definition above) does your unit have? Probably more than you think. Anything can be automated as long as you understand the process steps and you have the necessary resources to accomplish the automation. Let’s take a look at a simple example; Spending Accounts (SPAA) Database Management. Keep in mind this is just an example and not an all-encompassing, cohesive list. Here are some of the processes that exist for managing the database in my old position:
Area | Task |
Disk Management | Database Growth Estimation |
Disk Management | Performance Monitoring |
Build Management | Data Refresh |
Build Management | Database Builds |
Build Management | Script Builds |
Turn Process | Build Validation |
Turn Process | TCW Preparation |
Code Management | Code Reviews |
Code Management | Source Control Audits |
Code Management | Code Branching |
This is a short list of all the processes that are required, but I’d like to keep it simple for this exercise. Next, let’s categorize the processes into major and minor effort (i.e., how much resources does it take to accomplish – this could be considered resource savings or the REWARD), the dependency type of process (internal, external, mixed – i.e., will I need outside resources to finish the task?), and automation effort (i.e., how much resources would it take to automate – this could be considered the cost or the RISK). This is a much tougher task with a lot of variability. It is best done with a small group of knowledgeable associates; any group larger than 4 is going to lose focus and the discussion will breakdown pretty fast.
So let’s say this is the result (keep in mind this is hypothetical):
Area | Task | Current Effort (Hours/Month) | Dependency
Type |
Automation Effort
(Effort Months) |
Disk Management | Database Growth Estimation | 1 | Internal | 2 |
Disk Management | Performance Monitoring | 10 | External | 6 |
Build Management | Data Refresh | 60 | Mixed | 3 |
Build Management | Database Builds | 40 | Internal | 2 |
Build Management | Script Builds | 30 | Internal | 2 |
Turn Process | Build Validation | 4 | Internal | 2 |
Turn Process | TCW Preparation | 4 | Mixed | 1 |
Turn Process | TCW Turn | 4 | External | 2 |
Code Management | Code Reviews | 20 | Internal | 10 |
Code Management | Source Control Audits | 4 | Internal | 1 |
Code Management | Code Branching | 4 | Internal | 1 |
So with these numbers we can start the evaluation/prioritization step. Remember, we are looking to get the biggest bang for the buck. There are many measures you could you, but the one I like to use is the Breakeven Point; at what point did the effort payoff? I understand that this is highly subjective and imprecise, but you have to start somewhere. Here are the results:
Area | Task | Breakeven
Point (Months) |
Priority |
Disk Management | Database Growth Estimation | 320 | 7 |
Disk Management | Performance Monitoring | 96 | 6 |
Build Management | Data Refresh | 8 | 2 |
Build Management | Database Builds | 8 | 1 |
Build Management | Script Builds | 11 | 3 |
Turn Process | Build Validation | 80 | 5 |
Turn Process | TCW Preparation | 40 | 4 |
Turn Process | TCW Turn | 80 | 5 |
Code Management | Code Reviews | 80 | 5 |
Code Management | Source Control Audits | 40 | 4 |
Code Management | Code Branching | 40 | 4 |
So I can see that Data Refresh and Database Builds are taking the most of my time. They just happen to also be the fastest payoff for an automation investment, so I’ll target them first for automation. I also notice that while these tasks will require the same effort to automate, one has mixed (external) process dependencies so I might want to lower that tasks priority until I can arrange the necessary outside resources time.
Process improvement is a never ending endeavor: On a regular basis (e.g., once a quarter) this exercise should be conducted again to see what has changed and how it impacts existing maturity efforts. Business processes change, new technology becomes available, associates come up with new ideas for automation…These will impact what is possible and how they can be employed to improve the existing processes.
Next we’ll discuss breaking down a process targeted for automation.