- Traditional Change Models
- Disparate Change Groups
- Uncontained Change
- No Standard Change Approach
- Tools Focus
- Reliance on Benchmarking
- Changes Are Not Based On Data, Good Data, Or The Right Data
- Changes Made Based On Symptoms, Not Causes
- Systems Versus Processes
- Focus On People, Not On Process
- Lack of Context for Solutions
- Adding Versus Subtracting (Patching)
- Poor Implementation
- No Emphasis On Control
- Management Versus Leadership
- Summary
Systems Versus Processes
As in many other industries, staff in healthcare struggle with the differentiation between systems and processes. In simple terms, processes are “what” is (supposed to be) happening and “how” it occurs; systems are the things that support processes. For example, take a materials tracking system in a surgery (say). The process is made up of the steps, triggers, roles, responsibilities, and skills to ensure that material physically moves from the dock through the hospital to the operating room and beyond. The system involved merely tracks what’s occurring in support of the process to ensure that the current state is reflected and understood at all times (as shown in Figure 1.1).
Figure 1.1 The relationship between process and system
When material is unavailable, it is therefore inappropriate to blame the system when what has truly failed is the process. Also, it is naïve to believe that “all these problems will be resolved when we install xyz system or upgrade to version x.x of the software.” The impact of this has been a painful lesson for a great many organizations that implemented an electronic medical records (EMR) system in the past few years. Likewise, it is misguided to believe that a systems-based approach to performance improvement will change the physical aspects of the organization’s processes. Such an approach tries to tackle certain symptoms house-wide all at the same time, when the needs, context, and organizational setup are different from process to process. An example might be the desire to improve communication (say). True, communication is important in many instances, but without a detailed understanding of the requirements of a particular trigger, the communication mechanism imposed may not be the best (or required at all).