December 22, 2008

Business Architecture

Posted by Zahavi under Explaining | Tags: |
Leave a Comment 

What is business architecture? Given recent discussions at the OMG business architecture working group it seems there isn’t quite a consensus on the definition as yet. Some think there is overlap between business architecture and enterprise architecture. A business architecture can be part of an enterprise architecture, but many enterprise architectures focus on technology and only recently organizations have begun to look at enterprise level and cross business-unit business architectures.

Some think that a business architecture is about how the business is performed, its business model and structure. For example, whether a chain of restaurants is company owned or franchise owned.

Some think it is a description of how the various specific business models relate to each other. They believe the various models, such as business process models and business motivation models comprise components or layers of an overall business architecture. Some think it is a list of the specific standards themselves. Standards such as the Business Motivation Model (BMM) and Business Process Modeling Notation (BPMN.)

We named our book business modeling instead of business architecture specifically because of this confusion. The word architecture itself is often perceived to be technical by business people and does not resonate with them. But the term will be used by others so it is important to understand how it fits.

I think the purpose of a business architecture is somewhat analogous to a technical architecture. A technical architecture describes how a solution or system behaves and how it is structured. Specific architectural frameworks (such as TOGAF) describe how to organize an architecture (such as its layers and views) and which standards are applicable.

Similarly, a business architecture should capture how the business behaves and how it is structured. This information is captured using various business models but a set of business architectural frameworks should be the ones that define how particular models relate to each other, what their touch points are, and what standards might be used as part of the architecture. The OMG could produce such an architectural framework to support the creation of business architectures.

For example, the OMG has tried several times in the past to define an organizational structure or organization modeling standard. Such a model seems to be a basic model that is needed in business modeling and we describe it in our book as a separate modeling discipline. Yet, OMG has not been able to standardize an organization modeling standard on its own. Several other OMG business standards reference or require some form of an organization model. Should the definition of an organization be defined as part of those standards? If we do that how will we ensure that there is consistency and alignment between all of those definitions of an organization? This should be the purpose of the business architecture framework, to ensure such alignment occurs.

In the March 2009 OMG meeting in Washington D.C., the business architecture working group will attempt to reach a consensus on the definition of a business architecture and on its components. The group decided to start by identifying the overall categories that make up a business architecture and then drill down into the specific sub-components and standards that support them.

This is exactly the approach that we took in describing, what we called, the modeling disciplines. We named four: the business motivation models, the business process models, the business organization models, and the business rule models. With these as a starting point, it is much easier to identify the relationship between the various models and the applicable standards that support them. Once an architecture framework is created that identifies the components and modeling standards that support them, it will be possible to create business architectures based on the framework.

 

December 20, 2008

Model documentation and the platonic fold

Posted by bridgeland under Model documentation
Leave a Comment 

Most business models are documented. The modeler writes text that explains the model. The text serves as an introduction to others who later explore the model, trying to understand what it does and how it works. Of course the later explorer may be the modeler himself, forgetting the details he created a few weeks or months ago. (I am famous for not understanding models I built myself, only days before.)

What should be documented? Every named model element needs some explanation: every activity and gateway in a business process model, every rule and noun concept in a business rule model, every objective and opportunity in a business motivation model, and every organization and role in a business organization model.

In the book, we describe model documentation, including providing advice about what should be documented: “… every named model element should have a written description. The description of a model element should be a paragraph or two that is easy to read and easy to understand by someone who is not a modeler. Any model element should be a good starting point for a model; someone should be able to start his tour of a model by examining any model element, reading its description, and working out across its associations to other model elements.”

Some people think that every assumption in a model should be documented. Documenting assumptions has never made sense to me. A model is made out of assumptions. Assumptions are the bricks and mortar of modeling. It is assumptions all the way down. So documenting assumptions means documenting everything in the model, not a completely different idea than documenting every named element, but not entirely helpful as advice.

But there is a useful related idea about model documentation, a way to think about assumptions and documentation that yields particular insight. In his book The Black Swan, Nassim Taleb introduces the term platonic fold, “the place where our Platonic representation enters into contact with reality and you can see the side effect of models.” The platonic fold is the gap between model and reality.  He described his work as a Wall Street trader as studying “the flaws and limits of these models [by which others valued financial instruments], looking for the Platonic fold where they break down.”

