Design Variation - A necessary evil for global enterprises. Why?
The global design of business processes vary based on
• Nature of the operations and processes
• Local statutory / legal requirements
• Limitation of technology at the time of deployment
• Availability of standards
• Knowledge of the consultant who designed the processes
Even if the nature of operations is same, we are now seeing a variation in business processes from one division to other division. This means that there is more than one process to meet the same business requirement within the same installation. These processes will have their own merits and demerits. Once the implementation is completed and project is transitioned to support, the support analyst needs to understand more than one business process for the same business requirement.
There arises a question in the minds of the support analysts why there is a variation in process design? Can't we have the same business processes for the same requirement? The debate can continue for any long without any answer. This variation in the design can be called as evil and no one like to have the same at the time of initiation of the project. But by the time the project goes live the new design is evolved, resulting in multiple processes for the same requirement.
What is important to understand is that this kind of variation is good for global enterprises as one need not have to carry forward the inefficient processes designed in the early stages of deployment to the later stages. By this way enterprises can be more efficient. Imagine a simple purchase process of direct material was designed with 10 steps and 25 clicks as part of the global design. The same has been achieved with 8 steps and 20 clicks subsequently. Should we consider the later process or continue the former one for the subsequent deployments? Going with later process will result in design variation and going with former process is carry forwarding the inefficient process. One should also think of re-deploying the improved processes to existing business divisions and 'drive-in' continuous improvements. Does this answer why an evil is required?
• Nature of the operations and processes
• Local statutory / legal requirements
• Limitation of technology at the time of deployment
• Availability of standards
• Knowledge of the consultant who designed the processes
Even if the nature of operations is same, we are now seeing a variation in business processes from one division to other division. This means that there is more than one process to meet the same business requirement within the same installation. These processes will have their own merits and demerits. Once the implementation is completed and project is transitioned to support, the support analyst needs to understand more than one business process for the same business requirement.
There arises a question in the minds of the support analysts why there is a variation in process design? Can't we have the same business processes for the same requirement? The debate can continue for any long without any answer. This variation in the design can be called as evil and no one like to have the same at the time of initiation of the project. But by the time the project goes live the new design is evolved, resulting in multiple processes for the same requirement.
What is important to understand is that this kind of variation is good for global enterprises as one need not have to carry forward the inefficient processes designed in the early stages of deployment to the later stages. By this way enterprises can be more efficient. Imagine a simple purchase process of direct material was designed with 10 steps and 25 clicks as part of the global design. The same has been achieved with 8 steps and 20 clicks subsequently. Should we consider the later process or continue the former one for the subsequent deployments? Going with later process will result in design variation and going with former process is carry forwarding the inefficient process. One should also think of re-deploying the improved processes to existing business divisions and 'drive-in' continuous improvements. Does this answer why an evil is required?
