Mutating Processes
The reality of the world that the average business process lives in is brutal. Its environment is constantly changing, damaging and hurting its delicate internal mechanisms. If the process cannot adapt, it will die.
Contents
Mutating Processes
Processes rarely manage to stay the same over their lifetime. They change, they adapt, they mutate.
- May be a user downloads the original report to Excel and removes the rows that are no longer necessary.
- Perhaps the automatically generated emails are edited by hand prior to sending.
- The requester of a payment emails the approved with additional information to ensure the right decision.
- Configuration items are added that take the process beyond its designer's original intentions.
You have probably seen processes adapting right under your nose and not realised it. Often they adapt quietly and silently, at other times in response to a crisis.
What Happens if They Don't Adapt?
What happens if the process does not adapt? It dies.
Another way is found, bypassing the original process, or leaving it in a small niche to only do a small, specialised part of the work.
Symptoms of extinct processes can be:
- Fields that are filled in just to pass the validation on the screen, "Oh just pick the first option, it works then", even though no one knows if the first option is the real answer or not.
- We don't use the report generated, we keep a spreadsheet on the shared drive.
- "Oh, I'm not sure what that does, I've never used it".
- "We need a new system".
Another process, designed or not, has taken the place of this process.
Processes that can Adapt, Survive
So a process that can adapt to changes in its environment can survive. We often talk about the speed of business in era of computing/Internet/Cloud, but this speed of change can sometimes be an illusion - extinct processes being ripped out in favour of newer processes that still have a lack of adaptability, that in turn will need to be replaced.
Businesses can lose focus on the customer due to the internal processes needing continuous meddling.
Should Processes Survive?
The longer a process survives, the better chance it has of making a good return on the original investment. However, its mutations that help the process to survive can increase the ongoing costs. So from our perspective, there are "good" mutations and "bad" mutations.
There comes a point when a process, however much it has adapted, needs to give way to fresh processes and it should become extinct. There is a danger, and often happens, that the process holds on to one small niche where the new process cannot survive and the old process lingers there causing pain and complication to the new succeeding process.
Often, the full domination of the new process and so the extinction of the old processes is moved to the mythological "Phase 2".
Enabling the "Good" Mutations
Enabling a process to adapt and survive will increase its longevity, but if the wrong mutations are supported, then the increased cost of ownership can reduce that return. So we want to be able to enable right sorts of adaption, so that the process can survive changes and continue to return on its investment.
Documentation
In the short term, lack of understanding of a process can help it survive long past its sell-by date. No one wants to touch the process as no one knows enough to confidently replace it. However, unless they are understood, any facilities within the original process to enable its adaption will be for nought, and the process will have to be replaced or mutilated.
Configuration
The first ability to adapt is configuration. To enable a process's longevity, configuration needs to have the following characteristics:
1: The obvious changes - such as dates - need to be very readily accessible and separated from more complex, deep-rooted changes that need consideration before changing.
2: The configuration needs to be understandable. If the configuration is so complex that the effect of a configuration change is not obvious, then you have invented an esoteric programming language which is likely to be understood by exactly one person (the designer).
3: In as much as it can be, the configuration needs to be modular. New areas of configuration can be created and utilised, perhaps for a short time, perhaps indefinitely. Being able to switch on and off configuration items without deleting them can be a nice feature as this can aid periods of special processing.
There are layers of configuration - parameters, set up pages, set up data that is changed by loading, constants within the code, changeable defaults etc. Picking the right level for the configuration is crucial to keeping it simple.
Testability
This could probably form a book in its own right, but the testability of a process can aid its longevity by supporting "good" mutations. Its ability to survive when other business processes change can be tested and confirmed, affirming its survival in a new business epoch.
Factors that affect the testability of a process include:
- The existence of test systems.
- The connectivity of the test system to the test systems of other parts of the business or other solutions.
- The ability to inject new data into a test process to see how it behaves.
- The ability to "pretend" that a particular scenario has occurred - this is particularly true of Big Bang go-live dates.
Reviewing Results
If the process generates reports or interfaces that may need adjustment, the ability to review and test within the system increases the probability that bolt-on changes are not made outside the system and that the original data is corrected.
This increases the accuracy of data within the system, which in turn will improve the longevity of our system.
This can be improved further if there is the ability to link the results back to source data.
Integration
The ability of the process to integrate with other processes and systems - both large and small systems - is an essential quality. The ability for these integrations to change in nature is also important. The systems and processes surrounding our process are very likely to change and we need to be able to alter the integration quickly and easily in several aspects:
1: Format - additional columns, different ways of deriving data... Can this be done easily? Does it require an expert's intervention? Is the format a widely accepted one that many systems can read (XML, CSV etc)?
2: Transport - is the transport mechanism one that can be changed and are the options ones that another system can easily adopt.
3: Timing - are there methods to delay sending and receiving interfaces? This can help to minimise the business disruption of change. Can a change be made at one end of the interface without requiring a simultaneous change at the other?
Encapsulating Specifics
When a process becomes highly specific about a mechanism that is likely to change, if that is hidden in the depths of the code, it will be difficult (and costly) to change. If these specifics are exposed in the configuration or are kept in a single place, they are easier to change, or the number of places the specific code lives is reduced (ideally to one).
User Exits, Plug-Ins, Add-Ins and Bolt-Ons
Many different terms for one architectural idea, and it's a goodie. The concept is that the architecture (or process) allows, at particular points, a piece of custom code or workflow to be done that is a departure from the original design. These additional pieces are easier to change than the whole process and give a way for the process to adapt without major surgery.
Conclusion
Processes are changing entities, clinging to their existence in the harsh modern business environment. Those processes that cannot adapt, die out and have to be replaced. Worse, some processes cling to life, finding niches to survive in and making the environment more complex for any new processes. In this case, eradicating these dinosaur processes can be painful but necessary.
Other Interesting Reading
Our eBooks
|
|
PeopleSoft Users Companion Extras
|