In the capital markets, Taleb noted that price changes were modeled as Gaussian distributions, with frequent small changes and infrequent large changes. Extremely large price changes are then extremely infrequent.  But Taleb suspected that such extreme changes are not as infrequent as the models predict, infrequent to be sure, but to a lesser degree than predicted. Taleb investigated the platonic fold between the frequency predicted by the models and the frequency actually experienced.

So what? So what if the capital markets don’t behave like the model? In the capital markets, the existence of the platonic fold is an opportunity to make money (or to lose it).  Financial instruments that benefit from these very large price changes are underpriced, worth far more than their price because they were priced by people running models that dramatically underestimated the likelihoods.

And of course Taleb made money. He made a small fortune in 1987 on the 23% one day decline in the stock market, a decline that some models predicted would happen once every trillion days, i.e. once since the beginning of the universe. Clearly the models were wrong. They grossly underestimated the likelihood of that event. Taleb made piles of money again in 1998 with the collapse of Long Term Capital Management, a model-based hedge fund that lost $4.6 billion, despite a staff that included brilliant mathematicians and two Nobel prize winners. This year Taleb is a star. His black swan ideas and his critique of corporate risk management have been proven right in the financial collapse we are all experiencing. 2008 was greated as the year of the rat, but it has become the year of the platonic fold.

What does this mean for us business modelers, for those of us who model businesses not capital markets? The idea of the platonic fold is useful for us. When we create a model, we are aware of the simplification we are performing. When we model the organization of an insurance company, we are aware that our clean and simple model ignores the ad hoc task force established by the Director of Human Resources to reduce recruiting cost. That ad hoc task force is in the platonic fold of the model: it is not part of the model but it is part of reality. Of course we could model the task force, bringing it out of the fold and into the model, but much else will still stay in the fold. All models are wrong; some models are useful.

We are aware of the platonic fold when we model, but our awareness is fleeting. Soon we move on from modeling the insurance company, and the ad hoc task force is forgotten. Others who examine the model will not know. If the model is deployed in a software engine, the ad hoc task force will be forgotten, and hence unsupported.  The platonic fold fades into invisibility.

But we can do something about the platonic fold during our fleeting awareness of it. We can document it. We can write some words about the ad hoc task force, explaining that it exists in the world but not in the model. Others who later examine the model can read about our realization of the fold. We can make the fold visible.

When we document the platonic fold, we are writing not about the model, but about how the model is wrong. This is a curious kind of documentation. It is like an antiresume, a resume of one’s failures, shortcomings and lack of experience. (The antiresume is another Taleb idea, and an amusing one. What if everyone maintained an antiresume? Mine would include an utter ignorance of both business law and accounting. What’s in your antiresume?)

Documenting the platonic fold is a bit like the (mistaken) advice of documenting assumptions. It’s a similar idea, but to my mind documenting the platonic fold is much more useful. Anyone who uses a model will want to know its limitations.

 

December 14, 2008

Business models support communication

Posted by Zahavi under Value | Tags: |
Leave a Comment 

In our book we discuss several purposes of business modeling: communications, analysis, compliance management, requirements for software development, direct execution in software engines, building models for persuasion, for training, and for knowledge management (discussed in previous blogs entries.) Seven of these involve communications in one form or another and this makes communication one of the primary uses of business models.

Modeling supports communication because it supports different levels of detail.
Different people in a business need different levels detail. For example, when evaluating another company for an acquisition, different people in different departments will need different levels of detail because they are interested in different aspects of the business. The marketing department will want to know how well the new acquisition fits the existing portfolio of companies and whether it is similar enough to the existing holdings, brand and strategy. Marketing needs to understand the customers, locations, and competitors. Operations will be more interested in how well the potential acquisition is run. Operations needs to understand the organization, processes, and policies. The executive team will want to know how the business is performing. They want to understand finances and strategy.

Business models support the presentation of different detail to different audiences. To operations, you can show a detailed model of the business processes for processing a customer’s order. To marketing, a high level model showing the interactions between the customer and different groups within the company is sufficient, so they are aware of the commitment to customer support. To the executive team you can show a business motivation model so that they understand what the company is trying to achieve and if it is in alignment with their overall strategy.

Business models are effective for communication because most models are visual. We humans are visual beings; we have sophisticated visual processing engines built into our brains. Most business models are shown as visual diagrams to take advantage of this visual processing. Diagrams make a model easier to understand and faster to communicate.

A visual model also evokes an emotional response. If people like the model they see they will be more likely to understand it and accept it. If they helped create the model they typically also have a feeling of ownership.

