Model-Based Workshops
Models are often built interactively in facilitated modeling workshops, with subject matter experts talking about the business and a modeler changing the models on the fly. Workshops are group activities. Several subject matter experts—each with different knowledge and understanding—collectively build a model. Together they reach a common understanding.
We describe model-based workshops in two chapters. In this chapter we detail what a model-based workshop is, and in Chapter 9 we explain how to run one effectively.
In Chapters 4 and 5 we explored how the restaurant Portia is organized, who performs business processes at the restaurant, and what those business processes are. We examined organization models and business process models to understand why customers are experiencing delays before they are seated. But in practice how are these models created? What approach is used to create them?
One approach is to create models from documents that already exist. You start by studying the written policies of the restaurant and the training material for new hires. You then create the models in isolation. All the work can be done without leaving your office.
Creating models in isolation is a poor modeling approach. The existing written materials are always incomplete. Usually they are wrong as well—out-of-date and at odds with actual practice. And in interpreting the written materials, you will make mistakes as you try to understand material created by others—material they understand better than you do. Later we discuss when it is appropriate to create models in isolation, but in general this isolated approach is a poor way to create business models.
Another approach is to create the models in one-on-one sessions with subject matter experts. You meet with the restaurant host and understand how she handles reservations and how she assigns a table to a party of diners. You separately meet with a server and understand how she takes an order, serves the meals, and processes a payment. You meet with the manager to get her view on these processes. You then combine what you have learned into a single model.
When you model one on one, you are not completely isolated from the subject matter experts (SMEs), but you are working in lane isolation. You attempt to understand what each person does in his own business process lane, in isolation from everyone else. You then integrate the model fragments into a single model. After that, you verify the model with each SME, either individually or together as a group.
The one-on-one method presents three challenges. First, it takes time because you need to repeatedly rework the model. You rework the model after each meeting with a SME. You rework the model after you integrate it, because each SME has comments on the new sections of the model she has not seen before. She might have never considered how her activities fit with the activities of others.
Second, in a one-on-one meeting it is difficult to listen to what the SME is saying, to create a model, and to write notes all at the same time. To do all that, you need assistance.
Third, SMEs often disagree. When you work one on one, any disagreements will require you to engage in shuttle diplomacy, working back and forth between the disagreeing subject matter experts to resolve the differences. Disagreements are easier to resolve when the disagreeing SMEs are in the same room at the same time.
A better approach to business modeling is to perform the modeling in a workshop. You collect several SMEs in a room at the same time for a modeling session. You work together to create a model. In a workshop, you can create models in less time, reach consensus quicker, and see how everyone’s work fits together.
In a workshop, you cannot do everything yourself. It is difficult in a one-on-one modeling session to listen, model, and take notes all at the same time, but it is completely impossible when you work with multiple subject matter experts. You will need help. A workshop always involves multiple people playing different roles, in addition to the SMEs.
Workshops also introduce a new challenge: group dynamics. Getting people to agree—people with different agendas and personalities—is hard. It can also be hard to convince a subject matter expert (e.g., a server at Portia) to speak freely in front of her supervisor. Without good management, a workshop is chaotic, accomplishing nothing except the generation of ill-will. Workshops require order. They require someone to manage them. They require facilitation.
Facilitated Workshops
Over the last 30 years, some practical techniques have been developed to organize productive meetings. A meeting using these techniques is called a facilitated workshop. The model-based workshops we describe in this chapter are a special kind of facilitated workshop, one in which business models are created and used.
A facilitated workshop is an organized meeting run by a facilitator. A facilitated workshop will last at least a few hours and could span days. Each of the attendees in a facilitated workshop is an active participant. The participants interact with each other and with the facilitator.
The facilitator manages the workshop and leads the participants. The facilitator is responsible for being objective and impartial. He intervenes when he thinks the workshop is going off-track—for example, when he thinks that a participant is dominating the discussion. But he does not express his own opinions on the topic of the workshop. The facilitator leads the participants in exercises and activities to achieve the workshop objectives. Being an effective workshop facilitator is difficult; it requires training and practice.
The facilitator also has the daunting task of maintaining the social order. Sometimes conflicts arise between workshop participants. The facilitator intervenes, defusing the conflict and depersonalizing the disagreement. The facilitator leads the participants toward consensus.
A good facilitated workshop has a clear agenda and a timetable. No one likes wasting time, and no one likes to participate in a workshop that is unproductive. To be effective, a facilitated workshop must be time-bound and must achieve a particular goal. The facilitator must manage the time carefully, orchestrating the work sessions within the workshop so that the results are valuable and are produced in the time planned.
Facilitated workshops use visual tools. During a workshop, participants observe information created on a white board and recorded on flip-charts. Projectors are used to display slides, demos, and other documents. Visual tools make a workshop more interesting and keep the participants engaged. They also allow participants to track what they have accomplished and where they are headed.
Facilitated workshops use special techniques to build consensus and special techniques to actively involve everyone. A workshop with one active participant and many silent participants is worse than a one-on-one meeting. Like a one-on-one meeting, it reflects the views of a single person, but it is worse because it wastes everyone else’s time. No true consensus is reached. The facilitator must ensure that everyone is involved and that all opinions are heard. At times, the facilitator will silence one participant while urging another to provide her opinion. Sometimes the facilitator will circle the room, asking for each person’s opinion in turn. Sometimes the facilitator will use a voting technique to ensure that every opinion is counted.
A facilitated workshop has a clear desired outcome. The facilitator manages the meeting to achieve a goal or to answer a question, typically a goal posed or a question asked by the sponsor of the workshop. The facilitator does not drive towards a predetermined result. Rather, the facilitator helps the group arrive at an answer to the question or a solution to the goal that reflects their judgment and expertise.
Much has been written about workshop facilitation and the techniques used. In this chapter our focus is solely on model-based workshops—on using the techniques of facilitated workshops to create, correct, validate, and improve business models. To learn more about workshop facilitation in general, we recommend reading some of the many books on the topic [Schwartz 1994, Conklin 2006].
Model-based Workshops
A model-based workshop is a facilitated workshop that results in the creation of a business model. The workshop has a business goal—for example, deciding how to comply with a new government regulation—and business models are created to support the decision making about how to achieve the goal.
A small team runs a model-based workshop. The team includes a facilitator who facilitates the workshop, asking questions, managing time, and drawing out participation from everyone. The team includes a modeler who creates models and captures model-relevant detail. The team includes a scribe who takes notes while the facilitator and modeler are busy performing their tasks. The team may also include an independent subject matter expert, someone who has particular domain knowledge useful for communicating with the workshop participants. (Chapter 9 includes more detail about the roles required to run a successful model-based workshop.)
Suppose you are to facilitate a model-based workshop at Mykonos. The workshop is intended to capture organization models and business processes on the way work is performed at the Portia restaurant. Your stakeholder, the CFO of Mykonos, wants to understand how the long delays that diners are experiencing can be removed, and by removing delays how revenue can grow. In particular he wants the participants to consider whether restaurant pagers will help shrink the delays.
You have reserved a room that has a white board, a projector, and screen. The tables and chairs are arranged in the shape of a U, to create a casual and interactive atmosphere. You greet the participants as they arrive.
A few days earlier, you had sent email to the participants, reminding them of the workshop and its purpose. The participants understand that the workshop is about analyzing how work is performed at the restaurant so that delays can be reduced. They know that pagers for waiting diners are to be evaluated. You expect that this is the extent of their knowledge when they arrive at the workshop. And you expect them to know little about business modeling.
You start the workshop by reviewing the agenda. You explain the purpose of the workshop, who asked for it, and why everyone is here. You explain that the group will first capture the as-is state of interactions and processes at the restaurant and try to understand where delays occur. You mention that in the afternoon the group will explore how pagers could improve the process—how they could make the process easier not just for the customers but for the employees as well. Some in the group laugh in nervous acknowledgment; dealing with angry customers is unpleasant. The explanation also eases their fears. No one is going to be fired and no one is in trouble. Everyone understands that the delays are not their fault and that a solution is likely to improve their working conditions.
Introductions are made around the room. Some people they already know as colleagues; others they are meeting for the first time. You introduce the modeler and the scribe and explain their roles and yours.
You begin the workshop with a short presentation that describes both what a model is and the purpose of the models that will be created today. The participants become excited. They want to share what they do and the problems they are facing. You show some examples of models—similar to the ones that will be created. You also describe the model elements you will use.
To you this might seem straightforward; you have facilitated many similar sessions. But to the participants this is new. They know little about modeling and have never been part of a model-based workshop. They are uncertain. You convey that they need to trust you; models are useful and things will become clearer as the workshop progresses.
You then start the first modeling work session, one to create an organization model. You ask the participants to describe where they fit within the organization, who the different groups are, and with whom each group interacts. As they answer, you draw what they are saying on the board and ask them to validate the correctness of what you are capturing.
While you are facilitating, the modeler is creating the model on a laptop. The scribe is taking notes and occasionally asking for clarification. You are facilitating a model-based workshop.
Workshop Uses
Model-based workshops help realize the business value of modeling. They can be used to deliver and address seven of the eight purposes of modeling we described in Chapter 1. The workshop you are facilitating is a workshop for analyzing a problem and evaluating possible solutions.
A model-based workshop can be used to present models already created. In this case the models are used for communication. The already created models are presented to subject matter experts for validation or to a decision maker to provide supporting material in their decision-making process.
A model-based workshop can be used for training and learning. For example, employees can be trained on a new business process by working through the process in a model-based workshop. Or a workshop could be used to ensure compliance of policies and guidelines.
Workshops are also used for persuasion and selling. In fact, you worked with a pager vendor to design this workshop. For you the workshop is about analyzing the problems, but for them it is about selling pager systems.
If the workshop does result in acquisition of a pager system, the system must be integrated with other IT at Mykonos. The models created in the workshop can be used to understand how employees perform their work and how they will use these systems. The usage scenarios can be used as requirements for the system development.
A workshop can capture intellectual property for use elsewhere at Mykonos: knowledge management and reuse. For example, you might run a model-based workshop with your most skilled servers about how to upsell wine. If you capture information on the way the best servers do this, you can train new servers to use the same methods. Knowledge management is particularly important for companies facing the “big crew change,” when many older employees are about to retire. The models created in the workshop ensure that legacy knowledge is not lost forever.
Model-based workshops support seven of the standard eight purposes of modeling. But model-based workshops also provide other benefits. A model-based workshop is a facilitated workshop, and all well-run facilitated workshops promote collaboration. Employees from different groups—from different restaurants and corporate headquarters—work together in the workshop. They exchange ideas and create models. They learn from each other.
Workshops help participants reach consensus in a collaborative environment. Everyone has a say; the facilitator manages the session and ideas are captured. A model is refined until all agree the model represents their collective understanding.
As the SMEs create the models in the workshop, they develop a sense of ownership of the models. They try to improve the models on their own, finding problems and raising issues. Later they explain the models to others. Models created outside a model-based workshop often lack this kind of ownership. The SMEs feel that the model is someone else’s understanding, not theirs. The models are critiqued, and the consequences of the models are ignored.
Workshops create a common vocabulary. Staff at the newly acquired restaurants use different terms than staff at the existing Mykonos restaurants. The restaurant staff use different terms than the headquarters employees. For example, at one restaurant the person greeting diners is called a “host,” but at another she is called a “receptionist.” At one restaurant there are “servers,” at another “waiters.” At the workshop the participants create a common language that all understand and agree on. When models are created, the participants agree on the name of each model element.
Workshops help participants understand the impact of a change. By evaluating and comparing the as-is and the to-be, the participants can understand how their work will change. They understand the way their organization looks after the change. For example, the Cora Group staff understand how they interact with Mykonos corporate accounting now that they have been acquired.
Workshops are used to validate assumptions. Your stakeholder might have a strategy he would like to test. For example, he could assume that outsourcing information technology to a third-party vendor will save money. Or he could assume that the business process Portia uses for scheduling waitstaff is more efficient than the process used at other restaurants. In a model-based workshop, an assumption can be tested with various SMEs, resulting in either validation or disproof. It is common for a stakeholder to enter a workshop with one assumption and in the process of the workshop discover that their assumption was wrong. For example, your stakeholder might learn that Portia’s waitstaff scheduling business process is unpopular with the waitstaff because it does not reflect when they want to work. As practiced, the business process includes much later schedule rearrangement. A simple simulation reveals how much time and effort are actually spent correcting schedules, and the true costs of the process are revealed. Simulations can inform decisions, often producing results that might at first seem counterintuitive. Chapter 11 explains simulations in more detail.
A workshop can be used to understand the scope of a problem and build a business case. You can use a model-based workshop to evaluate several alternate projects. During the workshop, you evaluate motivations, capture goals, and map goals to the alternative projects. You compare the schedule and cost of each project. You can even perform ranking exercises to help the participants determine which alternative is best.
The Timing of Model-Based Workshops
A project can be understood to have two natural phases. A project starts with a conception phase and is implemented during a realization phase. In conception, the project is evaluated and planned. In realization, the project is started, performed, and concluded. Of course, real projects implement a bit at the beginning, as the project is conceived, and plan (or replan) a bit later, as the project is realized. Projects are often messy, not conforming to the neat separation between conception and realization.
A model-based workshop can support either conception or realization. A model-based workshop can be performed during conception, to evaluate an opportunity. The purpose of the workshop is to understand the opportunity—the requirements for the project and the way to best address those requirements. If the project itself involves business modeling, a model-based workshop can produce a model value analysis (as described in Chapter 7) to determine whether a modeling effort should proceed.
Sometimes a vendor or outside consultant proposes to perform the project for a client. When there is such as vendor/client relationship, the vendor often performs a model-based workshop during project conception, either for free or for a nominal charge. To the client, the workshop helps evaluate the proposed project. To the vendor, the workshop helps sell the project; the workshop is part of the sales effort. In these situations, care must be taken to ensure that the workshop honors the client’s goals. If the workshop is not performed in an objective and high-integrity manner, the client might not realize value from the workshop.
Sometimes a vendor performs a model-based sales workshop internally, evaluating a sales opportunity. The modeling in this kind of workshop helps understand what a prospective client might need or what an anticipated request for proposal (RFP) might include. It helps the proposal team understand the client, the client issues, and what the proposed solution needs to address. (See Chapter 5 for a related case study.)
Model-based workshops can also help a vendor write an effective proposal. Models can be created to trace and map the proposed solution to the client requirements and business processes to demonstrate how the technologies and solution will be used. Diagrams from these models can be used in the proposal itself; they help convey the solution in a way that client personnel can understand.
Model-based workshops are also useful during project realization. If the project itself involves business modeling, workshops can be used to create and validate those models. But model-based workshops can be useful even for projects that are not attempting to deliver any business models. For example, consider a project to develop a new IT system. While collecting requirements for the new system, it is important to understand the business process activities that each software requirement supports. In this way proposed requirements that do not match the business process can be avoided. A model-based workshop can be used to perform this mapping from proposed requirements to business process activities.
Some people believe that model-based workshops increase project costs. This is the view of inexperienced project managers who do not understand the value of modeling or who do not understand the effectiveness of model-based workshops to create business value. In our experience model-based workshops save time and reduce risk by creating consensus around important business challenges, by providing an avenue for raising issues, and by allowing participants to work together to resolve the issues.
Model-Based Workshops for Various Business Purposes
Every project has a business purpose. Some projects have purposes involving strategy—for example, creating a strategy for a business unit. Other projects have purposes involving execution—for example, deciding whether to outsource a function. Still other projects have purposes involving information technology implementation.
During a single project, multiple model-based workshops can serve different business purposes. One workshop can clarify business goals, another can evaluate alternative strategies, and a third workshop can align technology requirements with business needs.
Model-based workshops are useful in a wide range of different business purposes. In this section we explore some of the modeling workshops that we have delivered and how to create a model-based workshop that is appropriate for the purpose. This list is not exhaustive. There are other business purposes we have not described. But we have found these purposes to be the most common.
Strategy Workshop
Organizations are driven by goals, and by strategies to achieve those goals. Some organizations pick a strategy and execute it for long periods of time. Other organizations change direction every few years and some change more frequently, hopping from one strategy to another in an attempt to discover the right one.
A workshop for picking a strategy focuses on the influencers on the organization, and the goals and strategies that best address those influencers. As you recall in Chapter 3 we explored a business motivation model for doubling revenue in a restaurant. There were three alternative strategies: move to new larger location, raise prices, and market to business events. A model-based workshop was used to surface and evaluate those three strategies. First, the alternatives were modeled: What are the competitors doing? What are the problems and goals we are addressing with each alternative? What does the organization look like now, and how might it change after the new strategy is deployed? What are the steps we must take—the roadmap—to deploy the strategy?
Next, a facilitator used a scoring technique to allow workshop participants to rate the strategies. In this situation, people rated on a numeric scale from 1 to 5. The alternatives were rated on several categories: risk, time to execute, difficulty, and perceived benefit.
Finally, the strategies were ranked. The restaurant management team decided that marketing to business events was the best strategy to doubling revenue. Moving to a new location had the biggest revenue upside, but it was judged to be risky and difficult to execute.
Technology Alignment Workshop
All companies need to ensure their technology initiatives meet business needs. In an alignment workshop, participants explore their business goals and strategies and the planned technology initiatives and look at which initiatives achieve which goals and strategies.
Small organizations typically have one technology initiative, or at most a few. Large organizations have many operating concurrently. A huge organization like Citibank or the US Department of Defense will have hundreds of initiatives. But no organization—even the US Department of Defense—has enough money and time to do everything. Picking the right initiatives is important. What are the right initiatives? The right initiatives are the ones that best serve the business goals and strategies.
In an alignment workshop, the participants explore their business motivations, their problems and goals. Then they explore the technology initiatives that are underway and those that are planned. For each initiative, they consider what goals and strategies the initiative addresses.
Often the initiatives are rated and ranked. The initiatives are rated for the coverage of goals and strategies, for risk, for cost, for duration, and for difficulty. Then they are ranked, from the most important and valuable initiative to the least important and least valuable.
An alignment workshop exposes mismatches between the goals and problems of the organization and its technology projects. Participants will discover some projects they are already executing that do not address any goals or solve any problems. They also discover goals and problems they need to address for which they have no project planned.
Sometimes a technology initiative is discovered to have an unfortunate scope. For example, consider an initiative that is intended to meet a short-term goal, but that is scoped to finish after the goal is no longer relevant. This initiative is not useful as it is scoped; it needs to be either rescoped or cancelled.
Solution Rollout Workshop
Sometimes the business challenge is to roll out a solution across a large organization. This challenge is addressed by the solution rollout workshop.
Consider the restaurant pager system we explored in Chapter 5. As we discovered, the to-be business process with the pager system looks quite different from the as-is business process. We need to communicate the new business process to the general managers of the individual restaurants so that they can train the staff.
We also create business interaction and organizational models to show how the pager system will be supported. The general manager needs to know who to contact when the pager system malfunctions. The corporate IT department needs to know how to support the pagers and what processes to use to provide that support. Corporate IT also needs to understand when to interact with the pager vendor and how that interaction works.
The developers or integrators of the solution benefit from the models created in the workshop. By studying the models, they can understand how employees will perform their work and how they will use the system. The usage scenarios become requirements for the system development and deployment.
Mykonos Finance is interested in understanding the impact on the organization. How will the product be supported? Who maintains and operates it? What impact does it have on resources and staffing?
An associated work breakdown structure details the set of activities that must be performed to perform the rollout. Together with business rules, the organization can ensure that budget plans are created for accounting and that legal documents, licenses, and contracts are established by the legal and procurement departments. A smooth rollout depends on many departments within an organization and on a well-orchestrated set of activities.
Outsourcing Workshop
Most organizations outsource some of their work. Some organizations outsource software development; some outsource help desk and customer support; some outsource human resources, accounting, or legal work. Some outsource all these functions and business processes, and other functions as well.
Making good business decisions about outsourcing is often difficult. Will the new outsourcer deliver the same quality? What should be outsourced and what should be kept in-house? How will the rest of the organization adjust to the outsourced processes? Complicating the business decisions are the human resource issues. Will today’s people be reassigned or laid off? How will the outsourcing change the power dynamics in the organization?
To make good outsourcing decisions, you must understand the organizational goals, and how those goals are being accomplished. Like other model-based workshops, an outsourcing workshop involves creating a business motivation model, looking at the problems, goals, strategies, and influencers.
Outsourcing always has a knowledge effect. When functionality is outsourced, the knowledge about how to perform that function is outsourced as well. For example, many organizations outsource the information technology help desk; when an employee has forgotten his laptop password and calls the help desk, someone in the outsourcing company will reset the password. The knowledge and expertise of how to handle IT help desk calls has passed from the organization to the outsourcer. If the organization later wants to insource the IT help desk function, it will be difficult because they no longer have the knowledge in-house.
For the IT help desk function, that knowledge transfer is rarely significant. Most organizations want good help desk support, but few regard the help desk as a core component of their business. They don’t care if they lose the knowledge of how to provide good help desk service as long as they can get that service from someone. But every organization has some functions and some processes whose knowledge is too important to lose. Motivation models play an important role in an outsourcing workshop. When you explore what knowledge is deemed important, you can capture that learning as a goal in a motivation model.
Outsourcing usually changes business processes. The outsourcer performs the IT help desk differently, with different escalation processes and different reporting processes. In an outsourcing workshop you can examine the effect of the process change, looking at what employees need to do, who they will work with from the outsourcer, and how their work must adjust.
The business process changes are affected by the geography of the outsourcing relationship. Sometimes the outsourcer’s employees work side by side with their clients. Sometimes the outsourcer’s employees work across town or across the country. Sometimes the outsourcer’s employees are on the other side of the world. The business processes are different in each of these cases. In the outsourcing workshop, you investigate who does the work and where it is done as part of business process modeling.
System Transition Workshop
Most organizations have a mix of information technology—some new systems and some old systems. Old systems sometimes need to be replaced, either because they are no longer supported by vendors or because they have become too expensive to support—or simply because new alternatives offer important new functionality.
Transitioning from an old system to a new one involves technical challenges, of course, but it also presents issues of acceptance. Sometimes the transition is welcomed by employees: a system is so old that its use slows employees in their work. Sometimes the transition is not welcomed: employees are accustomed to the old system and they resist the change.
System transition always impacts the business. Employees must be trained to use the new system. Business processes are often affected. Sometimes there is an extended transition period when both the new and old systems are run concurrently and employees must use both until it is clear the new system works properly and ties to the older system can be severed.
A system transition workshop allows the participants to explore and understand the impact of the transition. As-is and to-be business process models are created to understand the business process changes. As-is and to-be business rule models are sometimes created to help the organization understand how the new system implements policies and other guidance.
Often organizational models are developed to explore which parts of the organization will be impacted by the new system. These organization models can also include IT organizations to investigate who will manage the new system and who will support it.
Regulatory Workshop
Every organization is affected by governmental laws and regulations. For example, many cities ban smoking in restaurants and bars. Some government regulations affect government agencies themselves. For example, the US Federal Information Security Management Act requires that US Federal agencies manage information securely and certify and accredit information security. And every publicly traded company in the United States is required by the Sarbanes-Oxley Act to have effective internal controls.
Internal organizational policies can be like a law or regulation. When the CEO decides that every improvement project must be justified with a cost-benefit analysis, to the rest of the organization his decision feels like a new law passed by Congress.
A regulatory workshop is a model-based workshop for understanding the consequences of a new regulation or a new policy. A new regulation (or a new policy) will have many consequences. It will affect business processes. It might affect organization and interactions. It will usually affect systems. And of course it affects business rules: The new regulation must be operationalized into the 10 or 100 business rules that implement the new regulation. Other existing business rules must be changed as a result of the new regulation.
In a regulatory workshop, participants begin with understanding the new regulation: What does it mean? They create organization models to understand how the regulation changes existing interactions. They create business process models to understand the business process impact. They might perform simulation to understand the cost and time implications of the new regulation. Finally, they operationalize the new regulations in business rules.
Reorganization Workshop
Businesses often reorganize. Some companies reorganize every six months. Others reorganize less often, but they implement far-reaching changes when they do. Some reorganizations work well and some do not. A bad reorganization slows a company down and makes it less effective.
A reorganization workshop is used to design a reorganization. The participants in the workshop might be starting fresh, considering what new organization would better suit the needs of the business. Or the new organization might have already been announced and the participants need to determine how to make it work.
The focus of the reorganization workshop is to understand the business interactions—which organizations interact with which. Organization models are used. The as-is interactions are compared to one or more to-be models. Participants explore the alternatives and try to understand which is best.
Once the interactions are understood, the participants create process models to examine how work will change. Often the focus of the business process models is the people: who now performs what work?
A business process model can also suggest ways to reorganize. Let’s consider a Mykonos example. At Mykonos the IT organization includes a help desk, application support, and field services. The help desk team takes IT support calls from the restaurants. Application support solves problems with the applications, servers, and databases. Field service personnel are dispatched to the restaurants to physically fix problems and to perform maintenance. The help desk has three people, application support has ten, and field services two.
When we look at the Mykonos IT processes, we discover something interesting. We find that most of the people handle security issues most of the time. Sixty percent of the total labor hours are consumed by security: dealing with viruses, spam email, botnet infections, installing security patches on existing software, and other security-related activities. These security tasks consume all three organizations.
This interesting finding suggests a reorganization. Rather than distributing responsibility for security across the three existing IT organizations, a new centralized security organization is created, with the responsibility of all IT security. This central security organization leads to somewhat better efficiency and much better visibility into IT security.
Merger Integration Workshop
When two companies merge, they combine their businesses to create a single larger business. When one company acquires another, the acquiring company folds the business of the acquired into its own, absorbing the employees, products, customers, and other assets. Mergers and acquisitions are legally different activities, but they have similar business processes. For either a merger or an acquisition, the laborious task is not deciding to combine but performing the merger integration—integrating the operations after the decision to merge is made.
According to several studies, large mergers usually fail: they fail to achieve the economic goals that motivated the merger [DePamphilis 2003]. The merged companies would have both been better staying separate. When a merger or an acquisition fails, the failure is almost always because merger integration was performed poorly.
Merger integration is difficult. The merging companies have different business processes, different policies and rules, different goals and objectives, and of course, they are organized differently. There are often other challenges to overcome: differences in geography, regional or national differences, and different corporate cultures. The merging companies will inevitably use different information technology. To merge effectively, all these differences must be addressed and reconciled.
A merger integration workshop is a model-based workshop that plans merger integration. Typically, a merger integration workshop is held just after the merger (or acquisition) has been announced. The workshop includes participants from both entities to be merged. They work together to design their new company.
The participants examine business processes. Often they decide to adopt all the business processes of one company, but sometimes they adopt some processes from one and some from the other. For example, one company might have a strong recruiting process and the other a superior new product development process. The new combined company will then have both better recruiting and better product development.
The business process decisions have systems implications. The strong recruiting process from the first entity is supported by their recruiting application and so that application is retained in the combined company. The weaker recruiting process of the second entity is supported by a different recruiting application, and that application can be discontinued. But there are inevitably complications. The data from the discontinued recruiting application must be migrated to the retained application. The recruiting application is part of a larger HR package—other components of which are being kept. The recruiting application is also integrated with other applications that are being retained.
Merger integration is simpler when a large company acquires a small one. The business processes and systems of the large company are retained and the small acquired company discontinues its processes and systems and adapts to being part of the acquirer. But even this simpler situation deserves examination. Some of the processes and systems of the small might be better—more agile processes and systems with better architectures that are a better baseline for the future.
In a merger integration workshop the participants create two as-is models and one to-be models. The as-is models represent how the two entities operate today. As-is organization, business process models, and business rule models are created. Multiple to-be models can be created to examine alternatives for the merger. But typically the merger integration must happen quickly. There is no time for alternatives, and the workshop participants create a single to-be model of their vision of the combined entity.
Often merger integration workshops are contentious. The best design for the combined company will differ from the career interests of the some of workshop participants. Conflicts will occur, sometimes even battles as employees fight for their positions. In Chapter 9, we describe some techniques for facilitating contentious model-based workshops.
Business Continuity Workshop
The terrorist attacks of 9/11 exposed which Wall Street banks had good plans for business continuity and which did not. Both the threat of further attacks and the threat of unrelated events—e.g., a pandemic or a hurricane—are leading not just Wall Street banks but many organizations of all sizes to consider how they can function in a crisis or disaster.
Business continuity involves having redundant infrastructure and data backup. It also involves having the processes and extra staff to perform the work when some people are ill or otherwise unavailable. In some situations, remote operations are sufficient. For other situations, work cannot be performed remotely because of security restrictions or other constraints.
The purpose of a business continuity workshop is to create a business continuity plan the business can follow if disaster strikes. Most plans include advanced preparation, some investments the business needs to make before any disaster strikes. The plan is communicated to stakeholders, so it can be widely understood and the mitigating investments can be made.
The participants in a business continuity workshop explore the business implications of a disaster. They try to understand the impact of various disaster scenarios. What if we lose power for several days? What if 60 percent of our employees are either sick or caring for sick loved ones? What if our suppliers are unable to make deliveries? The participants might also explore the IT implications of various scenarios. Can database server support be performed in one instead of two shifts? Can five instead of 12 people accomplish that work? Can three?
The participants typically create motivation models to debate and explore the real goals of continuity. For example, must critical business operations be recovered within 24 hours after a disaster, or is 72 hours good enough? Different continuity goals suggest different strategies.
Workshop participants create organization models to explore which organizations are involved in recovering from a disaster and how those organizations interact with each other. Interactions with customers are also considered, as are those with suppliers, government personnel, and other outside parties. Sometimes business process models are examined to see how the as-is processes are affected by a disaster. Processes can be simulated to see where bottlenecks will emerge under different scenarios.
Performance Improvement Workshop
Most organizations try to improve their own performance. They try to deliver goods or services faster. They try to reduce their own costs. They try to improve their quality or customer satisfaction. They try to reduce the capital tied up in their operations.
A performance improvement workshop is a workshop focused on improving organizational performance. The participants start by creating a motivation model of the objectives for the workshop—e.g., that this workshop is focused on improving customer satisfaction in the order-to-cash process and not focused on other processes or other measures. Constraints are also considered, for example that proposed improvements in customer satisfaction cannot raise the cost of the order-to-cash process.
In a performance improvement workshop, participants construct many to-be models. The participants compare these alternative to-bes with each other and compare them to the as-is model of the existing situation. The participants explore what would happen if they did the same work the same way but were organized differently. They explore what would happen if they changed the business process. They explore what would happen if they incorporated new methods or new technologies to obviate manual work that is done today.
Sometimes these explorations lead far from the as-is situation. For example, consider an IT support organization that is performing a lot of work responding to help desk calls. The workshop participants want to reduce the cost of this technical support and examine outsourcing the work to an offshore business unit, considering how much costs would be saved. They look at handling some of the easier problem with lower-cost (and less skilled) people. They also examine the possibility of reducing the number of tech support calls by eliminating the root causes for the calls, solving the problems before the problems ever occur.
In some performance improvement workshops, the participants identify bottlenecks to remove. For example, in a sales process an engineer is needed to design a solution as part of a proposal. If the right engineer is not available, fewer proposals can be generated, fewer sales will be made, and less revenue can be realized. While investigating the sales process, the workshop participants discover that the engineers also format the proposals, work that can be performed by staff without the key engineering skills. By reallocating work, more sales can be made.
Pursuit Workshop
When a small business makes a small purchase (e.g., a $100 desk), they purchase it off-the-shelf at a retailer. The entire transaction takes a few minutes. But when a large company makes a large purchase (e.g., a $40 million capital markets trade settlement system), a much longer and more careful acquisition process is involved. The large company talks to several prospective vendors. Each competing vendor tries to understand the purchase—what is needed and what is valued by the company. Often the large company creates a request for proposal (an RFP), a document describing what they would like to acquire, asking for proposals to be submitted by the vendors. Each competing vendor submits a proposal, including a description of its solution, what it will achieve for the large company, why it is the best choice, and how much it will cost. Sometimes the competing vendors perform orals, in-person presentations and demonstrations. The large company then chooses which proposal to accept and enters into negotiations with the winning bidder. For a prospective vendor, this is a large pursuit—a multimonth process to try to win a big deal.
Model-based pursuit workshops are useful for vendors engaged in these large pursuits. A pursuit workshop can increase the likelihood of success—the likelihood that a winning bid will be created. It can also reduce the risk of the winner’s curse, the risk that a winning bid will be created that subsequently loses money for the vendor, or cannot be performed as described. The pursuit team chasing a large acquisition will use several sales strategy workshops to shape their pursuit and improve their odds.
The participants in a pursuit workshop create motivation models to explore the goals and objectives of the customer, the purchasing company. Why are they purchasing? What change in their business are they trying to accomplish? What are the constraints they must live within? The pursuit team likely has an imperfect understanding of these motivational issues—unless they are already deeply involved with the customer performing other business. But in any case the participants create a model from what they do understand.
Once the motivation model is understood, the pursuit team uses the motivation model to design a winning bid. Large companies (and government organizations) typically select a winning bid based on a combination of four factors:
2 Technical quality of the solution
3 Business impact of the solution
4 Perceptions and prejudices of the individuals involved in the purchase decision
The motivation model guides each factor.
The motivation model guides the pricing. Pricing a large proposal is largely a matter of deciding what solution components to include and what to exclude. For example, does the customer value 24 × 7 support, or would they prefer a cheaper proposal that includes support only 10 hours each day and only Monday through Friday? Only by understanding the customer’s motivation can good decisions be made.
The motivation model guides the technical solution. When technical alternatives are considered, the one that best addresses the motivation is selected.
The customer is purchasing to accomplish some business performance benefits: perhaps lowered cost, perhaps reduced risk, perhaps improved customer satisfaction. Once these benefits are captured in the business motivation model, exploring the business impact is a bit like the performance improvement workshop described earlier in this chapter. The workshop participants explore alternative business process models, alternative business rule models, or alternative business strategies to see which accomplish those benefits. The resulting models are used in the proposal to illustrate the business benefits of the solution. Simulations can be run to show how the reduced cost or improved customer satisfaction is achieved. These simulations are particularly effective in demonstrations.
Sometimes a customer is interested in how well each vendor understands the business of the customer. Does this vendor really understand our world enough to perform well if we select them? Including business process models and business organization models in a proposal can address these concerns, proving deep understanding.
Finally, big purchases are always human decisions. Some people at the purchasing organization work together to write an RFP, listen to the oral presentations, and select a winner. Each of these people brings his own career goals, prejudices, and preferences to this decision. The pursuit team explores these human dynamics at the pursuit workshop. Who are the critical decision makers? Who is involved in shaping the proposal, and what are the critical concepts and ideas they care about that the proposal should address? What is each decision maker trying to achieve? These human dynamics are captured in organization models.
Workshop Benefits in Summary
Earlier in this chapter we listed and described the various benefits of model-based workshops: analysis of a problem, communication, training and learning, and so on. Some of these benefits are realized at every model-based workshop. For example, every workshop promotes collaboration. Every workshop serves to create a common vocabulary among the workshop participants. Some benefits are realized only at some workshops and not at others. For example, not every workshop builds a business case. Merger integration workshops do not create business cases. Instead the business case for the merger has already been made, and the task is figuring out how best to implement.
Figures 8.1 and 8.2 summarize the business purposes to which a model-based workshop can be applied: strategy, technology alignment, solution rollout, and so on. For each business purpose, Figures 8.1 and 8.2 list the benefits that apply. A full circle indicates that the benefit is often realized for workshops designed for that purpose. A half circle indicates that the benefit is sometimes realized in that type of workshop. A hollow circle indicates that the benefit is rarely realized.
Figure 8.3 shows which models are created in which workshops. In some workshops you will create models from all four disciplines: business motivation models, business organization models, business process models, and business rule models. But more typically in a workshop you will create models in one or two of the modeling disciplines. A full circle in Figure 8.3 indicates that the model is usually created, typically because it is critical for the success of that kind of workshop. A half circle indicates that the model is sometimes created, and a hollow circle that the model is rarely created.
Figures 8.1, 8.2, and 8.3 are based on our experience. They are meant as heuristic advice, not as rigid rules. As you acquire your own experience with model-based workshops, you will tackle new problems, and to solve those problems you will apply different models to these workshops purposes. You might even create entirely new workshop purposes. You will want to refine this advice with the heuristics from your own experience.
Workshop Focus and Deliverables
Workshops must be focused. A model-based workshop needs to target a particular business problem and focus on understanding that problem and solving it. A workshop without a clear focus is confusing to the participants. When a participant is not clear why she is performing the workshop activities, her attention wanders. The resulting models are not useful.
Some workshops are internally focused: focused on issues within your own organization. For example, you might be asked to facilitate a model-based workshop to improve a business process. Your stakeholders want to evaluate a particular process change. What are the impacts of the change?
Some workshops are externally focused: focused on issues at another organization, your client, or your business partner. You can run a workshop at your client’s organization to help them solve a problem. Or you can run a workshop to show how your company’s product can help your client.
Every model-based workshop must produce value. Discussions by themselves are generally not valuable; the discussions are soon forgotten. Instead, a workshop must create a product, a deliverable from the workshop that can be used by others. Some workshops create more than one deliverable.
Not surprisingly, one common deliverable of a model-based workshop is a model. Workshops can produce business motivation models capturing goals, problems, and strategies. They can produce organization models. They can produce business process models, as-is and to-be. They can produce business rule models, capturing policies and guidelines. Sometimes a workshop produces models from several disciplines.
After the models are built, someone creates a workshop report, another deliverable from the model-based workshop. The workshop report is a presentation that distills and summarizes the models for others: for senior management and other stakeholders. In addition to explaining the models, the workshop report also summarizes the model analysis, what the models mean, and what has been learned. Who creates the workshop report? Usually the facilitator does the work after the workshop is over. He sends the result to the workshop participants for their comments and suggestions. Sometimes the participants create the workshop report together as the last activity in the workshop itself.
The workshop report generally includes the business context of the workshop. It describes how the model-based workshop fits into the larger overall project. It describes the accomplishments of the workshop. The workshop report can include a business case for further workshops.
Sometimes simulation results or simulations themselves are deliverables of a model-based workshop. Simulation results are powerful in conveying information about the cost effectiveness or efficiency of different alternatives. Delivering a simulation itself—via a playable user interface—is also powerful. The stakeholders can run what-if scenarios on their own and evaluate the various scenarios from their own perspectives. Chapter 11 describes simulations.
Model-based workshops can produce other deliverables. A workshop that involves business process change may also examine the system impacts of the proposed process change. The resulting system impact assessment is a deliverable that analyzes the systems and other IT technology that are impacted by the proposed process changes. A system impact assessment is not a business model, but it is a natural outcome of some business model-based workshops.
A model-based workshop can also produce project planning deliverables: a high-level roadmap, a prioritization of what should be done next, a detailed project schedule, or a work breakdown structure. The high-level roadmap is a collection of activities, grouping activities by project phase. It shows what activities need to be done and the order in which those activities need to be performed. The detailed project plan describes the proposed project activities, resources, and schedule in greater detail.
When a model-based workshop delivers more than one model, the models can be traced together. For example, a strategy workshop may deliver both a to-be motivation model and a to-be business process model, showing the process that is designed to achieve the strategy. Some of the activities in the process model are intended to achieve particular objectives in the motivation model. Each of those activities is traced to the objectives it is intended to achieve.
The Value of Modeling in Facilitated Workshops
Why are model-based workshops better than more traditional facilitated workshops? In other words, what business value does a business model provide in a facilitated workshop?
Models are useful in workshops because they provide a mechanism for the participants to capture their thoughts in a visual way. It is much easier to view the constructed model on a white board or projected from a laptop than to write it down as notes for review later.
Modeling in a workshop helps the participants reach consensus. Instead of each participant keeping his or her own version of the notes, each individual’s ideas become additions to a single model created collaboratively. The model can be changed during the workshop as participants have new insights and new realizations.
Modeling during workshops allows the workshop participants to explore cause and effect before they actually do anything. The participants explore different policies, different organizational structures, and different business processes and explore the consequences of each. It is cheaper and safer to explore these in a model-based workshop (perhaps with subsequent analysis and simulations) than to actually implement the new policy or change the organization and see what happens. Models are cheaper and safer than reality.
By creating models during a workshop, the participants are creating intellectual property. Often the business models remain useful over time. Others—people not in the original workshop—can later refer to the business process models to understand the way a process is intended to work. A business motivation model can be used to later create a business plan or a business case.
When are Models Created?
When should business models be created? Should they be created during a workshop itself? There are advantages to creating them during a model-based workshop. The workshop participants feel that they are part of the creation. They perceive that they are adding value. They take ownership of the models, feeling that the models represent their beliefs and ideas.
But creating models during a workshop involves some scope uncertainty. The facilitator might not know what modeling is required until the workshop is underway. Is procurement a single process or three? The workshop can run out of time, and additional workshops might need to be scheduled with the participants. Scheduling time with participants is always difficult. Typically, busy participants do not welcome additional workshops that take them out of their day-to-day jobs and beyond their original commitment to the workshop stakeholders.
Another approach is to create some models before the workshop starts. Creating models in advance mitigates the scope uncertainty. With models in hand, it is clear that procurement is a single process, and the size and the shape of the process are clear as well. Models created in advance can make a workshop faster and more productive. The models are modified by the participants rather than created in their entirety, an easier and faster job. Modeling in advance also eases the facilitator’s job as the created models become a natural starting point: is this gateway accurate? Do you perform this activity next? Finally models created in advance make the facilitator look good. They demonstrate her knowledge of the business situation.
Creating models in advance does have a drawback. The participants feel less ownership of the models. Rather than creating the model, the participants modify something that was created by someone else. Instead of collaborating and feeling creative, the participants are commenting and critiquing. The workshop has a negative tone, like a complaint session.
Often a combination is best. You build models before the workshop and then you start the workshop fresh, without those models. The facilitator uses the knowledge of the already created models to drive the workshop. If participants become stuck, the facilitator can ask, “What if we added this activity here?” or “What about this business unit? Are there interactions with them?” Using this before-and-during method, the facilitator is ready when he starts the workshop. He understands the scope of the models that need to be created, but he is not asking the participants to comment on the models that already exist. The facilitator guides the participants to create models that they own.
Modeling is iterative in nature. Often one workshop is not sufficient to create the necessary models. Depending on the size and complexity of the models, a series of workshops might be necessary.
Between one model-based workshop and the next, you refine and improve the models. Typically, models created during a workshop are overly complex and need to be simplified and refactored. Typically, they are also ugly and need aesthetic improvements. Sometimes there are other problems: model element naming or scope issues. After a single eight-hour workshop, you might spend 20 hours improving the resulting models. (Chapter 7 explains techniques for creating a good model.)
After models are refined and improved, you must present them to the participants. They need to see the changes you made to their models—the models they created at the workshop and that they feel they own. If you present them, usually participants accept the changes, seeing those changes as improvements that retain the knowledge and spirit of their original work. Of course, your refinements could have introduced errors, and when you present the newly refined models, they can spot the errors.
Case Study
Healthcare is financed differently in the United States than in other parts of the world. Most people in the United States subscribe to health insurance from a private company, a health insurer. Some of these health insurers cover subscribers across the whole United States, in all 50 states. Other health insurers have more limited geographical coverage, offering health insurance to people who reside in some localities but not to those who reside elsewhere.
A client of ours is a healthcare company offering health insurance coverage to employees of companies across the country. Our client does not run its own business processes to receive health claims or to issue payments. Nor does it own the necessary information technology to support those claims or payment. Instead, our client contracts with another company to perform these services. This services company receives health claims and issues payments to members—patients—and to healthcare providers—physicians, hospitals, labs, and pharmacies—on behalf of our client.
As with any partnering relationship, our client wanted to ensure that if the services company became unable to provide services for any reason, our client could switch to a backup entity for claim processing and payment services. The backup entity was to be another services company, selected ahead of time, ready and willing to provide those services on short notice. To mitigate the risk of over-dependence on the services company, our client was willing to pay a suitable backup entity, just for the ability to be ready to take over if needed. Our client prepared an RFP for those backup services.
But a potential transition from the services company to a backup entity would not be easy. The healthcare insurance company’s program was performed by the services company staff and run on the services company computers—computers that also support other healthcare customers. If a transition were to occur, how could our client’s members be separated from other members? Could patient privacy be maintained if operations were to transition to the backup entity?
We worked with our client to explore the issues surrounding this potential transition (or portability) and to reach consensus among the stakeholders on a portability approach. We conducted 18 workshops to explore the issues and reach consensus and to help our client prepare the RFP for the backup entity.
We conducted business continuity workshops with key stakeholders and department heads, including both business subject matter experts and information technology subject matter experts. The focus of the workshops was to ensure that both the goals and timing of the transition were clearly understood and that the participants agreed on those goals and timing. The workshops also looked at the ways a transition would impact IT. The results of the workshops were captured as a business motivation model, with goals, problems, and strategies.
The modeling team facilitated a second series of workshops to understand how our client interacts with the services company today in providing health coverage for its members. They created an organization model with interactions between the two organizations. The purpose of this model was understanding what service a backup entity would need to provide if the transition were to occur. The model also examined the dependencies of our client on the services company. Each of the dependencies would have to be untied if a transition happened.
Business process models were created as well—not of every process performed on behalf of members but of a few critical processes. These business process models showed who in our client and who in the services company performed what activities. In the event of a transition, the services company activities would need to be performed by someone from the backup entity instead.
The workshops provided several benefits for our client. First, some previously unrecognized dependencies on the services company were identified at the workshops. Each dependency needed to be addressed in the go-forward plans, and each had an impact on the RFP for a backup entity. Second, over 50 gaps were identified. These gaps were problems that had to be solved before a transition could occur. Most of these gaps were technical problems. For example, one gap involved IT backups and patient privacy. Every IT organization periodically creates backup tapes to make it easier to recover from a variety of IT problems. The services company tapes included patient data from our client’s members as well as patient data from other services company customers. During a transition the tapes would need to be shared with the backup entity, but since the tapes contained patient data from other customers, the privacy of patients would be violated if the services company shared the tapes. To prepare for portability, the tape copy process had to be changed.
Third, the workshops supported better mutual understanding between senior management and operations. The cross-functional team was able to better understand the goals and objectives and the impact of those goals and objectives on the transition plan. For example, operations originally assumed that any transition would span 90 days. However, during the early strategy workshops, a senior manager explained that only the contract transition could span 90 days. The business processes for processing claims and issuing payments must be transitioned within 72 hours so that there are no significant interruptions to the patients and their healthcare providers. Obviously, a 72-hour transition is more difficult than a 90-day transition: it requires different processes and a different approach.
The workshops produced additional value beyond the identification of dependencies and technical gaps, or the promotion of mutual understanding of the business motivations. The workshops identified several transition processes that needed to be created—one-time processes to perform a rapid transition from the services company to a backup entity. The models produced in the workshop documented the way our client did its work. When a transition to a backup entity occurs (if it occurs), the models will be used for training that backup entity.
The workshops also looked at the technical infrastructure: the software and hardware that supports the transitioned business processes. Each application in the technical infrastructure was traced to the gaps and to the business process activities. The tracelinks help answer impact questions. If a gap is not addressed, what issues arise? If claims are transitioned first before other processes, what hardware and what applications are affected? Which organizations use that process? Which organizations use those systems? Exploring these impact questions is important to creating good plans.
Our client saw benefit in model-based workshops and benefit in the rigor that the workshops provided. The workshops helped the management team shape their approach. The workshops helped achieve consensus. The modeling allowed the company personnel to understand and articulate the scope of the RFP and required transition. Finally, the model-based workshop allowed the company to create a timely RFP.
A model-based workshop is a facilitated workshop performed for the purpose of creating business models. Model-based workshops can be performed during the conception of a project—to scope its effort—and during the execution. Model-based workshops have proven useful for many different business purposes, including developing strategy, aligning technology to business needs, rolling out solutions, implementing outsourcing, transitioning to a new software application, ensuring compliance with regulations, reorganizing, merging, planning for business continuity, improving performance, and pursuing new business.
Chapter 9 explains how model-based workshops are run. We describe phases of a workshop and types of participants as well as how to create an effective workshop and avoid some common pitfalls.