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.

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


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)

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.


Leave a Reply