Models also support the message a speaker is trying to convey. The audience does not have to simply listen to someone speak and try to interpret the words. The speaker can focus on the major points, while the audience views the model and associates it with the message.

Business models facilitate a common understanding of a business situation. When two business people create an on-the-spot drawing of a business process, they may think they agree on the process but actually disagree, because each interprets the drawing differently. Does Joe’s diagram box mean the same thing as Sharon’s? With a model, the modeling elements are rigorously defined. The same model means the same thing to anyone who sees it. (Or at least the modeling elements are intended to be rigorously defined, with the same meaning for everyone. In practice, the rigor is a matter of degrees. But relying on business models certainly leads to much less accidental misunderstanding than relying on informal drawings.)

Why is rigor important? Communication is all about finding common ground. In some languages (e.g. Hebrew) the same word is used for hello and goodbye. The meaning is determined from the context. If you begin a telephone conversation with someone and you do not agree on the form of communication, when you say hello the other person may hang up. Modeling is similar. The model and its semantics-the meaning of each model element-is an agreement that allows for information to be conveyed in a consistent manner. As long as those that create the model and those that read it have the same understanding, the model can be interpreted to have the same meaning.

People with different backgrounds can use models to communicate, as long as they agree on the meaning of the modeling elements. Someone purchasing a home may not be skilled in reading the builder’s plumbing or electrical diagrams. However a floorplan can be used as a common model between the purchaser, the plumber and the electrician. The floorplan is a baseline framework for common understanding. The floorplan includes modeling elements that are familiar to all: stairways, walls, closets, and doors. Business models serve the same purpose in a business environment.

 

December 10, 2008

Web-based sims, the late great BellSouth, and Forio

Posted by bridgeland under Practice, Tools
1 Comment 

In the book, we describe business motivation models, and how those models can be simulated. When you simulate a motivation model, you can try different strategies, and understand the potential outcomes of each. A “strategy sim”—the simulation of a business motivation model—is a particularly effective tool for training, for bringing a group of people to a new understanding of the dynamics of a business.

But how should a strategy sim be delivered to the people who want to use it? Strategy sims want to be delivered as web applications, with a user pointing his browser at the right sim URL, trying a variety of different potential tactics, and exploring the resulting impacts on his business. The web makes business sims easy to access, no harder than looking up something in Wikipedia or buying something on Amazon.

I became convinced of the value of web-based strategy sims in the mid-1990s, while performing some management consulting work for BellSouth in Atlanta. As you may know, BellSouth was one of the “baby bells” resulting from the breakup of AT&T in 1984. BellSouth was based in Atlanta, and offered local telephony to customers in Florida, Georgia, North Carolina, and other states in the southeast United States. BellSouth has since been acquired by (the new) AT&T.

In 1995, my client at BellSouth was interested in conducting a two day training seminar for all managers in the company. The purpose of the seminar was to introduce the BellSouth management to some of the changes taking place in the telecom market, and to prepare the company for some coming transformations in their business. The seminar was centered around a playable simulation, a strategy sim that reflected the ideas of the BellSouth thought leaders.

We created this sim for them. In the sim the user could make investments in consumer broadband (then a radical idea), make pricing decisions for long distance (then a rather expensive service, not bundled for free with landlines and wireless as it is today), and other telecom decisions. The user simulated forward for six years, from 1996-2002 (!). Each year the user could investigate what had happened, make decisions, and then advance to the next year.

The sim was used competitively. The participants were divided into teams. Each team explored what had happened, and discussed what should be done. The teams competed against each other, each trying to create the best end result for the simulated BellSouth. And the competition engaged them: they wanted to beat their friends and colleagues, and many spent extra hours in the evening learning the sim, and in the process, learning about changes in the telecom competitive landscape.

In creating the sim, we focused on the user interface, making it very attractive and intuitive. Actually my old friend Nadine Carroll did all the heavy lifting on the user interface. She wrote it in Visual Basic—an obvious choice in those days. Ed Vail and I wrote the model using the strategy simulation tool Powersim. To the user it was a standalone Windows 3.1 application, with the model and simulation engine completely hidden inside the app.

For the training seminar we needed the sim to run on 150 laptops. BellSouth supplied the laptops, shipping them to my office in Boston. Nadine had created a installer application with all the necessary DLLs. Of course this was before CDROMs were common, so the installer was delivered on a series of five diskettes. We copied the diskettes, then set up an assembly line to install the app on all the laptops.

