March 21, 2011

Business Services

Posted by Zahavi under Business Services | Tags: , |
Leave a Comment 

There is a lot of discussion today regarding Service Oriented Architectures.  With SOA, systems are designed to expose services so that other clients/applications can consume them.  The resulting system is loosely coupled and the services can be distributed to produce a more flexible system.  

Typically when people talk about SOA and services they are discussing the technical services – the interfaces such as web services that provide access to a particular function.    Examples of such functions include checking an account balance online or using a remote graphics service to create a bar chart given a set of data.

But what about Business Services?  What are they and are they part of SOA?  How do they relate to technical services?  A business service describes something of value that an organization provides its customers, or something that it uses from another organization to provide its own services.   

Business services are at a higher layer than technical services within a SOA architecture.  A business service can be provided by a person or people, by technology, or most often by people who use technology.  When technology is used, there could be several software services that support a single business service.

There is often confusion between the terms capability and service.  If you search on the Internet you will find that there are many views about these two terms and their relationship.  I like the view that describes the service as providing access and the means to use a capability.  Two hospitals may have the ability to perform surgeries, but only one may have the ability to perform Liver Transplants. The service, Liver Transplant, delivers the effect of using capabilities, where the capabilities are made of the organization’s skills (Liver Surgeons, Hepatology Specialty, etc.) and tools (Surgical Suite, CT scans, Ultrasound, etc.) that enable the service. 

My company recently performed a business architecture engagement for a new cancer center.  The work involved understanding how several oncology departments work independently and how they will work together using a multidisciplinary approach in the new center.  We captured a business motivation model, organization models and process models, for the as-is and the to-be states.  We created an accompanying strategy simulation for cancer center planning.  These models are discussed in greater detail in the Business Modeling book.

In addition, we created a business service model as it relates to organizations and locations. This model was not covered in the Business Modeling book and our intent on the project was to understand what services are provided by each department and at which location, and to identify the dependencies on other services.  Then we worked with the departments collectively to determine what services will be provided at the new center, what are the service overlaps, and what gaps exist if the services they depend on are not offered there or nearby.  For example, if in order to provide certain pre-op or post-op services there are dependencies on a phlebotomy service there are three choices, offer phlebotomy service at the center, provide transportation for patients to another location, or change a process so that blood work must occur before or after the appointment.

We have produced a complete business service architecture for a cancer center offering.  We created a classification framework that also identifies each service as billable or non-billable, as mission or non-mission critical, as core to the business, or context – one that is not a core capability and could be outsourced.  This allows for the creation of service groupings so that an organization can determine which services are an important part of its business where investment is warranted, and which services are not as critical and could be outsourced.

We found the business services to be one of the most useful business architecture artifacts as it provided insight into how an organization views its business and helped identify critical gaps.   The resulting architecture serves as a baseline so that other cancer centers that are undergoing transformation can be compared to ensure proper coverage of issues and analysis.

 

February 12, 2011

The challenges of big sales and the promise of model visioning

Posted by bridgeland under Model visioning
[3] Comments 

I work in big sales. Sales is of course the business function of convincing customers to exchange money for goods or services. But what is big sales? Big sales is simply a question of size: when a customer pays at least $10,000,000. Selling a Ford Explorer to Joe Sixpack is sales. Selling a fleet of 10,000 Ford Explorers to Hertz is big sales. Selling a new credit card to Joe Sixpack is sales. Selling IBM on providing American Express to all their employees: big sales.

The line between sales and big sales is not precise. There is no sharp difference between a $9.5 million deal and a $10.5 million deal. Rather there is a gradual continuum between regular everyday sales and the larger deals.

But big sales are truly different from regular everyday sales, different in a number of ways. First, the customers are different. An individual person buys a bag of groceries for $40, a computer for $1100, or a car for $27,000. But the big sales customers are not individual people. Few people pay $10 million for anything in their life; few have the money. Instead of individual people, big sales customers are big organizations: companies and governments. For the most part, only big companies and governments have the money to make big purchases.

Second, big sales are interactions between teams, not individuals. When Deloitte sells an accounting system installation to Chevron, a team of people at Deloitte make the sale, and a team of people at Chevron make the purchase. Multiple people are involved on both sides. Multiple stakeholders at Chevron must be convinced.

Third, big sales take time. Much time elapses between the initial meeting and the day the deal is inked. At least months elapse, sometimes years. Big sales have long sales cycles. When Accenture sells Visa International new IT system for approving credit card transactions, the sale takes more than a year.

Fourth, big sales are never anonymous. When a Ford dealership sells a new Explorer to Joe Sixpack, the dealership may know very little about Joe. But when Bechtel sells construction of a new subway line to the Washington Metropolitan Area Transit Authority, Bechtel knows WMATA well. There are Bechtel employees whose sole responsibility is to understand WMATA, to know all the key employees and decision-makers, and to understand WMATA’s challenges as well as WMATA does. Joe Sixpack is a customer, but to Bechtel, WMATA is a client, an organization known intimately.

