In a process improvement project is it best not to spend too much time on detailing an ‘as-is’ process analysis and focus on the ‘to-be’ process instead?
One of the arguments against detailing an as-is process analysis is that it precisely hinders the involvement of the people as they may be afraid to be evaluated. Focusing on the ‘to-be’, and making a fresh start based on their suggestions (without bringing the current process in a detailed picture), would then ease participation. But the ‘as-is’ phase is very important because (1) it represents the base for us to start from in improvement process, as (to be) process should result from handling the improvement opportunities in (as is) process, and (2) it ensures the involvement of process people as they share us the information of the ‘as-is’ process and have chance to give suggestions about to-be, thereby increasing the ownership of the new to-be process.
If you do not understand your current processes and what is and is not working then you will fail to successfully define and implement new processes. Even if management offers explicit direction on new processes, you need to know what your starting point is or was. There are several reasons for this: 1) to leverage what is already in place, 2) to socialize change and, regardless of management direction, 3) gain acceptance and support from the team that will be responsible for doing or managing the processes, and 4) identify and fix the existing problems that likely are leading to the new process needs. Otherwise, you’ll get processes that are essentially dead on arrival.
Knowing only the current, ‘as-is’ state does not help without knowing where you want to be in the future state. The first fact is just one data point, which as we know is useless by itself. We have to know both the current and future states of a process in order to measure the gap between. It is the gap that we refer to as a problem and it’s size, the magnitude of the problem. The gap can be characterized with many varying metrics such as quality, speed, or cost, but they should all be aligned to the customer and key strategic objectives. One way to do this is to use an an analogy of a map. (more…)
Change control within is a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary changes will be introduced to a system without forethought, introducing faults into the system or undoing changes made by other users of software. The goals of a change control procedure usually include minimal disruption to services, reduction in back-out activities, and cost-effective utilization of resources involved in implementing change. Change control is a major aspect of the broader discipline of change management.