What a pain! And it did not even work right. The laptops were not identical, and the app worked on most, but failed on some. The root cause was a DLL conflict (of course), and Nadine had to figure out the offending DLL and devise a workaround.

While installing the sim on the 150 laptops, I began to fantasize about a different architecture. What if the sim were a web application instead of a Windows application? The user interface could run in a web browser, and the simulation would run on a server. No installation would be required. The user would point his browser at the right URL and play the simulation. The server could even manage the competition, tracking the high score and which team had achieved it.

The next year I joined Powersim Corporation, and we created the product Powersim Metro to achieve that vision. Metro allowed someone to create a simulation and deploy it as a web application. Metro was not a great success as a product; it was a typical version 1.0 product that partly achieved its objectives and partly missed. And it sold poorly, even for the smallish niche of modeling tools.

My Powersim colleagues Michael Bean and Will Glass later created a company that has enjoyed some success with this kind of web-based simulation environment. Their product Forio Broadcast allows you to create a simulation with a web user interface. The model is simulated on a server, either on one of Forio’s servers or your own. The user interface is written in some combination of HTML, Javascript, and Flash, and runs in a browser. The result can be a sim that feels very smooth and natural, easy to access from anywhere.

 

December 3, 2008

Creating new knowledge with business models

Posted by Zahavi under Value | Tags: |
Leave a Comment 

In the last entry on business modeling and knowledge management we discussed the use of business models for capturing knowledge and reuse. Instead of simply capturing knowledge in documents, storing them and indexing them so that they can be located and searched, business models allow us to capture knowledge and provide the flexibility to modify it.

Business models also allow us to capture knowledge as it is created. For example, an executive team can create the company’s strategy at an offsite. They create the company’s mission statement, its goals and, decide on some critical initiatives to achieve those goals. They may also decide to move forward on a much needed reorganization to align with the new goals.

Today such knowledge is often captured in PowerPoint slides. This knowledge, however, can also be captured in models – in business motivation models and business organization models. Maintaining goals, organizational structure, initiatives, and other similar artifacts is very difficult in PowerPoint. In practice PowerPoint slides are often static and do not get updated regularly. It is very difficult to change elements on each separate slide and to ensure they are still in-synch. Models are much easier to maintain over time. Modeling tools allow us to modify model elements when needed, and when you modify a model element in one model it changes in other models that use it or reference it.

But creating business models accomplishes more than just capturing existing knowledge. Capturing the knowledge in business models can also expose something that might be hidden or otherwise missing. We might discover that we are missing an initiative to support a particular goal. We might also discover that we have initiatives that do not support any of our new goals and that might not be needed.

Ultimately business models are most useful in creating new knowledge – something that cannot be achieved by simply capturing knowledge and storing it in a knowledge management repository. When you capture an as-is business model and then modify it to generate possible to-be models, you are creating new information, new knowledge that might represent the actual future state of the organization. You can compare and evaluate alternatives and select the best one. You have just created something new, something that was not there before, but something based on that existing knowledge. You have created new knowledge that can be used in the future.

 

November 28, 2008

Business Modeling and Knowledge Management

Posted by Zahavi under Value | Tags: |
Leave a Comment 

I have just returned from Braintrust, a knowledge management focused event. I was there to speak about business modeling and how it relates to knowledge management. Knowledge management used to be about capturing existing information such as documents and presentations, converting them to a digital format if needed, and then storing them in a database, indexing them and making them available for others to search.

Over time knowledge management evolved also to be about how to capture tacit knowledge, the knowledge in people’s heads, and converting it to explicit knowledge, such as that found in documents. Many companies and organizations today are extremely concerned about their aging workforce – about the tacit knowledge that this workforce possess and that is about to walk out the door. The “great crew change” is the term given to this issue surrounding the retirement of the baby boomers and the need to train a new generation on what they know. Much of this baby boomer knowledge is tacit, not captured today in documents, and not easily captured in document form.

Today knowledge management is much more than capturing and storing knowledge so that others can use it. Today knowledge management is also about identifying where the knowledge exists and who might have it, it is about collecting and capturing the knowledge, it is about the creation of communities of interest and social networks, and it is about using web 2.0 and enterprise 2.0 technologies to harness the power of the knowledge and making it easier to find and use it.

