This white paper demonstrates the use of IBM WebSphere Business Modeler Advanced (WBM) to define, simulate, reengineer, and improve Information Technology Infrastructure Library (ITIL) processes, as well as some additional uses of WBM. Unless otherwise noted, this white paper refers to IBM WebSphere Business Modeler Advanced v. 7.0.
IBM's WBM is a process modeling tool that provides capabilities not found in many process modeling tools available in today's market. WBM lets users create, define, model, simulate, and analyze various processes in order to better understand how those processes work in a live business environment.
Most organizations have a need to define and understand how various processes used throughout their business work, and often need to make changes to those processes in order to increase business value. Unfortunately, there are very few methods available to make changes to a business process without risk of negative impact to the business. WBM not only provides a way to visually define process flows, but also a way to reengineer and simulate process flows. Simulation of process flows provides empirical evidence that lets decision makers modify and improve processes while minimizing the risk of those changes. In other words, WBM provides a way to demonstrate how a change will affect a process in a safe manner before that change is implemented in the live business environment.
Some of the key features of WBM include:
While this paper primarily discusses how WBM can be used as part of an adoption of service management best practices, WBM is a tool that supports many uses in an organization and is often seen as part of an implementation of Service-Oriented Architecture (SOA).
ITIL is a set of best practices that define various common activities that organizations perform. ITIL is the de facto approach that organizations delivering services follow. For example, ITIL defines processes such as change management, incident management, problem management, and request fulfillment, among many other processes, that are common processes that many organizations perform to underpin their business activities. Many adoptions of ITIL suffer from a lack of an ability to model, simulate, analyze, and ultimately improve these various service management processes, resulting in reduced efficiency and effectiveness of an investment in service management.
ITIL encourages organizations to be formal about how their services, processes, roles, and resources are defined and managed. Many organizations suffer from a lack of formality in key areas. This information often leads to inconsistency, and inconsistency in operational behavior tends to lead to increased costs of IT support and lower quality.
In this white paper we use a common service management process, incident management, to demonstrate the capabilities of WBM, as well as how organizations can exploit WBM to gain business value. Incident management refers to a process design to handle common everyday interruptions and degradations of service that most organizations spend significant amounts of their budget handling. Incidents are interruptions or degradations to services. Imagine an organization has promised that a service will behave a certain way under certain conditions. When it doesn't behave in line with that promise, ITIL refers to that as an incident. Common examples of incidents include a network latency issue that impacts the business, an interruption to an online system that prevents the business from performing work, or a failed change to an IT system that has caused significant business impact.
Figure 1. Defining a Simple Process
Defining a new process is simple in WBM. The new process wizard is invoked to provide the ability to name and describe the process. In this case, I've chosen to model an ITIL incident management process and given it a fitting description.Very little information other than a name is required to define a new process in WBM. However, the more information at hand during process definition, the better understanding of that process the organization will have. WBM is best used when working with a full and complete set of information about various aspects of an organization's processes, including the inputs used and outputs created, resources and roles involved, as well as what the various steps of a process cost the organization, and what revenue, if any, they produce. This level of information about processes will ultimately support the ability to simulate process activities and make decisions based on the results of those simulations.
Organizations must be diligent to avoid using WBM as simply a way to create diagrams of processes; rather, WBM should be used to document details of processes in support of simulation activities.
Figure 2. Process Diagram Layout
Next, I will choose the layout of the process, either free-form or swimlane. Swimlane is typically used when a rolebased view of process activities, and an understanding of the how process flow moves between roles, is required. Once I click "Finish" on the layout dialogue, I have a blank process workspace. Using the blank process workspace, I can then add in the various tasks and other objects to define the process. The purpose of this is to provide a simple example. In this case, I'm showing the first part of an incident management process.
Figure 3. Part of an ITIL Incident Management Process
To illustrate the use of business items, the process flow below shows the same, first part of an incident management process, but with some business items added.
Figure 4. Part of an ITIL Incident Management Process with Business Items
Business items in a process flow can represent inputs that are used by an activity, as well as outputs produced by an activity. In a more complex process flow, multiple business items would be in use, and changes would be shown throughout the process flow to those business items as process actions completed. In this case the business item "Incident Ticket" has been added as an output of several process activities.
Business items, and how WBM manages them, become an important aspect of using WBM as an organization develops more of its process collateral over time. Having an understanding of business items and how they are transformed by process activities is a key aspect of WBM that supports an adoption of service management best practices. In other words, ITIL would say that an organization with an understanding of the various business items that its organization creates, uses, and destroys, tends to perform better in the business environment than an organization that lacks such an understanding.
Once a flow of process activities is defined, more detailed aspects of that process can be defined within WBM. For example, consider the first step in our simple process flow, "Incident Is Received". Using WBM, I would add the following:
Figure 5. WebSphere Business Modeler Task Attributes
On this detail page I've added information about what the process does. Using the tabs at the top, you can see that I can also define cost and revenue, duration, inputs, outputs, resources, organizations, classifiers, and forms for this process task.
Figure 6. Cost and Revenue Attributes
In this cost and revenue tab for a process activity, I can define various costs and revenue associated with different aspects of the process activities, in numerous currencies. I can also define costs and revenue that are specific and well understood, as well as costs and revenue that are variable but follow a predictable distribution. The ability to define costs and revenue for process activities is an important feature that supports the ability to simulate processes.
Figure 7. Duration Attributes
The duration tab can be useful in service management process definition as well. It is used to define the length of time that an activity runs before the task is completed, as well as the maximum time an activity is allowed to wait on something.
Figure 8. Process Inputs
Inputs are data, information, and other objects that the process activity consumes. In this case, we can define simple inputs or more complex inputs in the form of business items used by that process activity.
Figure 9. Process Outputs
Like inputs, various simple or more-complex outputs of a process task can be defined within the tools, as well as state changes that occur when the activity is complete. In this case, I've used the "Incident Ticket" business item as an output of the "Incident Is Received" task.
Figure 10. Resource Definitions
In this resource tab role, individual resource and bulk resource requirements can be defined. In this case, I've defined a role requirement called a "Service Desk Agent" and I have specified that the role requires two minutes to complete this task. Individual resource requirements are a way to specify people, and bulk resource requirements are a way to specify consumables used by a process. Resource information is important, particularly when a process activity will require the use of a specially skilled, trained, or licensed resource. The time information defined for resources will also be important once a process is simulated, as it will impact how long a process runs.
Note: Organizations, classifiers, and forms are outside the scope of this white paper.
The ideal way to use WBM is to work with stakeholders to define an initial set of business items, roles, resources, and process activities representative of a service management process in an organization. Then, using WBM, define a new process space and add and arrange the tasks according to the process flow discussed with stakeholders. Once the process flow is visually defined within WBM, specific detailed aspects of the various process activities can be defined within the tool.
A finalized process flow will contain a wealth of information not only about the tasks in a process, but information about the people and roles involved; how much those roles cost; the time each activity takes; what business items are used, created, and consumed; as well as many other detailed aspects of a process. The more detailed that information is defined within WBM, the more predictive a process simulation will be.
Being able to simulate and predict how a process will run in a live environment is a very rare capability in service management initiatives. Most service management initiatives fail to use a tool like WBM, and instead opt for a trial-and-error approach to arriving at the right set and maturity of service management processes in an organization.
One of the most useful features of WBM is the ability to show visually how inputs and outputs change throughout the course of a process.
Figure 11. Transformation of Inputs and Outputs
For example, in the process snippet above, notice how the output "Incident Ticket" shows an image once it leaves the "Incident Is Received" task, but a different image is shown once the output leave the "Incident Is Identified" task. This demonstrates how process activities can change the state of a business item, and how that state can be used to visually represent how process inputs and outputs change throughout a process.
Once a process flow has been defined, and all of the detailed aspects of process specific within WBM, it is possible to simulate the process. Simulating a process is straightforward. Once a process has been defined, saved, validated, and ensured that it doesn't have any incomplete paths or errors, a simulation profile is built by right clicking on the process and choosing "simulate." The following is an example of a simulation flow that is created.
Figure 12. WebSphere Business Modeler Simulation Profile
Notice on the tab title how the simulation flow has the date and time that it was saved? This is useful, as it provides a simple way to manage and track simulation activities over time. Once a simulation flow is created, it is then possible to click on the simulation flow and choose "run simulation". When a simulation is run, an output is produced showing when the simulation started, when it ended, the total revenue, total cost, and total profit.
Figure 13. Simulation Output Example
Additional analysis can be done to better understand the impact of all aspects of the process, including specific tasks, role, and resource requirements and impacts. Again, organizations that can simulate processes and process changes before deploying them to the live environment will tend to produce more predictable results during process reengineering and improvement activities.
Over the course of any service management process definition or reengineering activity, effective use of WBM would result in several different simulation profiles and multiple results from completed simulations. The idea is to define a process flow, simulate it as a baseline, and then make a small change and run another simulation to see the effect of the change. Organizations can use this feature to experiment with different structures, constraints, costs, resources, probabilities, and roles for a process in order to compare results and make informed choices about process definition and reengineering activities.
The ability to create and use such empirical results is one of the key differentiators of WBM when compared to other process definition tools. Using WBM makes it is easy to define processes and their relevant aspects, and it is incredibly easy to then simulate and compare different versions of a process until a desired result is achieved.
Using WBM, an organization might define an incident management process as done in this white paper, simulate that process to understand the costs and resource requirements, and then consider that process the baseline incident management process for the organization. This could be considered an "AS-IS" process.
As time passes, the organization might realize a need to make a change to the incident management process. For example, consider the following:
Figure 14. A Reengineered Incident Management Process Flow
In this reengineered process flow, we've added a step where a service desk lead reviews all logged incidents. Imagine a case where an organization is having problems with service desk staff incorrectly logging incident tickets. One valid, possible solution would be to add a step where a lead service desk agent checks the work. If this organization were using WBM, rather than making this change initially in their live environment, they could copy the existing baseline incident management process, make the modification in the copy, and then simulate the new, updated process. The results of that simulation could then be compared to the current version of the process, and decisions made accordingly.
While sometimes things like adding a manual check-off step, as above, seem like a good idea on paper, under the light of being simulated they might have a detrimental impact to the time required to the complete the overall process, and therefore might not be acceptable. Historically, an organization has to make that type of decision without an ability to simulate and test various options. Using WBM provides the organization with a way to make decisions based on quality data and documented underlying assumptions. This is an important reason why a tool like WBM is essential to service management initiatives; it allows the organization to challenge haphazard and pointless changes and the introduction of manual steps when empirical evidence from simulations shows that doing such results in increased cost and lower levels of revenue.
WBM provides both an ideal environment for document the current state (or AS-IS state) as well as planning future states (or TO-BE state) of numerous service management processes. While this white paper shows some very simple activities using the ITIL Incident Management process as a backdrop, realistically, any of the twentysix service management processes defined by the current version of ITIL could benefit from being defined, simulated, and improved within WBM.
Service management is a very broad topic that covers everything from topics that organizations are often somewhat skilled at doing (such as incident management) to activities that organizations are less knowledgeable about (such as service portfolio management). An ideal way to use WBM in conjunction with a service management initiative is to document within WBM the process areas where the organization clearly demonstrates maturity. Once the organization learns how to use simulations to make small improvements to its processes, it can then use its newly defined roles, business items, and other process artifacts to document other service management activities that need improvement. The organization not only gains skill with WBM, but creates empirical evidence that shows a commitment to improvement, as well as a better understanding of the processes in use in the environment.
The real key to improving service management processes using WMB is to make effective use of the simulation feature of WBM. This requires an in-depth understanding of how to document the various roles, responsibilities, resources, business items, and attributes of process tasks that affect the way the organization works. Most service management initiatives lack these capabilities, as they are often using a static process-modeling tool that simply provides the ability to show a picture of a process. In such a case, a process change would have to be made in the live environment, which entails unacceptable risk. WBM provides the ability to make countless changes in a process flow, and simulate and quantify the effects of those changes, while generating evidence that justifies improvement initiatives.
When beginning to apply ITIL best practices, organizations rarely take time to document the state of things. Without establishing such a baseline or starting point, over time it becomes impossible to calculate a return on investment in ITIL. More than one company has abandoned a service management initiative because of a leadership change involving the new leadership asking about the value of the investments that were made in service management. When the IT organization can't answer that question, it's all too easy to abandon the service management initiative. Effective use of WBM can provide that evidence over time that shows where the organization was when it started, and what the effect of various improvements was upon not only the flow of process activities, but potentially both cost and revenue. Rarely can an IT organization empirically quantify its effect on an organization's revenue. WBM, when effectively deployed, provides that capability.
Many service management programs, particularly those that are in support of an organization's pursuit of ISO/IEC 2000 registration, are often subject to a series of internal and external audits. A typical service management audit will look for two types of evidence: evidence of intent and evidence of action. Evidence of intent is demonstrated proof that an organization has understood and documented how work should be performed. For example, an organization that has documented process flows, role definitions, and other collateral is able to demonstrate evidence of intent. Evidence of intent is what the organization wants, or intends, to happen.
Evidence of action is proof that the intent was followed. For example, if an incident management process indicates that an incident ticket is created, then the organization should be able to show evidence in the form of incident tickets. Evidence of intent demonstrates that the organization does what it says it does.
During a service management audit, many organizations struggle with producing evidence of intent because they often don't have process flows, role definitions, or other important service management artifacts documented. Or just as often, organizations will have these items documented, but not in the same consistent manner and not stored in the same repository. In other words, evidence of service management intent often exists in organizations, but quite frequently organizations don't know where it is.
WBM provides a consistent method for documenting service management process activities and details, as well as a single repository that can be used to train the organization about how process activities are intended to work. Additionally, this single repository of service management process information can be used as a source of evidence for an audit of intent.
Linking design and development activities with service management activities. Service management, as described by ITIL, is primarily geared toward managing the operational aspects of an IT environment. Certainly there are many touch points with development activities, but ITIL is not really focused on making organizations better at development. This is complicated by the fact that often, organizations that do both everyday IT operational support and conduct development activities, frequently use different processes and tools for both aspects of the organization, which often exacerbates the already poor link between development and operation activities.
Development teams can also use WBM since it integrates with other products in the IBM WebSphere product suite, including IBM Integration Designer. Process flows can be defined in WBM, and then specified using IBM Integration Designer. IBM Integration Designer turns the WBM-defined resources, process flows, business items, and services into reusable components in service-oriented architectures. By using these products together, organizations create clear links between the operational state of a process and what developers are building.
As part of an overall IBM product suite (and linking to ITIL and service management). WBM integrates with many other IBM products, including WebSphere Service Registry and Repository, WebSphere Enterprise Service Bus, and IBM Business Monitor. As a key part of an organization's decision to use IBM's suite of products, WBM links the use of these products with the organization's adoption of ITIL and service management best practices. While WBM is most often used in discussions around SOA, there is a case to be made for WBM providing a way to link SOA initiatives with ITIL and service management initiatives.
Creating stub code and Web Services Description Language (WSDL) for IT services. Once an organization has used WBM to define a process flow, it is then possible to use WBM to create stub code and WSDL for IT services. Stub code can be thought of as a skeletal structure that will be used to further define some aspect of a computerized system. WSDL refers to an XML document that describes a web service. WBM provides the ability to generate this information automatically from within the tool, which saves time when developing process flows and services defined within WBM.
WBM can be used in conjunction with an adoption of ITIL best practices. It is a full-featured process modeling and simulation tool that fits well with other IBM products that are used to define various service management processes and activities.
WBM provides both the ability to visually define process activities and the ability to define detailed information about processes, including inputs, outputs, cost, revenue, roles, and resources. Additionally, WBM has the unique ability to visually show how a process transforms inputs and outputs throughout the course of executing process activities.
An important key feature in support of process improvement and reengineering activities is WBM's ability to simulate a process and generate empirical evidence. This allows more organizations to make knowledgeable process improvements without risk of negative impact to their business.
With WBM, organizations get a consistent method of understanding processes as well as a single repository of process information, which can be used in support of both internal and external audit activities. From a service management perspective, this is an important capability for any organization pursuing ISO/IEC 20000 registration. Finally, WBM is an effective tool for organizations seeking to adopt service management best practices. It is also useful when organizations are implementing SOA, and for linking what an organization's developers are doing with how the organization's operational aspects are carried out.
Michael Scarborough has worked in information technology since the late 1980s in various roles including direct hands-on operation of IT systems, leadership of complex projects, establishing multi-platform automation, management of information security projects, and adoption of service management best practices. He has helped numerous organizations in various industries adopt ITIL best practices and is an ITIL v2 Service Manager, an ITIL Expert, a PMP, and a CISSP. Michael currently helps large and small organizations make significant improvements through adoption of ITIL best practices and regularly delivers ITIL training at all levels on behalf of, and is the ITIL Portfolio Course Director for Global Knowledge.