Value


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.

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.

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.

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.

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.

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.