Many organizations today have some form of a knowledge management program. The program may be a formalized set of processes and technologies used to rollout the knowledge management capability, or it may be based on a more viral grass roots movement to get employees to share their knowledge and network with other employees. Most organizations today still have rather basic knowledge management programs that are divided into two steps. First knowledge is captured, put in the repository, and indexed so it can be found. Later, in a new situation, the knowledge is found. At that point it can be reused. The same knowledge that was used before—on the original project or activity when it was captured—is used again in the new situation.

While organizations today have methods and tools to store the knowledge and find it, they are still struggling with the best way to capture that knowledge. Should it be done by asking the retiring workforce to write down what they know? Should it be done by interviewing them? Should it be done by having the new younger workforce “shadow” or work side-by-side with the retiring employees to learn what they know? And how can we tell what information is correct, what is a lessons learned that should be repeated and what is one that should be avoided? Just because someone has performed a job a certain way for years does not necessarily mean it is the best or safest way to perform it today or in the future.

Why use business models for assisting in the capture step? We have found that business models are an excellent way for capturing tacit knowledge. The workshop methods we discuss in our book are also an excellent process that can be used to capture such knowledge and models. The workshop format allows the people possessing the knowledge (such as the baby boomers) and those that require it (such as new employees) to interact. Together they create the models, pose and answer questions, agree on common terminology and representation, and feel ownership of the models they create. Building models is also much more interactive and visual than creating textual documents and therefore more interesting.

Unlike standard documents that are static, business models are created in tools and can be maintained as a “live” artifact over time. Business process models and business rule models can also be simulated and executed, so the knowledge is not just stored until it is reused, but the knowledge can actually be tested and deployed in real systems.

Business models are easier to reuse than other kinds of documents typically found in a knowledge management repository. If the new situation is sufficiently similar to the original project, the model can be used without changes. If the new situation is only somewhat similar, the model may be changed to fit. For example, a company may capture business models surrounding the deployment of a contract management system for one of their pharmaceutical manufacturing clients. They can capture the goals for the system; they can capture organization models showing how the contract department interacts with internal departments and with pharmaceutical wholesalers and buyers. They can capture process and rule models that are involved in these interactions and in contract solicitations, bidding, award and management. When the project opportunity arises to sell and install a system for a medical and surgical supplies manufacturer (instead of a drug manufacturer), the types of products need to be changed, and rules associated with the different type of business might change, but much of the way the contracts are issued and managed is similar and can be reused.

In addition to supporting reuse within an organization, business models can also promote reuse across organizations. For example, in information technology support, the IT Information Library (ITIL) standard defines some best practice processes that can be used in many organizations for functions such as configuration management, help desk support, incident management, and availability management. These processes help ensure that needed IT is correctly configured, supported, and available. A business model based on ITIL defines business processes useful for any IT department, in any company or public sector agency. The models are based on knowledge representing best practices harvested from many experts.

In our next knowledge management related entry we will discuss how business models can be used not only to capture knowledge, but also to create new knowledge.

 

November 28, 2008

Model credibility and transparency

Posted by bridgeland under Practice | Tags: |
Leave a Comment 

Business models often elicit skepticism. “What is behind the model?” someone asks. Behind their polite question you can hear some less polite variants, questions they are thinking but do not say: “Why should I trust the results?” “How do I know you haven’t cooked this model for your own benefit?” Even: “I will not be fooled by your scam.”

Model credibility is often a problem. We are successful with our business models only to the extent that other people trust those models. And frankly their concerns are often warranted. As modelers, we know that all models are wrong. Some models are wrong in ways that undermine their conclusions. And some models are indeed cooked—not ours of course, but those created by less scrupulous modelers.

Model credibility is a fundamental problem with all kinds of modeling, not just business models. When we create a model we understand the details. The consumers of models do not understand the details. There is a fundamental tension between our deep knowledge and their lack of it, a tension that plays out in their skepticism.

This is similar to what happens when I drive a car for three years and then sell it to someone else. I know the defects. I know whether I crashed it on an icy road last January. I know whether I forgot to change the oil, and how aggressively I drive when listening to Big D and the Kids Table. My would-be buyer knows none of this. He reacts with skepticism.

To economists the used car sale is an example of information asymmetry. The seller has more information about the product than the buyer, and better information as well. The information is asymmetric.

Business models suffer from information asymmetry just as used cars do. Those of us who sell business models know more about the models we build. Our buyers know less. The credibility problem is inherent in this asymmetry.