Fifth, big sales have complex effects on the procuring organization. When British Airways buys a fleet of new A380s from Airbus, the procurement has significant and complex impacts on BA. Their pilots must learn to fly the new jets. Who will train? When will they train? What is the impact on the existing routes? The BA mechanics must learn to service the new jets. Who? Where? The new jets will fly some routes, and not others. Which routes? What schedules?

At least British Airways flies jets today, and so understands many of the complexities of acquiring a fleet of A380s. These are known complexities. When the United States Border Patrol acquires a new surveillance system, there are not only many complex effects, but some of these effects are unknown. How should Border Patrol change their staffing: what skills do they need more and what less? How should Border Patrol change their training? How will drug trafficking organizations adapt their tactics to the new surveillance, and hence what should Border Patrol do differently to adapt to those new tactics?

Finally, big sales often fail to launch. Safeway does not worry about customers entering their stores, filling their shopping carts with groceries, and then changing their minds and leaving without making a purchase. But it is common for a big company or a government to spend years planning a big procurement, to decide on the vendor, to negotiate a deal, and then before signing the final agreement, to decide not to purchase anything after all. The big procurement is judged to be too risky: better to not launch now.

Simulations are useful for purchasing organizations. With a simulation WMATA personnel could explore different strategies of subway construction. Should the eight new stations be opened all at once, or should one station be opened at a time, as they are built? Which routes should be underground and which above ground? When should roads be closed to permit construction, and which roads? What roads should be rerouted for the subway, and when?

Simulations can provide cost estimates for the different WMATA alternatives. But just as important as cost estimates are nonfinancial results. How much inconvenience and traffic delays does the subway construction incur on the driving public? How popular is the resulting infrastructure? What is the impact—positive and negative—on the surrounding retail?

Simulations conquer complexity, allowing people in a procuring organization to better understand their options. Simulations are also uniquely useful for helping a group of stakeholders reach as decision. As Ron Zahavi and I describe in our book, simulation models can be used in a model-based workshop, allowing all the stakeholders to collectively arrive at a decdision. Ideas can be tried, and results can be shared.

Finally simulations lower the risk of a major procurement, both the actual risks and the perceived risks. Working with a simulation leads to a better understanding of the consequences of the purchase. Better understanding means lower risk.

Simulations are useful for procuring organizations but today they are rarely built for this purpose. Procuring organizations do not spend the time and money to create a simulation around their major procurements. Who has the time and money?

Sellers do. Sellers have the time and money to create procurement-oriented sims. Sellers know their products, the alternatives for the customers, and the tradeoffs involved. Sellers know their clients, and understand the details of the clients’ problems. And sellers have the motivation, to reduce the likelihood of a failure to launch.

We call this model visioning, creating simulation models for big sales. Model visioning sims help customers understand the ramifications of major procurements. Model visioning sims increase the likelihood that a customer will act. Model visioning sims increase the likelihood that a customer will make the right decisions.

I work in big sales, creating model visioning sims.

 

November 29, 2009

Climategate and three lessons of using models for persuasion

Posted by bridgeland under Uncategorized
1 Comment 

Last week, the Climatatic Research Unit—one of the world’s leading institutions devoted to the study of climate change—suffered a leak. Someone anonymously released thousands of previously secret CRU emails and documents to the internet. Since then, critics of the CRU—including global warming skeptics—have found embarrassing materials among the leaked files. Some emails appear to advocate changing measured temperature data to better fit global warming arguments. Other emails discuss pressuring academic journals to reject papers skeptical of global warming. Still other emails recommend deleting models and data files rather than providing them to a Freedom of Information Act request. The Daily Telegraph has (inevitably) dubbed this scandal Climategate.

What does Climategate mean for global warming? Is the scandal a “smoking gun” as some have suggesting, showing that man-made global warming is not occurring, or perhaps only occurring slowly? Or is it a “tempest in a teapot”, as others claim, certainly embarrassing for the scientists involved but ultimately providing no evidence against man-made global warming? Frankly I don’t understand the science deeply enough to have a useful opinion. But no matter what it means for the science and politics of climate change, Climategate offers lessons for us, for those of us who use models to persuade.

As we describe in our book, business models are used for eight purposes. One of those purposes is analysis, using a business model to gain insight, insight about customers, regulations, productivity improvements, or whatever. Another purpose is persuasion, using a business model to change someone’s mind. Models are used to persuade customers to buy, to persuade stakeholders to invest, and to persuade employees to commit.

CRU created models, models of climate of course, not models of business situations, but models nonetheless. They used these models for both analysis and persuasion. They used their climate models to analyze temperature data, as part of the scientific process, ultimately publishing academic papers based on their analysis. And they used their climate models for persuasion, to convince other scientists, politicians, the media, and the general public that the world is warming, and that fossil fuel emissions are causing that warming.

The CRU kept their models secret. They did not provide them to global warming critics in the scientific community, and in fact they did not provide them to supporters in that community. No one outside CRU had access to the models.

Secret models are fine for analysis. But secret models fail to persuade. Skeptics ask why they should believe the results of your model, if you won’t share it with them. How do I know you haven’t cheated in some way, created a model that simply supports what you want rather than one that is independent of your desires?

