Posted July 5th, 2010 by John M. Clark
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:
- Who are the key stakeholders? (not just managers, but users, customers, partners, and so on)
- What is influence/support they have? (do not forget non-organizational leadership)
- What is expected from them and of them?
- What will they gain and/or lose? (WIIFM, the most popular radio station in the world of OCM)
- What recommendations do we have to engage with them?
- How will we get the stakeholders to conform to any new way of working?
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:
Strategy and business interaction
Business architecture linked to goal models mapped as guiding principles and metric models (for measurement)
|
| 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:
Business architecture linked to goal models
Plan models (project plans)
|
| 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
Stakeholder analysis
Communication models
Organizational models linked to goals and objectives as well as process models
Plan models (project plans)
|
| 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
Barrier analysis
Plan models (project plans)
Impact and problem 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
Plan models (project plans) and status reports against baseline
|
| 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
Process models (workflow)
Goals and policy models
Metrics 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:
- Ability to model all assets and interrelationships, including systems, data, people, resources, products, services, customers, processes, etc.
- Ability to work on, share, and manage models in a collaborative online environment.
- An interface and methodology that is intuitive and easy for business users of all types to use.
- A set of reference model frameworks that accelerate adherence to desired industry standards.
- Ability to roll multiple models up under a single framework and overall enterprise model.
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:
- Ability to model not only the process itself but also all of the people, systems, data, services, resources, and associated interdependencies associated with that process.
- Ability to work on, share, and manage process models in a collaborative online environment.
- An interface and methodology that is intuitive and easy for business users of all types to use.
- A built-in set of optimization algorithms and methodologies that are proven and that meet your specific industry and process needs.
- Ability to import Visio diagrams so you can use what you have as a starting point.
- A clear technology path for automation and deployment of process models – either a packaged connector to a third-party BPM system or ideally a shared framework with a BPM platform from the same vendor.
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:
- Ability to support the entire process life-cycle, including process design, automation, integration, monitoring, analysis, and simulation.
- Ability to fully support both human-centric and system-centric processes on an enterprise scale.
- Ability to integrate with a diverse set of systems, platforms, and services.
- An interface and methodology that is intuitive and easy for business and IT users of all types.
- Proven results and a track record of rapid deployment and flexibility to adapt to change.
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.
Comments