What can we do to gain credibility? Some people suggest model validation (or verification). (We describe the validation and verification of business models in our book.) I think these people are mistaken: validation does not help. Validation and verification are techniques to make a model more accurate, a better reflection of reality. But the credibility problem is not about the model, it is about how the model is perceived. A skeptic can be just as skeptical about a more accurate model as about a less accurate one.

So what can we do? In practice, we use two approaches. First we engage the model consumers in the modeling process. We work with them in model-based workshops to create the model. In essence the model consumers become modelers, albeit modelers without the technical modeling skills. People who help us create models are never skeptical of the results.

Of course there are limits to engaging the model consumers. The workshops for creating the model rarely include more than nine or ten people. Everyone else is outside the room. And often when the model is created, we do not even know the ultimate consumers. Their experience with our model is later, only after the model is finished.

The second approach to creating credibility is to make the model transparent. Everything is shown. Everything is made clear and easy to understand. A model consumer who is sufficiently motivated should be able to open up the model and understand everything.

Making a transparent model is hard, harder than making an opaque one. Models often include messy details. These details must be cleaned up so they can be shown. Models often have complexities. These complexities must either be simplified, or at least explained in a simple way.

Making a transparent model is indeed hard, but it is worth the trouble. When someone is skeptical we show him the model and invite him to investigate.

 

November 28, 2008

Golf and frisbee: a common misconception

Posted by bridgeland under Explaining
Leave a Comment 

Most business people do not create business models. They design software or they manage sales accounts or they are responsible for regulatory compliance, but they do not create business models. Fewerthan 1% of business people create business models of the sorts we describe in the book. Even if you expand the definition of business model to include financial models and accounting models, even then fewer than 5% of all business professionals are modelers. As a business modeler, I work with a few other modelers and many nonmodelers. Most of my business interactions are with nonmodelers.

Nonmodelers share a common misconception about business modeling. They think some situations are amenable to modeling and other situations are not. They think business models apply to a small and limited domain and that most of the problems they encounter are outside of that domain. They say “Of course you cannot model that human behavior of people undercutting their colleagues as they compete for scarce internal investment.”  Or they ask whether colleague competition for internal investment is modelable. Or worst of all, they simply assume that it is not modelable, that models apply elsewhere perhaps but not to what they are doing.  They see business modeling as like golf, only to be played in special designated courses, and not playable elsewhere.

They are wrong. Business modeling is like Frisbee, playable everywhere, on greens, on a sidewalk, on a street, or in the snow. You can model any business situation. There are no domains of modelable and not modelable. Everything is modelable. The answer is always yes.

Why does this common misconception exist? Why do nonmodelers assume that business modeling is like golf and not like Frisbee? One reason for the golf assumption is perhaps lack of knowledge. Nonmodelers do not understand business modeling (of course) and so do not know the extent that can be modeled.

Perhaps the golf assumption is also due to the human tendency to exaggerate the importance of one’s own knowledge. “Those domains over there may be amenable to modeling, but my own specialization is far too complex.” When working with subject matter experts, I often see this peculiar combination of arrogance and fear. They are both arrogant in their assumptions about the complexity of their own field, and fearful that what they know can in fact be reduced to some digital models.

Of course some situations are not amenable to business process modeling. They don’t involve business processes, or at least they do not involve business processes in any important way. Last year, Ron and I worked with a third modeler, Varun Panchapakesan to analyze an existing IT desktop support operation. Our job was to take costs out, to determine how the same quality of service could be provided to customers at a lower cost. Our initial plan was to model the business process of desktop support, and then redesign it, implementing a cheaper process that accomplishes the same result. But as we dug into the problem, we discovered that the business process was very simple. Someone calls the service desk with an issue with their desktop computer, an “incident”. The incident is either solved on the first call or it is escalated to tier 2. They either solve the incident on the phone, dispatch someone to solve it in person, or it is escalated to a tier 3 specialist. And tier 3 solves the vast majority of the incidents that reach them.

We could model the business processes of this desktop support operation, but modeling the processes would not help us remove costs. Instead we modeled the mix of incidents, what kinds of problems the users actually see, and how the mix of incidents would change with different interventions. We built a motivation model, creating causal loop diagrams and a simple system dynamics simulation.

The issue is never whether a business situation can be modeled. It can always be modeled. The answer is always yes.

You can always play Frisbee, even in the snow.

 

« Previous Page