So the first lesson of Climategate is share your models. Make the models available to anyone who wants them. And in particular share your models with skeptics. The skeptics are the people who most need to be convinced, and they are the people who are the least likely to be convinced by secret models.

Among the leaked CRU documents were model files, software code that implements the CRU climate models. As outsiders slowly pore over the code, they have found many issues of professionalism: poor programming practices, apparent bugs, and comments that indicate that a later model developer does not understand the code written by an earlier one. These professionalism issues with the CRU models have provided skeptics with more reasons to be skeptical. If the CRU follows poor programming practices, how can we know that the results are accurate? If the CRU personnel who are responsible for the model code do not themselves understand it, how can we outsiders trust it?

The second lesson of Climategate is ensure that your models are professional. Models meant to persuade should be easy to understand, exhibit best practices, and of course be free of bugs. Reasonable people may disagree with the assumptions contained in the models, but those same reasonable people should not have cause to question the professionalism of the models themselves. Only professional models persuade.

The CRU relies on temperature data from many different sources all over the world, collected over many years. Some of the data was collected more than 100 years ago. Altogether the CRU assembled millions of individual temperature measurements. But this raw data was collected by hundreds of different organizations, with varying equipment and varying disciplines. Before the data could be analyzed, it had to be statistically adjusted and normalized, so it could be properly compared.

Since the leak, the adjustments themselves have become controversial. No one is denying the need to do statistical adjustments, but some climatologists have accused the CRU of always adjusting in ways that increase the amount of apparent global warming. They claim that the raw data shows much less warming than the adjusted data, that the global warming is an artifact of the statistical adjustment process not the climate.

There is no easy way to compare the adjustments that the CRU made to other potential adjustments that could have been made to normalize the data. The CRU made assumptions about the adjustments, and perhaps those adjustments were reasonable, or perhaps the assumptions themselves introduced bias. There is no easy way to know.

So the third lesson of Climategate is make it easy for others to change the assumptions. When I create models to persuade, I provide a user interface of assumptions, giving skeptics the ability to change the assumptions I made and understand the effect of each assumption on the outcome. Allowing skeptics to provide their own assumptions is critical to convincing them.

What if the CRU had learned and applied these three lessons? First, they would have given their models to everyone who wanted them. The models could not have been leaked if they were not secret in the first place. Second, the CRU models would have been professional, free of bugs and easy to understand. Doubts about the results of the models would have been averted. Third, the models would have included assumption user interfaces, allowing critics to understand how different assumptions would have changed the outcome.

I suspect that global warming would have been contentious no matter what actions the CRU had taken. The stakes are large—trillions of dollars and thousands of lives—too large to avoid controversy. But certainly if the Climatic Research Unit had learned these three lessons of using models for persuasion, they could have avoided much of the Climategate mess they are suffering today.

 

August 16, 2009

Noodling about the Fat Smoker

Posted by bridgeland under Uncategorized
Leave a Comment 

I have been noodling lately about the problem of strategy execution. Some organizations know what they need to do, and they know why. But they cannot seem to do it. They cannot make the process changes required to execute the new strategy. (Have you ever worked for such an organization?)

The recent book Strategy and the Fat Smoker is about strategy execution. Its clever title compares the problem of strategy execution to the difficulties faced by fat smokers.  Today, every fat smoker knows he should change. He knows that he should eat more salads and less ice cream.  He knows he should exercise more and watch less TV. And he knows he should quit tobacco. He knows what he should do, and he knows why. He just cannot manage to change his behavior.

Of course there are significant differences between failures of personal strategy execution—like the fat smoker’s—and failures of organizational strategy execution. All organizations are political, and what is best for the organization as a whole is always worse for some business unit, or some function, or some group. Somebody always loses. And the (prospective) losers will lobby hard to prevent the changes required.

The 2004 book Predictable Surprises looks at failed execution of disaster prevention, organizations that knew what to do to prevent a predictable disaster, but that failed to take the appropriate actions. Bazerman and Watkins—the authors of PredictableSurprises—examine some disasters in detail, and probe into why the disasters were not averted. One disaster they examine is the 9/11 terrorist attack. For 20 years, several government agencies were aware of the increasing violence of jihadists, and their increasing willing to strike at distant infidels in the US as well as nearby infidels in Israel, India, Egypt, etc. For 20 years, the FAA (and other government agencies) was aware of weaknesses in air travel security, including the very tactics used by the 9/11 jihadists. The authors claim that 9/11 was not in fact a “failure of imagination” (as famously described by the 9/11 Commission) but rather a failure of execution: the Gore Commission knew what to do in 1996, but could not manage to execute it, particularly in the face of opposition by the airline industry and by Congress.

Can business modeling (and simulation) help? I suspect so, but I am not sure. That is my noodling topic. The business modeling techniques we describe in our book are certainly useful for figuring out what to do, and how to do it. But the four modeling disciplines we describe are not particularly useful in actually changing behavior once the what and the how are known and accepted. We need something additional, a simulation discipline that explicitly addresses the inherent politics, that allows different groups within the organization to make their cases, and that induces action.

 

