Popular in Course
verified elite notetaker
Popular in Business
This 36 page Document was uploaded by an elite notetaker on Sunday December 20, 2015. The Document belongs to a course at a university taught by a professor in Fall. Since its upload, it has received 9 views.
Reviews for Document-Engineering
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 12/20/15
10 Designing Business Processes With Patterns 10.0 INTRODUCTION 313 10.1 WHY WE USE PATTERNS IN PROCESS MODELS 313 10.2 HOW WE USE PATTERNS IN PROCESS MODELS 320 10.3 PATTERNS AND THE MODEL MATRIX 321 10.4 IDENTIFYING CANDIDATE DESIGN PATTERNS 324 10.5 CHOOSING APPROPRIATE PATTERNS 337 10.6 ADAPTING PATTERNS 341 10.7 INSTANTIATING PATTERNS TO CREATE NEW MODEL343 10.8 USING PATTERNS TO SUGGEST INFORMATION COMPONENTS AND DOCUMENTS 347 10.9 KEY POINTS IN CHAPTER TEN 351 318 DOCUMENT ENGINEEANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES 10.0 INTRODUCTION Patterns are models that are sufficiently general, adaptable, and worthy of imitation that we can reuse them. They are an essential theme in Document Engineering; we began Chapter 1 with GMBooks.com and the drop shipment pattern, in Chapter 4 we presented a repertoire of organizational, process, information, and architecture patterns, and in Chapter 5 we explained how those patterns mutually evolve with technology. In Chapter 9 we introduced transaction and collaboration patterns in the framework of a three-level metamodel for describing processes. In Chapters 12-14, we will discuss patterns in document and document component models. We devote this chapter to specific techniques for applying and adapting patterns to business process designs because the choice of process pattern strongly influences what information is required and how that information is packaged and exchanged as documents. WHY WE USE PATTERNS 10.1 IN PROCESS MODELS In Section 3.4.2 we discussed why businesses follow patterns. Now we will take a closer look at the benefits of using patterns for our process models: • Simplify work. Patterns provide the immediate benefit of reduced design and integration efforts and the longer-term benefit of greater consistency and standardi- zation. • Encourage best practices. We call something a pattern because it captures typi- cal or preferred ways of doing things, making it worthy of imitation. As such, pat- terns are always candidates for To-Be models. • Assist in analysis. A process pattern brings with it a set of roles, requirements and rules. For example, the drop shipment pattern includes roles for the retailer, the inventory distributor, the shipper, and the payment authority. The pattern may also suggest the types of firms that can perform one or more of these roles and the types DESIGNING BUSINESS PROCESSESWITH PATTERNS 319 of users and other stakeholders with whom we can verify the requirements in our context. Patterns also give us insights that we can't see in instances; for example, generalized patterns let us recognize that both automobile and computer makers are adopting similar component assembly and make-to-order processes. • Expose inefficiencies. In a typical instantiation of the drop shipment pattern, the distributor simultaneously sends shipment information to both the customer and to the retailer (so that the latter can handle customer queries). In contrast, we might find in an As-Is model that the distributor sends shipment information to the seller, who then forwards it to the customer. Comparing the As-Is model to the pattern sug- 1 gests an inefficiency that might be removed in an improved To-Be model. • Remove redundancies. For example, we might learn in an As-Is model that both the seller and the distributor are sending shipment information to the buye.rThe pat- tern helps us identify and remove the redundant information exchange. • Consolidate interfaces. Using a common pattern allows different contexts of use to share a common interface. Using a single integration point to support all of the information exchanges can substantially reduce implementation and maintenance costs. For example, a buyer can use a common interface for both direct and indirect procurement processes. • Encourage modularity and transparent substitution. When patterns are organ- ized for reuse, they are more easily adopted, and the network effects yield even greater benefits to those who follow them. The standardization and generalization that comes from using patterns over time encourages more modular perspectives and architectures for roles and processes and further reduces implementation and main- tenance costs. For example, it becomes easier to replace one service with another to meet quality of service or cost goals and facilitates the outsourcing of internal func- tions to external services. 320 DOCUMENT ENGINEERANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES These benefits help explain why designing business processes more often involves applying and adapting patterns than inventing new ones. Designing business processes more often involves applying and adapting patterns than inventing new ones 10.2 HOW WE USE PATTERNS IN PROCESS MODELS To design new business process models we want to identify patterns that best satisfy the requirements of our context of use. If a business process pattern is an excellent fit to a set of requirements we can use it without change. Then we simply follow the pattern exactly to design our To-Be Model, just as we might make a pizza by follow- ing a recipe exactly. In recent years many merchants have followed the drop ship- ment pattern exactly, playing the role of the retailer with other enterprises serving as inventory distributor, shipper, and payment authority. Even when a standard pattern isn’t the best match to our requirements, we might consider changing some of those requirements and adapting to the pattern. Otherwise, the advantage we might gain by changing the pattern to better satisfy internal needs might be outweighed by new costs imposed on customers, external partners and services that can no longer use the standard pattern in dealing with us. If the process isn’t one where innovation can yield competitive advantage, standard processes win the cost-benefit analysis over customized ones. Business strategist Geoffrey Moore puts it succinctly: “Differentiation that does not drive customer pref- erence is a liability.” But sometimes we do need to adapt a pattern and make changes to fit the specific requirements of our context of use. This is analogous to how we adapt a pizza recipe when we substitute different cheeses or toppings for those it specifies. Sometimes our adaptations are successful enough to be imitated as patterns in their own right DESIGNING BUSINESS PROCESSESWITH PATTERNS 321 Sometimes adaptations are successful enough to be imitated as patterns in their own right. The Hawaiian Pizza, created by substituting the Polynesian ingredients of ham and pineapple for more traditional ones, has become popular enough to become part of the pizza pattern library. In contrast, the much rarer Indonesian Pizza adaptation that uses soy sauce, cane sugar, peanuts, and chili has not been followed enough to warrant calling it a pizza pattern. We don’t need to invoke any mechanisms of natural selection or evolutionary advan- tage to appreciate the reasons and benefits for patterns to take hold. Is it better to drive on the right side or the left side of the road? We won’t argue either way; the right-side or left-side pattern becomes worthy of imitation in some jurisdictions just because people have agreed to it. 10.3 PATTERNS AND THE MODEL MATRIX In Chapter 4 we discussed a range of patterns at different modeling levels to give you some familiarity with the more common patterns at each level from the new perspec- tive of Document Engineering. Our survey was by no means exhaustive, especially at the process level, where there are several much more comprehensive collections of business process patterns and business reference models. But our survey was sufficient to show that what distinguishes Document Engineering is its systematic approach for discovering and formalizing the relationships between the patterns and artifacts at the organizational and business process levels and those of documents and their information components. This connects the strategic perspec- tive of what to do with the implementation perspective of how to do it. We can use the dimensional framework of the Model Matrix depicted in Figure 7-2 to demonstrate how different kinds of patterns relate to each other. We begin with a discussion of how we can use both the abstraction and granularity axes in the Model Matrix to find candidate patterns for our required (To-Be) models. Then we will discuss how to choose the most appropriate patterns and adapt them if necessary. DOCUMENT ENGINEERINGANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES 322 The most abstract patterns of business organization describe business roles and func- tions from a context-free, generic perspective. These are depicted on the top left side of the Matrix. Patterns of this type would include Manufacturing, Transporting, Selling, and so on, with no specification of the industry or type of product or service involved. As we move to the right, we add context to these abstract patterns to describe a nar- rower set of situations. For example, in Figure 10-1 we depict a Computer Manufacturer pattern as a specialization of the manufacturing pattern in the infor- mation technology industry. When we reach the top right side of the Matrix we encounter specific firms that follow the pattern as customized to meet all the busi- ness rules of a particular enterprise or ecosystem; in Figure 10-1 we use Dell as an implementation of the Computer Manufacturer pattern. Figure 10-1.Reusing Patterns in the Model Matrix A similar progression from generalized patterns to contextualized implementations is represented at the process layer in the Model Matrix. We've depicted three rows in the process model layer to remind us of the three layers of the Chapter 9 metamod- DESIGNING BUSINESS PROCESSESWITH PATTERNS 323 el for processes, which treats processes as consisting of collaborations, which in turn consist of transactions. At the coarsest process granularity are the business process pattns, such as Demand Chain, Information Aggregation, Procurement, or Auction. We described these (and others) in Chapter 4. As we move to the right, we contextualize the Demand Chain process pattern to dis- tinguish the Make-to-Order pattern for products manufactured from components. These patterns can be further contextualized to describe the specific operational processes and business rules used when Dell applies the Make-to-Order pattern for personal computers in its relationships with its suppliers of disk drives, microchips, and other components. Collaborations offer a level of granularity between business processes and the trans- actions that implement them. In Figure 10-1, collaboration patterns that are used in the Demand Chain pattern such as Negotiation are contextualized as industry codes of practice and contract laws. These in turn, may be implemented as the specific terms and conditions expressed in trading terms used by Dell. Transactional patterns provide the finest level of granularity in the process layer. On the conceptual side we find general transaction patterns like Offer-Acceptance or Query-Response. As we move to the right we find these patterns applied in a more specialized purchasing and order management context. For example, the RosettaNet PIPs would fit here, once we've specified the context of the electronics and informa- tion technology product Demand Chain using a Make-to-Order pattern. Companies like Dell then build interfaces to their supply chain using these transactional patterns as specifications. Along the bottom row of the Model Matrix we can see the same progressive contex- ualization of abstract patterns for information components that we saw for process- es in the rows above it. Collaboration and transactional patterns require certain key information compo- nents. For example, we know that the Demand Chain/Negotiation/Of fer and Acceptance process pattern requires a component for the date (or time) an offer is sent. On the conceptual side we might use a generic definition of a component pat- 324 DOCUMENT ENGINEERANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES tern known as Date. This may be further qualified as Date Sent to define its use as the sending date. As we move to the right in this row this pattern might be reused in the more specific context of a physical model, perhaps as the element DateSent in a UBL Order schema. We would then see implementations of these components as the value of the date the actual offer was sent. IDENTIFYING CANDIDATE 10.4 DESIGN PATTERNS When we use the idea of the Model Matrix to identify suitabrs for our design, we are simply moving along the abstraction and granularity dimensions to confirm our analysis and understanding of the context of use. We are not the first to recognize how compelling these dimensions are for navigating between different types of models. Our approach adapts and extends ideas that are embodied in the MIT Process Handbook (see SIDEBAR). Our innovation is to incor- porate the lowest level of patterns for documents and information components using the same two dimensions. So we call our navigation mechanism the “Pattern Compass” in contrast to the “Process Compass” in the MIT framework. Figure 10-2 illustrates this idea of navigation in the Model Matrix to identify and evaluate candidate patterns. DESIGNING BUSINESS PROCESSESWITH PATTERNS 325 Figure 10-2.The Pattern Compass in the Model Matrix • Movement from left to right is in the Contextualize direction. As we illustrated when we explained Figure 10-1, this makes patterns more specific (or specialized) for a particular context. • Movement in the reverse direction from right to left follows the Generalize direc- tion to select patterns that are more abstract. • Movement from top to bottom on the Granularity dimension increases the gran- ularity of the pattern. As we move in this direction we take a close up perspective on a pattern to see details that aren't visible at the higher levels; we might call this look- ing at the trees instead of the forest. This means we see the processes inranization- al patterns and the document exchanges and information components that aren't vis- ible in process patterns. • Movement in the reverse direction from bottom to top on the Granularity dimen- sion reduces the granularity of the pattern. We progressively hide the lower level details to create a coarser, big picture view of the pattern; now we're looking at the forest instead of the trees. DOCUMENT ENGINEERINGANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES 326 MIT Process Handbook The MIT Process Handbook contains thousands of process descriptions and case stud- ies and is a unique re s ouerfor process analysis and redesign. It has three import a n t characteristics: it is comprehensive, easy to use, and based on the formal analysis of businesses using a consistent theoretical base. The pro j e s t’ p o s iyt oes beyond traditional process databases and pattern libraries by explicitly storing the abstraction and compositional relationships among the process patterns. Explicit re prsentation of these two dimensions enables the nav- igation metaphor to be implemented in the user interface to the pattern re p o s iytosr a “process compass.” In addition, users can annotate existing patterns or create new ones that they can link into the appropriate locations in the logical grid. The network of associations between processes enables a great deal of information to be automatically inherited from more abstract patterns. It also makes it possible to 6 generate alternatives for how a given process could be perf o rm e d . Rather than create our own physical re p o s iytorsupport the Model Matrix, we hope to someday add these lowest level patterns for documents and information compo- nents to the MIT one. A re p o s iythart contained patterns at all three levels would be significantly more useful than two separate ones. The business process models we developed in Chapter 9 usually describe cur rent (As- Is) business processes, together with their collaborations and transactions. When our process analysis is grounded in existing implementations, this means that we will be starting the design phase on the right side of the Model Matrix. As we create To-Be models, we will be taking a more conceptual and general, and less granular, perspec- tive on processes and moving left and up in the Model Matrix. In contrast, if we are designing a business process where there is no existing imple- mentation, or if we are developing a standard pattern or reference model for an industry association or standards activity, we might start with a more abstract pat- tern. Then we work our way to the right in the Model Matrix as we systematize the roles and rules needed for these more specific contexts. DESIGNING BUSINESS PROCESSESWITH PA327RNS 10.4.1 GENERALIZING PATTERNS We generalize patterns by relaxing or eliminating requirements in our context of use and assessing the resulting effects and dependencies. We might vary the product, the industry, geography, regulations, or other context dimensions and determine if we can ignore them without consequence. A pattern also becomes more general if we di-s card or choose not to implement rules or properties that govern the state or behav- ior of the transactions and collaborations in the pattern (we’ll discuss these in Section 10.7.2). And, because our process models are conceptual and not bound to any spe- cific implementation technology, we can generalize patterns from widely different contexts. We generalize patterns by relaxing or eliminating requirements in our context of use and assessing the resulting effects and dependencies Figure 10-3 illustrates the idea of generalizing patterns with a depiction of some of the contents in a hypothetical repository of process patterns. A bookstore might use the most specific relevant pattern, the one labeled Sell Books. But we could general- ize this pattern into selling tangible products other than books, or further generalize it to include sales of intangible products like information or digital entertainment. Figure 10-3.Generalization in a Process Pattern Repository DOCUMENT ENGINEERING ANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES 328 Their reduced contextual constraints means that generalized patterns can also be used to consolidate disparate processes. For example, a department store or super- market would probably want to avoid distinct processes for sales and inventory con- trol for each type of product. So they generalize their patterns wherever possible. Processes for some categories of goods, such as perishable ones, might be specializa- tions of the general sales and inventory patterns. But even they would be governed by more general patterns. For example, processes for selling perishable goods are driven by expiration date, whether the goods are cut flowers or airline tickets. We need to emphasize that when we’re discussing how to generalize patterns as part of process design we are still at the conceptual level. The bookstore, department stoe r or supermarket in our examples are generalizing their business models; that is, how they think about the businesses they are in and the processes they carry out. In real- ity, a store’s ability to generalize its implementation of these models will be con- strained by the application software used to run the business (as well as by the soft- ware used by its business partners). Using ready-made software tailored for a specif- ic industry can be the most efficient way to set up a business but also makes it diff i c u l t to scale it up or expand it beyond its original business model. That’s why it is so criti- cal to think about processes before choosing the technologies for implementing them. Generalizing the Business Pattern of Colocation We can demonstrate the idea of generalizing a business pattern by examining the instances of business models involving colocation. Consider: ▯ • A bank inside a superm a r k e t ▯ • A post office inside a superm a r k e t ▯ • A photo processing service inside a superm a r k e t . These three examples suggest a pattern that we might call Colocation of C o m p l e m e y Prtodrct or Service for Supermarket Customers. Once we've described it in this more general way, we can readily apply this pattern to recognize other ways in which an errand or quick business interaction could be made more efficient by co location of a business service in a supermarket. Dry clean- ing and shoe repair businesses are appropriate candidates because of their quick DESIGNING BUSINESS PROCESSESWITH PA329RNS transactions; dentists and auto body shops aren't because their transactions are nei- ther short nor complementary. We might try to further generalize the pattern by relaxing the supermarketr e n tei m and making it Colocation of Complementary Businesses. We can use this more abstract pattern to generate additional ideas for new business combinations; one that is already well established is the large bookstore that contains a coffee shop franchise. 10.4.2 VARYING THE GRANULARITY OF PATTERNS The granularity of an As-Is process model is shaped by the sources of information about processes and whether the analysis was more top-down or bottom-up. Top- down analysis yields large, goal-oriented processes; bottom-up analysis produces a more detailed, transactional view. Both views of processes can be correct, but process models are most useful when they contain at least a little of both perspectives. The granularity of an As-Is process model is shaped by the sources of information about processes and whether the analysis was more top-down or bottom-up Moving down on the Granularity dimension in the Model Matrix increases the gran- ularity of a process model and suggests documents and information components that we need to find or design in the document and component analysis phases of Document Engineering. We will describe this activity in Section 10.7. Moving up on the Granularity dimension decreases the granularity of a process model to create a broader view that hides details. Describing processes at a higher level makes it easier to make models more rational or consistent because the equiv- alences among instances are no longer obscured by specific low-level details. C o a r s e r or less granular models also suggest patterns that encourage new specializations. Coarser grained models suggest patterns that encourage new specializations DOCUMENT ENGINEERINGANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES 330 Returning to our pizza analogy, we notice that following an extremely detailed recipe with precise descriptions of processes and ingredients (like those at the bottom of Figure 10-4) ensures that the pizzas come out exactly the same every time. But a l e s s detailed recipe that consists of only the midlevel steps would make it easier to re c o-g nize possibilities for reuse and adaptation of other patterns. This coarser view might i n s peitrhe realization that making pizza has much in common with making bre a d . F rom such insights emerge new models like focaccia, the Italian bread-pizza hybrid. Figure 10-4.Different Granularity in Pizza Recipes Process libraries like the MIT Process Handbook or the RosettaNet Partner Interface Processes (PIPs) are organized hierarchically to encourage process analysts to vary their perspectives on processes until they find a level of granularity that works for them. The RosettaNet process library is especially useful because its three-level hier- archy of process clusters, segments, and PIPs reinforces the three-level metamodel of 7 processes, collaborations, and transactions. This consistency makes RosettaNet a helpful guide for both novice and experienced analysts, and we have adapted the PIPs as patterns in domains far from the information technology supply chain for which they were originally designed. In Figure 10-5 we show a subset of the library that includes some of the order and inventory management patterns we often use as examples in this book. DESIGNING BUSINESS PROCESSESWITH PATTERNS 331 Figure 10-5.The RosettaNet Business Process Hierarchy DOCUMENT ENGINEERINANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES 332 10.4.3 COMBINING PATTERNS We also can create composite processes by combining separate ones. Consider the processes that are carried out to make arrangements for a business trip. A traveler might need an airplane ticket, a rental car, a hotel room, and a restaurant reserva- tion near the hotel. These four procurement processes involve different business serv- ice providers and might be conducted separatel, but this is highly inefficient because they have overlapping information requirements and dependencies. It would be desirable for the processes to be combined as a composite service in which the over- lapping information about time, location, and price is collected just once (perhaps in a single web form). The composite service handles all the interactions and depend- encies among the four processes in a way that is invisible to the traveler or the process that invoked the service. We can create composite process models by combining separate ones The composite service is not a generalized travel process; it simply carries out the original four processes for making airplane, rental car, hotel, and restaurant reserva- tions. But it has a single interface and is invoked with just one document or web form . Composite processes can be faster, cheaper, and more reliable than separate ones and can even be reused. But there are some significant challenges in creating composites. Unlike the composite travel service example, in which the composite is a single inter- face to multiple services but doesn’t change any of them, many composite processes require changes or agreements about the separate processes from which they are composed. For example, the Single Administrative Document (SAD) for cross-border European trading replaced numerous documents for customs declarations and transport proce- dures. Harmonizing and simplifying the information contained in the SAD required governments, shippers and transport companies to combine their processes into a single process, changing the timing and responsibility for information exchanges 8 among them. DESIGNING BUSINESS PROCESSESWITH PATTERNS 333 A second and more abstract challenge in creating composite services is that the sep- arate processes must have enough overlap in their goals and requirements to justify bringing them together. Some amount of contextual overlap is essential, but there must also be some business necessity for the combination, and both are difficult to specify. Separate processes must have enough overlap in their goals and requirements to justify putting them together For example, referring back to the business colocation pattern from the sidebarear- lier, unless the businesses that colocate have some overlapping customers, processes, and business goals, nothing is gained by their colocation. That is why some shopping malls thrive while others fail. The Science of Business Combination What exactly has to be “in common” for combinations of business processes or serv- ices to be successful? Why it makes sense to bring together some sets of pro c e s s e s 9 but not others is one of the emerging re s echr questions for Document Engineering. We hinted at this problem in our discussion of Service Oriented Arc h i t e cest u inr Chapter 4, because it limits the “plug and play” vision of virtual enterprises in which new businesses are created by combining component services. It doesn't seem eff i- cient to attack the problem with bru t efomr ethods like those used by Thomas Edison, who tried thousands of materials for light bulb filaments until he identified the most 10 a p popr riate combination. A more deterministic and theoretical approach would re q uei ra metamodel for describing services that captures many more aspects of their information and pro c e s s semantics. Such metamodels will undoubtedly be layered to correspond to the abstrac- tion and granularity dimensions we use to organize patterns and will also exploit the metadata that specifies the contexts in which the patterns are appro p r i a t e . T h eerare some glimmers of this idea in version 3 of the UDDI specification, which allows for arbitrarily complex and extensible service descriptions.11But until serv i c e 334 DOCUMENT ENGINEERINANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES p oviders fully use these enhancements little automated service discovery is feasible. N e v thrless, we can imagine a virtual business builder that interrogates registries of richly described business services, computes some metric of semantic distance to find s evrice combinations with the necessary amount of complementary overlap and then p oposes new kinds of virtual enterprises that exploit undiscovered business opport u- nities by applying patterns to new domains. 10.4.4 USING IMPLEMENTATIONS AS PATTERNS Sometimes we want to replicate a process exactly as it has been implemented in another instance. This usually means that the target context of use is effectively iden- tical to an existing one. In this case, we apply the physical model that describes the implementation of the process to be copied, rather than a conceptual model. So the target process uses the same implementation technology and duplicates the specific values currently filling the roles and activities in the source process. Using implementations as patterns is the principle behind franchising and is mani- fested in the identical appearance and operation of the stores in hamburger, coffee, pizza, and other retail chains. Each outlet is essentially a clone, with rigorously spec- ified and enforced facility designs and processes to ensure a predictable customer experience and minimize the business risk to the franchisee. But exact replication of a process can be a denial that patns often must evolve over time in response to changes in the technology and business context in which enter- prises exist (see Chapter 5). Exact replication of a process can be a denial that patterns will and must evolve over time Doing things the way they have always been done can give enterprises too narrow a view of why they are in business and institutionalize practices that might have become inefficient or uncompetitive. In the 19th century, railroad companies viewed their business model as running railroads, and they failed to adapt to new technolo- gies for transportation and communication. More recently we've seen a similar myopia in the music industry, whose fixation on maintaining tight control over the DESIGNING BUSINESS PROCESSESWITH PATTERNS 335 distribution of records, tapes, and compact discs made them late to exploit digital distribution processes. And even the local pizza parlor that reliably produces the exact same excellent pizza will eventually find that its customers want to try some- thing different. It is easier to copy than to innovate because it isn't necessary to understand underlying motivations and conceptual models Exact copying of a business pattern can make it less necessary to understand under- lying requirements and conceptual models. This can be a costly shortcut, however, because if this knowledge is lost then so too is the chance to improve the process at a later time. So while making an exact electronic copy of a printed form may reduce the initial effort to automate paper-based document processes (see Section 126.96.36.199), not analyzing the process and context carefully when new technology and processes are introduced will over time create an increasing burden of processes and documents that contain unnecessary steps and data requirements. These process rituals and doc- ument relics persist because no one understands them well enough to redesign them. P rocess Rituals and Document Relics A ritual is a customary activity or series of actions perf r ed in a given context. Sometimes there is no apparent reason or purpose for the activity, or the original jus- tification has been lost. Rituals are often associated with relics, carefully pre s evre d a rtifacts from the past. A famous example of a process ritual is the cargo cult. During and immediately fol- lowing the Second World Wa ,r groups of indigenous peoples in New Guinea fabri- cated all the surface manifestations of an airport, from cleared jungle runways to wooden headsets with bamboo “antennas.” They were following the processes they had seen perf om red by military personnel when ordering a drop of cargo. But the 1 2 airplanes and the goods never arr i v e d . Most of us have encountered situations in which a paper document and the pro c e -s s es that it participates in have been frozen in time across numerous changes in docu- DOCUMENT ENGINEERINGANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES 336 ment and workflow technology. The cause in most cases appears to be a short s i g -h t ed desire to simplify a document automation eff o trby exactly pre s evirng printed f ors and manual processes. But now no one knows why the forms look the way they do or why the process involves as many approval steps as it does. For example in the Course Approval System at the University of California, Berkeley, many aspects of the original printed Course Approval Form have survived for decades in computer systems despite having little or no contemporary value. One such re l i c on the current form is a data item for the Short Title of the course, a shortened form of the complete course title needed in the 1980s when course registration used 80-col- umn computer punch cards. The form also contains a list of course format codes that includes some types of courses not taught for decades with codes that are meaning- less. Finally, the form contains data entry fields for tracking the state of the appro v a l p ocess that would be unnecessary if the process were effectively automated. What this means is that even when a business copies a pattern exactly it is best to be equally meticulous at extracting and preserving the contextual understanding it con- tains so that it can improve the processes if necessay. This is the approach Intel takes when it uses the slogan of “Copy Exactly” as it copies everything about the plant where a new microprocessor was developed to the facilities where it will be manufac- tured: “everything at the development plant – the process flow, equipment set, sup- pliers, plumbing, manufacturing clean room, and training methodologies - is select- ed to meet high volume needs, recorded, and then copied exactly to the high-volume plant.”13 Intel credits this strategy with substantially increasing quality and reduc- ing time to market. But Intel follows equally disciplined methods for updating technologies and process- es in its network of identical manufacturing plants. Any changes must be implemen- t ed in parallel everywhere with continuous information sharing between the installa- tions to ensure that they remain the same in every respect. And while it is possible for Intel to continuously improve its internal processes even while exactly copying them, a firm may not be able to change its processes after they are implemented because of their connections to external processes that it can’t con- trol. The benefits from improving processes must always be weighed against the cost DESIGNING BUSINESS PROCESSESWITH 337TERNS of changing them, and when others must pay some of the costs it may be difficult to persuade them to change. 10.5 CHOOSING APPROPRIATE PATTERNS The inherent flexibility in our description of processes, the diversity of the sources of information about them, and the varying levels of abstraction of the information we gather make it inevitable that many different patterns will seem appropriate. This is often desirable because evaluating a variety of potential process patterns can encourage innovation. Choosing the most appropriate pattern means selecting the one that best satisfies the requirements of the context of use. We evaluate pattern alternatives by instantiating the roles and testing the rules of the pattern using the requirements we identified during process analysis. Evaluating a variety of potential process patterns encourages innovation Selecting the most appropriate pattern can thus be somewhat subjective, and the choice might be based on which pattern provides the most insight about the target context. One pattern may describe the existing processes (the As-Is model) better than another, but another might more clearly illustrate the changes that would make the processes more robust or effective (the To-Be model). 10.5.1 VALIDATING REQUIREMENTS VS. DISCOVERING THEM The benefits of applying broadly relevant, generalized patterns must be balanced against those that arise when an existing pattern closely fits a well-defined context. For example, a highly abstract and general pattern, such as the one for procurement in Figure 8-3, describes many situations but lacks the precision to satisfy all the bus-i ness rules of complex contexts. If our context were “German automaker buying from a US supplier of industrial chemicals,” it would be better to start with a more spe- cialized pattern that is already tailored to the target requirements. It is easier to val- 338 DOCUMENT ENGINEERINANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES idate the requirements of a specific pattern than to discover and formalize those needed to contextualize a general one. It is also easier to assess the comparative costs and benefits for the parties involved in the more detailed context assumed by a spe- cific pattern. 10.5.2 REINFORCING CONTEXTS WITH PATTERNS But in addition to satisfying contextual requirements, using a pattern also reinforces an interpretation of the context by emphasizing some requirements and business rules more than others. Using a pattern reinforces an interpretation of the context by emphasizing some requirements more than others For example, earlier we described Dell as a computer manufacturer because we wanted to highlight its Make-to-Order manufacturing pattern and focus on its rela- tionships with organizations in its supply chain. But if we wanted to emphasize Dell's direct sales model, we would apply a pattern with a set of requirements and business rules associated with direct distribution. The Berkeley Event Calendar processes could be described using a syndication pattern, which emphasizes content or catalog manage- ment and distribution processes, or using a supply chain pattern, which highlights production, scheduling, and inventory manage- ment processes. Abstracting the business process this way allows us to consider business process libraries (such as the RosettaNet PIPs) for potentially re-usable col- laboration patterns. Figure 10-6 shows the reuse of a syndication pattern (based on the RosettaNet Distribute Product Catalog Information pattern - PIP2A1). In this scenario, the col- laboration of Publish Calendar is based on a calendar being treated as a syndi- cated product. The suppliers/providers of calendar products/events wish to get them to buyers/public who can easily find the products/events they want to pur- DESIGNING BUSINESS PROCESSESWITH PATTERNS 339 chase/attend. As an optional feature of this pattern, a notification message advis- es buyers/public of new products/events. Figure 10-6 Publish Event using a Syndication Pattern But we can also view this collaboration as a reuse of a supply chain pattern (for example, the RosettaNet pattern for Distribute Inventory Report – PIP4C1). Here the scenario is based on treating the events that form a calendar as inventory. Figure 10-7 Publish Event using a Supply Chain Pattern 340 DOCUMENT ENGINEERINANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES In the pattern shown in Figure 10-7, producers/providers of inventory/calendars want to keep their inventory/calendars up to date and remove expire d stock/events. Naturally there will be customization differences between these patterns. For many kinds of goods, expired goods aren't desirable so they get removed from the inven- tory report. Expired events, on the other hand, help people understand the nature of events likely to appear on a calendar so they should not be removed; expira- tion is implied by their date being in the past. The choice between syndication and supply chain patterns here is important, because it highlights different factors and concerns in the context of use. The sup- ply chain pattern seems a better fit because it calls attention to the critical mass problem: without a steady stream of events from different sources, there would be no benefit of shared content. 10.5.3 APPLYING PATTERNS TO ACHIEVE INSIGHT Sometimes we can get new insights about a business problem or inefficiency by try- ing to apply a pattern to a context substantially different from its usual ones. The pattern will probably not fit the target context well enough to be used as the To-Be model, but this design exercise is a way of thinking that forces us to take a fresh and almost metaphorical look at the roles and rules that the pattern entails. We can get new insights about a business problem or inefficiency when we apply a pattern to a substantially different context Suppose we apply the general patterns of component-based manufacturing and sup- ply chains to the university, treating it as a factory from which students buy their degrees. This isn't an entirely new metaphor; schools with low academic standards are sometimes derogatorily described as “diploma mills.” We can apply the Supply Chain Operations Reference (SCOR) pattern (Figure 4-2) to the university by treat- ing it as the manufacturer that drives the supply chain. This makes the university DESIGNING BUSINESS PROCESSESWITH PAT341NS course catalog a multivendor catalog (Section 188.8.131.52) that aggregates the products offered by the competing suppliers, the various schools or academic departments. The students are the buyers who hope to obtain a valuable degree by paying the uni- versity to enforce graduation requirements, which are analogous in the supply chain to the bill of materials for each manufactured product. Finally, selecting courses and registering for classes each term are analogous specializations of the sourcing and ordering transactions in the procurement process. Why do some courses and majors always have wait lists while others fail to meet their enrollment targets? Interpreting the supply chain pattern in the university context gives us some insight about these typical mismatches between supply and demand that plague students and university officials. SCOR tells us that every supply chain should have a rigorous planning phase with binding commitments where possible between buyers and suppliers to make demand predictable. But most universities don't control their supply chains with this degree of sophistication, and most lack any equivalents to supply chain processes and documents like Forecasts, Inventory R e p ots,rand Commitment to Supply, whose use might reduce these typical pro b l e m s . Of course, factors like faculty tenure limit the application of these control mecha- nisms in the university supply chain, and applying that pattern disregards the essen- tial role of the university as a research institution. So when we gave students at UC Berkeley the assignment to apply the Make-to-Order pattern (used so successfully by Dell Computer as a computer manufacturer) to the university's operations, many of them initially resisted the extent of commercialization implied by viewing themselves as product consumers and their professors as product suppliers. Later, though, after applying the commercial patterns to a new domain and thinking about the implica- tions, most students appreciated that a “Dell-iversity” might offer them more course choices and personalized majors. 10.6 ADAPTING PATTERNS Even if a process pattern fits the target context requirements in most respects, it might need to be adapted to improve efficiency, reduce costs, or satisfy other busi- ness goals. DOCUMENT ENGINEERINANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES 342 Even if a process pattern mostly fits the target context requirements, it might need to be adapted For example, for products that are highly configurable with components that suffer from rapid obsolescence, it is advantageous to adapt the drop shipment pattern so that a distributor, instead of shipping finished goods from inventory, performs some final assembly to customize the inventoried goods. This modified pattern, called channel assembly, was introduced in the late 1990s by indirect retailers of personal computers to enable them to compete better with direct retailers like Dell.15 Adapting a pattern may involve consolidating roles. For example, the drop shipment pattern distinguishes the roles of the distributor and shipper but does not require that they be carried out by different enterprises. So for products like spare parts for which timely delivery to the customer is essential, pre-positioning the inventory to delivery service distribution hubs near customers can dramatically reduce delivery times while reducing transportation costs. This colocation of the distributor and shipper roles is sometimes called field stocking and is one of many logistics services offered by UPS. 16 There is no sharp line at which changes to an existing pattern are substantial enough to consider the adapted pattern a newly invented one. Business process patterns are certainly evolutionary, but the family boundaries are blurred. Business process patterns are evolutionary, but the family boundaries are blurred Channel assembly can be considered a minor adaptation of drop shipment because the basic role of the distributor does not change when it takes on some assembly responsibilities. But field stocking is a somewhat more substantial adaptation because it eliminates one of the roles through consolidation. Another adaptation of drop shipment called hosted drop shipment also changes the basic pattern in a radical way. As used by Amazon.com, this pattern nearly elimi- nates the traditional role of the retailer. The Amazon Merchant Platform, which uses software Amazon developed for its own book-selling business, enables Amazon to carry out the catalog management, shopping cart, and personalization services for the retailer. This makes the actual retailer almost completely virtual because it does DESIGNING BUSINESS PROCESSESWITH 343TERNS little more than decide what products to sell and the distributors from which to drop ship them. The retailer follows this pattern by uploading its product information to Amazon.com as XML documents using web services.17 10.7 INSTANTIATING PATTERNS TO CREATE NEW MODELS After a process pattern is identified, selected and adapted it must then be instantiat- ed for the specific context of use. To do this we begin by designating the actors, organizations, or enterprises that will carry out the generic roles and activities defined in the pattern. Then we must configure the collaboration and transaction properties that implement business rules like quality of service levels or other guar- antees about how the process behaves. 10.7.1 INSTANTIATING ROLES When we instantiate roles in a pattern we need to consider the existing technology environments, organizational and business relationships, as well as any competition, trust or antitrust concerns. For example, are some enterprises XML-capable while others only support EDI? Is there a market operator who is a neutral participant or is there a dominant buyer or seller? What preexisting relationships or agreements must be preserved or strengthened? We may need to apply some bias when we assign roles to accommodate factors like these. In Chapter 1 we introduced GMBooks.com as an instantiation of the drop shipment pattern, which includes four primary roles for the retailer, the distributor, the deliv- ery service provider, and the credit authority. GMBooks.com, like many Internet startups, might have instantiated the drop shipment pattern in a bottom-up way, try- ing to copy successful Internet-only firms like Amazon.com as implementation pattern s . But it would have been better for GMBooks.com to take a more strategic and top- down route to choosing the pattern. Starting with the intention of opening a book- store, GMBooks.com might have considered traditional retailing with a physical bookstore and inventory, a hybrid model of a store with an Internet presence, and the DOCUMENT ENGINEERINANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES 344 Internet-only business. The latter approach with more systematic analysis of a range of patterns would have given GMBooks.com better insights about the advantages and disadvantages of using drop shipment or one of its adaptations as a process pattern. When we instantiate the marketplace pattern, we need to specify the market opera- tor, market participants, and service providers. The market participants are often the suppliers and distributors in the supply chain centered on a dominant enterprise that also operates the marketplace. The services that are most useful depend on the industry, geography, and other characteristics of the context in which the pattern is being adopted. 10.7.2 CONFIGURING COLLABORATION AND TRANSACTION PROPERTIES The level of granularity below the business process patterns goes from business col- laborations down to transaction patterns. In Section 9.6 we described the six transaction patterns that come from ebXML: Offer and Acceptance, Request and Response, Request and Confirm, Query and Response, Notification, and Information Distribution. The contrasts between these patterns reflect whether the two parties already have a business relationship, which affects their obligations to each other and the need for acknowledgments. But in any contextualized implementation of these patterns, we often need to make finer distinctions. Because of varying business rules and technology capabilities, the same transaction pattern can work differently within a particular collaboration for specific trading communities, supply chains, or marketplaces. Even the routine collaboration of order management that combines the order process for a buyer with the sales process for the seller has dozens of permutations depend- ing on the responses, changes, and cancellations allowed. For example, some buy- ers would want to receive an explicit acknowledgement for every order; some sellers may only want to send acknowledgements for orders that cannot be fully filled. If they want to do business with each other, one or both must compromise. DESIGNING BUSINESS PROCESSESWITH PATT345S An order-driven demand chain must necessarily operate faster than a forecast-driv- en supply chain. This speedup typically derives in part from faster information flow enabled by improved information technology, but also from the commitment of the participating businesses to work faster and respond more rapidly to requests or infor- mation from each other. These different kinds of contextual configurations are enabled by properties (or metadata) that further define the rules of collaborations and transactions to tell the participating businesses precisely what to expect from each other. These are called collaboration or transaction properties. Each transaction or collaboration pattern has a characteristic profile of properties Each transaction or collaboration pattern has a characteristic profile of collaboration properties. Sometimes these profiles are set by a market operator or industry consor- tium to guarantee acceptable service levels for all participants in some specified con- text or trading community. These profiles are represented in a trading partner agree- ment or Service Level Agreement (SLA) between the collaborating parties that spec- ifies their roles and mutual obligations with respect to reliability, performance, secu- rity, problem resolution, and a host of other dimensions that define their relationship in objective terms. A large enterprise is likely to have different agreements for the sarcess conduct- ed with business partners of varying capabilities. For example, some small or tech- nologically unsophisticated partners might use email or web forms, and they can’t respond as quickly or handle the same transaction volumes as those using fully auto- mated document exchanges or web services. 10.7.2.1 Time-based Properties The lifespan of business collaborations and their transactions can rangom seconds to days, weeks, or longer. For very short transactions that involve little processing or decision making such as verifying a credit card or checking inventory, the response can come quickly. DOCUMENT ENGINEERINANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES 346 For long running business transactions, however, it may take some time for the recip- ient of a business document to determine how to respond to it. During that time, the process that initiated the transaction might not be able to do anything. So it is good practice to send business signals (Section 9.5) when the document has been received or when it is validated so the sender knows that the recipient's processing has begun. When the recipient must send receipt and confirmation signals is specified by the Time to Acknowledge Receipt and the Time to Acknowledge Acceptance properties, respectively. A more important time-based property is the Time to Respond (or time to perform). This is the time in which a recipient of a document must respond with the next doc- ument in the business transaction. For example, this property might specify how long a supplier can take to decide whether to accept a purchase order. Because every delay with a supplier ripples through the chain to lower tiers that con- tain that supplier's suppliers, well-managed supply chains impose and measure tight performance requirements with time-based transaction properties. The RosettaNet specification for the Request Purchase Order PIP 3A4 sets Time to Acknowledge Receipt at 2 hours and Time to Respond at 24 hours. 19 Dell's legendary efficiency in building computers to order requires almost ruthless performance standards for its suppliers, who must respond to component orders so efficiently that they never have more than two hours worth of inventory in a Dell manufacturing plant. 20 10.7.2.2 Other Properties Three other properties might need to be configured to meet the contextual require- ments of transaction or collaboration patterns: • Authorization Required. The partner role sending the message must sign the document and the recipient must validate the signature and the role associated with the signature. ▯ • Non-Repudiation of Origin and Content. The sender must store the business document in its original form for a mutually agreed duration; the nonrepudiation process includes validating the identity of the sender and the integrity of the content. DESIGNING BUSINESS PROCESSESWIT347ATTERNS • Non-Repudiation of Receipt. The sender of the receipt must store the Acknowledgement Receipt for the mutually agreed time period; the nonrepudiation process includes validating the identity of the sender and the integrity of the content. These properties are especially important in contexts involving high-value transac- tions or actions that are expensive or impossible to undo. USING PATTERNS TO SUGGEST 10.8 INFORMATION COMPONENTS AND DOCUMENTS Every business collaboration and its transactions has requirements for the informa- tion components they produce and consume. Business analysts sometimes refer to these components as the business entities or business objects of the business process. The complete models for these information components and for the document into which they are assembled emerge only with careful analysis of existing documents, other information sources, and business rules. But some of the information compo- nents and documents will be suggested by process patterns. 10.8.1 KEY INFORMATION COMPONENTS Most business processes will have multiple instances of the same unit of work being carried on at the same time. For example, in the procurement process a supplier will exchange documents with many buyers and vice versa. The process thus needs infor- mation to distinguish the participants in these parallel and interleaved business transactions and to identify the document instances associated with each of them. Furthermore, many business collaborations consist of a chain or choreography of documents that are interrelated because each contains information that flows from one document and process to another. We can consider this as a kind of memory of the collaboration. There may also be a requirement to reconcile the information on a series of business documents, such as Order with Invoice, Statement with Remittance Advice, Dispatch with Receipt or Claim with Payment documents. DOCUMENT ENGINEERINANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES 348 So every process model needs information components that link threads of related document instances within the process. We could describe these as the component patterns within processes, but that's a bit confusing. Instead we will call them the key information components. Every process model needs information components that link threads of related document instances within the process Key information components include, but are not limited to, the following types: • Identifiers for the transactions or the documents within them. These might be business-based like Purchase Order Number, Order Reference, and Invoice Numbers, or application-based, like time stamps or message identifiers. • Identifiers for the participants in the process. These might be instantiated as Social Security numbers, employee IDs, business registration numbers, D-U-N-S numbers, or other unique or contextually unique values. • Identifiers for the product or service that is mentioned in the transaction so that authoritative information about it can be retrieved from any process that involves it (pricing, ordering, invoicing, shipping, etc.). A unique Global Trade Item Number (GTIN) can be obtained from an international “ a t ricle numbering” organization. A similar goal motivates the Unique Consignment Reference number (UCR) proposed by the World Customs Org a n i z a t i toonaccess information about goods shipped in inter- national trade. • Integration or interoperability information, such as values or codes used by pro- cessing applications or ERP systems. We inevitably discover key information components when we ask about business transactions (see Section 9.4), and standards like the RosettaNet PIPs document the information components that are generally required to implement the transaction. DESIGNING BUSINESS PROCESSESWITH PATTERNS 349 However, the generic recommendations in the standard PIPs may be superseded by trading partner agreements or implementation guidelines for more specific contexts. In the Event Calendar, a component known as Submission Identification is used to distinguish submission transactions. Components for Authorized Party and Event Identification are used to identify event submissions as they move through the business processes. 10.8.2 THE DOCUMENT CHECKLIST In addition to identifying key information components, business process analysis typically yields the names of actual or potential d
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'