PHIOS CORPORATIONWHITE PAPER
New Tools forManaging Business Processes
One Broadway, Suite 600Cambridge, MA 02142
New Tools for Managing Business Processes
This Phios white paper gives an overview of the problems of businessprocess management and how the Phios Process Repository tools can helpaddress these problems.
The problem: Managing business processes
In the last decade or two, most companies use of data has been transformed throughinitiatives like decision support systems, information resource management, datarepositories, enterprise resource planning systems, and most recently knowledgemanagement. It is now hard to find a large, successful company that has not madesignificant progress in computerizing and integrating their data across the company.Many companies, for example, now have extensive customer histories available on-lineto the service representatives who help customers on the phone. Some leading companiesare deriving significant additional benefits from mining their corporate data for detailedinsights into which customers and which products are most profitable.
Compared to their use of data, however, most companies today are still very primitive inthe ways they manage their processes. Business processes are inconsistent acrossapplications, locations, functions, and divisions. Few people understand how their workrelates to the overall processes in which they participate. Even though process maps, taskdocumentation, and job aids exist in isolated cases, most knowledge about how thingsare or should be done is stored in incompatible and disconnected ways. Usually thisknowledge is not even written down at all, but exists only in peoples heads.
Why is this a problem?
This informal and haphazard management of processes has a number of undesirableconsequences:
Customers receive inconsistent and often inadequate service from different parts ofthe company, sometimes compromising the entire corporate brand image.
Managers continually struggle to manage the horizontal interactions betweenpeople in different parts of the company who dont understand how their work fitsinto an overall corporate process.
Best practices and other ideas for improving how things are done are discovered andshared haphazardly, and often repeatedly re-invented in different parts of thecompany.
Installing new computer systems, such as for electronic commerce or enterpriseresource planning, is often extremely difficult not primarily because of the technicalproblems but because of the organizational ones. Merely understanding what peoplealready do is hard enough, much less designing and communicating the processesthey will need to use with the new systems.
In general, the problems of continually adapting to a rapidly changing world newcompetitors, new products, new technologies, and new business models are gettingmore and more important, but the tools most companies have for dealing with themare increasingly inadequate.
Needed: Better process management
In the same way that information technology has already helped most companies managetheir data more effectively, we believe that one of the next big opportunities for usinginformation technology is to help companies manage their processes more effectively.We define process management as:
Systematically understanding, tracking, and improving the businessprocesses that matter.
In fact, we believe that many successful companies in the 21st century will devote asmuch attention to managing their processes as they currently devote to managing theirproducts.
More and more companies today are already beginning to make the changes in cultureand managerial mindset needed to manage in this new way. For instance, the veryprocess of implementing an enterprise resource planning (ERP) system often requires acompany to think much more explicitly about their business processes than they everhave before.
As more companies move in this direction, they are beginning to realize that in order tomanage their processes more effectively they need more systematic ways of managingtheir process knowledge: What things need to be done? Who is responsible for them?What works well and what doesnt? How do other companies do these things? What areinnovative new ways of doing these things?
It is, of course, possible to manage this kind of knowledge in the ad hoc, haphazard waysmost companies do today. But to do this well requires specially designed electronicknowledge repositories.
The Phios approach: Process repositories
The Phios mission is to be the leading supplier of these electronic knowledge repositoriesthat help companies better manage their business processes. These processrepositories include both software tools and knowledge content to help companiesexplicitly define and manage their own processes and find state-of-the-art knowledgeabout how other companies do similar things.
We define process repositories as:
Consistent, easy-to-use collections of process knowledge, used formultiple purposes.
For example, in addition to just storing process maps, these repositories can be used toorganize process documentation, best practice libraries, measurement andbenchmarking data, software configuration and change data, linkages to relevant websites, and many other kinds of knowledge. In some cases, these additional kinds ofprocess knowledge will be actually stored in the process repository. In other cases, therepository will only store links to information that is physically stored somewhere else(e.g., on separate web pages or in a document repository)
We view process repositories as a critical component of a companys knowledgemanagement strategy. Unlike most other approaches to knowledge management, processrepositories focus on know how rather than know what. However, these repositoriescan also be used to organize many kinds of know what by categorizing them accordingto the business activities for which the knowledge is relevant.
History of the Phios approach: The MIT Process Handbook Project
The Phios Process Repository approach is based on over 7 years of research at the MITSloan School of Management, involving over 30 person-years of effort. Drawing onresearch in computer science, organization theory, and coordination science, these MITresearchers developed a pioneering process repository, called the Process Handbook.This repository includes knowledge about over 5000 business processes and activities. Italso includes a variety of software tools to edit and view this knowledge base.1
In order to commercialize the results of this research, MIT has licensed to Phios, on anexclusive basis, all the intellectual property resulting from the project. This intellectualproperty includes the software, the repository contents, and patents covering the basicapproach to process representation. In addition, the researchers who led this project atMIT are co-founders of Phios.
The Process Compass
One of the most important features of the Phios Process Repository approach is its use ofthe Process Compass to help people organize--and navigate through--richlyinterconnected networks of related processes and activities. As shown in Figure 1, theProcess Compass represents the four different directions you can go from any activity (orprocess) in the repository.
The vertical dimension of the compass represents the conventional way of analyzingprocesses: according to their different parts. You can go down to the different parts ofthe activity (its subactivities) or up to the larger activities of which this one is a part (itsuses).
Figure 1. The Process Compass shows two dimensions for analyzingbusiness processes. The vertical dimension distinguishes different parts ofa process; the horizontal dimension distinguishes different types of aprocess.
Almost all process-mapping techniques use only this vertical dimension. The PhiosProcess Repository adds a novel second dimension, the horizontal one. This dimensiondeals, not with the parts of a process, but with the types of a process. You can go rightfrom an activity to its different types (or specializations), and you can go left from anactivity to the different activities of which this one is a type (its generalizations).
In addition to providing an intuitive way of organizing large collections of processes, thisapproach also simplifies the problems of maintaining them using a concept calledinheritance from computer science. More details of this approach are included in theappendix of this paper.
Phios is developing three primary software products:
Process editor This tool lets power users create and maintain the knowledge in aprocess repository. This knowledge can include process maps (such as flowcharts),text and graphics about the processes, and links to Web sites. The tool uses softwareloaded onto a users PC to edit either a local or shared process repository.
Process repository server This software allows users with standard Web browsers(such as Internet Explorer or Netscape Navigator) to view the contents of a processrepository (such as a repository containing their own companys processes). Thisinstallation includes database and Web server software. The software is installed on aserver computer (usually on a companys own Intranet).
Stand-alone process viewer This tool lets users view the contents of a processrepository on their own PC without being connected to a network. It can be used, forexample, to view processes on an airplane or in a meeting where connection to theInternet is not convenient.
Phios is also developing the following content-based products:
Business process knowledge The Phios Process Repository currently includes over5000 process and activities. This knowledge base includes (a) a detailed skeletonfor representing knowledge about all business processes, (b) a number of businessprocess reference models, and (c) case examples, best practices, and links to otherkinds of business knowledge from a variety of sources.
Some companies may use the Phios software tools to represent only their ownbusiness processes, but we expect that many will want to use some of this otherknowledge provided by Phios as a starting point for organizing or supplementing theirinternally generated process knowledge.
Public web site For companies that do not use the Phios software tools, the Phiosbusiness process knowledge will also be available via a public web site. Some of thiscontent will be available for free; other parts will require subscriptions or other formsof payment.
As shown in the figure below, the Phios software includes three primary levels: (a) arelational database (such as Microsoft Access, SQL Server, Oracle, etc.), (b) a processrepository engine layer that adds the object-oriented features described in theappendix on top of a standard relational database, and (c) a variety of different userinterfaces and links to other tools. The Process Handbook Applications ProgramInterface (PH API) between the top two levels simplifies the development of multiplealternatives at these two levels.
The Phios content is available as information stored in a companys local processrepository or via the public Phios web site.
Figure 2. The Phios product architecture
A typical customer configuration
While different customers will have different needs, we expect a typical productconfiguration for a company using the Phios Process Repository tools to include:
(1) One or more process repository servers to make the companys internal processknowledge available over the companys Intranet to people involved in performingand managing the processes in the repository.
(2) A number of process editor tools to be used by process analysts, process managers,and others involved in defining and maintaining the process knowledge base for thecompany.
(3) If some users need to access the repository when it is difficult to connect to theInternet (e.g., in meetings or on airplanes), stand-alone process viewers for theseusers.
TOOL INTERFACESUSER INTERFACECLIENTS
Other add-on tools
Process Handbook API
Process Repository Engine
Other software tools
Other processmodeling tools
(4) A corporate license to use the Phios business process knowledge in the companysinternal repository
(5) A corporate subscription to access the Phios repository on the public web site.
Using the Phios Process Repository: Company examples
Dow Corning Corporation: Implementing SAP and supply chain management
Dow Corning Corporation is a leading producer of silicone materials and polycrystallinesilicon. The company has annual revenues of approximately $2.5 billion, with greaterthan 50% of it's sales base being outside the U.S. They are nearing completion of theinstallation of SAP's integrated software suites (an Enterprise Resource Planning System)worldwide. This is enabling the identification of a number of business processimprovements. Dow Corning is taking advantage of these opportunities throughrationalizing and standardizing many of their global business processes. They feel it isparticularly important that these process changes be documented to provide a basis forcontinued process innovation from future learning.
Before working with Phios, they had developed initial models of the business processesthey expect to use with SAP. These models are quite detailed, including color coding toindicate which activities in the process are performed using SAP functions, which areperformed manually, and which are performed with legacy software systems.
Dow Corning represented these models using the Visio business diagramming tool. Assuch, the models were essentially isolated drawings: Whenever an arrow from onediagram pointed to another diagram, or whenever the same activity was used in multiplediagrams, consistency between the different diagrams had to be maintained manually.
In their discussions with Phios, Dow Corning realized that what they really wanted wasan underlying process repository that would maintain a single consistent representation ofall their business processes and would allow different subsets of the processes to beviewed in different ways at different times.
Working with Dow Corning, Phios developed software to automatically import theexisting Dow Corning Visio diagrams into the Phios Process Repository. Phios alsodeveloped software to edit the contents of the repository using Visio as a live userinterface. This Visio-based user interface is now the primary user interface in the Phiosprocess editor.
Dow Corning now has over 30 SAP-related business processes represented in the PhiosProcess Repository, each including a number of activities and events (see example inFigure 3). They are preparing to use the Phios Process Repository to make these processmodels and related documentation available on their corporate Intranet to the people whomanage and carry out these processes.
Figure 3. A sample view of the Dow Corning business processes over theWeb.
After initially representing their SAP-related processes in the Phios Process Repository,Dow Corning also became interested in using the Phios repository to analyze theirprocesses from an integrated supply chain perspective. The supply chain model theywanted to use was the Supply Chain Operations Reference (SCOR) model developed bythe Supply Chain Council (described in more detail in the next section). In doing this
supply chain modeling, however, Dow Corning wanted to take as much advantage aspossible of the work they had already done on representing SAP processes.
The Phios repository already included the SCOR model, and working with Phios, DowCorning created a new specialization of the SCOR model that was specific to DowCorning. Then, they modified this specialized model to include linkages to the detailedDow Corning SAP-related processes used to do the various supply chain activities. Inthis way, Dow Corning was able to re-use the same detailed models in multiple ways fordifferent purposes.
Now, in addition to their SAP and supply chain modeling, Dow Corning is alsoinvestigating using the Phios Process Repository for other purposes such as ISO 9000modeling and compliance with regulated processes such as those for handling hazardousmaterials.
The Supply Chain Council: Managing and sharing a process reference model
The Supply Chain Council is a trade association of over 400 companies interested insupply chain management (see www.supply-chain.org). The founding members of thegroup include AMR Research, Bayer Corp., Compaq Computer, Pittiglio Rabin Todd &McGrath (PRTM), Procter & Gamble, Lockheed Martin, Nortel, RockwellSemiconductor, and Texas Instruments. Formed in 1997, the Council developed theSupply Chain Operations Reference (SCOR) model, which has quickly become the defacto standard model for cross-industry supply chain modeling. The SCOR modelcontains standard process definitions, standard terminology, standard metrics, supply-chain best practices, and references to enabling information technology.
The Supply Chain Council has recently chosen the Phios Process Repository as the toolwith which they will manage and extend the SCOR model. The current version of theSCOR model is now incorporated in a Phios repository, and the Phios tool is alreadyproviding a simple, easy-to-use way for SCC members to view the model using theWorld Wide Web. For example, Figure 4 shows part of the SCOR model as viewed overthe Web.
In the future, by providing a single, integrated, repository, the Phios tool is also expectedto help the Council much more easily manage and maintain consistency among differentparts of the model, successive releases of the model, and multiple versions of the model.
Figure 4. A sample view of the Supply Chain Councils SCOR model.
Firm A: Getting innovative ideas about hiring
Firm A is a large, well-known services company, which doesnt want to be explicitlyidentified. As part of the MIT research project on which the Phios products are based,MIT worked with AT Kearney (one of the MIT research sponsors) and Firm A (one ofAT Kearneys clients) to generate highly innovative new ideas about how Firm A couldimprove its hiring process.
This project was motivated by the fact that Firm A was experiencing increasing problemswith hiring. They were growing rapidly in a tightening labor market, and they had aculture of independent, competitive business units. Together, these factors led toincreases in the time and cost to hire people and to increasingly frequent instances ofbusiness units hoarding candidates or bidding against each other for the samecandidate. Before this project began, Firm A had already invested a great deal of timeand energy into as is process analysis using techniques such as flowcharting.
The project teams first step was simply to see how the hiring process was represented inthe process repository. Several of the steps in the activity called Hire human resourceswere similar to those already identified by the as is analysis (e.g., identify need,determine source, select, and make offer). One immediate insight, however, resulted
from the fact that the repository included a step of pay employee which had not beenincluded in the as is analysis. Even though they hadnt previously thought of it in thisway, the team members from Firm A found it surprising and useful to realize that theemployee receiving a first paycheck is, in a sense, the logical culmination of the hiringprocess. Receiving a (correct) paycheck, for instance, confirms that the hiringinformation has been entered correctly in the relevant administrative systems.
To generate further ideas, the team looked at the specializations of the overall hiringprocess and then at the specializations of each of its subactivities. (In other words, theylooked to the right on the Process Compass.) In doing so, they came across dozens ofexamples of innovative practices other companies used in hiring (see Figure 5). Forinstance, one interesting example involved how Marriott uses an automated telephonesystem to screen job applicants. The system asks job candidates a series of questionsabout their qualifications and salary requirements over the telephone, and candidatesanswer these questions using their touch tone telephone keys. Then, at the end of thecall, the candidates are immediately told if they're qualified for the position and invited toschedule an interview through the system's automated scheduling feature. Although thisapproach would be very inappropriate in many situations, the team members from Firm Athought this approach might be very useful for some of their entry-level positions.
After looking at a number of these examples of innovative hiring practices, the teamsnext step was to look further afield in the repository for distant analogies (or cousins)of the hiring process. That is, they looked first at generalizations (ancestors) of thehiring process and then at other specializations (descendants) of these generalizations.(In terms of the Process Compass, they moved left and then right again.)
For example, hiring is classified in the repository as a specialization of buying, so ahandbook user who looks at the generalizations of hiring will see buying. Inretrospect, this connection may seem obvious (hiring is a form of buying someonestime), but this analogy had not been obvious to the project team, and it was a verystimulating source of insights. For example, the team found a description of GeneralElectrics Internet-based purchasing system through which buyers can find and comparesuppliers, and this example stimulated ideas about how Firm A might be able to use asimilar system to identify job candidates using the Internet.
As a result of this project, Firm A identified dozens of new ideas for how they could dohiring. They also felt that, in addition to simply being a source of new ideas, the processrepository could be useful as a framework for organizing and keeping track of all theideas generated in the course of the teams discussions.
Figure 5. A sample of innovative hiring practices viewed by Firm A.
Just as most companies today are far more sophisticated about systematically managinginformation than they were a decade or two ago, we believe that more and morecompanies are now beginning to recognize the benefits of systematically managing theirprocesses as well. To realize its ultimate potential, this kind of systematic processmanagement will require managerial and cultural changes similar to those that haveoccurred with information management. It will also require specially designed electronicrepositories to help define, track, and share knowledge about business processes.
The mission of Phios is to be a leading provider of products in this important new area.
1 A detailed description of the results of the MIT research project is available in thefollowing article: Malone, T. W., Crowston, K. G., Lee, J., Pentland, B., Dellarocas, C.,Wyner, G., Quimby, J., Osborn, C. S., Bernstein, A., Herman, G., Klein, M., &ODonnell, E. Tools for inventing organizations: Toward a handbook of organizationalprocesses. Management Science, in press. (Available at http://ccs.mit.edu/21c/mgtsci/)
Appendix:Specialization of Processes
In addition to providing a powerful, but intuitive, way of organizing large collections ofprocesses, this approach also lets us take advantage of the concept of inheritance fromobject-oriented programming in computer science. This means that each activityautomatically inherits the subactivities and other properties of its generalization, exceptwhere the specialized activity explicitly adds or changes a property. For example, Figure2 shows how the generic activity called Sell product is differentiated into types (orspecializations) like Sell by mail order and Sell in retail store. Each of thesespecializations inherits some of the subactivities of Sell product and changes others.For instance, in Sell by mail order, the subactivities of delivering a product andreceiving payment are inherited without modification, but Identifying potentialcustomers is replaced by the more specialized activity of "Obtaining mailing lists."
Figure 6. Sample views of three different sales processes. "Sell by mailorder" and "Sell in retail store", are specializations of the generic salesprocess "Sell product". The subactivities shown with shadows arechanged relative to the corresponding activities in the generic salesprocess.
Using this approach, any number of activities can be arranged in a richly interconnectedtwo-dimensional network. Each of the subactivities shown in Figure 6, for instance, canbe further broken down into more detailed subactivities (e.g., "Type mailing list nameinto computer using SAP function #17A") or more specialized types (e.g., "Obtainmailing list from broker, Obtain mailing list from trade association, Obtain mailinglist from current customer list, etc.) to any level desired.
This approach can be used, for example, to create different types of the same genericprocess for: (a) different industries, (b) different companies, (c) different divisions of a
Mail adsto mailing
Sell by mail order
Sell in retail store
company, (d) different geographical regions of a company, (e) different softwareimplementations (e.g., purchase using SAP vs. purchase using Baan), and many otherdimensions.
This approach significantly simplifies the problem of maintaining large repositoriesbecause it explicitly represents the commonalties and relationships among differentvariations of the same generic process. Changes made at a high level, for instance, to thecorporate standard process for selling at Company X are then automatically inherited toall the different specializations of this process (e.g., for different products or divisions)except where the specializations have already made other changes of their own.
Comparison with object-oriented programming
To readers familiar with conventional object-oriented programming techniques, it isworth commenting on the difference between this approach and conventional object-oriented programming. Traditional object-oriented programming inherits down ahierarchy of increasingly specialized objects, which may have associated with themactions (or methods). Our approach, by contrast, inherits down a hierarchy ofincreasingly specialized actions (or processes) which may have associated with themobjects. Loosely speaking, then, traditional object-oriented programming involvesinheriting down a hierarchy of nouns; our approach involves inheriting down a hierarchyof verbs.
There is, of course, nothing contradictory between these two approaches. We believe thatboth are often useful in the same system. In a sense, this process oriented inheritancecan be considered the missing half of object-oriented programming. The process-oriented approach appears to be particularly appropriate for the analysis and design ofbusiness processes.
We have also found it useful to combine specializations into what we call bundles ofrelated alternatives. For instance, Figure 7 shows part of the specialization hierarchy forsales processes. In this example, one bundle of specializations for Sell something isrelated to how the sale is made: direct mail, retail storefront, or direct sales force. Anotherbundle of specializations has to do with what is being sold: beer, automotive components,financial services, etc.
Figure 7. Summary display showing specializations of the activity "Sell something".Items in brackets (such as "[Sell how?]") are "bundles" which group together sets ofrelated specializations.
Comparing alternative specializations is usually meaningful only within a bundle ofrelated alternatives. For example, comparing retail store front sales to direct mailsales is sensible, but comparing retail store front sales to selling automotivecomponents is not. Where there are related alternative specializations in a bundle, ourrepository can include comparisons of the alternatives on multiple dimensions, thusmaking explicit the tradeoff between these dimensions.
For example, Figure 8 shows a tradeoff matrix that compares alternatives in terms oftheir ratings on various criteria; different specializations are the rows and differentcharacteristics are the columns. For very generic processes such as those shown here, thecells usually contain rough qualitative comparisons (such as High, Medium, andLow); for specific process examples, they may contain detailed quantitativeperformance metrics for time, cost, job satisfaction, or other factors. In some cases, thesecomparisons may be the result of systematic studies; in others, they may be simply roughguesses by knowledgeable experts and, of course, in some cases, there may not beenough information to include any comparisons at all.
Figure 8. A tradeoff matrix showing typical advantages and disadvantages of differentspecializations for the generic sales process. (Note that the values in this version of thematrix are not intended to be definitive, merely suggestive.)
Copyright 1999 Phios Corporation.
All rights reserved.