June 9, 2009

Aligning solution development with client requirements

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

In part one of this two-part article I discussed how business models can help a school system select the set of features most important to it in a school student management system. Such an application allows teachers to manage student attendance, grades and calendars, and provides students, parents, teachers and other school administrators the ability to collaborate.

Business models also help software developers at a student management system vendor create the right application. For example, instead of describing that a daily calendar is a requirement, we begin with the business models. What is the need for the calendar? What is the motivation for deploying it? Who will use the calendar and how will it be used (if teachers, parents, students use it , what is the process for each)? How will the calendar change the user experience? The answers to these questions will ensure that we deploy the best solution for the need.

But software developers are often removed from the client and user. To help them design the application they are often given some form of use cases, descriptions of how users will interact with the application. Sometimes the requirements are in the form of the list of functional requirements detailing what the system must or might support (for example “The system shall provide a daily calendar”.) The software developers have to interpret the requirements and design the application. But if they don’t understand what is driving the user, if they don’t understand some of the user issues or what the process is for using the application, they might interpret things wrong, or in a way that the users won’t like. The application won’t meet the user’s expectations and the users won’t like or accept the application.

The developers need to bridge the requirements as described in the business models to the application they are to implement. They need to map the business activities to features that support the activities. Through studying the processes teachers use to manage their day and to schedule and grade assignments for periods they teach, the developers realize that  teachers desire a daily calendar based on periods, not on hours of the day.

In part one of this article I described a school system that on odd days switches periods 4 and 7. But another school system might have the same 7 periods each day in the same order 1-7, while another might have periods 1, 3, 5,and 7 on Mondays, Wednesdays and Fridays, and periods 2, 4, and 6 on Tuesdays and Thursdays. Since each school system has a different set of periods, and periods that start and end at different times, the application should be flexible to accommodate these variations.

Business models provide additional critical information to the application developers. They provide a context, a business context for the technical requirements. The software developer can visualize how the user will use the system and by understanding more about how the application will be used, the developer can build or select the right set of features.

 

April 26, 2009

Aligning solution selection with business needs

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

When an organization selects an application or system to meets it needs there are two aspects of that selection. One is from the perspective of the organization acquiring the system and the other is from the perspective of the supplier of the system. The organization must understand its needs and requirements and select the features that are most essential to its business. The vendor supplying the system must ensure that what is developed meets the needs of its prospective clients. If the wrong set of features is developed, a mismatch will occur.Business models help with both aspects. They help organizations understand their strategy and goals and map the essential capabilities they need to support those goals. Business models also help in the software development process. They help developers better understand what features their clients need and how they will use those features. In the first of this two-part article I discuss how business models can help organizations select the right solution.

In traditional technology initiatives, such as the acquisition of an application, requirements are gathered and handed to vendors so that they can develop or configure the application to match the requirements (we discuss the topic of business models and software requirements in chapters 1 and 12 of our book.) The requirements are sometimes in the form of use cases and sometimes in a list of “shall” and “may” functional requirements (for example “the application shall support 100 concurrent users.”) However, traditional forms of requirements such as these do not convey the strategy of the organization or which requirements represent the most essential features.

Business models are a crucial part of the requirements gathering and definition phase as they help us capture the business view from the subject matter experts that know the business. We can capture the business motivation for a new application, and for each individual feature of the new application. We can capture whose work the application supports, what activities the supported users perform, and which of those activities are to be supported by application functionality.

For example, many middle and high schools today in the US are in the midst of deploying new technologies for managing student data and tracking student performance. Almost all teachers submit grades to the county level where it is processed by some application, but many teachers are still maintaining student data such as attendance and grades in notebooks. The review of student assignments is a manual activity, not supported by any software. The recording of the grades is a manual activity today, but in the future the teachers will use the new student management systems for this activity.

Student management systems are applications that typically manage student assignments, grades, attendance and school calendars and announcements. Such systems may be standalone applications used by teachers in schools, or they may be web-based, offering access to teachers, school administrators, students, and parents. Most colleges in the US use such systems today and many state counties (particularly those with high income households and high personal computer and web use) have begun using or experimenting with student management systems at the high school (grades 9-12) and middle school (grades 6-8) levels.

In the US most county school systems have very small IT departments. IT staff move from school to school to troubleshoot local computer problems but they don’t have the ability to develop large applications themselves. The decision to purchase a student management system often occurs at the county level where it is decided that all schools in the county must use the same applications. Sometimes individual schools decide to experiment with a particular system.

The development and deployment of a student management system has many requirements. Such systems may provide teachers with the ability to record attendance, record grades, let parents and students track performance, provide a calendar and collaboration capabilities, and more. Schools in the US today face tightening budgets and funding is often tied to student performance. They would like to deploy a technology that will help them but which features should they deploy?

Student performance can be tied to the ability to track student grades and intervene early if needed, but it is also tied to parental involvement. If a choice has to be made between features, should notification of dropping grades be implemented, a calendar showing assignment due dates and test dates, or a collaboration capability allowing all users to message with each other, or maybe a combination of these?

