One of the most important aspects of instantiating any business processes, measurement and change into an organization is organizational change management, or OCM. This is often an aspect of ITSM programs that is the least addressed and invested in, and unfortunately, the reason many initiatives fail. If the “people” component of people, process, and technology is not addressed, the chances of achieving value, quality, innovation or compliance goals from just processes and technology will be very limited – this is true in any process improvement inside or outside of the IT department.
Each component of an OCM plan is not mutually exclusive of the others. When a component of OCM is missed or fails, it impacts the effectiveness and objective of the entire endeavor. A first key attribute of all of these components is to understand who the stakeholders of the change are. The term “stakeholder” is often perceived to mean managers, directors and “higher ups” in the organization. This is another fallacy of stakeholder analysis that often thwarts the execution of an OCM plan. It is important to know:
Capturing stakeholders, plans, goals and metrics, relationships and dependencies is challenging. Trying to capture all of this in spreadsheets, documents, and SharePoint sites can be laborious. More importantly, many of these methods were not designed to capture and maintain relationships and dependencies that are as crucial as understanding dependencies and relationships between services and CIs.
As OCM has been key to the success of business process improvement efforts outside of the IT department, models (architectural, process, etc) have evolved to address many of the aspects of an OCM plan. They have effectively been used in the business world to document, analyze and most importantly, allow the organization to understand all of the aspects of an improvement program that add to or limit its success. Quite often, it is the complexity of the relationships and inter-dependencies that derail organizational changes, because it is often difficult to conceptualize the entire change and what it means, and why it is being done.
The idea is by automating and reducing the cost, complexity and delay involved with OCM, OCM actually plays and fulfills the more important part of the change being made to an organization. This eliminates of many of the risks that are often the culprit in thwarting successful ITSM programs.
The following table lists components needed for a successful organizational change and more importantly, results of not addressing this part of the OCM plan. Also listed are various models and approaches from the world of BPMS that have been leveraged to help address and automate key aspects of this part of the OCM plan.
| Component of organizational change Mgmt | Result if not addressed: models and approaches to mitigate |
|---|---|
| Business case | Complacency – People have difficulty changing when they do not understand the “why” or the rationale of what is happening. It should be well understood why the organization is changing for the betterment of the business, even if it means changes in behavior that may not seem obvious or logical. Recommended models: |
| Common vision | False starts / confusion / misalignment – A common vision provides the stars to steer by. If people are not working in the same direction, there is going to be confusion, missteps and misalignment of the change. A great example of common vision; In the 1960’s, every employee of NASA had a common vision, even down to Janitorial employees – that was to put a man on the moon by the end of the decade. Recommended models: |
| Communication | Inaction / confusion / resistance - People naturally want to feel they are a part of the change and are being recognized as contributors of its success, even if that means being communicated with. People need to understand their role in the process and how to move forward. Recommended models |
| Address barriers | Frustration – If the “what about” questions have not been addressed, there is going to be frustration. Obviously, a solid assessment and analysis of “as-is” helps to identify barriers and challenges to change. It’s frustrating for stakeholders to run into walls that haven’t been addressed by the program. It is very important that the program have processes in place to address barriers discovered throughout the program. Recommended models |
| Demonstrating progress | Cynicism / loss of momentum – It becomes just another project or initiative that didn’t go anywhere. Over-communication of progress and celebrating wins is important as change grows throughout the organization. Recommended models |
| Enforcement | Wasted effort / lack of adoption – Nothing sticks. Obviously, for those embracing change, enforcement is not as necessary. But 100% change is rarely achievable, therefore enforcement of policies and procedures are needed to assure that the change is implemented despite failures in other areas, and people just unwilling to change. Recommended models |
ITSM practitioners often believe models are only about processes and workflows, systems and architectures. In fact, they can be used for so much more. Modeling technologies have been around for a while and continue to grow in their role as a WMD’s, or Weapons of Mass Depiction. All of the artifacts above can be modeled alone and in isolation – however, it is recommended that they be modeled into a consolidated, linked, model called a strategy model.
Strategy models are constructed to allow strategic components such as plans, projects, goals, problems, opportunities, rules and environmental influences to be related on the same model to display the strategic Influence each has on the others. The influence relationships among them can be visually charted and better understood. For example, the influence of problems inhibits the attainment of goals, the influence of opportunities to solve problems, the influence of environmental Influences restricting the realization of opportunities, an so on.
A strategy model can be used for a variety of purposes, such as supporting the balanced scorecard approach for setting goals and measuring performance, or cause and effect analysis.
Selecting BPMS technology for OCM
BPMS technologies and methodologies are already demonstrating considerable success in the business world, so your ITSM improvement journey should be much more enhanced and chances of success greatly improved by leveraging these tools and methods in the same way.
As this market is currently experiencing major growth and popularity, choosing an appropriate BPMS solution can be challenging. The following tips are provided to help you select a BPMS technology (or a portion of a BPMS solution) that will help you effectively and efficiently address organizational change management.
Tip #1 – Standardize your enterprise modeling technology. While use of software such as Excel, Word, and PowerPoint will likely remain in use for reporting and presentation purposes, it is most critical to standardize on a single modeling tool.
A single enterprise modeling and architecture tool will allow each strategy stakeholder to model its piece of the business in a common format, allow for collaboration across multiple participants, and enable the models to come together easily into a single enterprise view. The resulting enterprise-wide model can then be viewed at a high-level or viewed in detail by drilling down into specific areas of the enterprise. A strong enterprise architecture (EA) and modeling tool will provide the following:
Tip #2 – Select the right business process analysis tool and standardize on it. We know you love it, but you have to agree that Microsoft Visio is not a true business process modeling and analysis tool.. It is a great illustration tool, but it does not provide intelligence to help you with process discovery or optimization. Nor does it provide you with an easy path for process deployment.
If you want to get serious about process improvement, you need to select a business process analysis (BPA) tool that provides:
Tip #3 – Select the right business process management suite. Without the right Business Process Management (BPM) software, you will never achieve the gains in efficiency, productivity, or visibility that you desire. BPM software also allows you to become more flexible and agile while at the same time gaining greater control over your processes. Here are a few critical capabilities to look for in a BPM suite:
In conclusion, there is plenty of technology to fulfill the technology component of IT Service Management. Unfortunately, the biggest problems start with people and process. While many activities, artifacts and deliverables of OCM, and other soft areas of an ITSM program are manual in nature, BPMS technologies have evolved to help support and automate not only the execution and integration of work processes, but also to help shape and define those processes through strategy and analysis models, incorporation of architecture models and a never before seen level of stakeholder collaboration - before a process ever reaches execution.
John - you're right about saying "Unfortunately, the biggest problems start with people and process. "
Although we've been working on these two domains for more than two decades now, there's little gained.
It's like Mazlov: if you haven't organized People and Process, it's no use upgrading your Product dimension. And actually it starts with Process - the common factor in all service organizations. That's why it's such a shame that ITIL skipped the process focus, as if organizations don't need that anymore. It's completely the other way around - if organizations don't start mastering their Process dimension, they'll never be able to achieve the benefits you describe.
Jan,
Good points - It's ALL ABOUT THE PROCESS...
It's interesting in the last few customer meetings and demonstrations, it's the ability to automate non-ITSM processes that garners the most interest - processes that have no guidance or "best practices" out there and very limited options as far as vertical applications available for automation.
It's the business people that know their process (they understand the goals and objectives, procedural steps, etc) and can easily see it elaborated within our BPM environment.
Why ITSMer's don't see this is a mystery...??
Comments