Chapter 1.6: Process Rings-on-a-Tree

It is possible to tell the approximate age of an organization by looking at its information processes.  The approach is similar to determining the age of a tree.  For trees growing in places with strong seasonal climate cycles their age can be estimated from a core sample extracted from the trunk.   A ring of visible xylem cells is created each year.  The age of the tree is established by simply counting each ring in the sample. 

As shown in Figure 1.9 a core sample of an organization’s processes can be used to count the layers of process artifacts that are layered one on the other each year.

Figure 1.9:  Process rings-on-a-tree

Just like a core sample taken from a tree, it is possible to estimate the age of an organization by counting the layers upon layers of process that naturally build up over time.

5 years:  Process standardization

·         First cookbooks are developed for internal processes

·         Activities are tailored to the skills and personality of the individuals performing the roles

·         Priorities are set by a common system-wide understanding of the created value

·         Process training is the responsibility of first level management

·         Low variation in how different individuals perform a common process

·         IT systems and processes are aligned

10 years:  Process solidification

·         Reports are generated that no one reads

·         Process cookbooks are less than 60% accurate

·         Process training is the responsibility of employee mentors

·         No one has an end-to-end system view of how the process works

·         Processes include workarounds due to the inflexibility of IT systems to change as the processes change

·         Individuals inherit their assigned activities as other people leave

·         Priorities are set by expediting across functional groups

20 years:  Process senescence

·         All of the 10 year attributes plus

·         Process cookbooks are no longer valid

·         The only way to learn a job is from someone who has done it

·         No one can explain why certain process activities exist – we have always done it that way

·         The number of just-in-case process artifacts outnumber the do-it-right-the-first-time process artifacts

·         Processes rely on IT systems that duplicate and overlap with each other

·         More operational information is maintained in spreadsheets than in IT systems

·         Process activities are owned by functional groups rather than the individuals within the group

·         Priorities are set based on the objectives of individual functional groups

30 years:  Process fossilization

·         All of the 20 year attributes plus

·         Processes exist just to fix other processes that are broken but considered un-repairable

·         There are entire processes that produce results of no value

·         Processes rely on IT systems that are no longer supported by their vendors

·         Functional groups are silos

·         Individuals set their own priorities

·         There is so much process variation that it is no longer possible to establish a single definition of the value created by the process  

These process rings-on-a-tree exist for the same reason they exist in trees.  New processes are added all of the time.  There is no such thing as a process status quo.  Processes are in a constant state of change because:

·         Customers – change what they value

·         Markets – grow and shrink

·         Organizations – grow and shrink

·         Products and services – added and removed

·         Management –  adopt new strategies and objectives

·         Employees – join and leave

·         Individuals – gain skills and capabilities

·         Information Systems – new technologies 

Each of these factors leads to process change.  While new processes are added old processes are almost never removed.  Since information processes are largely invisible unless the process documentation is kept up to date, with time no one knows which process activities are candidates for removal.   It is very difficult to tell if:

·         Someone still uses the process

·         Another process or system is dependent on the process

·         Certain activities belong to this process or to another

·         It is worth the cost of removing 

Therefore removing process is a sure way to break something else.  In fact this is usually the only way to remove process activities.  Turn it off and wait for someone to scream. 

Even if a process is relatively new there is rarely the opportunity to revert back to some prior state.  Even in a short period of time other process changes could have been layered on top of the original change so the old status quo no longer exists.   

In fact removing a portion of a process usually requires a new layer of patches to fix the broken dependencies between the activities that remain.  It can be difficult to remove an obsolete activity, if any part of its output is now used somewhere else.  

As a result most organizations have too much process, not too little.  There are processes for just-in-case processes to fix processes to link to processes to add processes to remove processes.  With time layer upon layer of these processes build up like rings-on-a-tree.