Business models can help the school system determine which features they need most to help them select the right student management system from a vendor. A business motivation model tying improved performance goals to metrics and tactics might indicate that early parental and counselor intervention is crucial and a facility is needed to send alerts based on conditions such as dropping grades. This capability along with a calendar allowing parents to know what assignments and tests are coming would be a better choice for the school system at this time than investing in messaging or collaboration features.

An organization model showing that a particular teacher teaches several versions of the same course in different periods, along with a business rule model for how a particular school system manages its periods during a week provides much more information than a simple requirement for a calendar. Only through the understanding that their schools need a flexible calendar system that allows periods to start at 8:03 and end at 8:44, and that supports the policy that on odd week days periods 4 and 7 are switched, can a school system avoid acquiring a system that has a simple daily calendar with on-the-hour period start and end times.

In the second part of this article I will discuss how business models can help vendors and software developers better understand their client’s needs.

 

March 4, 2009

World’s first model-driven recession

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

We are in the midst of the world’s first recession caused by modeling, a model-driven recession.

We are certainly in the middle of a recession, a declining economy. Some think this downturn is the beginning of a depression, comparable to the depressions of the 1930s or the 1870s. Others think this will be more like the typical post-WWII recessions, lasting 1 or 2 years.

Every recession is different, with different causes, different dynamics, and different outcomes. For example, the 1990-1991 recession was triggered by the oil price shocks of the first Gulf War, and by the failure of 747 savings and loan associations.  (I oversimplify. At the risk of stating the obvious, the American economy is enormously complex, the most complex human-constructed artifact in world history. There are no single causes for anything.) How did today’s recession happen?  This recession started with the big banks and other financial institutions in New York.

In the course of their everyday business, big banks buy securities and take other financial positions. All of these positions carry risks, risks that the positions will decline in value, become worthless, or even lead to large liabilities. Banks attempt to manage their risks, both by limiting the positions they take and by hedging their positions with other positions, positions that will gain value when the former positions lose it.

Starting in the mid-1990s many banks began to use a new form of model to manage their risks: value at risk. VaR models attempted to measure the riskiness of a position in terms of a 1% worst-case. A VaR value of $1 million means that there is a 1% chance of losing more than $1 million on a particular position. VaR values are computed both for individual positions and for portfolios of thousands of positions taken together. Banks used VaR models to determine how much risk they were taking, and how they should hedge that risk. (The business journalist Joe Nocera explains the history behind value at risk, how the banks adopted these models, and what happened next.)

Unfortunately VaR models are fundamentally flawed. There are several problems with value at risk, but the biggest problem is the implicit statistical assumption that financial markets behave as normal distributions. The normal distribution is of course just the good old bell curve from elementary statistics, an accurate model for some phenomena: for example, men’s heights. But normal distributions are known to be a poor model for the price fluctuations of financial instruments. Extreme movements are much more likely on Wall Street than in a normal distribution. (Power law distributions are a better model of financial markets.)

So VaR works fine, except when the markets change quickly. David Einhorn compares VaR to “an airbag that works all the time, except when you have a car accident”.

The consequence of banks using VaR models to manage risk is that they systematically underestimated the risk of big losses. They saw their portfolios as substantially less risky than they turned out to be. Based on the model-driven overoptimistic assessment of the portfolios, the banks acquired more risky securities than they otherwise would have. Then when things turned, everything declined quickly. Once a bank started to experience a larger loss than it thought likely under its VaR models, it sold the assets, leading to lower prices for those assets, and bigger losses for everyone else who held those assets, or similar ones. The losses fed on themselves.

To some extent, this is a typical pattern for a speculative bubble and its subsequent burst. The railroad bubble of the 1870s and the following Panic of 1873 followed essentially the same steps. People were overoptimistic about the value of the railroads that many were building. Then when things turned, everyone tried to sell at the same time, prices declined, and panic ensured. But the bad models that drove the Panic of 1873 were merely in people’s heads; they were poor mental models, not poor computer models. Today’s recession is the first caused by computer models.

We business modelers can take some small comfort here. It was not business models that drove this recession. VaR is a model discipline of capital market valuation. VaR is about the chance that a given security will decline in value. VaR is not about models of corporate goals or processes or business rules, not the kind of business models we describe in the book. Their models were at fault, not ours.

And if their models got us into this fix, maybe our models have a role in getting us out. Phil Gilbert argues that we need to improve the productivity of white collar work to turn the corner on this recession. I think he is right. Historically the greatest increases in productivity have come during recessions. When times are good, everyone focuses on meeting the topline numbers, on selling more and then somehow delivering on what has been sold. Costs and productivity are less important. When times are bad, everyone focuses on the bottomline numbers, on somehow generating more earnings from the meager sales they are able to make. Costs and productivity rule. And since white collar work is vastly larger than blue collar work these days, increasing the productivity of white collar work is essential to improving overall productivity.

We can use business modeling to increase the productivity of white collar work, so fewer people create more value. For example, when business process models are executed in a BPMS, the work can be done faster, better, and more consistently. Our book is about the business value of business modeling, and much of that business value show up as white collar productivity.

In addition to improving white collar productivity, Phil also talks about increasing the transparency of white collar work. He says: “There needs to be a revolution in implementation of processes that bring greater visibility and less risk to all aspects of our businesses. It is no longer acceptable that senior management remain ignorant of the goings-on at even the deepest depths of the organization.” This identification of visibility and risk is new to me, but perhaps it should not be.  We all accept the importance of visibility in the public sector, as the premier means of preventing corruption. In fact the most influential anti-corruption NGO is called Transparency International—their very name reflects the link between visibility and the biggest public sector risk, corruption.

The growth of systemic risk in Wall Street over the last 20 years is not the same as public sector corruption of course. In fact, it is closer to incompetence than corruption. As Michael Lewis says “[Meredith Whitney] just expressed most clearly and loudly a view that was, in retrospect, far more seditious to the financial order than, say, Eliot Spitzer’s campaign against Wall Street corruption. If mere scandal could have destroyed the big Wall Street investment banks, they’d have vanished long ago. This woman wasn’t saying that Wall Street bankers were corrupt. She was saying they were stupid. These people whose job it was to allocate capital apparently didn’t even know how to manage their own.”

But there is a similarity between this model-driven stupidity about risk and simple corruption. Both rely on secrecy. Corruption relies on secret payments from (for example) a favored firm to a government official. The big banks relied on secrecy about the risks they were taking to achieve the profits they reported. If the risks had been visible to everyone—shareholders, other lenders, analysts, regulators—the banks might have avoided this mess.

Perhaps the mess was unavoidable, even with better visibility.  VaR might have driven the banks to make the same blunders, and just made those blunders more rapidly obvious to everyone outside. The increased visibility from business modeling can still help us grow the rest of the economy again. Most of the economy is outside Wall Street, outside of the financial service industry entirely. Those businesses need better visibility of their business processes, the business rules they are using, and the goals and objectives they are trying to achieve. Our business models can deliver that kind of visibility. With that visibility we can turn the corner on this model-driven recession.

 

January 18, 2009

Model visioning

Posted by bridgeland under Model visioning, Practice
1 Comment 

In the book, we describe how business models are useful for persuasion, for changing someone’s mind about something. Of course business models have many other uses as well: analysis, training, etc. Seven other uses are described in the book.

Among business models, business simulations are particularly persuasive. In the book we say:

… simulation can be a powerful tool for persuasion, and this use of simulation is not widely appreciated. In fact, simulations are used so rarely for persuasion that sims are something of a secret sales weapon, an advantage to the people and companies who make use of them.

BJ Fogg, the director of the Stanford Persuasive Technology Lab, says, “Cause-and-effect simulations can be powerful persuaders. The power comes from the ability to explore cause-and-effect relationships without having to wait a long time to see the results and the ability to convey the effect in vivid and credible ways.” [Fogg 2003] Today when people want to persuade, they typically uses verbal techniques, numbers and graphs, or images and video. All these media have limited effectiveness. People dismiss words, ignore numbers, and are sophisticated critics of images and video. But simulations give them the ability to try things out, to experiment and build up their own understanding inside the simulated world. Simulations encourage people to reach their own conclusions through their own trial and error, but faster and more safely than they can in the real world.

[From the book Business Modeling: A Practical Guide to Realizing Business Value, by David M. Bridgeland and Ron Zahavi, published by Morgan Kaufmann Publishers, Copyright 2009 Elsevier Inc. All rights reserved.]

Let’s look at an example. Suppose you are attempting to sell Indian offshore call center services. Like most offshore call centers, yours provides telephone-based customer service cheaper than can be done by onshore call centers in North America. The main value proposition is price. Of course price can be easily understood without a need for simulation.

But the situation is a bit more complex. You differentiate yourself from other offshore call center services (who also offer low prices) by your relentless focus on accent. Most offshore call centers speak Indian English, but your call center employees speak American English with a South Carolina accent, thanks to hundreds of hours of training, monitoring, and coaching. You even focus your hiring on dialect. Your call center is based in Mumbai, home of Bollywood, the Indian movie industry. You hire aspiring and out-of-work actors and actresses to fill your cubicles, hiring employees who delight in playing characters from Charlestown and Greenville.

But so what? Why should your clients care about accent? There are several business advantages that accrue to your clients. First, some residential callers from North America have difficulty understanding Indian English. Communication with someone speaking American English is easier and more natural. Second, some residential callers from North America become uncomfortable when they realize they are speaking with someone from the other side of the world. Many people have not realized that telecommunication is free, and have little day-to-day experience with international calls. These callers never realize they are speaking to Amita and not Amy. To someone from Ohio or Oregon, South Carolina feels familiar to them; Mumbai does not. Finally some residential callers are politically opposed to speaking with Indian call centers. They see call centers in India as the “export of American jobs”, and they become angry when they talk to someone speaking Indian English. When they talk to your staff, they are usually fooled into thinking the call center is really based in South Carolina.

You have a compelling value proposition for your call center, but how do you show that value prop to your prospective clients? Of course you provide demonstrations. You play recordings of calls between North Americans and your call center, to show how natural the conversation is.

In addition, you provide a simulation, a web-based strategy sim that allows your prospective clients to try different alternative strategies. Working in the sim, your clients can experiment with different call pickup times, how quickly the calls are answered. They can experiment with different targets for time spent on the level 1 calls. They can experiment with different strategies for when to escalate to level 2 and to level 3. And of course they can experiment with different degrees of accent and dialect.

Their experiments have results. Your clients can see the results on time spent, on costs, on success rate for solving their customer’s problems, and most importantly on customer satisfaction. They can see for themselves the big and lasting effect accent and dialect has on customer satisfaction. And they can experience for themselves the difficulties of making an offshore call center work when customers are uncomfortable or angry. (Customer satisfaction is a “soft variable”. Soft variables will be explained in a future posting.)

You have built a model visioning sim. Model visioning is the use of business simulation for sales pursuits.

Model visioning is most useful for big sales, sales of a $100 million system integration project, or a $200 million outsourcing contract, or a $300 million construction plan. These big projects have big business consequences, positive and negative. Anticipating and understanding all the consequences is hard. Buyers need help in thinking through the big project. They need a custom-built business simulation to experiment with.

Traditionally what do people do to sell big projects? Big projects are sold with meetings and presentations, long written proposals, and demonstrations. A model visioning sim does not replace any of these techniques. Instead it complements these techniques. At the meeting, the sim is presented. Since it is a websim, the URL is provided to the prospective client. He can try it on his own, experimenting with different approaches to the project.

Model visioning is new: few people have employed sims in the sales process. It is virgin territory. When I create a sim for a big pursuit, and show it a client, I feel like the Dutch explorer Aerjan Block seeing Long Island for the first time. Who knows how big this is, or how important?

 

January 16, 2009

Business modeling and compliance

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

Businesses always have to comply with something.  They must comply with policies or rules they set themselves (e.g. size of a check an employee is allowed to sign), they must comply with policies or rules set by their business partners (e.g. adhere to terms of a loan agreement or terms of a contract), and they must comply with laws and regulations set by local, national, supranational, and foreign governments (e.g. what a company is allowed to export.)

Compliance is achieved when a business adheres, and can demonstrate that it adheres, to a set of rules, standards or regulations.  Compliance can be achieved by the use of systems that enforce certain employee behavior and business flow, or through training and oversight to ensure employees are compliant when they perform their work.

Business models help businesses understand how to be compliant, help them understand the impact of compliance, and allow them to manage compliance over time. A business can create business models to better understand what it needs to change in order to be compliant.  It can compare the existing organizational structure, processes, and rules against the compliant ones to understand what must be changed. The models can also be used in training so that employees understand what they must do to be compliant. 

The business can use the models to understand how being compliant will impact the business.  Will efficiency change?  Will customers be lost?  Will revenue be reduced?  Analyzing the differences helps the business understand the impact of the change.

Once a business understands the delta between where it is today and where it is headed in order to be compliant, the business can use business models to manage compliance.  As the business changes and the regulations change, the models can be changed to represent the state of the business.

Compliant business processes can be deployed and business rules modified to ensure compliance is followed. Business rules directly model corporate policies. If the rules are executed in a rules engine, the engine will notice when a rule is violated, and when a policy is not being followed. For example, a business might have a policy that a purchase of more than $5000 by a department must be approved by a corporate officer at headquarters. When someone purchases new software licenses for $6329, that purchase is flagged and routed to the appropriate officer for approval.

Let’s look at another example of managing compliance. The US healthcare industry is regulated by the Health Insurance Portability and Accountability Act of 1996 (HIPAA), a law protecting patient privacy. One of the HIPAA rules is that a hospital cannot disclose protected health information about a patient without first getting written permission from the patient, at least in circumstances where the health information is not needed for treatment, payment or healthcare operations. For example, the hospital cannot share health information with an insurance company to be used for a decision about patient’s coverage, unless the patient OKs the sharing.

To comply with HIPAA, hospitals have to examine all of their business processes that involve private patient information. They must understand all of their interactions with outside organizations-insurance companies, healthcare maintenance organizations (HMOs), pharmaceutical companies, laboratories, etc.-and ensure that all hospital employees who interact with these organizations follow HIPAA-compliant policies.

Business modeling supports compliance with regulations like HIPAA. With a model of the interactions with outside organizations, our hospital can see who shares information with whom. With business process models, our hospital can see that patients are asked for permission before information is shared, in all the situations in which such sharing is needed. With a model of the business rules, our hospital can understand whether their policies cover the HIPAA regulations, and leave no area where private information is inappropriately shared. Our hospital can use business modeling to ensure they have the appropriate interactions, processes, roles and policies to satisfy HIPAA.

In addition to checking regulatory compliance, business modeling also can be used to evaluate the business impact of a new regulation.  For example, one state may require parental consent or notification for some medical situations concerning their teenagers, while an adjoining state might not. Such laws impact those states that must enforce them and the nearby states that also suffer the consequences. 

What will happen as a result of a parental notification law?  Will some patients be treated in a nearby state? What will the impact be on a local hospital business?  Should a hospital open a clinic in another state?  What will the impact be over time?

Using business modeling and simulations we can evaluate different scenarios to determine the expected impact of a regulation, and experiment with alternative responses. In this case, compliance is not difficult. Instead the challenge is to understand how to adapt the business strategy to the new regulation.

 

January 2, 2009

Isaac Asimov

Posted by bridgeland under Uncategorized
Leave a Comment 

Thirty-five years ago, when I was 12, I received a postcard from New York. The postcard read:

Dear David,
The whole country is humming with the news that you are a
fan of mine. I hear about it everywhere, and I think that’s
great.

I wish you all possible success as a science fiction writer
and as an astronomer.

Isaac Asimov

I was stunned.  The Great Man had written me! Wishing me success!

Of course my mom had arranged it. She had written Asimov a week earlier, asking him to write me. And his practice was to reply to fans. Over the course of his 72 years, he wrote an estimated 9000 postcards and letters, many to his fans. Including one to me.

Peter Graham once noted that the “golden age of science fiction was twelve”. For me, twelve was the golden age of Isaac Asimov.  I tried to read everything he had written, all the science fiction of course, but also the popular science and the history. I even tried “Isaac Asimov’s Treasury of Humor” and “Asimov’s Guide to the Bible”. (I did not like either.)

When I was twelve, I did in fact want to be an astronomer and a science fiction writer, as my Asimov postcard attests. But later, I lost interest in the inner workings of the stars, and instead became fascinated with the inner workings of algorithms and software. And starting in my early twenties, I became increasing interested in the dynamics of business. Others read the Wall Street Journal and the Economist out of professional obligation. I read them for fun, trading my youthful passion for tales of space travel and time travel with the sagas of the long decline of General Motors and the rise and fall of AIG.

But through these 35 years, one aspect of my career has not changed: I have wanted to write a book. 35 years ago, I wanted to write science fiction novels. Since then, my ambition changed to nonfiction. I have started several books. I worked for a bit in the early 1990s on a book about business process modeling and business process simulation, with my then colleagues Ralph Welborn and Brian Otis. We never progressed further than a detailed outline, although Ralph later published two books on related topics. In the late 1990s I became convinced that technical recruiting was practiced poorly everywhere, and I knew how to do it better. I started a book on recruiting, but never finished. (It still is practiced poorly, by the way.) Earlier this decade I helped Deutsche Bank launch a startup—Cokinetic Systems—and wrote a book on their innovative RIA technology I3ML. But I never found a publisher for the book. (Cokinetic has since pioneered a rich media platform for air passengers, based on I3ML.)

The fourth attempt was more successful. Our book was published in mid-December. It is not science fiction of course. It is nonfiction about a rather arcane topic, creating models of business situations. But it does include a fictional story within it. We needed examples to illustrate the business modeling techniques and disciplines. Some of the needed examples were supplied by case studies, real business modeling situations that either Ron or I had experienced in our consulting work. But we needed both more examples and different ones than the case studies provided. So we created a single fictional business—Mykonos Dining Corporation—that owns and manages 200 high end restaurants. Neither Ron nor I have any experience running restaurants, but we knew people who did, and more importantly the restaurant business is accessible to a wide audience. Everyone eats in restaurants, and many people have fantasized about opening their own.

Writing a book was much harder than I anticipated. The biggest problem was keeping everything consistent across the 12 chapters: keeping the wording consistent, the structure of the chapters, the models we explain, and the storyline about Mykonos Dining Corp. We made hundreds of changes to keep things consistent. Fortunately for me, Ron has an eye for inconsistency, and spotted the vast majority of the problems.

Isaac Asimov wrote many books during his life. Perhaps 468. Or perhaps 515. There is some controversy about the count, about which books should be included. But in any case, hundreds. He was astonishingly prolific. I am more astonished now, after having written one, that Asimov wrote so many.

One key to Asimov’s productivity was the quality of his first drafts. Another key was the lack of revision.  Apparently Asimov rarely revised anything he wrote. He claimed to be incapable of seeing the flaws in his own sentences, so his first drafts were submitted to his editor, and often published as they were. I do not share that particular weakness. I see the flaws in my own sentences quite well. So I rewrite, and rewrite again.

I know my continual revisions drove Ron crazy. Several times he pointed out that I was revising a paragraph I had already revised. As late as September, we were fixing problems introduced in the production process, and I found some more wording I did not like. Ron tried to talk me out of changing it.

Curiously, Ron was also an Isaac Asimov fan as a boy. While I was reading the Foundation Series in downstate Illinois, he was reading it 6000 miles away in Israel. Ron credits Asimov with his early interest in computers and modeling, and in retrospect, so do I.

I dedicated the book to my daughters, Miranda, Isabel, and Alexandra. Ron’s dedication was to his mother and to the memory of his father. But perhaps we should have both dedicated it to Isaac Asimov.

 

Next Page »