UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Knowledge in business processes : the VMI case Mroz, Martin Frederick 2001

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


831-ubc_2001-0256.pdf [ 7.36MB ]
JSON: 831-1.0089970.json
JSON-LD: 831-1.0089970-ld.json
RDF/XML (Pretty): 831-1.0089970-rdf.xml
RDF/JSON: 831-1.0089970-rdf.json
Turtle: 831-1.0089970-turtle.txt
N-Triples: 831-1.0089970-rdf-ntriples.txt
Original Record: 831-1.0089970-source.json
Full Text

Full Text

KNOWLEDGE IN BUSINESS PROCESSES: THE VMI CASE by MARTIN FREDERICK MROZ B.Sc, Dalhousie University, 1991 A THESIS SUBMITTED IN P A R T I A L F U L F I L M E N T OF T H E REQUIREMENTS FOR T H E DEGREE OF M A S T E R OF SCIENCE (Business Administration) in T H E F A C U L T Y OF G R A D U A T E STUDIES (Management Information Systems Division, Faculty of Commerce and Business Administration) We accept this thesis as conforming to the required standard T H E UNIVERSITY OF BRITISH C O L U M B I A April 2001 © Martin Frederick Mroz, 2001 In presenting t h i s thesis i n p a r t i a l f u l f i l l m e n t of the requirements for an advanced degree at the U n i v e r s i t y of B r i t i s h Columbia, I agree that the L i b r a r y s h a l l make i t f r e e l y a v a i l a b l e for reference and study. I further agree that permission for extensive copying of t h i s thesis for s c h o l a r l y purposes may be granted by the head of my department or by h i s or her representatives. It i s understood that copying or p u b l i c a t i o n of t h i s thesis for f i n a n c i a l gain s h a l l not be allowed without my written permission. Department of The U n i v e r s i t y of B r i t i s h Columbia Vancouver, Canada Abstract Business knowledge requirements are crucial for a thorough understanding of how business processes function. This thesis provides a method of how to capture knowledge requirements in business processes, using an initiative in supply chain management as an example. Supply chain initiatives that involve cooperation are gaining notoriety in today's business environment. Vendor Managed Inventory (VMI) is one such system. VMI, a system where the vendor manages the buyer's inventory, requires the sharing of data, information and knowledge between supply chain partners. Knowledge requirements are therefore needed for understanding how such a system functions. This thesis studies VMI via a process-centric view of associated knowledge. The types of knowledge examined include knowledge embedded in business processes, knowledge used in businesses processes and knowledge generated by business processes. A methodology is used in an attempt to capture the relevant knowledge and information requirements for Vendor Managed Inventory. ii Table of Contents Abstract ii Table of Contents iii List of Tables vii List of Figures v m Acknowledgments ix Dedication x 1. Introduction 1 1.1 Research 1 1.1.1 Research Goals 2 1.2 Outline of Thesis 3 1.2.1 Chapter 2 - Vendor Managed Inventory 3 1.2.2 Chapter 3 - Knowledge 4 1.2.3 Chapter 4 - Processes 4 1.2.4 Chapter 5 - VMI Processes 4 1.2.5 Chapter 6 - Knowledge in the VMI Context 5 1.2.6 Chapter 7 - Conclusion 5 2. Vendor Managed Inventory 6 2.1 Introduction 6 2.2 What is VMI? 6 2.3 Related Supply Chain Initiatives 8 2.3.1 Collaboration Planning, Forecasting, and Replenishment 8 2.3.2 ECR - Efficient Customer Response 11 2.3.3 Discussion of Initiatives 13 2.4 Facets of VMI 14 iii 2.4.1 Benefits of VMI 14 2.4.2 Problems with VMI 18 2.4.3 Moving from Non-VMI to VMI 21 2.4 Conclusion 24 3. Knowledge 25 3.1 Introduction 25 3.2 About Knowledge 25 3.2.1 Knowledge Description 26 3.3 Definition of Knowledge 31 3.4 Knowledge Management 32 3.4.1 History 34 3.4.2 Strategic Value 35 3.4.3 Direction 36 3.5 Example 37 3.6 Conclusion 41 4. Processes 42 4.1 Introduction 42 4.2 Process Definition 42 4.3 Event Driven Process Diagram 44 4.4 Knowledge in Processes 50 4.4.1 Three Occurrences of Knowledge 51 5. VMI Processes - Embedded Knowledge 53 5.1 Introduction • 53 5.1.1 Processes That Have to Change to Support VMI 53 5.1.2 Processes That Can Have Value Added To Them In VMI 55 iv 5.1.3 Strategic VMI Processes 55 5.2 Processes That Have to Change to Support VMI 55 5.2.1 Traditional System 55 5.2.2 VMI System 62 5.3 Processes That Can Have Value-Added To Them In VMI 71 6. Identifying Knowledge: The VMI Context 75 6.1 Introduction 75 6.1.1 Knowledge Requirements and Agreements 75 6.2 Methods to Identify Knowledge 77 6.2.1 General Methods for Knowledge Analyses 77 6.2.2 A VMI Example of the Methods 79 6.3 Domain, Operational and Performance Knowledge 83 6.3.1 Domain Knowledge 83 6.3.2 Operational Knowledge 85 6.3.3 Performance Knowledge 85 6.4 Knowledge Requirements in VMI 86 6.5 Service Level Agreement and Front-end Agreements 94 6.5.1 Front-end Agreement 95 6.5.2 Service Level Agreement 95 7. Conclusion , 98 7.1 Summary 98 7.2 Main Contributions 98 7.3 Limitations 99 7.4 Future Research 99 Bibliography. 101 v Appendix A - VMI Examples 106 Appendix B - EDI 110 Appendix C - Event Driven Process Diagram to SAP Modelling Notation 113 Appendix D - CPFR Diagrams 115 Appendix E - American Productivity and Quality Center Steps 117 Appendix F - Service Level Agreement 117 vi List of Tables TABLE 1: KNOWLEDGE CREATION (NONAKA, 1995, P.72) 27 TABLE 2: VALUE DISCIPLINE MODEL 36 TABLE 3: KNOWLEDGE DIMENSIONS (WIIG ET AL., 1997) 39 TABLE 4: RELATIONSHIP TO VMI 53 TABLE 5: RELEVANT FULFILLMENT PROCESSES SUMMARY 54 TABLE 6: STRATEGIC VMI SUMMARY 55 TABLE 7: TRADITIONAL NON AUTO-REPLENISHMENT SYSTEM 56 TABLE 8: CHANGED PROCESSES IN A VMI SYSTEM 63 TABLE 9: SALES AND RETURNS (VMI SYSTEM) 65 TABLE 10: INVENTORY MANAGEMENT (VMI SYSTEM) 67 TABLE 11: PURCHASE ORDER PROCESSING (VMI SYSTEM) 70 TABLE 12: ORDER PROCESSING (VMI SYSTEM) 71 TABLE 13: KNOWLEDGE DESCRIPTION OF ACTIVITY: 'SALES CAPTURED ELECTRONICALLY' 82 TABLE 14: STRATEGY DECISIONS AREAS ORGANIZED BY THE 4 PS (MODIFIED FROM SHAPIRO, 1996) 85 TABLE 15: (SALES) CONSUMER PURCHASES GOODS - KNOWLEDGE 87 TABLE 16: (SALES) SALES CAPTURED ELECTRONICALLY - KNOWLEDGE 87 TABLE 17: (RETURNS) CONSUMER RETURNS GOODS - KNOWLEDGE 88 TABLE 18: (RETURNS) GOODS EXAMINED - KNOWLEDGE 88 TABLE 19: (RETURNS) GOODS RESTOCKED - KNOWLEDGE 89 TABLE 20: (RETAILER INVENTORY UPDATE) INVENTORY COUNTS UPDATED -KNOWLEDGE 90 TABLE 21: (INVENTORY MONITORING) INVENTORY EXAMINED - KNOWLEDGE 91 TABLE 22: (INVENTORY MONITORING) REPLENISHMENT NEEDS DETERMINED -KNOWLEDGE 91 TABLE 23: DETERMINE ABILITY TO REPLENISH - KNOWLEDGE 92 TABLE 24: REPLENISH WHAT IS AVAILABLE - KNOWLEDGE 92 TABLE 25: REPLENISH TO FORECAST - KNOWLEDGE 92 TABLE 26: REPLENISH OPTIMALLY - KNOWLEDGE 93 TABLE 27: DETERMINE AVAILABLE SUBSTITUTES - KNOWLEDGE 93 TABLE 28: CREATE SMALLER SEPARATE ORDERS - KNOWLEDGE 93 TABLE 29: RESERVE STOCK - KNOWLEDGE 94 TABLE 30: PRELIMINARY SCHEDULES DETERMINED - KNOWLEDGE 94 TABLE 31: MODIFICATIONS OF R/3 STANDARD (HOLMSTROM, 1998) 107 TABLE 32: EDI DOCUMENT SET FOR VMI (MODIFIED FROM ORIGINAL) 112 TABLE 33: EVENT DRIVEN PROCESS DIAGRAM AND SAP MODELING NOTATION 114 vii List of Figures FIGURE 1: K N O W L E D G E C R E A T I O N C Y C L E (MORTON, 1998, P. 17) 29 FIGURE 2: A R C H I T E C T U R E OF A K N O W L E D G E M A N A G E M E N T EPISODE (HOLSAPPLE, 1997)30 FIGURE 3: K N O W L E D G E PROCESSING 32 FIGURE 4: WIIG'S K N O W L E D G E INTERACTION 38 FIGURE 5: A N A C T I V I T Y 45 FIGURE 6: E V E N T S 46 FIGURE 7: E V E N T S A N D ACTIVITIES 46 FIGURE 8: BEGINNING A N D E N D OF PROCESSES 47 FIGURE 9: ' A N D ' C O N S T R U C T TRIGGERING A N A C T I V I T Y 47 FIGURE 10: ' A N D ' C O N S T R U C T BEING TRIGGERED B Y A N A C T I V I T Y 48 FIGURE 11: ' E X C L U S I V E OR' C O N S T R U C T BEING TRIGGERED B Y A N A C T I V I T Y 48 FIGURE 12: ' E X C L U S I V E OR' C O N S T R U C T TRIGGERING A N A C T I V I T Y 49 FIGURE 13: NON-REQUIRED E V E N T VS. 'REQUIRED' E V E N T S 50 FIGURE 14: R E L E V A N T F U L F I L L M E N T PROCESSES 54 FIGURE 15: RETAILER SALES T O C O N S U M E R (TRADITIONAL SYSTEM). . ! 57 FIGURE 16: C O N S U M E R RETURNS GOODS T O T H E RETAILER (TRADITIONAL SYSTEM) 58 FIGURE 17: RETAILER I N V E N T O R Y U P D A T E (TRADITIONAL SYSTEM) 59 FIGURE 18: I N V E N T O R Y MONITORING OF RETAILER GOODS (TRADITIONAL SYSTEM) 60 FIGURE 19: P U R C H A S E ORDER PROCESS (TRADITIONAL SYSTEM) 61 FIGURE 20: V E N D O R PROCESSES ORDER (TRADITIONAL SYSTEM) 62 FIGURE 21: RETAILER SALES T O C O N S U M E R (VMI SYSTEM) 64 FIGURE 22: C O N S U M E R RETURNS GOODS T O T H E RETAILER (VMI SYSTEM) 65 FIGURE 23: RETAILER I N V E N T O R Y U P D A T E (VMI SYSTEM) 66 FIGURE 24: I N V E N T O R Y MONITORING OF RETAILER GOODS (VMI SYSTEM) 67 FIGURE 25: P U R C H A S E ORDER PROCESSING (VMI SYSTEM) 69 FIGURE 26: ORDER PROCESSING (VMI SYSTEM) 71 FIGURE 27: SHIPPER SELECTION (TRADITIONAL SYSTEM) 72 FIGURE 28: SHIPPER SELECTION (VMI SYSTEM) 73 FIGURE 29: A C T I V I T Y 77 FIGURE 30: WIIG'S K N O W L E D G E INTERACTION (WIIG, E T A L , 1997.) 78 FIGURE 31: ACTIVITY: 'SALES C A P T U R E D E L E C T R O N I C A L L Y ' 80 FIGURE 32: O V E R V I E W OF S Y S T E M SOLUTION ( H O L M S T R O M , 1998) 108 FIGURE 33: D E V E L O P FRONT E N D A G R E E M E N T (CPFR) 115 FIGURE 34: C R E A T E JOINT BUSINESS P L A N (CPFR) 116 viii Acknowledgments My appreciation and admiration to Kalpna for her priceless support, encouragement and insights. My thanks to Winston Mackenzie for his constructive criticism and brain storming sessions. My thanks to Sunuil Chauhan for his scrutiny of the final pages. My acknowledgements to Yair for his many contributions in shaping this thesis and attention to detail. I would also like to sincerely thank Jacob and A l for their support, encouragement and input. My gratitude to SFU library for sharing its wealth of books and resources. My utmost gratitude to Julie Nichols and Jennifer Papke for making a difficult process less so... and with a smile. Finally I'd like to thank my parents Edward and Margaret Mroz for their love and encouragement. ix Dedication To my beloved wife Kalpna. For believing in me. x 1. Introduction As indicated by the proliferation of conferences, literature and technology being produced, knowledge is currently being seen as an invaluable resource. Older research and technology are also being retrofitted to deal with knowledge, as seen in the sudden re-labelling of both research and products. Knowledge about customers has spurred a wide use of concepts such as customer relationship management and business intelligence. In wake of this, there are many existing and less glamorous initiatives that can be better implemented with a more structured understanding of the associated knowledge in their business processes. In the supply chain, new ideas such as Collaborative Planning, Forecasting and Replenishment are built from the top down, incorporating an understanding of what processes define the initiative and their inputs. The use of new and popular concepts, such as knowledge management, are built into the design. However, older initiatives do not often benefit from the current research and interest in knowledge. Also, the application of new concepts is often only seen in actual implementations, in the form of knowledge management projects. 1.1 Research This thesis attempts to offer some insight into knowledge in everyday business processes. This is accomplished by examining aspects of a supply chain initiative called Vendor Managed Inventory (VMI). VMI is an initiative that involves increased cooperation among supply chain partners. The vendor in a VMI relationship assumes responsibility for the buyer's inventory. Hopefully, a practitioner or consultant will be able to use this knowledge for a practical Vendor Managed Inventory project, or use the methodology to extract knowledge requirements from some other business processes. The use of process modelling and a methodological examination of knowledge may also be useful in future research. 1 1.1.1 Research Goals The purpose of this paper is to explore the following research question: "How can an understanding of business knowledge be extracted from business processes?". Gathering an understanding of related concepts, and looking at a practical example accomplishes this. The thesis hopes to explore: • A better understanding of how to do VMI. • Examples of a method to analyze business processes for knowledge. • An example of the types of agreements between VMI practitioners that can be used to structure knowledge. The method of analysis used consists of the following: • Choose a definition of knowledge (Chapter 3). • Choose a process modelling method (Chapter 4). • Develop an understanding of how knowledge relates to processes (Chapter 4). • Map the processes in an example, in this case VMI (Chapter 5). • Examine the processes by looking at the rules, resources and roles that exist within the processes (Chapter 6). Shoshana Zuboff talks of the 'dissociation of sentience and knowledge' in her book 'In the Age of the Smart Machine' (Kock, 1999). Understanding things such as abstractions is difficult because humans often do not have something that mental images can be based upon. For example, people have mental images of chairs because they have seen chairs before. Ned Kock applies this concept to processes. Since processes are abstract, it is difficult to understand what a process is without further clarification (Kock, 1999, p. 19). To understand processes, there needs to be a way to capture and model them in some fashion. This is what process modeling attempts to do. However, the solution is not necessarily complete with just modeling. For example, what if knowledge concerning an abstraction notion such as Vendor Managed Inventory was needed? Vendor 2 Managed Inventory is an abstraction, and so is knowledge. This is what makes the job of capturing knowledge about an abstraction such a confusing prospect. Knowledge like this is often needed. Innately, consultants have, or at least claim to have, this sort of knowledge whenever they enter into a discussion about a project with a client. This is the foundation of this thesis. The initiative of interest, Vendor Managed Inventory was discovered to be a topic with little clarification in the literature and little empirical work (Daugherty, 1999, p.64). VMI was also chosen because initiatives dealing with cooperation along the supply chain have been gaining notoriety in today's business environment (Daugherty, 1999, p.63). As said by Rashi Glaser: "... the notion of creating loyal customers extends to forming sustainable strategic alliances or partnerships with all members of the value added chain - upstream, to suppliers; downstream, to distributors and retailers. Such linkages are forged primarily through transaction-based information systems, which typify the merging focus on cooperative rather than competitive strategy." (Desphande, 2001, p. 128) 1.2 Outline of Thesis 1.2.1 Chapter 2-Vendor Managed Inventory Chapter one explores the concept of Vendor Managed Inventory (VMI) from several angles, in order to allow a good appreciation of what the initiative is. It explores the principles of VMI, similar initiatives, and how they are related. Next, several benefits and problems that can be encountered are explored. The chapter then closes with an examination of the changes necessary when moving from a non-VMI environment to a VMI environment. The goal of the chapter is to give the reader an understanding of how VMI is understood. The sources of literature on VMI are predominately business cases and examples, although there are a few studies that explored concepts in greater detail. However, as one author expounded, there is little academic work done on the subject (Daughtery, 1999, p.64). 3 1.2.2 Chapter 3 - Knowledge Chapter 2 discusses aspects of knowledge and attempts to give an overall sense of the task of managing knowledge. Organizations have used their collective brain trusts for hundreds of years to innovate and provide goods and services better than their competitors, or at a lower cost. Data and information have been acquired and catalogued by companies to gain an advantage. It would seem that the culmination of these facts would be the obvious use of knowledge, but that has not always been the case. More recently, with organizations growing to titanic proportions, there is a need to not only capture facts, but to organize them and disseminate them to the proper users. Organizations' knowledge is also more widely dispersed and difficult to identify and tap. It is from this position that organizations have come to recognize the importance of management of the content of their collective mind. Definitions of knowledge are discussed in this chapter. Some facets of knowledge are examined as well, for instance, aspects of knowledge management. The chapter closes with an example of a framework for managing knowledge as put forward by Karl Wiig. 1.2.3 Chapter 4 - Processes Business processes are often defined in a very contextual sense. Depending on the perspective, business processes seem to mean different things. As mentioned previously, processes are difficult to grasp because they are abstract. This chapter explores business processes. It then looks at a particular notation called the Event Driven Process Diagram, explaining its origins and constructs. This diagramming notation is then used in the following chapter on VMI processes. At the end of the chapter, processes, VMI and knowledge are brought together for a lead-in to the remaining chapters. 1.2.4 Chapter 5 - VMI Processes This chapter explores the structure of processes that make up VMI. VMI is part of a complete fulfillment process on behalf of the vendor, so the actual processes that are explored are limited to the 4 ones that change and those that can have value added to them when entering into VMI. This is done by modeling a traditional non auto-replenishment system and comparing it to a model of a VMI system. The Event Driven Process Diagram notation is used to do this. 1.2.5 Chapter 6 - Knowledge in the VMI Context Having knowledge of something is more than knowing the structure of processes it is comprised of. In this chapter two more aspects of knowledge are explored. These aspects are knowledge used in processes, and knowledge created in processes. These are examined in terms of roles, resources and rules within the processes. A method is presented to accomplish this at the start of the chapter. The chapter ends with an overview of the contractual agreements that may be engaged in by practitioners of VMI. 1.2.6 Chapter 7- Conclusion Chapter 7 gives a summary of the work, contributions and discusses both limitations and future research. It seems that this thesis could not get any more specific. The processes in Vendor Managed Inventory are examined and their knowledge is uncovered. However, several issues that can apply to a wide variety of business problems are discussed. For example, anywhere a consultant needs to gather an understanding of processes and the knowledge involved in them. 5 2. Vendor Managed Inventory 2.1 Introduction This chapter looks at Vendor Managed Inventory (VMI) from several angles, to allow a good appreciation of what the initiative is. It explores the principles of V M I , similar initiatives and how they are related. Next, several benefits and problems that can be encountered are explored. The chapter closes with an examination of the changes necessary when moving from a non-VMI environment to a V M I environment. In this chapter, retailers are a subset of buyers that are in a V M I relationship with a vendor. Later, the focus will be solely on retailers, as opposed to buyers, to limit the scope of the discussion. Specific V M I business processes will be used as the example for extracting knowledge requirements in later chapters. 2.2 What is VMI? Traditionally, the buyer stocked a product at a certain level within its store or manufacturing plant. When the stock level fell to a certain point, the buyer reordered the product, which hopefully arrived when needed. Buyers attempt to maintain a safety stock to prevent the bane of sales or production, stock-outs. A n alternative was the vendor sold products on consignment. For example, vendors would go to grocery stores and stock the shelves to certain levels. When product was sold, the store would pay the vendor. Vendor Managed Inventory is an initiative where the vendor takes responsibility for tracking buyers' needs for products and initiating the order process. The vendor knows the inventory of the buyer and initiates an order based on inventory on-hand, inventory in transit, ability to supply, and demand for the inventory. This can take into consideration many factors including the seasonality of products, promotions by the buyer and by the vendor, and popularity of the product. In one article V M I is defined as: " V M I - A collaborative strategy between a customer and a supplier to optimise the availability of products at a minimal cost to the two 6 companies. The supplier takes responsibility for the operational management of the inventory within a mutually agreed framework of performance targets which are constantly monitored and updated to create an environment of continuous improvement." (Hines, 2000, p.339) Sales transactions, sometimes in the form of Point Of Sale (POS) or Point Of Use (POU) are shared between the retailer and vendor electronically. POS consists of data concerning a retail sale that is collected and stored at the time of purchase. This is commonly seen in grocery stores. POU data refers to data collected at the time of usage, or consumption. In a grocery store, this may be when a product leaves a shelf. However, POU is most commonly mentioned concerning manufacturing replenishment or the continual replenishment of a product such as gas or water. The entire order - for example, forecasting, purchase order processing, shipping and invoicing process - can be done electronically based upon this data and what is known about the market. This is seen as a shift in thinking about replenishment: "The subtle change in the character of who controls systems has moved the emphasis from making ample supplies of products and pushing those products toward the stores to a system where the actual consumption of products triggers release information and goods are sent toward the store shelves to meet current customer demands. In the latter case, the opportunity is created to reduce the costs that are traditionally associated with carrying the extra inventories and slow-moving products." (Poirier, 1996, p.59) See Appendix A for two summaries of VMI implementations from the literature. Generally, VMI projects have been very successful. Wal-Mart, Kmart and JC Penny have seen the following which they attribute to their VMI systems (Simchi-Levi, 2000, p. 133): Improved vendor relationships Sale increases Improved inventory turnovers Proctor & Gamble, one of the first to implement automated VMI, now sells 40% of its products in that manner (Cooke, 1998). Automated VMI is practiced in many industries, including automotive, 7 chemical, water supplies, health care (Emigh, 1999), and heating oil (Canadian Transportation Logistics, 1997). Today, it is considered a standard practice in the electronic component industry (Cooke, 1998). Vendors find value in VMI by better knowing the consumer demand, by creating stronger trading partner relationships, and by controlling, to an extent, the replenishment of inventory. Buyers, such as retailers, receive value from stocking a better assortment of product, lowering inventory storage costs, avoiding stock-outs and by relinquishing many logistic and administration activities. When there is a strong relationship between trading partners it may make sense to enter into a VMI partnership. It depends on the competencies that each trading partner has with regard to the product, such as: Visibility of the industry Understanding of demand for the product The relationships with other supply chain partners. Some industries have had greater success with VMI than others. For example, it has been very successful in the automotive industry compared to retail, where problems arise in forecasting seasonality (Cooke, 1998). An advanced information system is a requirement to make VMI work (Simchi-Levi, 2000, p. 133). Due to the exchange of information, both customer and vendor must help support this system. Electronic Data Interchange (EDI) has commonly been used to transfer POS and transaction related documents between trading partners. A description of EDI can be found in Appendix B. 2.3 Related Supply Chain Initiatives 2.3.1 Collaboration Planning, Forecasting, and Replenishment A very closely related initiative to VMI is Collaborative Planning, Forecasting and Replenishment (CPFR). The following description has been referenced from the source of the initiative, 8 the Voluntary Interindustry Commerce Standards Association (VICS) (CPFR.org, 2001), except where otherwise noted. CPFR is an initiative put forward by the Voluntary Interindustry Commerce Standards Association to correct some perceived deficiencies of VMI, such as one way communication (Katz, 2000). This is accomplished through a set of standards for developing and implementing collaborative planning between members of the supply chain to create better forecasts. When better forecasts are created, replenishment levels are more accurate. The key to CPFR lies in the relationships between trading partners. Forecast levels are independently derived between partners and as a precursor to a shared demand driven forecast. Forecasts have the benefit of the experience and insight of the retailer, the vendor/distributor and the manufacturer. Areas where benefits are noticed, or where they are hoped to be, include: Forecast accuracy levels - Inaccurate forecast levels can leave members of the supply chain with surplus inventory or stock-outs. In either case, there is the cost of lost sales, or excess merchandise or materials. Service Levels - CPFR connects the players in the supply chain much closer together allowing a better lead-time for manufacturing or distribution of product. It allows the proper product to be available when the supply chain member needs it. Ultimately this boils down to the product being available to retail customers when they want or expect it. Inventory levels - Inventory levels are more reactive to the retail environment through CPFR allowing less padding. Inventory levels are smaller with higher turns. Sales Increases - Presumably, CPFR will increase sales by having a better mix of product in the correct quantities at the correct times. The business processes involved in CPFR as described by VICS consist of the following steps (CPFR.org, 2001): 9 1. Develop Front-end Agreement - Trading partners come to agreement on individual and joint business goals. 2. Create Joint Business Plan - This covers the exchanging of strategy, objective and goal setting information between trading partners for a specific planning period. 3. Create Sales Forecast - Trading partners create and exchange sales forecasts based upon objectives, events, and sales. 4. Identify Exceptions for Sales Forecast - Exceptions that show discrepancies between forecasts are identified based upon agreed tolerance levels and criteria established in the joint business plan. 5. Resolve/Collaborate on Exception Items - Exception items that cannot automatically be resolved are examined and analysed. Exceptions are resolved based on the best information from the partners. 6. Create Order Forecast - An order forecast is created based upon the forecasts and joint business plan. 7. Identify Exceptions for Order Forecast - Exceptions for the order are identified, for example changes in forecasts and ability to supply product. 8. Resolve/Collaborate on Exception Items - Exceptions are resolved through collaboration with the trading partners. 9. Order Generation - A firm order is generated based upon the forecast. CPFR tries to utilize existing standards and implemented technology whenever possible. Collaborative documents are mapped to existing EDI and Standard Interchange Language (SIL) specifications to capitalize on the existing installed base. As other standards mature and are accepted in business practice, they will be considered to supplement and extend document messaging. CPFR seems to be expanding; however the success of any initiative is best determined by its longevity. Several implementers and practitioners gush in its support. As said in one industry analysis 10 "Support of the [CPFR] guidelines is growing rapidly, and now more than 100 leading organizations are actively participating in adoption, refinement, and market education. Participants include Andersen Consulting, Eastman Kodak, Federated Department Stores, JC Penny, Kimberly-Clark, Kmart, Kurt Salmon Associates, Nabisco, NCR, Proctor & Gamble, Wal-Mart, and Warner and Lambert." (CPFR Survey & Analysis, 2000, p.2) The key to CPFR is collaboration. As such, the ability to exchange information meaningfully between trading partners is of the utmost importance. Previous initiatives focused on transactions, however the main focus here is on the sharing of information for mutual benefit. CPFR requires the sharing of information that many businesses may not be prepared to share. It also requires a large implementation effort with the least difficult aspect not necessarily being technical. It requires a change in organizational structure and business acumen. Proponents of CPFR claim that it succeeds more completely than other initiatives. CPFR.org discusses the implementation of CPFR in Wal-Mart and Sara Lee as an example of success. However, within the trade journals, the same Wal-Mart implementation has been described as limited and effort intense (Messmer, 2000). 2.3.2 ECR-Efficient Customer Response Efficient Customer Response means efficiently reacting to and enabling customer demands across all aspects of the supply chain. The goal is to satisfy the customer with the proper product offerings. It is examining and optimizing all areas of the supply chain to lower costs and create value for the customer through cooperation and joint strategies. This is done using a holistic approach so that benefits in some areas are achieved at the expense of other areas. ECRNET Europe describes it as "The ECR ('Efficient Consumer Response') movement effectively began in the mid-nineties and was characterised by the emergence of new principles of collaborative management along the supply chain. It was understood that companies can serve consumers better, faster and at less cost by working together with trading partners. At the heart of ECR was a business environment characterised by dramatic advances in information technology, shifts in consumer demand, and the increasing movements of goods across international borders aided by the internal European market." (ECRNET.org, 2000) 11 Principles of ECR are: Lower costs. Creation of win/win opportunities. Use of current information for decision making; giving the customer what they want when they want it. Use of standard metrics to evaluate and reward performance. These are done to not only respond to demand, but also to help generate demand. Benefits of ECR include: Cost savings by reducing non-value adding activities and lowering inventory. Timeliness by better access to data and the synchronization of goods. Improved quality by better process and delivery reliability and the timely treatment of perishable goods. Better customer service through fewer stock-outs, more choices and increased responsiveness. More market adaptability because of better and new product offerings. Elimination of paper transactions. Efficient customer response found its origins in the United States in 1993. A voluntary group called the Efficient Customer Response Working Group had a report created by Kurt Salmon Associates to detail ways to save on costs and create efficiencies in the grocery industry (Poirier, 1996, p.40). Since then, it has since been used in several industries of fast moving consumer goods and durables. ECR has moved across North America and is now frequently used in Europe. ECR relies upon two key areas: Category management. Efficient replenishment. 12 Category Management, which consist of coordinating the management of the product to best satisfy consumers (Lowson, 1999, p.41), includes: Efficient Assortment. Efficient Promotion. Efficient Product Introduction. The US ECR Best Practices committee defines category management as: " A retailer/supplier process of managing categories as strategic business units, producing enhanced business results by focusing customer value" (GEAC, 1999). Efficient Replenishment is the synchronization of product delivery with product demand. This is accomplished with less handling, fewer interruptions and reduced stored inventory along the supply chain using several different initiatives, such as Auto-Replenishment and Just In Time (JIT) replenishment. It is also facilitated with the electronic exchange of information, such as POS, sales forecasts and purchasing orders. This is very similar to VMI and CPFR through the goal of providing the customer with the product or service that is needed at the proper time. 2.3.3 Discussion of Initiatives VMI has been described as a cornerstone to ECR (Cooke, 1998). It essentially fulfills the efficient product replenishment aspect specified in ECR. Depending on the level of VMI implemented, it could also fulfill efficient category management. In fact, VMI could be an implementation of ECR practices. CPFR has as a tenet that the collaboration of supply chain partners for forecasting creates a more efficient force than any one partner trying to create forecasts on its own. CPFR has a set of guidelines for implementation that do not preclude it from being the same as VMI with more collaboration. The deficits that CPFR pundits mention concerning VMI are ones that could be improved upon without radically changing the spirit of the initiative. For instance, as one industry article reads: 13 "Vendors pull information from retailers - information that often fails to consider last minute changes driven by promotions, multiple inventory sources and seasonality. Another concern is that warehouse withdrawal is the primary focus of VMI planning. This high-level forecasting results in store-level stock-outs among retailers and dissatisfied consumers." (Katz, 2000) These flaws are not inherent to VMI, but rather to a VMI implementation. The same article recognizes the roots of CPFR as being VMI. However, none of the literature reviewed limited VMI to only certain procedures. Rather, literature stresses the importance of visibility of inventory, the sharing of data and an increased role of the vendor, which can be seen as obstacles to either initiative. CPFR is not without problems either. Communication between trading partners has been difficult to establish. As mentioned earlier, Wal-Mart was able to make an implementation of CPFR work with one vendor, only with tremendous effort due to problems in establishing trust (Messmer, 2000). 2.4 Facets of VMI The remainder of this chapter looks at several facets of VMI. Some benefits are outlined along with some problems. The chapter ends with some of the changes that are necessary when transitioning from an environment that is non-VMI to one that is. 2.4.1 Benefits of VMI There are real advantages to VMI found for both the vendor and the buyer. Even simple inventory management tools, when combined with VMI offer significant advantages for several levels of demand variability. One study concluded: ".. .[S]imple inventory management tools designed for more stable environments can be used effectively in environments characterized by dynamic demand patterns. While these simple approaches are made more effective through frequent ordering and shipping, it is the cross-echelon coordination gained by information-sharing and vendor managed inventory that can carry these systems to significantly better performance." (Warsing, 2000) 14 This section will look at several benefits of VMI in retail. The advantages are broken down to Reduced Costs for both the vendor and the buyer, and Improved Customer Service for the buyer. Reduced Costs Lower/More Accurate Inventory Reduced inventory can lower costs for both vendor and buyer. Savings for the buyer can be realized due to lower inventory management costs, such as less money being tied up in inventory and lower inventory storage space. The ideal case is replenishment that follows very closely to consumption, before another piece is sold. However in retail, this short inventory cycle is often not practical due to delay of transportation of goods and the potential of variable demand. Lower inventory is possible because of more accurate forecasts, which try to minimise excess inventory in the system and shorten customer lead times (Harrington, 2000). This is also the result of more timely, accurate and better-planned shipments of product, which results in lower variation in demand (Holmstrom, 1998). Lower demand variation decreases demand distortion, which causes a build-up of inventory at certain junctions in the supply chain. This build-up is the direct result of uncertainty and the desire to ensure that adequate inventory will be available to satisfy supply chain partners and avoid stock-outs. Jay Forrester has referred to this as the 'Bullwhip Effect' in his supply chain model (Forrester, 1961). In one case, VMI lowered demand variability from 75% to 26%, while cutting delivery times from 48 hours to 10 hours (Holmstrom, 1998). Better forecasts will reduce the number of returns that are necessary for slowly selling or discontinued products (Waller, 1999), and also reduce the potential for excess and obsolete products (Jamal, 1998). Increase Sales Both the buyer and vendor increase sales as more accurate inventory is flushed through the system quickly (Waller, 1999). Increased inventory turnover is a result of the proper product being in the right store at the right time, possibly even surrounded with the right complementary goods. From a VMI 15 perspective, complementary goods would need to be from the same vendor. However, cooperative strategies between vendors concerning complementary goods may also be a potential source of improved sales. One buyer participating in VMI increased inventory turns by 17% in first year of implementation of (Harrington, 2000). Increased sales could also be the result of more timely and cheaper product introductions, and better rollover to replacement products (Waller, 1999). Insight into these issues may be more evident in vendor product plans than in any product knowledge the retailer may have. Eliminate Inefficiencies There are several areas where eliminating inefficiencies will reduce costs. Improvement in warehousing and transportation can result in cost savings for both buyer and vendor (Waller, 1999). Partial orders can be better supported (Emigh, 1999) because of more frequent deliveries and more efficient transportation. More efficient warehouses can take advantage of cross-docking and tighter schedules for busy docks with more predictable delivery. Cross-docking is the procedure of moving products from the receiving docks to shipping without first putting it in storage (Ross, 1995, p.521). This shows how VMI may facilitate the optimization of processes that are not directly related to VMI. Also, because of better relationships with the buyer, vendors can make important decisions concerning critical deliveries. For instance, a vendor can service a more urgent need over a less urgent need, and not alarm the buyers as readily (Waller, 1999). VMI also eliminates the problems that may occur when many purchasers for an organization act in isolation with one vendor or when buyer and vendor calendars are not properly synchronized with schedules. For example, the buyer may be on a 13 month, four-week schedule whereas the vendor is on a 52-week schedule (Waller, 1999). Long lead times for sourcing are also decreased as responsible vendors abide by the service level contract (Holmstrdm, 1998) and provide 'standing quotes' that the buyer can trust. 16 Buyer Lock-in Buyer lock-in can result in reduced costs for the vendor because of less effort in maintaining a current customer compared to finding a new one (Jamal, 1998). Because of the better relationship with the buyer, the vendor may have more leeway in exceptional circumstances. Also, the buyer is less likely to leave a relationship after there are very real costs in developing a VMI program with a particular vendor. Both vendors and buyers benefit from stability in the relationship. Streamlining Processes and Reallocating Costs The buyer can realise reduced costs from the sheer act of giving up the responsibility of maintaining its own inventory. Giving this responsibility to the vendor would decrease administration costs, capital equipment costs, labour costs and inventory management costs (Canadian Transportation Logistics, 1997). Thus, the buyer can focus more on its core competencies (Solanki, 2000, p.8). A simplified order process can also benefit both the vendor and the buyer (Schorr, 1998). The buyer, in most cases, gives up many of the aspects and costs of buying altogether. The vendor can also improve its planning processes because of better visibility of demand and inventory on the retailer's shelves (Holmstrom, 1998). Better planning processes can also mean better production processes as the vendor is better able to mitigate demand fluctuations and level load its production and purchasing processes (Schorr, 1998, p. 146). Improved Customer Service Improved customer service comes in many forms for the buyer in a VMI relationship. In many ways, all of the methods for reducing costs outlined above improve service for the buyer, since improved customer service ultimately is quantified in reduced costs. The vendor is committed to ensuring that the buyer is consistently happy. The terms to make the buyer content are spelled out in clear language in a service agreement, so ambiguity should not occur. A better relationship also means that the vendor has a 17 clearer understanding of the special needs of the buyer, or more knowledge, offering better service (Jamal, 1998). Avoiding Stock-outs Products that are not available to consumers are considered out of stock (or 'stock-outs') and are one of the worst things that can happen. Stock-outs mean a potential loss of a customer, and this can result in losses for both the vendor and the buyer. The losses are in terms of dollars, but also in terms of good will. If the stock-out is the vendor's fault, the buyer loses faith in the ability of the vendor to meet its needs. Future orders may therefore go to competitors. The buyer also loses the faith of its own customers, which may then jeopardize future sales. Stock-outs occur because of poor planning on the vendor's or buyer's side, long lead times for product delivery, and carelessness on the buyer's side. Stock-outs could be avoided by the closer control the vendor has over the inventory in a VMI relationship (Schorr, 1998, p. 146) and because of the ability to replenish this inventory faster (Jamal, 1998). In one case, after the implementation of VMI, average in-stock position moved from 95% to 99% (Emigh, 1999). Better Visibility The vendor has better visibility of the buyer's inventory and demand, and thus has a heightened awareness of trends (Waller, 1999). Using this awareness, the vendor can create better forecasts and replenish the buyer with the proper product. Ultimately, if both the vendor and buyer are producers of goods, production smoothing may be a result of better forecasts (Emigh, 1999). 2.4.2 Problems with VMI There are some problems that can be encountered with the implementation of VMI. VMI is not for all industries, nor for all companies. An example is custom made goods, for which demand can be very difficult to forecast. Some companies with incredibly high numbers of very similar products, such as grocery stores, also found it initially difficult to implement VMI successfully (Emigh, 1999). Similar 18 products can be difficult to track, especially when rung in at the checkout. An example is facial tissues with different patterns, yet otherwise exactly the same product. Another example is the same product labelled 'Improved'. The use of bar coding and scanning has helped alleviate some of these problems with better tracking. Also, some companies may not want to give up their buying process as they consider it one of their core competencies (Cooke, 1998). However, one North American department store was able to reduce its vendors from several hundred to fifty after taking control of its buying (Canadian Transportation Logistics, 1997). Obstacles The majority of the problems that can be encountered with VMI occur because of obstacles such as a break down in communication, loss of faith in the vendor, or breach of the service agreement. Both parties must perform as expected and give the proper visibility to inventory. For example, the buyer's retail stores must inform the vendor of any between store transfers, if it is the responsibility of the vendor to supply inventory directly to all location. An article called 'Very Mixed Impact' lashes out at several perceived failings of VMI, such as the obstacles mentioned above (Cooke, 1998). It recommends a move to CPFR instead, without recognizing that if trust, communication, technology and the will from upper management are absent, any initiative, including CPFR, will fail. For instance, one of the largest impediments to implementing VMI is an unwillingness to share information, such as forecasts for demand, POS, production plans, promotion plans, sales plans, inventory plans and new product plans (Schorr, 1998, p. 146). This obstacle can result from previous strategic decisions to keep this information confidential and can prevent successful implementation of CPFR as well. Radical Change Any company that implements VMI will need to take the company's vision into consideration. The company has to be willing to make the cultural, operational, tactical and strategic changes that are necessary. For example, certain jobs may be radically changed as processes are re-engineered or 19 eliminated. Resistance to change must be overcome. Change management consultants may need to be contracted. Expensive Processes There are certain areas where VMI can be improved. The vendor must be able to make VMI processes as value-added and automated as possible (Schorr, 1998, p. 149). Vendors are assuming the administration costs of many aspects of buying and management that the buyers previously had. This is great for the buyers as several costs, such as administrative and logistic costs, are lowered. However, the vendor must carefully manage these assumed responsibilities (Cooke, 1998). Managing Technology Technology must be properly managed. Technology is the largest enabler of automated VMI and should be implemented efficiently and accurately. Lack of some crucial components such as EDI, or some sort of facility to exchange data, would be disastrous. As well, lack of standards can cause VMI to fail as the vendor tries to scale out to other buyers and finds resistance because of incompatible interfaces. Integration with Enterprise-wide Resource Planning (ERP) software has been quite difficult as well. Incompatible data models and the lack of compatible interfaces make it difficult to deal with ERP data. ERPs also lack the attention to item locations and volumes within the enterprise, making VMI very problematic (Emigh, 1999). This results in difficulty finding the proper quantity of items at particular locations. The complexity of the data models makes for an expensive implementation if dealing with the ERP vendor. Customizations of ERPs can also result in problems further down the road with upgrades. For an overview of VMI implemented in a customized ERP, see Appendix A - VMI Examples. 20 2.4.3 Moving from Non-VMI to VMI Moving from Non-VMI to VMI changes a company in several ways. This section outlines some of those changes, broken down as Strategic, Tactical or Operational. Strategic Strategic changes are long-term and affect the vision or the direction of the company. There are several strategic decisions that need to be made before implementing VMI. For instance, the willingness to change the company's culture and investing in information technology are two large strategic decisions to make. The company's culture can change in many ways. Information sharing is a requirement of VMI. Several companies have traditionally considered their secretive data an advantage that they had over competitors. Sharing information in a VMI relationship may not be a natural transition for a company to make. Trusting other companies involves adopting a win/win view, which differs from the previous win/lose view. Information that can be shared in a VMI relationship includes: POS data, production planning, product plans, sales plans, marketing plans, promotional plans, and often business plans. Sharing information is much more of a trust and communication issue than a technical issue. The technical requirements for the information sharing are fairly well defined in EDI. Cultural changes are often less well defined. With a move towards interfacing of extranets, companies are seeing the investment in VMI as just the beginning. May aspects of strategic decisions in VMI can be used for more collaborative relationships like those in practicing CPFR. A large cultural change for the vendor is also the new role that it takes on in VMI. The vendor assumes all responsibility for the buyer's inventory. The vendor becomes responsible for accuracy, timeliness and sometimes quality. Other responsibilities could include new product introductions, product phase-outs, and promotions. This can be a big change from previously, where the vendor would 21 respond to purchase order requests that could occur at any time. The actual changes that could be made to support this new role are tactical or operational. The willingness to adopt the role is strategic. With the vendor assuming more responsibilities also comes increased costs. Administrative and logistic duties must be performed by the vendor in such a way as to minimize these costs. A criticism of VMI is that costs and inventory are pushed up the supply chain to the upstream trading partner. The vendor must be willing to adopt changes to existing processes that minimize these costs, and automate them as much as possible, making them value added. When necessary, benefit sharing between companies must be considered. This would involve full disclosure of accounts between trading partners and would require further research. Also, benefit sharing between cost centres within a company may be necessary. The role of the vendor would be outlined in a service agreement and must be flexible enough to allow for a changing business environment, but unambiguous enough to allow for performance measures to be captured fairly. Tactical Tactical changes are changes that are short term and support the strategic direction of the company. Job roles must be changed to support new processes as necessary. The manner of communication will change between buyer and vendor. Vendor sales staff and buyer purchasers will no longer have to interact as much concerning typical sales. The Sales function is changed from trying to actually make sales to monitoring the customer's interactions and providing customer service. Sales loses power as auto-replenishment takes over the traditional sales job. Administration in shipping, receiving, purchasing and scheduling can become more automated. As this happens, the vendor is able to place people in more strategic positions concerning sale promotions, marketing trends, and product maintenance, introductions and planning. Power can shift within an organization from Sales to Logistics 22 and these changes need to be managed. Marketing may play a more interactive role with the VMI system, as maintenance of the product forecasts would become a more important function in the life cycle of the product. Cross-functional and cross-company team building may also be necessary at times. Cross-functional teams may already be part of a company's culture, but cross-company teams will require a new sharing of responsibility and information. Warehouse and shipping flexibility will be necessary to support more frequent and variable orders. The warehouse may be responsible for special pallet creation and planning as per the service agreement and promotional plan. Shipping would be responsible for coordinating transportation of partial truckloads and cross-docking. Operational Operational changes are changes as a result of supporting tactical and strategic changes. Whereas it becomes a tactical decision to make warehousing responsible for creating special pallets, it becomes an operational task for employees to perform the necessary duties. Space, planning and resources would be necessary to perform the new operations. The systems need to support smaller and more frequent orders. EDI, or something similar would need to be implemented and managed on a daily basis, and this is to be automated as much as possible. Tools to allow collaboration and workflow need to be implemented and supported. Sneaker-nets (manually transporting data) and other inefficient systems would have to be changed causing a need of employee training. The buyer also needs to implement the necessary technology and processes to support VMI. Scanning and POS or POU systems are ways for the buyer to capture sales and trace inventory on its own shelves. The buyer needs to ensure all inventory transactions are made visible to the vendor, for example, by tracking SKUs. Theft and between store transfers would also need to be captured, possibly through inventory level updates or manual inventory counts. If it keeps any inventory off the shelves, 23 such as in storage or locked away, it needs to ensure that the inventory is accounted for and accessible as well. The vendor may also need visibility of the buyer's floor space planning. Transportation companies can allow access to their data and systems to provide vendors with the ability to display the status of inventory in transit. Administration also needs to maintain the service agreement and interact with all parties as needed. This could include monitoring the agreement for cost sharing issues, or propose service agreement amendments. 2.4 Conclusion V M I is a very diverse and powerful initiative. It has an important position and history in the evolution of several supply chain initiatives. It is also very flexible, in that several levels of implementation are possible. This can span from a simple implementation where only the vendor is 'processing' data for all inventory needs, to an implementation where the buyer is interacting much more. It is that variation that would seem to possess more forecasting prowess, and also seems to be the direction of the industry, especially for more difficult to forecast items. 24 3. Knowledge 3.1 Introduction Organizations have used their collective brain trusts for hundreds of years to innovate and provide goods and services better than their competition, or at a lower cost. Data and information have been acquired and catalogued by companies to gain competitive advantage. It would seem that the culmination of these facts would be the obvious use of knowledge, but that has not always been the case. More recently, with organizations growing to titanic proportions, there is a need to not only capture facts, but to organize them and disseminate them to the proper users. Also, an organization's knowledge is more widely dispersed and difficult to identify and tap. It is from this position that organizations have come to recognize the importance of the management of the contents of their collective mind. This realization has sparked some very interesting discussion on what it is that makes an organization competitive or viable. Knowledge surely; but what is knowledge? Is it an understanding of the contents of an analysis, the capacity to find the proper information when decisions need to be made, or is it where baby patents come from? This chapter explores several different aspects of knowledge such as descriptions, types of knowledge and knowledge management. Several definitions of knowledge are reviewed, as well as an example of techniques to manage knowledge projects. 3.2 About Knowledge There are many different definitions of knowledge that could be used as the bases for further discussion. Authors often offer convoluted, extremely open, or no definition whatsoever. Nonaka and Takeuchi (1995, p.58) in the 'Knowledge Creating Company' talk about knowledge at great depth and describe several types but do not give a useful definition. Davenport and Prusak (1998, p.5) in 'Working Knowledge' give a very general definition. It is for these reasons that the Oxford English Dictionary (1996) would be a good place to look for a definition. The Oxford English Dictionary has over 22 25 definitions for knowledge, from "the underlying inference rules for a computer system" to "recognise and confess". To insist that knowledge is something greater than the dictionary's definition is to perhaps confuse the concept and place greater meaning to it than it perhaps deserves. Nonetheless, agreement of the definition is paramount to continued dialogue, as a word that has a loose definition cannot lead to useful discourse. For example one useful Oxford English Dictionary definition is as follows: "Intellectual acquaintance with, or perception, of fact or truth; clear and certain mental apprehensions; the fact, state or condition of understanding. " (OED, 1991) A different definition can be offered in whatever context a person wishes. However, this should make little difference, as this definition is used in the context of being vital to the viability or success of an organization. Nonaka and Takeuchi give an interesting overview of this topic in their book 'The Knowledge Creating Company' (Nonaka, 1995). In Section 3.3, a more definitive definition of knowledge for the task at hand will be offered. 3.2.1 Knowledge Description Knowledge is often placed in a hierarchy with data and information below it. Before talking about knowledge was fashionable in the business world, Peter Drucker referred to knowledge in this context (Drucker, 1988, p.5): "Information is data endowed with relevance and purpose. Converting into information thus requires knowledge. And knowledge, by definition, is specialized." This gives knowledge the feeling of meta-rules that can be applied to data to produce meaningful information. Throughout the literature there is a wide range of types of knowledge described. Two types of knowledge that describe accessibility deserve special mention as they are often cited in writings of knowledge management. These are 'explicit' knowledge and 'tacit' knowledge, concepts put forth by Michael Polanyi and expanded upon by Nonaka and Takeuchi (1995, p.59). 26 Explicit knowledge as discussed by Nonaka and Takeuchi is the knowledge that a person has that can be formalised and expressed clearly. It is codified knowledge that uses a systematic language, and because of this is transferable and quantifiable. An example may be simple procedures or processes. Tacit knowledge, as discussed by Nonaka and Takeuchi, is more difficult to define. This is the knowledge that a person has inside of them that cannot be expressed easily, such as skills and expertise. It is personal and context specific, often influenced with beliefs and faith. It is also knowledge that consists of how an individual cognitively creates mental representations of the world using imagery, analogy and experience. The knowledge that a person may have in a domain such as surgery or golf falls into this type of knowledge. For most skills, all the necessary knowledge cannot be expressed in a formalised way, and because of this, it is difficult to transfer. Interestingly, Beckman (Liebowitz, 1999) introduces a third type degree of accessibility with implicit knowledge. Implicit knowledge is accessible through interaction and querying, however, it can be difficult to locate and elicit. This type is not included in the following discussion. Nonaka et al use their categorization of knowledge in a two by two matrix to show how transference and new knowledge creation takes place. To E Tacit Explicit Socialization Externalization Tacit (Sympathized (Conceptual Knowledge) Knowledge) Internalization Combination Explicit (Operational (Systematic Knowledge) Knowledge) Table 1: Knowledge Creation (Nonaka, 1995, p.72) Socialization is the process of sharing tacit knowledge, which creates sympathized knowledge. For example, apprenticeships and observation of skill can transfer tacit knowledge from one person to another. The resulting experience that the learner has is knowledge in the tacit form. 27 Combination occurs when explicit knowledge becomes explicit knowledge elsewhere to create systematic knowledge. The knowledge is moved from one explicit form to another in some systematic manner, such as documents. It is often combined with other explicit knowledge in the process. Externalization occurs when tacit knowledge becomes explicit knowledge to create operational knowledge. For example, a concept (intangible) could be transformed into a product (with specifications). Later in this thesis, this, along with Combination will be shown in the creation of process diagrams. Internalization occurs when explicit knowledge becomes tacit knowledge to create conceptual knowledge. This occurs as users incorporate explicit knowledge into their repertoire of knowledge. Explicit knowledge is exposed to the user, who can then use this to increase their skill sets or expertise (Morton, 1998, p. 15). Steven Gatley describes these types of knowledge in a Knowledge Creation Cycle (Morton, 1998, p. 17) (see Figure 1). Ideas are shared with others, which creates new concepts with specifications, which are combined with existing knowledge. This ends (or begins) with increasing the tacit knowledge of all parties involved, as new products and ideas generate more ideas. This is a cycle that continually increases the body of knowledge within an organisation. 28 Testing against what is already known COMBINATION EXPLICIT TO EXPLICIT Sharing of ideas SOCIALISATION TACIT TO TACIT Figure 1: Knowledge Creadon Cycle (Morton, 1998, p. 17) Holsapple and Joshi describe the utilization of knowledge as occurring in a 'knowledge management episode' (Holsapple, 1997) (see Figure 2). Knowledge resources are used by people computers to make decisions. 29 Recognition of Knowledge Need Knowledge Management Influences Govern Triggers^ An Episode Involving Some Configuration of Knowledge Activities Available fo Culminates in Achievement ot Processing in Knowledge Resources Figure 2: Architecture of a Knowledge Management episode (Holsapple, 1997) Learning Projection The episode begins with the recognition of a need. Resources are used by a computer or person and governed by influences. The outcome, if the episode is completed, is the direct result of any knowledge management episode: learning or projection. These two results are the source of innovation for an organization. Kao describes the transfer of knowledge as similar to a jazz 'jamming' session (Kao, 1996). Each individual contributes some small part that is combined and complemented with another. As the musicians practice more, they challenge each other to produce something more interesting. The end result can be an incredibly complex piece that could not have been created without all the small inputs. In much the same way, workers should challenge each other to create new ideas. Wiig talks of three notions of knowledge (Wiig et al., 1997). The first deals with knowledge that is in an explicit form, such as databases and knowledge bases. This knowledge can be found in emails and with groupware applications. A second form of management involves intellectual capital, including structural and human capital. This is knowledge that is found in people. A third notion that he deals 30 with is a much broader focus that tries to capture all aspects as related to the firm's success. Wiig puts forward that these notions could be useful in categorizing a project that involves knowledge. 3.3 Definition of Knowledge A working definition of knowledge that will be used is different than what was explored at the introduction to this chapter. The following definition of knowledge is accredited to Dorit Nevo and Dr. Yair Wand at the University of British Columbia. It was first discussed at a doctoral seminar course on Knowledge Management in early 2000. It has similarities to the work by Karl-Erik Sveiby who defines knowledge as the 'capacity to act' (Sveiby, 2000). The precise definition from Nevo's dissertation proposal is: "Organizational knowledge is the ability of an agent to change or to predict the change of things - in accordance with organizational goals -either by actions (tacit knowledge) or by predicates (explicit knowledge)." (Nevo, 2000) The premise is as follows (Wand, 2001): Data refers to records of facts, states of things or about changes that happen to things in the domain of interest. Information is any data or knowledge used to decide on a course of action that might affect behaviour. Often data becomes information by some processing, but this is not absolutely necessary. For example, in a transaction system, the records are often considered data. However, a transaction may be so large or such an exception as to be thought of as information. If several records are processed in some way, such as by aggregation over certain relevant dimensions, it may also become information. Knowledge is the understanding of the possible outcomes of things or how to bring about certain outcomes. 31 Knowledge and information are interrelated. Information is what is used to change a course of action. Sometimes knowledge informs what information you need, where to look for it and how to use it. Figure 3: Knowledge Processing Figure 3 depicts the knowledge process. Data is processed into information. Knowledge is applied to the information, and knowledge of possible outcomes is formed. Later in this thesis, this definition of knowledge will be used in conjunction with processes for an understanding of knowledge in processes. 3.4 Knowledge Management 'Knowledge management' is the set of practices that generate, locate, track, transfer, share, and codify knowledge. Except for codification, these management techniques are not unique to knowledge, but because of the nature of knowledge, they require new practices. The objectives of knowledge management are to ensure that knowledge is available or delivered in the proper format, at the proper time, to the proper knowledge user. Knowledge management is important to monitor, control, grow and understand all types of knowledge. Knowledge management is also to nurture and keep healthy the body of knowledge in the organization. However, this is not done in isolation. The aspiration is to meet the organization's goals by using knowledge assets. Knowledge 32 management goals should support first and foremost the goals of the organization and help ensure its success and viability. Knowledge is a particularly difficult resource to manage. This is due in part to the subjective nature of knowledge, but also to the immaturity of the discipline. Knowledge management has become the buzzword over the past five years. If anything, the number of conferences on the subject and proliferation of related literature is a good indicator of this. There is no agreement on standards for knowledge, nor is there agreement on accompanying frameworks. Indeed, knowledge management is a discipline that is trying to identify itself. So far, it has been most successful by borrowing from other disciplines such as philosophy, human resource management, information technology, AI and knowledge engineering. Organizations hire psychologists, anthropologist and engineers in attempts to create knowledge management initiatives to shed light onto the subject. There are several factors that make knowledge difficult to grasp, most notably its intangibility, volatility and dispersion. This is much different from other resources that are much more quantifiable, such as labour or materials (Wiig, 1997). Other factors that make knowledge different are its way of growing with use. Economists recognize the phenomena of an economy of ideas that transcends typical supply and demand. As individuals use knowledge it is combined and consolidated with other knowledge, ultimately increasing in size, as opposed to being consumed. Sharing knowledge also allows for more interaction with different knowledge users, resulting in an increase once more. Metcalfe's Law says that the value of a network is proportional to the number of users squared (Gloor, 2000, p.62). This observation is due to the fact that as more information is shared, productivity (in some sense) increases and can be applied to knowledge user interaction. Sharing knowledge also allows the same knowledge to exist at different places at the same time. Great wealth of knowledge can be found in the most unexpected places due to the ignorance of roles that are in a position to benefit from the outcome of knowledge use or 'knowledge episodes'. Knowledge is also something that can be difficult to lock down, as it can very quickly vanish with an employee. 33 3.4.1 History Knowledge has been implicitly managed for thousands of years. Any discipline that builds upon itself, such as physics or mathematics is an example of the transference and growth of knowledge from one person to the next. Apprenticeships were designed to transfer knowledge. Universities are a more recent example of this. As said: "[c]learly, knowledge has been managed implicitly for as long as people have thought seriously about their work" (Wiig et al., 1997). It was in the 80s that knowledge management became recognized as a discipline in its own right. Over the past 20 years, knowledge management has grown to ill-defined specifics. The roots of knowledge management can be partially found in the proliferation of information technology within organizations and the increase in the understanding of operations. The increase in technology brought with it shared information, networks for transferring knowledge and advanced A l computing techniques. Operations brought a better understanding and focus on business processes. However, the source of value within the organization was overlooked, possibly because of a complacency brought by these efficiencies. Indeed, increased improvements in operations and processes allowed companies to eliminate many knowledgeable employees during business reengineering, only to find out later that the devil was in the details. These details went with the downsized, and this sparked a renewal of the need to manage knowledge and capture what was in the heads of employees. Even prominent information theorists failed to see the risks of downsizing and talked of creating flat structures (Drucker, 1988). It is interesting to note that the concept of purposefully having redundant employees was an important factor in the structure of knowledge creating companies in Japan for years (Nonaka, 1991, p. 36). Western practitioners came to recognize the importance of middle management as a value added knowledge relay in latter years as well. Knowledge management means many different things to different organizations, as particular needs are addressed with disparate technologies. Indeed, the use of different technology creates very specific solutions that have localized meaning, which causes confusion when the technology itself is 34 considered knowledge management. The immaturity and lack of standards amplifies the situation, meaning it will probably be a while before agreement on aspects will allow mix and match solutions. 3.4.2 Strategic Value Companies have always valued knowledge of employees, most notably seen in hiring practices. It goes to reason the educated or experienced would be sought after before anyone else because of their wealth of knowledge. Knowledge management is a vital exercise for today's firm, where knowledge is a defining competitive advantage. Competitiveness within industry has grown dramatically over the past 50 years. Where before the market was predominately defined by the US, foreign companies have become very proficient at offering goods and services, virtually eliminating margins for less capable companies. Companies focused on two aspects initially, processes and products (Wiig et al., 1997). They eliminated and streamlined their processes to add value and lower the costs of delivering the goods to the consumer. They also concentrated on developing new goods in an efficient manner for consumers. Now companies are focusing on satisfying the explicit needs of the customer for their success. To do this they need to understand information like never before. Treacy and Wiersema suggest organizations focus on the following in their Value Discipline model (Wiig et al., 1997). 35 Operational Excellence Decreasing friction costs and optimizing processes. Product Leadership Pursuing new solutions and creating new products. Customer Intimacy Continual tailoring to fit the customers personal needs for success. How best to serve the customer. Table 2: Value Discipline Model Customer intimacy has become the competitive strategy for many companies. Customers' tastes have become more discerning and their demands more specific. Advances in science allow more advanced production, better educated and skilled craftsmen, and increased the quality of goods and services that make their way to customers. These craftsmen are in high demand for the knowledge that they bring to a company. Donald Marchard (2000, p.24) talks of four ways that companies can compete better using knowledge. These are minimizing risks, reducing costs, creating new realities and adding value. Without concentrating on using these ways to actively use knowledge, a company can flounder in some competitive way. Gone are the days when a company could mange the traditional resources, material, labour and capital without direct use of knowledge. 3.4.3 Direction Wiig talks of the incorporation of knowledge management with the organization (Wiig et al., 1997). Currently, there are several different notions of knowledge management that span a diverse set of practices. As time goes on, the haze around these practices will begin to clear as practitioners and academics begin talking the same language. Knowledge management initiatives will be implemented within organizations to produce certain goals. As time goes on, knowledge management practices will 36 become second nature, and part of the daily practices that occur, like other initiatives before it. Eventually some other fad will arise that will capture the attention of managers and academics. By then knowledge management will be a standard practice, incorporated into all parts of the organization in order to be able to compete. Shortcomings due to technology will be eliminated with advanced computing and more focussed effort. Value will be seen in the shared knowledge, and the facilities to connect. Standards in practice and information technology will allow better and faster creation and incorporation of knowledge management solutions. 3.5 Example There have been many attempts to create conceptual methodologies to manage knowledge projects. However, the appropriateness for a method would depend on the type of project being undertaken. Wiig et al. (1997) crafted a knowledge management cycle as a conceptual framework to order knowledge management techniques. This is a loosely constructed method for knowledge managers to use to attempt to structure a project. A summary of this cycle is presented. The methodology is broken down into four phases: Review, Conceptualize, Reflect, and Act. These phases interact with knowledge in many ways, including developing new knowledge, distributing existing knowledge, combining knowledge and consolidating knowledge. Review The first phase to be presented is the 'review' phase, which consists of two components, Monitor Performance and Evaluate Performance. Monitoring performance is looking for opportunities for continual improvement in the existing practices. All actors are expected to be doing this while performing their roles. Can things be done better? Also, external forces are monitored to detect anything that may have an impact on performance, or the continual success or viability of the company. 37 Evaluation of performance is done based on the goals of the organization or knowledge management strategies. This is to determine if results have been achieved based on some predefined measures. Conceptualisation A very important phase is the 'conceptualisation' phase. This is the phase where you identify and analyse the knowledge assets in the project. The first task is to create an inventory of the knowledge. Wiig uses a simple diagram to depict the interaction of knowledge and asks the questions: What uses the knowledge? Which knowledge is used? Where is it used? When is it used? Which organizational role uses it? Figure 4: Wiig's knowledge interaction 'What' business processes use 'which' particular knowledge assets in their operation? 'Where' and 'when' are time and location attributes of the knowledge asset. These attributes also include form and content. Although it is often difficult, it is important to identify these knowledge assets. Knowledge 38 assets are rarely clearly identifiable, so they must be organized in some fashion. Wiig uses a table (see Table 3) of successively detailed knowledge dimensions and suggests using the middle sections and segments. Knowledge Span Examples Knowledge Domain Knowledge region Knowledge Section Knowledge Segment Knowledge Elements Knowledge Fragments Knowledge Atoms Domains - Internal medicine - Mechanical engineering - Business management Regions - Urology - Automotive mechanical design - Product marketing Sections - Kidney diseases - Transmission design - New product planning Segments - Diagnoses of kidney disease - Gear specification and design - Product marketability Elements - Diagnostic strategies, such as "When considering which disease is present, first collect all symptoms, then try to explain as many of them as possible with one disease candidate" Fragments - "If the symptom is excruciating pain, then consider kidney stone" - "When there are too many gears in the transmission, the energy loss will be excessive" Atoms - "Excruciating pain is a symptom" - "Use case hardening of gear surfaces in pressure range 4" Table 3: Knowledge Dimensions (Wiig et al., 1997) The next tasks would be to identify the roles that use the knowledge and link the knowledge assets to business processes. Wiig advocates many different techniques to associate knowledge with roles, such as question surveys, knowledge mapping and knowledge scripting and profiling. To identify the processes that need the knowledge, he suggests task environment analysis, critical knowledge 39 function analysis, knowledge use and requirements analysis and knowledge flow analysis. Finally, a method to describe the knowledge is needed. These descriptors capture the attributes of the knowledge. After the knowledge has been organized, it is to be analysed for strong and weak points. Two methods are suggested, bottleneck analysis and SWOT (Strengths, Weaknesses, Opportunities and Threats) analysis. Bottleneck analysis examines for constraints that limit the ability of a process to execute more efficiently. Wiig lists several knowledge related problems and symptoms that can be used as a starting point for identification of bottlenecks. The SWOT analysis is used to analyse knowledge from the perspective of the organizational goals. Reflect The 'reflect' phase is used to produce improvement plans that are to be carried out in the 'act' phase. The quality of the decisions made in this phase depends heavily upon the previous phase. It is important that this phase follows the previous, as these are the items that should be addressed. It is not uncommon for the wrong conclusions to be made before a proper analysis. Wiig warns that solving the wrong problem can be one of the worst errors that can be made, especially when information technology is involved. Wiig advises either elaborating on the SWOT analysis, bottleneck analysis or thinking of the improvements in terms of programs: Effectiveness improvement programs Knowledge building programs Strategic action programs Improvements must be prioritized using decision analysis for implementation. To do this, some value must be placed upon the improvements using a methodology. This methodology is just some way to attribute value, which can consist of several difficult to quantify cultural and organizational factors. After the improvements are identified, they are incorporated into improvement plans for execution. Some of the improvements will be ongoing concerns, such as plans to share knowledge 40 through more communication. In selecting the improvement plans to be carried, risk analysis is of the utmost importance to determine the impact on the organization. Act The final phase is not a knowledge management activity in its own right. Several enablers of plans already exist in areas such as human resource management, information technology and organizational development. The best tools for the job from these areas should be used. 3.6 Conclusion Knowledge management is a phrase that is widely used and is applied to several diverse practices. As it is one of the latest fads, existing business practices are being offered as being knowledge management. Also old problems are repacked under the moniker. However, as said in an article by Junnarkar (1997): "Giving a new name to a known problem does not solve the problem at all." What knowledge management can be seen as is a way to use old and new practices in a directed manner to support knowledge. The usefulness of the organization of knowledge as shown in the example, especially the conceptual phase, will be applied later when VMI processes are organized. This chapter has attempted to look at knowledge and knowledge management, not so much from a perspective of practices, but from a holistic view. Several areas can be examined from a specific outlook and indeed deserve their own chapters when talking about knowledge: intellectual capital, knowledge discovery in databases, and the creation and application of ontologies. However, the goal of this chapter was to frame the discussion of knowledge to be useful when considering business processes. 41 4. Processes 4.1 Introduction Generally it is agreed that processes happen within business, they are very important, and it is essential to understand them. However, from the literature, it is difficult to find agreement on what a business process is. Darnton, in his book 'Business Process Analysis' goes so far as to use the tongue-in-cheek term BPW meaning 'Business Process Whatever' to refer to various business activities that operate with processes (Darnton, 1997, p.xv). This chapter will look at the meaning of business processes and will discuss the notation that is used in this thesis. At the end of the chapter, knowledge in processes will be discussed. This understanding of knowledge in processes is used in the following two chapters to understand and capture knowledge in VMI. 4.2 Process Definition The meaning of processes depends on the context and person using the term. For example, executives, consultants, information professionals, and business process redesign champions all have different perspectives on what business processes mean to their organization, and invariably they have their own definitions. Darnton (1997, p.8) provides a survey of various academics works on descriptions of business processes. Of the several examples he provides, the following is a popular definition by Davenport and Short: "[A business process is] simply a structured, measured set of activities designed to produce a specified output for a particular customer or market. It implies a strong emphasis on how work is done within an organization, in contrast to a product focus's emphasis on what. A process is thus a specific ordering of work activities across time and place, with a beginning, and end, and clearly identified inputs and outputs: a structure for action". (Darnton, 1997, p. 10) Darnton goes on to describe the state of confusion concerning an agreed upon definition in the following quote: 42 "We are surprised that there is not general agreement about the definition of business processes. This makes it more difficult for the analysts to know what to look for. When we first began to look for the meaning of business process, we anticipated finding more detailed, operational definitions, that is, a minimum set of information that would be needed by those who have to do the more detailed work, or implement new processes. Clearly, the definitions obtained so far will require supplementary material before there is enough for the practitioner to handle in a rigorous, systematic way." (Darnton, 1997, p.13) This confusion can be partially explained as a result of the abstract nature of processes. Since processes are abstractions, the mere mention of a process is not enough to conjure a mental representation of what it is, unlike, for example, a chair (Kock, 1999, p. 19). Ned Kock cites work by Harvard Professor Shoshana Zuboff who discusses 'dissociation of sentience and knowledge' (Kock, 1999, p.20). If people have no models to apply something to, confusion of thought about the thing sets in. For example, labourers who are moved from physical labour to working in production control rooms with computers have problems recognizing their new role as part of the overall production process. Kock goes on to discuss the need for models of processes: "Processes, as most abstract entities, need to be modeled in some way to be understood. And, more importantly, two or more people must understand the processes in roughly the same way. Models, however, irrespective of how complex they are, are in most cases limited representations of whatever they are supposed to represent, whether these are real objects or abstract entities." (Kock, 1999, p.20) It is little wonder that there is uncertainty in terms being used when there is such great confusion surrounding processes and the tools that are used to diagram or manage them. The words 'processes' and 'functions' are used interchangeably. For example, two of the family of IDEF notations are IDEFO, a functional notation, and JDEF3, a process notation (Bernus, 1998, p.209; Rolstadas, 2000, p.55). It is not uncommon for texts and software to ignore these distinctions. IDEFO is often used as an example of process mapping in both literature and in software systems (Hunt, 1996, p.96; Purba, 1999, p. 11-8; CAI, 43 2001). In turn JDEF3 is described as a workflow-mapping notation (CAI, 2001). The distinctions are not always clear, as seen in the following quote: "Although there seems to be little agreement on what a process is or the main elements that make it up, the predominant view among academics and practitioners seems to be that of a set of interrelated activities (Hunt, 1996; Ould, 1995). In this sense, processes are seen as activity flows (a.k.a. workflows) composed of activities that bear some sort of relationship with each other (White and Fischer, 1994)... The terms 'interrelated activities' and workflow can be understood differently by different people in the field of process management" (Kock, 1999, p.21) However, for the sake of this thesis, the much cited description of processes as defined by Hammer and Champy and used by SAP (Keller, 1998, p.45) will be employed: "We define a business process as a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer." (Hammer, 1993, p.35) 4.3 Event Driven Process Diagram The process notation that will be used is the Event Driven Process diagramming method created by Jacob Steif. Steif began developing the technique while in Israel in the early 80s and completed it in 1985. The technique was originally used in research in the fields of medical computing and clinical laboratory information systems. Using this notation, Steif explored knowledge based clinical process systems in the second half of the 80s (Steif, 2001). Along with being used in several industry projects, the notation is currently being taught in a slightly modified version at the University of British Columbia in business system analysis courses. The notation that will be described and used for this thesis is an adaptation of this version. Except where noted, the following diagramming information has been sourced from lecture notes at UBC (Wand et al., 2001), and the SAP model (Keller, 1998, p. 145). The notation is an event-driven process diagramming technique, which shows the sequence of activities and events using boxes, arrows and text. 44 Activities Activities describe what is to be done (see Figure 5). They are seen as actions that are performed to change the state of something. Activities can also be decomposed to show internal activities that are relevant. Activities are composed of the following properties: Operations - describes what is done in the activity Agents - describes who performs the activity Resources - describes what is used in the activity Rules - Describes controls on the activity. Activity Name (Decomposition) operation 1, operation2... {agents} [resources] V (rules) J Figure 5: An Activity Activities are also performed by a role. The role can be quite specific, or more general in the case of modeling an initiative such as VMI. Not all activities will necessarily note all of these internal properties, however. It depends on the level of interest and granularity. The inputs to the activities are resources and/or information objects (in the form of resources), rules, and knowledge. Outputs are physical objects, knowledge, and/or information objects (in the form of resources). 45 Events Events describe when something is done or is to be done (Keller, 1998; Wand et al., 2001). Events consist of an arrow and an event name (see Figure 6). The direction of the arrow also denotes the sequencing and flow of consecutive activities and events. The notation used by UBC includes inputs and outputs associated with the events, however they are not used in this thesis. event name > event name. Figure 6: Events An event can be thought of as changes to the state of one or more objects that happen at a particular point in time. Events are seen triggering an activity or being triggered by an activity (see Figure 7). event name • Act iv i t y N a m e (Decomposition) o p e r a t i o n ! operat ion2. event name • {agents} [resources] (rules) Figure 7: Events and Activities Events occur and trigger processes or activities. When events are triggered by, or trigger, a process they are denoted with a circle symbol to show the beginning or end of the process (see Figure 8). 46 start of process end of process Figure 8: Beginning and end of processes Logical symbols Events can be drawn to show various combinations. When more than one event occurs in a process or activity, there are different logical conditions that may be expressed. AND: 'AND' constructs means that all of the events associated occur. This is denoted by a diamond symbol seen in Figure 9 and Figure 10. AND symbol V J Figure 9: 'AND' construct triggering an activity 47 f Activity Name A J Figure 10: 'AND' construct being triggered by an activity In Figure 9, both events must occur when triggering the activity. In Figure 10, both events are the result of an activity and must occur. 'OR' constructs mean that one or more of the events may or may not occur. This is denoted by showing one or more events triggering or being triggered by an activity. EXCLUSIVE OR: The 'Exclusive OR' (XOR) construct means that exactly one and only one of the choices will occur. This can be seen triggering (see Figure 11) and being triggered by (see Figure 12) an activity. f Activity Name A OR: T T XOR symbol Figure 11: 'Exclusive OR' construct being triggered by an activity 48 XOR symbol f Activity Name \ J Figure 12: 'Exclusive OR' construct triggering an activity Required Event The notation that is used at UBC does not include a construct for a required event (Wand et al., 2001). A required event is one that must occur when triggering, or when being triggered by an activity. Previously, this was denoted without any particular construction. However this can lead to confusion. For example, consider Figure 13a. According to the constructs that were mentioned previously, this would be an 'OR' by itself. In other words, it may or may not occur. Figure 13a shows events that may or may not occur when triggering and being triggered by an activity. However, when treated with an 'Exclusive OR' construct, as in Figure 13b, it means that exactly one of the events must occur. In the situation where there is only one event, that event must occur. For Figure 13b, the event triggering the activity must occur and the event being triggered must occur, because of the 'Exclusive OR' constructs. This 'Required' construct can be nested within itself, 'Exclusive OR' constructs, and 'AND' constructs to portray complicated conditions. 49 f Activity N a m e A f Activity N a m e N a. b. Figure 13: Non-required event vs. 'Required' events 'Required' events are useful in simplifying and extending the notation taught at UBC. It should be noted that this notation changes from what is proposed by Steif (2000). Steif handles the same sort of conditions by extending what UBC calls the 'AND' construct. For the purpose of this thesis, 'Required' events will be used sparingly, if at all. This is due to the nature of what is being examined, that is, an abstract initiative, which avoids any implementation. It was mentioned as a suggestion to extend the notation taught at UBC. The constructs for the Event-Driven Process Diagram are summed up in Table 33 in Appendix C, where they are also compared to corresponding events in the SAP model. 4.4 Knowledge in Processes Examination of business activities is often used in several knowledge management techniques. Usually it occurs at some auditing stage where existing operational knowledge is captured to try to define the state of the knowledge house. For example, in Wiig's method for knowledge management as seen in the previous chapter, a reasonable stage in the analysis of processes would be to map them. However, what is required for this thesis is the examination of an initiative that is not implemented. It must also be general enough so that it can be applied to several situations, regardless of existing technology. There is no particular knowledge management project that needs to be done. 50 However, techniques can provide some guidance in answering the following question: "Specifically, how can processes and knowledge requirements be used together for a better understanding of a concept, such as VMI?" Knowledge can be found in rules, in the minds of the roles that perform the activities and in the diagrammed description of processes. The conceptualization phase presented in the example in the previous chapter ties in nicely with the understanding of knowledge needed here. VMI is manifested by certain types of processes. These processes are comprised of actions that are performed by individual agents and machines. If the actions occur, some of them require data whereas some of them generate data. If the actions require discretion, then whatever is used for the discretion is information. The question is, 'where is this knowledge embedded?'. 4.4.1 Three Occurrences of Knowledge Three types of knowledge will be examined in this thesis using an application of the working definition of knowledge used in the previous chapter and the description of processes earlier in this chapter. Following is a description of the three types of knowledge, along with the process of deriving them from the process models. To reiterate, knowledge is the capacity to act (Sveiby, 2000), which manifests itself in processes in three ways. Embedded Knowledge This is knowledge of how processes are performed. This is depicted in the structure of process diagrams in how activities interact with other activities and events, using the logical operators. Embedded knowledge of VMI processes is shown in Chapter 5 using the Event Driven Process Diagrams. The diagrams show how to do VMI by capturing activities, events, logical constructions, sequencing and flow. 51 Knowledge Used in Processes This is knowledge that occurs in the rules, resources and within the minds of the roles, or agents, that perform the process. This knowledge is used in the V M I processes to inform how to make decisions. This is captured in 'how to' type questions by examining the roles, rules and resources that are contained within the activities. In Chapter 6, this knowledge is examined within the processes as either 'Domain Knowledge' or 'Operational Knowledge'. These terms are described in Chapter 6. Knowledge Created Within Processes This is knowledge, which is produced within an activity or process that can be used inside the same process or activity or in another process or activity. Similar to knowledge used within processes, this is captured in 'how to' type questions by examining the roles, rules and resources that are contained within the activities. In Chapter 6, this knowledge is examined in terms of 'Performance Knowledge'. 52 5. VMI Processes - Embedded Knowledge 5.1 Introduction There are several processes that are required or interrelated with VMI. There is also knowledge that is embedded in how to do VMI processes. This chapter looks at embedded knowledge by mapping the VMI processes. The chapter attempts to do this by looking at the following: Processes that have to change to support VMI (Section 5.2) Processes that can have value added to them in VMI (Section 5.3) The relationships with processes can be seen in Table 4. 'VMI Changes' refers to the processes that must be performed in a certain way to facilitate VMI. 'Value added' refers to the 'Required', but not 'Necessary to VMF processes that can have value added to them with the implementation of VMI. A couple of examples of this will be shown. •iflggpess ', VMI Changes j; Value Added Sales and Returns X i | | r ^ to r ) |M| r |agement X P O Processing X Order processing X Delivery processing X Receiving (and.Billing) . . i! X Placement Quality Management Vendor's Own Replenishment X Table 4: Relationship to VMI 5.1.1 Processes That Have to Change to Support VMI A traditional non auto-replenishment system is described and compared with a VMI system. The processes that change are mapped to show the major differences in activities and events. 53 First, the relevant operational business processes, from the depletion to the replenishment of products in a retail environment, are identified. They are shown below in Figure 14. Sales/ Returns Inventory Management PO Processing Order Processing Delivery Processing Vendor's Procurement Quality Management Billing Receiving Placement Figure 14: Relevant Fulfillment Processes. A summary of these processes is described in Table 5: Processes Sales and Returns ilnventory [Management i Description v _ Selling products and handling returns for consumers at the retail site. This changes retailer's inventory levels. Updating non-sale retailer inventory changes and monitoring J retailer inventory for replenishment needs. ' PO Processing Creating a purchase order for more retail goods. JOrder processing 'Processing a.PO.receiyed from the retailer. Delivery Drocessina P e r f o r m i n 9 a " t n e duties required to coordinate and move goods _ _ _ t o the retailer. 'Receiving ( a n d \ " ~""™ ' " ' "~" Billing) ^ Placement .Vendor's "own iProcurement The retailer gaining control of the product and paying the vendor. The placement of the product at the retail site. Replenishment of trie vendor's own inventory, which is in turn sold :to retailers. - . " .< Quality Management A practice of ensuring a particular quality of products. Table 5: Relevant Fulfillment Processes Summary 54 5.1.2 Processes That Can Have Value Added To Them In VMI When entering into VMI, certain processes may have value added to them, yet may not necessarily change. Some examples of these processes are shown at the end of the chapter. They can also be seen in Table 4 under the heading 'Value Added'. 5.1.3 Strategic VMI Processes There are two more occurrences that must be mentioned with regard to VMI (see Table 6). These are strategic and are not performed continuously, but rather developed at the beginning of the relationship and updated at specific periods over the course of the VMI partnership. These occurrences will be discussed in the next chapter. - ^Occur rences Descript ion Develop Front-end Determines the strategic direction of the VMI relationship, and Agreement defines its scope and'spirit'. •Develop Service "•, Specifies the details of the, VMf relationship..; Includes information-'Level Agreement on metrics, and rules (i.e. structure, application, and parameters. Table 6: Strategic VMI Summary 5.2 Processes That Have to Change to Support VMI To understand the major changes that occur when VMI is implemented, it is helpful to consider a situation where there is currently no auto-replenishment system in place. This helps illustrate the changes that need to occur. Subsequently, a traditional non auto-replenishment system is discussed, showing the relevant activities and events in the processes. 5.2.1 Traditional System The traditional system that is modeled assumes that there is currently no auto-replenishment system of any kind in place. A brief summary of the system is shown in Table 7. 'Link to Other Role' 55 refers to an activity that links to another activity that is performed by another role, the vendor becomes active in the system. This is to show where Main Processes Activities Role Link to other role Data shared Sales and Returns (Sales) Consumer goods purchased Retailer (Sales) Sales information captured Retailer (Returns) Consumer returns goods Retailer (Returns) Goods examined Retailer (Returns) Goods restocked Retailer Inventory Management (Retailer Inventory Update) Inventory Counts Updated Retailer (Inventory Monitoring) Inventory Examined Retailer (Inventory Monitoring) Replenishment Needs Determined Retailer PO Processing Purchase Order Initiated Retailer Products Sourced Retailer Quotes Examined Retailer Vendor PO details Order processing PO entered Vendor Preliminary schedules determined Vendor Table 7: Traditional Non Auto-replenishment System PROCESS: Sales and Returns (Traditional System) This describes the day-to-day selling of products to consumers and the handling of returned products. A sale results in the depletion of goods from inventory. The capturing of this information may or may not occur at the time of the sale. For example, a retailer may use POS to capture sales transactions and inventory changes, or the retailer may rely solely on periodic physical counts of inventory to capture the changes. A return may result in a good being returned and resold, or being returned and not resold. If restocked for resale, the inventory change may or may not be captured, similar to a sale. Sales (Figure 15) and returns (Figure 16) activities are shown below. 56 o Sale completed - no electronic transaction record Consumer initiates purchase O Consumer purchases goods J Sale completed -electronic transaction record Sales captured electronically (data capture rules) inventory updates made O Figure 15: Retailer Sales to Consumer (Traditional System) 57 o Consumer initiates return O O o Consumer returns goods (returns policy) T y. return completed Goods examined (returns policy) goods resellable -transaction record fReturns informations captured goods defective goods resellable -no transaction record goods restocked (returns policy) inventory update made Figure 16: Consumer Returns Goods to the Retailer (Traditional System) PROCESS: Inventory Management (Traditional System) Inventory Management is grouped into two main processes, 'Retailer Inventory Update Activities' and 'Inventory Monitoring': /. Retailer Inventory Update (see Figure 17) refers to the capturing of non-sales changes in inventory levels and the changes to inventory that occur when a physical counting of inventory is performed. Example of non-sale changes may be between store transfers of goods, or goods that become unusable. Physical inventory counts are used to reconcile 58 the recorded inventory levels with the actual inventory levels, or they may be used to capture the actual inventory levels, if no recording is done. o inventory quantity changed inventory counted Inventory counts updated inventory \updates made inventory updates not made O O Figure 17: Retailer Inventory Update (Traditional System) 2. Inventory Monitoring (see Figure 18) refers to the monitoring and triggering of the replenishment determination activity. The trigger can be due to changes in the inventory levels, or periodic reviews of inventory. The determination of replenishment needs could be as simple as hitting predefined minimum stock levels, or using forecasting techniques. The amount of inventory that is determined is requested through a purchase order. 59 O; O inventory levels change milestone reached Inventory examined ^ replenishment triggered f Replenishment Needs^\ Determined O order requested. (replenishment rules) (forecasting techniques) Figure 18: Inventory Monitoring of Retailer Goods (Traditional System) PROCESS: Purchase order processing (Traditional System) The purchasing order process involves all of the activities needed to create and transmit a purchase order to a vendor (see Figure 19). Three alternative arrangements could occur: 1. Before requesting quotes, potential vendors need to be sourced 2. Quotes are requested ('Request For Quote' - RFQ) from potential vendors that are already sourced. 3. A specific vendor is already chosen and quotes have been predefined according to some relationship. In the case where the vendor needs to be chosen, RFQs are sent to select vendors asking for availability and prices for a certain quantity of products in a certain time period. 60 f Purchase order A o order requested O initiated potential ( p r o c j u c t s s o u r c e c j (PO rules) PO transmitted vendor quotes requested PO transmitted vendor quotes requested Quotes examined availability checked quote selected Figure 19: Purchase Order Process (Traditional System) PROCESS: Order Processing (Traditional System) The vendor performs Order Processing after receiving a PO (see Figure 20). The PO is initiated and entered into the vendor system in some fashion. The PO is examined and an availability check, along with credit checks may be performed. If it is to be filled, preliminary dates concerning fulfillment schedules are determined. If not, it is aborted. A PO acknowledgement is returned to the retailer and the order is sent for delivery processing. 61 PO received PO entered checks ^(purchase order)J order aborted - retailer notified PO examined order ok Preliminary schedules determined (purchase order) delivery processing triggered PO ack returned O Figure 20: Vendor Processes Order (Traditional System) 5.2.2 VMI System Table 8 shows the different required processes that are changed in the V M I system. Note that these processes are all operational processes - they do not include the development or maintenance of the V M I system. These issues will be mentioned in the next chapter. Note as well that the terminology that is used in the V M I system is the same as the traditional system. For example, a purchase order for the retailer is used in the V M I system, even though it did not originate from the retailer, but rather from the vendor itself and is not necessarily referred to as a 'purchase order'. Also, different ways of replenishment are not distinguished. For example, 'one piece flow' of goods is not modeled differently than other methods such as 'periodic replenishment'. This is because what determines the replenishment, regardless of frequency of replenishment, is still governed by replenishment rules. In 'one piece flow' the rule may simply be 'replace one piece'. 62 Main Processes Activities Role Link to other role Data Shared Sales and Returns (Sales) Consumer purchases goods Retailer (Sales) Sale captured electronically Retailer Vendor Purchase details, possibly consumer details (Returns) Consumer returns goods Retailer (Returns) Goods examined Retailer (Returns) Goods restocked Retailer Vendor Return details, possibly consumer details Inventory Management (Retailer Inventory Update) Inventory Counts Updated Retailer Vendor Proper inventory counts, inventory updates (Inventory Monitoring) Inventory Examined Vendor (Inventory Monitoring) Replenishment Needs Determined Vendor PO Processing Determine ability to replenish Vendor Replenish to forecast Vendor Replenish optimally Vendor Replenish what is available Vendor Determine available substitutes Vendor Create smaller separate orders Vendor Reserve stock Vendor Order Processing Preliminary schedules determined Vendor Retailer PO details Table 8: Changed Processes in a VMI System PROCESS: Sales and Returns (VMI System) The Sales and Return processes consist of similar activities as the traditional system (see Figure 21 and Figure 22). However the following differences are important to note: Sales transactions and return transactions should be captured electronically, and in detail. This differs from the traditional system where electronic data collection was optional 63 Transactions are shared with the vendor. Rules govern the capturing and sharing of data. These processes trigger processes beyond the retailer directly, as opposed to through a purchase order that contains aggregated information. The vendor needs a data link, which provides visibility to the retailer's inventory. This data is stored by the vendor and used along with rules to determine replenishment. Data may be shared in several different ways. For example, the retailer may allow data to be pulled by the vendor, or may push the data to the vendor. Also the sharing may occur per transaction, or batched over an interval such as a period of time or a number of transactions. Benefits to the vendor are: More timely and accurate information. More detailed information. For example the data is not aggregated into a purchase order, which would be the exchange of information in the traditional system. Examples of data that could be captured are shown in Table 9. a o Consumer initiates purchase Consumer purchases goods Sale completed Sales captured electronically capture data, share data (data capture rules) (data sharing rules) inventory updates made O Figure 21: Retailer Sales to Consumer (VMI System) 64 inma o Consumer initiates return O O Consumer returns goods (returns policy) T return I completed Goods examined (returns policy) goods resellable -transaction record f Returns information^ captured goods restocked (data sharing rules) (data capture rules) (returns policy) goods defective inventory update made Figure 22: Consumer Returns Goods to the Retailer (VMI System) ': Sales and Returns Activities (Sales) Consumer purchases goods Link to Other Main •' Processes (Sales) Sale captured electronically i Inventory Monitoring of Retailer Goods (Returns) Consumer returns goods l(Returns) Goods examined , Examples of Data ' Purchase details: time and = : date of sale, quantity/ S K U , ! price, discounts, store, and i possibly customer and sales' .person. / n * '' \ r%' J . j i Inventory Monitoring of (Returns) Goods restocked R e t a j | e r y Q o o c | s Table 9: Sales and Returns (VMI System) Return details: time and date of return, quantity, S K U , link to sales transaction reasons for return. 65 PROCESS: Inventory Management (VMI System) Inventory management is grouped into the same two main processes as in the traditional system, Retailer Inventory Update Activities and Inventory Monitoring (see Figure 23 and Figure 24). The main differences with the processes under Retailer Inventory Update Activities relate to: Inventory updates must be captured electronically, and in detail. Updates are shared with the vendor. Specific and jointly agreed upon rules govern the capturing and sharing of data. These processes directly trigger processes beyond the retailer. The same manner of data link as mentioned in Sales And Returns for the vendor is required to capture any updates. inventory quantity changed Inventory counts updated share data (data capture rules) (data sharing rules) inventory counted Figure 23: Retailer Inventory Update (VMI System) f inventory updates made O The main differences with the processes under Inventory Monitoring relate to: The vendor performs this process. Service Level Agreement (SLA) rules govern the process. This is elaborated upon in the next chapter. The same benefits as mentioned in the previous process apply here, as well. Examples of data that could be captured are shown in Table 10. 66 mil O inventory levels change ilestone reached Inventory examined f Replenishment Needs^ Determined replenishment triggered (SLA) (replenishment rules) (forecasting techniques) PO required J Note: - Replen ishment is not necessar i ly triggered each time data is shared , this is governed by the replenishment rules. -Mi lestones can be some predef ined interval, such as t ime or number of updates Figure 24: Inventory Monitoring of Retailer Goods (VMI System) Inventory Management (Retailer Inventory Update) Inventory Counts Updated (Inventory Monitoring) Inventory Examined ; Link to Other Main _j| Processes Examples of Data . . S K U quantity changes, data Inventory Monitoring a n d ^ Q f • J ^ of Retailer Goods r e a s o n s f o r u £ d a t e s . (Inventory Monitoring) Replenishment Needs Determined Process Table 10: Inventory Management (VMI System) Retailer Inventory Update Purchase Order Inventory levels, sales history, demand, SLA Forecast, or replenishment rules. PROCESS: Purchase order processing (VMI System) This process (see Figure 25) is very different from the traditional system. It should be noted that within this process, the vendor in effect creates a purchase order on behalf of the retailer and 'sends' it to itself. The vendor determines the ability to fulfill the PO. This process consists of the following: 67 1. Replenish to forecast - the PO will contain what is forecasted. 2. Replenish optimally - the PO will contain the best possible combination of goods depending on substitute products and the ability to create partial orders. 3. Replenish what is available - the PO consists of the forecasted goods that are availability. After this, the vendor reserves the stock and sends the order to be processed. This brings to light several differences compared to the traditional system: No quotes are made. This is governed by the Service Level Agreement. The vendor is already selected. This has been pre-arranged in the Service Level Agreement and the Front-End Agreement. The vendor determines the details of the PO. This is governed by the Service Level Agreement. The benefits that can be found from this process are: Faster and more effective processing. Smarter use of market knowledge in choosing replenishment order. Examples of data that could be captured and links to other processes are shown in Table 11. 68 has not Wthe ability f determine ability to replenish PO required I OH (availability) (SLA) Replenish optimally (±.1) items to be reserved [availability] (substitution rules) ^replenishment rules^ Replenish what is available items to be reserved [availability] (replenishment rules) Replenish to forecast Reserve stock' [availability] Vitems to be (replenishment rules) ) reserved  i I i J  process as 'PO' items to be reserved^. Create smaller, separate orders [availability] (replenishment rules) has not the ability to replenish to « i forecast ^ items to be reserved] /Determine available^ substitutes has not the ability {1} to replenish to ^ fnmnafst [availability] (substitution rules) substitutes not available Figure 25: Purchase Order Processing (VMI System) 69 JPurchase Order Process ing ^ a i n ^ r o c e s s Examples of Data K * ..... . , • u Inventory Forecast, availability of products, PO Determine ability to replenish needs , iRepIenishtqforecast •. . ; Z l F o r e c a s t " . ; '",,„,„," Replenish optimally Forecast, substitutes, S L A Replenish whaJBavai lable • 1 Forecast, SLA Determine available substitutes Substitutes, S L A .Create smaller separate o l . brders . „ _ J ^ ± Reserve stock Order Processing Availability, P O Table 11: Purchase Order Processing (VMI System) PROCESS: Order Processing (VMI System) The Order Processing process in the VMI system (see Figure 26) eliminates several activities present in the traditional system. This is possible because of the pre-existing relationship that exists between the vendor and retailer and expressed in the Service Level Agreement. The main differences are: The PO is already within the vendor's system. Availability was determined earlier during the creation of the PO. Credit check need not be performed. The benefits that can be found from this process are: Streamlined communication with the retailer. Several activities have been previously done and are supported by agreements. Examples of data that could be captured and links to other processes are shown in Table 12. 70 PO received outbound logistics activities triggered (SLA) (purchase order) PO notice sent to retailer (same as 'PO ack returned') Figure 26: Order Processing (VMI System) Order Processing Link to Other Main Examples of Data Processes Preliminary schedule determined Purchase order processing, Delivery processing PO details, preliminary schedules, SLA Table 12: Order processing (VMI System) 5.3 Processes That Can Have Value Added To Them In V M I The processes mentioned above are not only required for VMI, but they must also be performed in certain ways. Beyond these processes, there are opportunities to add value elsewhere when entering into VMI. The main factor that allows this is the improved opportunity to forecast retailer demand. Without VMI the vendor may not see the trends in demand. The better opportunity to predict demand is caused by the better visibility of the retailer's data. With this comes the ability for the vendor to plan its own activities better. Three examples of where value can be added are mentioned below. Interestingly, all examples occur where the vendor, or retailer interacts with other supply chain partners. This implies that planning abilities can be greatly enhanced with better information. 71 PROCESS: Delivery Processing When the vendor has a better handle on demand, it can plan better. One activity this can be seen in is a section of the Delivery Processing, which is Shipper Selection. Not only does the vendor have a better idea of when it will need to ship in the future, but it also has a better idea of the service levels that are required. Consider how a vendor chooses a shipper. Figure 27 shows how a traditional process may be performed. With VMI the vendor may have the information it needs to plan and form a partnership with shipping companies. It can negotiate fares and schedules, for example. Figure 28 shows how the process may be performed with VMI. The differences are: Shippers may already be sourced. A preferred shipper may exist. Quotes may already exist from the shipper. Quotes may contain costs, discounts, shipment sizes and shipping frequency. These may have been previously negotiated based on predicted usage. delivery required Transport needs assessed potential shippers identified shipper chosen shipper quotes requested Shippers sourced 'shipper quotes requested shipper chosen Quotes examined schedules checked quote selected Figure 27: Shipper Selection (Traditional System) 72 r Transport needs assessed delivery required (shipping rules) (SLA) shipper chosen shipper quotes requested C Quotes examined jr shipper schedules checked quote selected Figure 28: Shipper Selection (VMI System) PROCESS: Vendor's Own Inventory Replenishment Better visibility of retailer demand will allow the vendor to plan its own replenishment better. For example, the vendor can use similar VMI principles with its own vendors. The vendor knows how much it will need to replenish its retailers, and using this knowledge, predict how much and when it needs to replenish its own inventory. The overall result will improve visibility of demand across the supply chain, as the dreaded Bullwhip Effect, mentioned in Chapter 2, is minimized. PROCESS: Receiving and Payment A final example of ways that processes may change is seen in receiving and payment arrangements. In a traditional system, a retailer will need to reconcile the purchase order, the bill of lading and the shipping slip before paying. In VMI, the retailer may only need the shipping notice for 73 payment. They may possibly compare the details of the received shipment with the purchase order sent back to them when the vendor generated the order. However this would be simplified in itself, as the purchase order should only contain items shipped. 74 6. Identifying Knowledge: The VMI Context 6.1 Introduction The previous chapter looked at the processes that define operational aspects of VMI. This chapter will examine each of the processes and discuss: Knowledge that is used in processes Knowledge that is created by the processes The use of Service Level Agreement (SLA) and Front-end Agreements to hold knowledge. First, the general methodology used to examine the processes will be discussed in Section 6.2, along with an example pertaining specifically to VMI. Following that will be more in-depth discussions about different classes of knowledge. The following is a brief overview of what will be covered in each section. The overview is also provided here to give some reference to the terms used in Section 6.2. 6.1.1 Knowledge Requirements and Agreements Knowledge Used in Processes Knowledge that is used for action within the processes can be thought of in terms of: Operational knowledge - the operational aspects that are required for the execution of the processes (described in Section 6.3.1) Domain knowledge - domain specific; in this case marketing knowledge required during the operation of the processes (described in Section 6.3.2). This is shown by examining the roles, rules and resources specified in the VMI processes in the previous chapter. Knowledge that is required is presented in the form of 'how to' questions for each of the activities within the processes. 75 Knowledge Created in Processes The main type of knowledge that is created within VMI processes is typically found to be 'Performance Knowledge' (described in Section 6.3.3). This is also shown by examining the roles, rules and resources that were specified in the VMI processes in the previous chapter. Knowledge that is required is presented in the form of 'how to' questions for each of the activities within the processes. It should be noted that a second type of knowledge could be created during the execution of the processes. This is knowledge found in different analysis and operations such as data mining. However, the explicit creation of this knowledge, as well as its results are not modeled in the processes. As such, this is treated as knowledge used by processes. What do knowledge requirements look like at this level of examination? It consists of the questions that must be answered in order to implement VMI. Delving deeper into specific questions can eventually lead to an implementation, however the goal of this thesis is to address the knowledge that the model brings to light. Service Level Agreement and Front-end Agreements The Service Level Agreement and Front-end Agreements are essentially contracts that can be instantiated in many different ways. Often, they are discussed in terms of actual documents. However, for the purpose of this thesis, they refer to ways of structuring or ordering knowledge and information pertaining to the VMI system and are not restricted to any particular form - how they are created can be subjective to the organization. The Front-end Agreement addresses the initial agreement, strategy and spirit of the relationship, while the Service Level Agreement specifies the finer details of its operation. These documents contain rules and parameters that are used to control and guide the execution of VMI processes. They will be explained in more detail in Section 6.5 76 6.2 Methods to Identify Knowledge This section will outline methods to extract an understanding of knowledge used in business processes from process models. First the general procedure is outlined, followed by an example from the VMI case. Section 6.4 of this chapter contains the application of the method to all the VMI processes modelled in Chapter 5. 6.2.1 General Methods for Knowledge Analyses As mentioned in section 4.4.1, three occurrences of knowledge can be derived from business processes: To extract the latter two types, the activities within the process models are examined. In Chapter 4, the process model notation shows that the activities (as depicted in Figure 29) consist of certain operations that are executed by agents (described in terms of roles) requiring resources, and governed by business rules. Embedded knowledge - from the examination of the structure of business processes. For example, sequencing and flow of activities. This was seen in the previous chapter. Knowledge created in the processes Knowledge used in the processes r Activity Name (Decomposition) operat ion 1, operat ion2. . . {agents} [resources] (rules) Figure 29: Activity 11 These relations are seen in the depiction of Wiig's 'knowledge interaction' (Figure 30) first noted in Chapter 3. The agents are the equivalent of the organizational roles, and the knowledge assets are the rules, resources and the knowledge the agents have within them of how to perform the operations. The business processes contain activities and operations. Figure 30: Wiig's Knowledge Interaction (Wiig, et al, 1997.) In the ensuing discussion, 'operations' refer to the operations noted in an activity, or, if there are no operations noted, the activity itself. Explicit Knowledge in Knowledge Assets Consider Figure 29. To perform an activity or the operations within the activity, certain resources may be used. These resources may be materials, human or machine time, energy, data and information. The rules may comprise of explicit knowledge of when to do something or what to do. The rules encapsulate conditions or procedures that constrain the execution of the activity. The source of these rules may also provide some insight. For example, they may be unwritten rules, or they may be described in procedures that implement some contract or agreement. Unwritten or implicit rules may be uncovered in the examination of an agent performing the operations in the activities, or from interviewing the agent. 78 Usually, rules reside within a particular organization. For example, rules governing when products are reserved in a warehouse after being committed to a retailer. However, in certain situations, they may span organizations. For example, rules governing what data are transferred between trading partners. These resources and rules can be linked back to Wiig's 'knowledge assets' seen in Figure 30. Tacit Knowledge in Role's Definition The agents perform the operations. Agents can be linked back to Wiig's 'organizational roles' seen in Figure 30. The role's definition may also contain information or knowledge of how precisely the operations are performed in certain conditions and how to apply the rules and use the resources appropriately. Some of this knowledge may not be readily externalized, as it may be derived from skill or experience. Difficult to externalize knowledge is tacit knowledge of how to achieve a desired outcome. Classifying Knowledge as Domain, Operational or Performance The method used to identify knowledge examines the rules, resources and roles along with the knowledge that the roles' definitions may have within them. This thesis classifies the knowledge used in the activities as 'domain knowledge' or 'operational knowledge'. Generated knowledge is classified as 'performance knowledge'. This is because knowledge generated in business processes typically refers to observations about the functioning of the activities within the business processes. These observations are used as feedback in the monitoring or improvement of the business processes. 6.2.2 A VMI Example of the Methods Classifying Knowledge in the VMI Case The VMI business processes were examined in this thesis and an understanding of their knowledge requirements was captured. This section will now show an example of how this was done. 79 First, after creating the process diagrams, an understanding of domain and operational knowledge was decided upon. The domain knowledge in VMI was found to be knowledge related to replenishment, or in more general terms, market knowledge. For example, knowledge of how to price a product, or what products should be sold in which stores. Descriptions of domain and operational knowledge pertaining to VMI can be found in the following sections 6.3.1 and 6.3.2 respectively. In this particular example, it was initially believed that domain and operational knowledge would be adequate to describe knowledge that was created. However, this was not the case for VMI. Upon closer examination, the knowledge that was created was found to be performance knowledge. This performance knowledge pertains to the maintenance and improvement of the business processes. Section 6.3.3 contains more on performance knowledge. Deriving Knowledge Requirements The following example shows how the knowledge requirements were derived from the activity called 'Sales captured electronically' (see Figure 31). ^ Sales captured ^ electronically I share data, | _ 1 capture data 1 {retailer} [sales database] (data capture rules) ^(data sharing ru les)^ Figure 31: Activity: 'Sales captured electronically' This activity, as shown in Figure 31, depicts operations, agents, resources and rules. In the description of the process in the previous chapter it was explained that the retailer (agent) performs this activity. As mentioned, informal rules followed by the agents can be derived from observation of their performance, interviews or by examination of the agent's role definition. An example of this is an 80 agent's knowledge of the flexibility of the shipper in handling expedited orders. Some shippers may officially say they would not handle expedited orders, however, a vendor agent may know otherwise. The two classes of rules in this activity pertain to both domain and operational knowledge and are manifested in the operation 'share data', which the retailer enacts. The rules specify when to share data and what data to share. The sales database is an example of a resource used in the activity. The database may provide product information, and be a physical repository for sales transactions. For example, in 'data capture rules' (see table below), application of the rules require knowledge of the domain, as product demand type may affect the frequency of data sharing, or even the manner of data sharing. Operational knowledge is also needed, as the format of the data (such as EDI specifications), and the manner of sharing (such as via email, web pages, or documents) may be prescribed in certain fashions. These particular arrangements may be necessary for accurate and timely sharing of data between the vendor and the retailer. 'Data sharing rules' can be examined in a similar way as seen in Figure 31. Table 13 shows the knowledge requirements and examples of information requirements for the activity. For clarity in the example, the source of the knowledge from the process models and the source from within the business are also shown. Note that the knowledge requirements are phrased in the form of questions. Also, the type of knowledge used (domain or operational) is not necessarily exclusive. The most relevant type was listed in the tables. For example in Table 13, 'how must the data be shared' can be considered to be operational knowledge because it considers a routine operation. However, the frequency of sharing data may be dependent on an understanding of replenishment and the products involved. This would be domain knowledge. Also in the table is performance knowledge, which is mainly derived from examining how the operations can be monitored or improved. 81 Knowledge Type Source in the Model Information Source in the Business How frequently must Domain the data be shared? (data sharing rules) fcapturjeoifor accurate., feplenl^enm. What data needsffo bel Operational (data capture Il lSi; Demand analysis of the Vendor -product: Replenishment policies ! iemand analysis of'the vendor -product, vendor's 'data Replenishment ' n j g l . u poiiies X What format should the data be captured in? Operational (data capture rules) Vendor's data needs. How isjthe data,to be Operational snared? • i f • m rules Vendor - Data analysis policies or replenishment policies i Vendor ard. Retailer What requirements must the retailer and vendor meet to share data? [How ac'cur'atetisithe ''.. t&tmfc clfuTred? Operational (data sharing rules) PerformanceM data capture *1 cperlt joffan'd/^ bv^ l l errMrepbtt? ^ possibly,(r' A X • How timely is the data Performance data capture captured? operation and/or possibly (SLA) capaoilitieslriarketi- -iPossiblyf'specified information|(e.g. in a Front-end frecjUency^e data.must agreement IbjeTslaiied). * Technological and Vendor and Retailer operational ability and -Possibly specified willingness. in a Front-end agreement ,Eir^ratef^.alys|^f J|§e ' rv^on of data cleansing*, requirements. Observation of data sharing. Service levels Howaccyrate.is.the ,| Performance datagjgring p Service levels, error data sharing? 'operation and/orr ' rates?"complaints POsSliSLA).. How necessary are the Performance Observation of the Service levels, error current practices? usefulness and rates, costs/benefits effectiveness of the activity. Possibly (SLA); Table 13: Knowledge Description of Activity: 'Sales Captured Electronically' Observation of, data i sharing. ^ * ^ : Key performance indicators and reports. Source of Rules The final aspect that can be examined from this activity is the source of the rules. It is interesting to note that although the retailer enacts the rules in the above example, the vendor is often the source of the rules. The claim for VMI states that the vendor has better knowledge of its products and the market. This knowledge is captured in the rules to be enacted by the retailer. Both the vendor and the retailer may need to agree on several aspects of the rules. For example, the vendor may have a rule pertaining to 82 how frequently the retailer sends data. This rule may originate from the vendor, however it is the retailer that uses the rule in the operation of sharing data. Certain rules may be based upon procedures, documents and specifications individually owned by the retailer and vendor, such as business plans. These rules may be 'combined' in some fashion and applied to certain operations in particular activities. It may be possible to capture these joint rules in a Service Level Agreement, or they may be agreed upon in a Front-end agreement. These two agreements are explained in greater detail in section 6.5. Sometimes these rules are not captured in documents at all, as in the case of rules that agents may follow in their understanding of the execution of operations. 6.3 Domain, Operational and Performance Knowledge 6.3.1 Domain Knowledge The VMI domain deals with replenishment of products for the retailer by the vendor. At its simplest level it consists solely of knowledge on how the processes operate. At a more sophisticated level of implementation, domain knowledge is essential to make decisions. The interaction of several different dimensions comes into play. In a simple implementation of VMI, a commodity may be sold steadily at a predictable rate, such as nails or screws. When a bin gets to a certain level it is filled back up again. With more complex market conditions, the interactions between the store, seasonality and other products may come into play. Replenishment needs may not be as easily predicted anymore. However, greater understanding of domain knowledge can be derived from the discovery of trends and rules from activities such as data mining. 83 Marketing strategy can be used as a framework to help organize thoughts concerning VMI domain knowledge. Marketing strategy consists of two aspects: Target market Marketing mix. The target market consists of the group of consumers that are sold to. The marketing mix describes the controllable ways that the needs of the target group are satisfied. This is the area of interest. A popular way to think of the marketing mix is in terms of the four Ps (Shapiro, 1996): 1. Product - the good used to satisfy the customer. 2. Place - decisions related to getting the right good to the right customer at the right time. 3. Promotion - related to telling the customer about the product 4. Price - setting the proper price for the product. Table 14 shows several aspects of interest of these four dimensions. 84 Product Physical good j Service, ? Features Quality level Accessories Place Promotion t Installation Instructions Warranty Product lines rPackaging Branding I Substitutions i ' * ' Seasonality Objectives Channel type Marketing exposure Kinds of middlemen (i.e.. shippers) Kinds of locations and stores How to handle transportation and storing Service levels Recruiting middlemen (i.e. shippers) Managing retailer Objectives Price Objectives Promotion blend Salespeople - kind j! Flexibility Level over product life cycle Salespeople - number Geographic _ L " f e . ' • -,, '"'r,-:l• termsi , Salespeople - selection Discounts Salespeople - training I [ Allowances Salespeople - motivation Advertising - targets Advert is ing-k inds of ads J Advertising - media typiTl l Advertising - copy thrust ji Advertising - prepared by.jL whpm ! Sales promotion Publicity " J Table 14: Strategy Decisions areas organized by the 4 Ps (modified from Shapiro, 1996) 6.3.2 Operational Knowledge Operational knowledge consists of how to make operational decisions within the processes. An example of this is 'how to capture data or share data?'. These decisions do not require domain knowledge, although they may be influenced by it. For example, a product may require rapid and constant sharing of data between the retailer and the vendor, because of particular product attributes. 6.3.3 Performance Knowledge It was found that the main type of knowledge that is created in the processes examined refers to performance. Performance refers to measuring the effectiveness of a role over a certain metric. These 85 measurements can be captured along the lines of certain key performance indicators or analyses that relate to performance of the trading partners and also to the general health of the relationship. Both the vendor and the retailer can be measured. Two areas where measures are useful in VMI are: Operational effectiveness. Domain or market effectiveness. The retailer can be measured for what it offers the vendor in terms of sales, data collection and sharing, or exposure to the market. The vendor also faces performance measures in the realm of operational effectiveness and effectiveness in the market place. Performance knowledge allows the comparing of actual metrics with expected metrics so that actions can be taken. Dimancescu and Dwenger describe metrics in the following: "The tangible quality of a number is attractive in a results driven world. That's why metrics is a magic word with most managers. It helps to focus improvement efforts and provide feedback, guides recognition and rewards..." (Dimancescu, 1996, p.92) Performance knowledge is used to improve and monitor processes as they operate. 6.4 Knowledge Requirements in VMI This section explores the specific knowledge requirements for VMI processes and activities. Each activity within the main VMI processes, as specified in the previous chapter, is examined and relevant examples are given. Knowledge created, in terms of performance knowledge; and knowledge used, in terms of domain of operational knowledge, is identified. PROCESS: Sales/Returns Requirements in the VMI model show that data must be collected and shared for both sales and returns. Most of the knowledge needed in these processes is operational knowledge. 86 ACTIVITY: (Sales) Consumer Purchases Goods It is fitting that this is the first activity listed, as the proper goods must be at the store to be purchased by consumers - this is, therefore, the culmination of the entire VMI system. h ., Knowledge Type Information,, How is the retail price determined? Domain Demand analysis and marketing information. How araprombtionsiapplied? Domain ,!! Demajyd analysis and marketing / I S 17J H r J i n f o r ^ o n . . ^ " . . . What factors affect sales? Performance Sales data, market environment data. How qood is the retailer at selhnq?j rferfoipla'nce'^lSalesjSata, .comparative sale's datlffrorn Table 15: (Sales) Consumer Purchases Goods - Knowledge ACTIVITY: (Sales) Sales Captured Electronically _ . Knowledge , ..-Type ... Information How frequently must the data be Domain Demand analysis of the product, shared? jy^hattaata rifels tol^caBfl^Bcl f jS9| ' O p e ^ o n l H b e ^ ^ ^ . ^ S y s i s ^ p T i e ^ ^ ^ u c t ^ n d ^ ^ B teuMWlt^hrrfnl? " * " ^ ' d a t a ^ e e d ^ What format should the data be Operational Vendor's data needs, captured in? How is the data to be shared? -,s Operational^. Retailer and.vendor. capabilities, market What requirements must the retailer Operational Technological and operational ability and and vendor meet to share data? willingness. How accurate j s the data that is : Performance . Error.' rates, analysis of overall error c a p t u @ 9 - -:' "=V r e p ^ s . J f f _ ._ How timely is the data captured? Performance Service levels. How aecurate'Iis the-data shining? . PerfdnmanctsService levl ls, "errp^rates.tcornplaints. How necessary are the current Performance Service levels, error rates, costs/benefits. practices?' '• ' ; : ' : ? : ; ^ ^ C : : 7aWe 16: (Sales) Sales Captured Electronically - Knowledge The retailer may share data as soon as a transaction is captured or it may be batched after a particular interval. Alternatively, the vendor may pull the data at particular intervals. Frequent 87 transactions may increase overheads in communication costs and complexity. However, depending on the replenishment needs of the product, this frequency may be necessary. For example, a goal may be to lower inventory at the retailer to as low as possible. Many purchases occurring at a variable rate require frequent inventory checks at the vendor to replace product as it sells. Technically, both the vendor and retailer must have systems that support proper and error free data sharing. Data must be in a readily usable form by the vendor. Special considerations for a vendor or retailer add to the complexity of any VMI system that may be extended to other supply chain partners. Interestingly, a study has shown that bar-coding data is not a determining factor in VMI effectiveness, whereas forecasting technology is (Daugherty, 1999). The complexity of installing a bar-coding system is seen as a drawback in several cases, where useful information can be acquired in other fashions. ACTIVITY: (Returns) Consumer Returns Goods L. 11 Knowledge " ~ * ~3] [ Type • \ I •>'•. sf,,;;lhformatio"n' ' - ~ " 1 How do returns relate to the vendor? Operational Quality and service guarantees. Table 17: (Returns) Consumer Returns Goods - Knowledge This is in terms of returns being sent back to the vendor, and the retailer losing sales because of returns. ACTIVITY: (Returns) Goods Examined : ^Knowledge = = j j Typje , |£ Information , How is it decided that a good is resalable or not? Operational Quality levels. Table 18: (Returns) Goods Examined - Knowledge 88 ACTIVITY: (Returns) Goods Restocked Knowledge . Type Information Are goods restocked according to plans? Operational Planogram information, product information. How frequently must the data be shared? Domain Demand analysis of the product. What data needs to be captured for Operational Demand analysis of the product, accurate replenishment? ' vendor's data needs. (What format should the data Ise capturedj Operational ^Vendor's data needs. in?jlJlvi. - . *'_ : l _ ' K '•: _ - '. How is the data to be shared? Operational Retailer and vendor capabilities, market information (e.g. frequency the data must be shared). What requirements must the retailer and .Operational , Technological and operational ability • vendor meet to share data? ' -. ' and willingness. i _ ' . . ' j How accurate is the data that is Performance Error rates, analysis of overall error captured? reports. How timely is the data captured? 'Performance 'Service levels. L " How necessary are the current Performance Service levels, error rates, practices? costs/benefits. How accurate is the data sharing? J Performance .Service levels, error rates, i • complaints. Table 19: (Returns) Goods Restocked - Knowledge Similar knowledge as in 'sales purchases being captured electronically' is necessary for '(returns) goods restocked'. This is because restocked goods mean a change in inventory levels. Goods being restocked are different from the initial stocking process. This is because the initial stocking does not necessarily reflect a change in inventory levels since the changes were captured during a receiving process. 89 P R O C E S S : Inventory Management ACTIVITY: (Retailer Inventory Update) Inventory Counts Updated Similar knowledge as in 'sales purchases being captured electronically' is necessary for 'retailer inventory updates'. This is because restocked goods mean a change in inventory levels. Knowledge . _ .-Typei.. How frequently must the data be shared? Domain W h a ^ l a t a ^ ^ e d s j ^ ^ e c^Dturejfcgr aetfaratelfe. Operational; r e p l e f e h r n f e W ^ * T ^ What format should the data be captured in? Operational Vendor's data needs. Plow-is the'ciata to%e shared? ^ ? ,:t.' Information Demand analysis. Demand analysis. „ Operatiohar Retailer/anc vendor"." What requirements must the retailer and vendor meet to share data? Operational capabilities, market i information (such asidemand Jype) . Technological and operational ability and willingness. How often does inventory need to be physically Operational counted? How are inventory,changes investigated? ;ni» _ Operational When is inventory counted? Operational \ 'Jr^XJH" *wBl8b^  jpMWBk.^  i operational capabilities Market information, stock levels, rate of sales. WhetFare^feentoS leve lsI lMld? ..^..Operational How accurate is the data that is captured? iowjtimely is theigata captured? How necessary are the current practices? ; Operational ability Market information, stock levels, rate of sales. Market'jnformation • Performance Error rates, analysis of overall error reports. P ^ S e ' Servicelievels: Performance Service levels, error rates, costs/benefits. How accurate is the,data sharing? Performance Service-levels, error rates, y 4 • § ^ f m & m P i a f r t s . ' ? 1. /_ How well does the retailer comply to inventory Performance Service levels, error rates, management rules? stock levels. Table 20: (Retailer Inventory Update) Inventory Counts Updated - Knowledge 90 ACTIVITY: (Inventory Monitoring) Inventory Examined Knowledge Why is replenishment triggered? How often does inventory need to be examined? ' Type Domain Operational When is retailer inventory examined? Operational How reliable is the replenishment Performance trigger? _ [ How accurate is the examination of Performance retail inventory? Information Demand of product. Demand of product, minimum stock levels. Demand of product, inventory levels, minimum stock levels. Service levels, overstocks, stock-Service levels, overstocks, stock-outs. Table 21: (Inventory Monitoring) Inventory Examined - Knowledge ACTIVITY: (Inventory Monitoring) Replenishment Needs Determined Knowledge What method is used to determine replenishment amounts? II Type Information Domain Market information (e.g. product demand), VMI relationship. What amounts should be replenished?! Domain Operational Performance How are replenishment amounts calculated? How accurate is the replenishment needs? __ . . . „ What data or information can be used Performance to produce better results? Table 22: (Inventory Monitoring) Replenishment Needs Determined - Knowledge Market information, inventory levels, replenishment requirements. Market information, VMI relationship; forecasting needs. Inventory levels, stock-outs, over 'stocks. Analysis of market info, inventory levels. 91 PROCESS: Purchase Order Processing ACTIVITY: Determine Ability to Replenish Knowledge __. ___ \ Type __. Information Service levels, relationships, What is allowable in terms of PO? Operational availability. What limits are there to replenishing productsj Operational j Otherdient restraints. How is ability to replenish determined? Operational Availability, service levels. How is retailer priority determined when 0 ! | inventory is short? ... ; . . . :Operational j Service levels, market info. What happens when there are not enough products available? Operational Service level. *" ' j * ~ ( F o r e c a s t s , availability,; service How is the current availability to be measured?,-Performance 1 level; . .... ~. How accurate is the vendor's ability to Forecasts, availability, inventory replenish stock to forecast? Performance levels, sales. Table 23: Determine Ability to Replenish - Knowledge ACTIVITY: Replenish what is Available . Knowledge ,| Type Information, How are orders that are not fulfilled completely handled in terms of subsequent orders? Operational ; Service levels, inventory levels. Table 24: Replenish what is Available - Knowledge Similar to the activity, 'Replenish to Forecast' this is useful to know because the ability to replenish may not be immediately possible, but according to information, may be available in an allowable period of time. ACTIVITY: Replenish to Forecast Knowledge" - ^ j - ^ ' - - ^ How much time is needed to fulfill the order? Operational Stock levels, schedules. Table 25: Replenish to Forecast - Knowledge 92 ACTIVITY: Replenish Optimally Knowledge Type How are orders that are not fulfilled completely handled in terms of subsequent orders? Operational l o w much time -is needed to!fl!iifiJI the, order? Operational Table 26: Replenish Optimally - Knowledge Information Service levels, inventory levels. Stock levels, schedules. ACTIVITY: Determine Available Substitutes Knowledge Type Information What are appropriate substitutes? Ma^uflgff luW c h o s e n ? ^ How are orders that are not fulfilled completely handled in terms of subsequent orders? Are substitute products allowed? How is substitution tracked? Domain Domain M j _ Domain 1 Domain Market info (I.e. product info). Market info (I.e. product .info i. Stock levels, market info (I.e. demand info), schedules. Relationship info, product info ; Operational Product info and attributes. How is substitution updated? How often are substitutes updated? How useful is this process? '"' Operational Operational • B i i i B i i « l | | Performance Table 27: Determine Available Substitutes - Knowledge Product info and attributes, market info Market info, product info, availability. Service level, fulfillment of retailer needs. ACTIVITY: Create Smaller Separate Orders Knowledge How practical is it to create smaller orders? .... Type.. Operational ' Operational Operational Operational How useful is this process? Performance Table 28: Create Smaller Separate Orders - Knowledge How large must an order be? How are smaller orders tracked? How are orders that are'not fulfilled completely handled, in terms' of subsequent orders? ^ * Information Schedules, relationship, delivery processing info. ! P^liveryiprocessfng info (i.e. ,'s^pping*=jeceiying). Delivery processing info. . r — n Delivery processing info, ! replenishment methods.*. j Service level, fulfillment of retailer needs. 93 ACTIVITY: Reserve Stock Knowledge Information How are goods reserved? Can goods be reservations be cancelled for other orders? ' . Table 29: Reserve Stock - Knowledge Type IF" ; Operational Warehouse data. Operational Warehouse data, service levels. PROCESS: Order Processing ACTIVITY: Preliminary Schedules Determined Knowledge _ I Type Information What schedules of the retailer must the vendor abide by? Operational Schedules. Operational Info to arrange receiving and , istdcking. Jli}^;^» What information does the retaileBneed? Schedules, service levels, What information does the vendor need? Operational delivery processing info. P S other schedules must be abided by? j Operational I Schedules."-Schedules, delivery info, How well are the schedules kept? Performance service levels. Table 30: Preliminary Schedules Determined — Knowledge Knowledge of schedules is very important. This is because as the vendor attempts to fulfill retailer needs it is restricted by arrangements with shippers and various delivery processes (e.g. picking and packing). 6.5 Service Level Agreement and Front-end Agreements Two types of agreements are discussed that cover the contract between the retailer and the vendor. These agreements embody much knowledge of the VMI relationship. The agreements are: Front-end Agreement - containing strategic information and rules. Service Level Agreement - containing operational and tactical information and rules. 94 There is no distinct requirement that says these agreements must exist in this fashion, or that they should exist at all. However, the nature of the agreement between the retailer and the vendor requires some vessel for understanding. The Front-end Agreement addresses the initial agreement, strategy and spirit of the relationship, while the Service Level Agreement specifies the finer details of its operation. CPFR, for example, contains a Front-end Agreement that governs many different strategic specifications that exist between the trading partners. The CPFR process description of the Front-end Agreement can be seen in Appendix D. 6.5.1 Front-end Agreement * The Front-end Agreement is a contract that specifies the spirit of a trading relationship and consolidates several strategic goals and is made at the initiation of the relationship. For example, joint business plans can be created by the vendor and retailer and used to establish rules in the Service Level Agreement. The outcome of the front-end agreement is to clarify the business goals of the relationship and the willingness for attaining them. For example, a goal may be to engage in VMI for certain products. This in turn may mean an examination of market strategies and the identification of capabilities. As mentioned previously, CPFR has diagrams specifying the creation of a Front-end Agreement and the creation of joint business plans (see Appendix D). There are several sources of knowledge for creating Front-end Agreements. The American Productivity and Quality Center and benchmarking clearinghouse (www.apqc.org) provides processes that can assist practitioners in identifying generic areas that need consideration (Tiwana, 2000, p.437). Appendix E contains a list of steps relevant to VMI from the American Productivity and Quality Center that can help to direct practitioners in developing their agreements and understanding their markets (Tiwana, 2000, p.439). 6.5.2 Service Level Agreement The purpose of the Service Level Agreement is to specify: 95 Tactical rules and parameters Operating rules and parameters Monitoring for performance and improvements See Appendix F for an example of several considerations that may be addressed in the Service Level Agreement. Tactical Rules and Parameters Tactical rules and parameters manifest in terms of operational changes that are required for some short term or non-strategic effect. An example of a tactical change may be the short-term collection of non-standard data for testing a change in analysis methods. Another example may be a change in shipping procedures due to a change in shippers. Tactical changes may also occur during a promotion when the vendor needs flexibility to capitalize on market conditions. In addition, tactical changes occur when exceptions arise. Exceptions are generally expensive to manage unless there are rules in place to handle them (Abramowicz, 2000, p.4). However, unanticipated exceptions, by their nature, are difficult to handle with embedded rules in processes. Rules must exist to specify how they are to be managed. Other types of exceptions may occur on a more regular basis, and can be better planned for. An example of exceptions may be the temporary closure of a store due to fire during a busy season, or it could be a failed promotional campaign. Operational Rules and Parameters The operating rules and parameters bring together the knowledge of how the system is supposed to be executed on a regular basis. They also help specify the decisions that need to be made in the processes. For example, a process may specify that transfer of data must be performed in a certain way. This would be spelled out by the Service Level Agreement. In addition, prices may be affected by certain parameters such as taxes, tariffs, or discounts. These would follow rules as specified by the Service Level Agreement as well. 96 Other factors that need to be included in the Service Level Agreement include: pricing, standing quotes, quality levels, availability, and special considerations. Monitoring for Performance and Improvements Performance monitoring measures the strategic, tactical and operational health of the trading relationship. They are placed in the Service Level Agreement as they would entail reporting and monitoring that must occur from data derived at the most detailed level, and aggregated and analysed as appropriate. Monitoring and collecting metrics would occur at an operating level and could trigger tactical or strategic responses. Monitoring can be done for service level compliance, or also for improvements that can be incorporated into the system. Hines (2000, p.346) describes a contract very similar to the Service Level Agreement as a framework agreement. The rigidity of the framework depends on the type of relationship and trust that exists between the vendor and retailer. "Clearly the type of trust has a major bearing on the nature of the agreement. The closer that the relationship is founded to a form of contractual trust (Sako, 1992), the more likely it is to be 'tight' or prescriptive in nature. A prescriptive agreement reduces supplier flexibility, and it is this flexibility which is a cornerstone for the creation of supplier benefit in a VMI relationship. There is therefore a relationship between the level of prescription of contract and the equity of benefit and it is not surprising to find that contractual trust is the dominant type in a VMI relationship based on a domination mode of inception. Conversely, the closer to a form of goodwill trust, the more obligatory (Williamson, 1986) and thus the 'looser' the contract. From the previous argument it should be apparent that this offers flexibility opportunities to the supplier, and hence the potential to increase the equity of his benefits." (Hines, 2000, p.346) It should be noted that the tightness or looseness noted above do not necessary refer to the complexity of system. For example, a complex system in a highly automated environment may contain many rules and parameters; however, the nature of the trust may still be of the 'goodwill' type. 97 7. Conclusion 7.1 Summary At the start of this thesis, the following research question was asked: "How can an understanding of business knowledge be extracted from business processes?" Throughout the thesis, this was answered using an example of knowledge in VMI processes. This was accomplished by examining the following: Aspects of Vendor Managed Inventory. Knowledge and knowledge management. Business processes and how to model them. Knowledge requirements in business processes. Process models of how VMI is implemented, compared to traditional non auto-replenishment processes. An exploration of knowledge created and used in VMI processes based on an examination of the roles, rules and resources within processes. A discussion of the knowledge that goes into agreements that support VMI. 7.2 Main Contributions The main contribution of this thesis is a method of how to extract knowledge requirements from business processes. It is hoped that this research will be helpful to individuals who need to explore a poorly defined initiative in terms of knowledge. This exploration of knowledge requirements in business processes was accomplished using the VMI example, which provides additional research into this interesting initiative. 98 7.3 Limitations Dealing with an abstraction is a double-edged sword. On one level, knowledge about an initiative is harnessed to give a consultant an understanding of what the topic is. On the other hand the abstraction is often too general to be applied readily to practical use without being extended. It would be interesting to see how the knowledge disclosed in this thesis can be used during an implementation. To accomplish this, however, a broader scope would be useful in capturing more business processes. This thesis has looked at a rather narrow view of business processes in only examining VMI. Examples extending beyond VMI would be helpful. Each business has different ways of doing things, and in this sense, several implementation cases would go far to validate and extend this work in terms of empirical research. Another limitation with this work is in the exploration of the knowledge that is created within the processes. The knowledge that was captured was all performance related. However, perhaps there are other classes of knowledge created in other business processes. Perhaps another methodology could be used to capture types of knowledge that are created other than 'performance knowledge'. Once again though, this is limited by the lack of an implementation, since related functions, such as marketing, may behave very differently in diverse organizations. 7.4 Future Research Because of the lack of research in initiatives such as Vendor Managed Inventory, there are several possible avenues of exploration. This work could be extended with more well-defined cases of implementations with a focus on knowledge and processes. Using such data points, the processes can be extended to show more specific activities and events, along with accompanying knowledge requirements. Research into the various initiatives that support the web-enabled transfer of data may also be interesting. Groups such as RosettaNet (www.rosettanet.org) and Biztalk (www.biztalk.org) are rapidly growing as they gather information on processes and data schematics that can be used for creating 99 standards to share information. These standards could be a source of several examples of data that is shared between trading partners. Perhaps a mapping of this data to processes in VMI may provide a clearer picture of its information and knowledge requirements. Work of this nature would contain more prescriptive descriptions of what VMI is, much like the work on CPFR. Workflow systems are often viewed as implementations of automated business processes involving transactions, often using computers (Darnton, 1997, p.65). For the purpose of this paper, extending into workflow would be very difficult, as there is no implementation. However, work done by groups such as the Workflow Management Coalition (www.wfmc.org) can be used to provide some insight into the creation of technical VMI implementations. More research into the use of Service Level Agreements and Front-end Agreements would also be interesting. For example, one of the original, albeit premature ideas when approaching this thesis was the use of some form of Standard General Mark-up Language, such as X M L , as a way to communicate between documents such as Service Level Agreements, and between workflow systems of vendors and buyers. The idea was to create a system where rules could easily be captured in the form of easy to use business plans and rule repositories. Research into the practicality and usefulness of such a technical system to support VMI would be interesting, as this can be used to extend and possibly automate the Service Level Agreement. Finally, the actual classes of knowledge found to be used and created by business processes can be explored in greater detail. This thesis considered operational and domain knowledge used within processes, and performance knowledge created in processes. Further research may be useful for validating or extending these classifications. 100 Bibliography Abramowicz, W. and M . E. Orolowska, eds. BIS 2000. Proceedings of the 4 International Conference on Business Information Systems, Poznan, Poland, April 2000. London, U K : Springer-Verlag. Bhulai, S. Efficient Consumer Response. BWI Paper, vrije Universiteit Amsterdam. www.cs.vu.nl/~sbhulai/ecr/index.html. December 1997. Bernus, P., J. Blazewicz, G. Schmidt and M . Shaw, ed. (1998). International Handbook on Information Systems. Germany: Springer-Verlag Berlin • Heidelberg. Canadian Transportation Logistics. "Vendor Managed Inventory: Best Practices or Best Forgotten?" Volume 100, January 1997, p. 14. CAI . BPWin Business Process Design. Computer Associates International Inc. ca.com/products/alm/bpwin/bpwin_pd_new.pdf. 2001 Cooke, J. A . " V M I : Very Mixed Impact?" Logistics Management and Distribution Report. December 1998,p.51-53. CPFR, Voluntary Interindustry Commerce Standards Association, www.cpfr.org. 2001. Darnton, G. and M . Darnton (1997). Business Process Analysis. Boston, M A : International Thomson Business Press. Daugherty, P. J., M . Myers and C. Autry. "Automatic Replenishment Programs: A n Empirical Examination." Journal Of Business Logistics, Volume 20, Issue 2, 1999, p.63-82. Davenport, T. H . and L . Prusak (1998). Working Knowledge. Boston, M A : Harvard Business School Press. Deshpande, R., ed. (2001). Using Market Knowledge. Thousand Oaks, C A : Sage Publications Inc. Drucker, P. F. (1988). "The Coming of the New Organization." In Harvard Business Review On Knowledge Management. 1998. Boston, M A : Harvard Business School Press. ECRNET.ORG. What is ECR?. www.ecmet.org/ECR/ecr. wwv_main.main?p_language=us&p_cornerid=842&p_currcomerid=l &p_full=l. April 2001. 101 Emigh, J. "Vendor Managed Inventories." Computerworld, Vol. 33, Issue 34, August 1999, p.52. Forrester, J. (1961). Industrial Dynamics. Cambridge, MA.: M.I.T. Press GEAC. Efficient Consumer Response - Improving Value Chain Management: Part 2. www.just-apparel.com/features_detail.asp?art=25. January 1999. Gloor, P. (2000). Making the e-Business Transformation. Great Britain: Springer-Verlag London Limited. Hammer, M . and J. Champy (1993). Reengineering The Corporation. New York, NY: Harper Collins Publishers. Harrington, L. H. " A Tale of Two Planners." Industry Weekly. Volume 249, Issue 7, Apr 2000, p.80-84. Hines, P. et al (2000). Value Stream Management. London, UK: Prentice Hall. Holmstrom, J. "Business Process Innovation in the Supply Chain - A Case Study of Implementing Vendor Managed Inventory." European Journal of Purchasing & Supply Management. Volume 4, 1998, p.127-131. Holsapple, C W . and K. D. Joshi. "An Investigation Of Factors That Influence The Management Of Knowledge In Organizations." Journal Of Strategic Information Systems, Issue 9, 2000, p.235-261. Hunt, V.D (1996). Process Mapping: How to Reengineer Your Business Processes. New York, NY: John Wiley & Sons, Ltd. Industry Directions Inc. and Syncra Systems Inc. (2000). The Next Wave Of Supply Chain Advantage: Collaborative Planning, Forecasting and Replenishment, p.1-16. Jamal, A. "Reduce Costs with Vendor Managed Inventory." Materials Management & Distribution. Volume 43, Issue 6, June 1998, p. 123. Jenkins, G. and R. Lancashire (1992). The Electronic Data Interchange Handbook. Etobicoke, ON: MacTop Publishing. Junnarkar, B. "Leveraging Collective Intellect By Building Organizational Capabilities." Expert Systems Applications, Volume 13, Issue 1, 1997, p.29-40. 102 Kahn, B. E and L. McAlister (1997). Grocery Revolution - The New Focus On The Customer. Reading, MA: Addison-Wesley Educational Publishers, Inc. Kao, J. (1996). Jamming: The Art And Discipline Of Business Creativity. New York, NY: Harper Collins. Katz, M . , A. Klaris and S. Caitlain. "CPFR: Moving Beyond VMI." Bobbin. Volume 41, Issue 9, May 2000, p.90-94. Keller, G. and T. Teufel (1998). SAP R/3 Process Oriented Implementation. Translated by A. Weinland. Harlow, Essex: Addison-Wesley Longman Limited. Kock, T. (1999). Learning: The Role Of Collaboration Technologies. Hershey, PA: Idea Group Publishing. Liebowitz, J., ed. (1999). Knowledge Management Handbook. Boca Raton, FL: CRC Press. Lowson, B., R. King and A. Hunter (1999). Quick Response: Managing The Supply Chain To Meet Consumer Demand. Chichester, West Sussex: John Wiley & Sons Ltd. Marchand, D. A., ed. (2000). Competing With Information. New York, NY: John Wiley & Sons, Ltd. Messmer, E. "CPFR: Buzzword or Reality." Network World. Volume 17, Issue 17, Apr 2000, p. 12. Morton, C. (1998). Beyond World Class. Basingstoke, Hampshire: MacMillan Press. Nevo, D. Developing Foundations for Knowledge Management Systems. Dissertation proposal to be presented at CAiSEOl doctoral consortium. Interlaken, Switzerland. 2001. Nonaka, I. (1991). "The Knowledge-Creating Company." In Harvard Business Review On Knowledge Management. 1998. Boston, MA: Harvard Business School Press. Nonaka, I. and H. Takeuchi (1995). The Knowledge Creating Company. New York, NY: Oxford University Press. Oxford University (1996). The Compact Oxford English Dictionary. 2nd Edition. New York, NY: Oxford University Press Inc. 103 Poirier, C. C. and S. E. Reiter (1996). Supply Chain Optimization: Building The Strongest Total Business Network. San Francisco, CA: Berrett-Koehler Publishers. Purba, S., ed. (1999). Handbook of Data Management 1999. Boca Raton, FL: CRC Press LLC. Rolstadas, A., and B. Andersen, ed. (2000). Enterprise Modeling - Improving Global Industrial Competitiveness. Boston, MA: Kluwer Academic Publishers. Ross, D. F (1995). Distribution Planning And Control. New York, NY: Chapman & Hall. Schorr, J. E. (1998). Purchasing In The 21s' Century. 2nd Edition. New York, NY: John Wiley & Sons Inc. Shapiro, S. J., W. D. Perreault Jr., E. J. McCarthy (1996). Basic Marketing: A Global Management Approach. Toronto, ON: Times Mirror Professional Publishing Ltd. Simchi-Levi, D. P. Kaminsky and E Simchi-Levy (2000). Designing And Managing The Supply Chain. Boston, MA: Irwin McGraw-Hill. Solanki, K. (2000). The Role of Business Intelligence and Electronic Commerce in Supply Chain Management. Vancouver, BC: Simon Fraser University. Steif, J. Personal Communication. Vancouver, BC. 2001. Sveiby K. E. A Knowledge-based Theory of the Firm to Guide Strategy Formulation. Paper presented at A N Z A M conference. Macquarie University, Sydney. April 2000. Tiwana, A. (2000). Knowledge Management Toolkit. Upper Saddle River, NJ: Prentice Hall PTR. United States Treasury, www.fms.treas.gov/edi/index.html. April 2000. Waller, M . , M . E. Johnson, T. Davis. "Vendor Managed Inventory In The Supply Retail Chain." Journal of Business Logistics. Volume 20, Issue 1, 1999, p.183-203. Wand, Y. Personal Communication. Vancouver, BC. 2001. Wand, Y., C. Woo. "Process Modelling." Lecture notes, University of British Columbia. 2001, p. 1-60 104 Warsing, D. P., A. E. Marucheck and N. P. Greis. Using Consumer Demand Information To Improve Supply Chain Performance For Short Life Cycle Products. Decision Science Institute 1988 Annual Meeting, Las Vegas, Nevada, November 1988. Wiig, K. M . "Knowledge Management: Where Did It Come From And Where Will It Go?" Expert Systems With Applications. Volume 13, Number 1, 1997, p. 1-14. Wiig, K. M . , R. de Hoog and R. van der Spek. "Supporting Knowledge Management: A Selection Of Methods And Techniques." Expert Systems With Applications. Volume 13, Number 1, 1997, p. 15-27. 105 Appendix A - V M I Examples Two summaries of implementations. Summary 1: Summary of SAP VMI solution from the paper 'Business process innovation in the supply chain - a case study of implementing vendor managed inventory' (Holmstrom, 1998) Supply Chain Partners • Vendor: Importer of packed goods in grocery supply chain. • Wholesaler: Wholesaler and leader of chain of retail stores. Problems Vendor • Long lead times in sourcing goods. • High variability of incoming orders. Wholesaler • High stocks. • Periodic poor service from vendors. Requirements • Low cost. • Extensible to other supply chain partners. Solution • The standard EDIFACT inventory report and a modified SAP R/3 installation. Implementation Phases Phase 1: Conceptualization and definition • Vendor determined the minimal information requirements for replenishment. • These were identified as: o Reorder point (considered fairly constant). o Minimum replenishment batch (considered fairly constant). o Free stock (needed constant updating). o Cumulative goods receipt to the wholesalers warehouse (needed constant updating). Phase 2: Pilot Implementation • A group of products with low replenishment frequency was chosen. • Replenishment was done manually. • Information sent via email to vendor. • Processed on a spreadsheet to calculate replenishment needed. • Order was placed in the information system of the chain and sent as a purchase order to the vendor. Phase 3: Full Implementation (see Figure 32) • Configuration. • Daily replenishment by vendor. 106 • Based on customizing SAP modules already installed. • Based on consignment order processing, with the difference being the vendor was only assuming responsibility for inventory management, not retaining ownership (Table 31J Transaction R/3 standard (version 2.2F) Modification for VMI solution Consignment fill up Moves stock to wholesaler Moves stock to wholesaler warehouse - is not consumption warehouse - is consumption for for vendor. vendor. Wholesaler is not invoiced by Wholesaler is invoiced by vendor. vendor. Inventory Physical inventory is entered Physical inventory transaction of adjustment manually. wholesaler stock is made based on an EDI inventory report. Table 31: Modifications of R/3 standard (Holmstrom, 1998) Operational components • Consignment reorder fill up is programmatically created based on: o Minimum replenishment quantity, o Stock level at customer, o Reorder point. • A user eyeballs orders and make adjustments of replenishment order as necessary. • The vendor checks to ensure replenishments were made at the wholesaler's side. • Data requirements at the vendor side were: o Customer specific material information record o Minimum delivery quantity for each SKU. o Promotional contracts were used to increase the minimum replenishment required for before, and sometimes for the whole duration of, a campaign. Benefits • Delivery and admin costs of all vendor products decreased. • Demand variability was reduced from 75% to 26% in the pilot phase. • Reduced safety stock by > 8 weeks at the wholesaler for problem SKUs in the key product category. • Total stock decreased by 30%. • Order/delivery time decreased from 48 to 10 hours. 107 Purchase Order W H O L E S A L E R / R E T A I L C H A I N Free Stock by INVRPT Daily EDI Order Confirmation V E N D O R Sales and Distribution info system of Vendor EDI-Invoice 2) Based on the new stock level in the wholesaler warehouse and replenishment levels defined for the wholesaler an order is generated. Replenishment Order Order Confirmation, Delivery & Invoicing Physical Inventory Transaction for Wholesaler Warehouse INVRPT 1) Based on the INVRPT message stock levels for the wholesaler warehouse! are updated in the Sales and Distribution information system of the vendor ("Physical Inventory transaction") 3) Order handler reviews the order and makes adjustments (based on sales activity information and/or vendor stock situation) - Order is confirmed (and a purchase order is generated in the wholesaler's purchasing system) - Delivery of the goods and invoicing follows standard procedure. Figure 32: Overview of system solution (Holmstrom, 1998) Summary 2: A summary of vendor managed inventory practices as written in 'Purchasing in the 21st century: a guide to state-of-the-art techniques and strategies' (Schorr, 1998, p. 147): • Service framework developed between buyer and vendor. • Buyer develops sales forecast or production schedule. • These are transmitted via EDI document 862 for retail, 830 for manufacturing. • Vendor puts together production plan. • Changes to service framework are made using EDI documents 845-865. 108 Vendor monitors usage, when inventory set low, 2-3 days inventory, vendor delivers daily what was sold. Usage sent via EDI document 852. Vendor reviews current inventory levels via EDI document 846. Vendor notifies buyer of replenishment via EDI document 855. Buyer uses this transaction for transportation planning and receiving if necessary. When ready to ship, vendor notifies with EDI document 856. Buyer receives shipment with EDI document 861. When consignment, buyer pays for goods with the EDI document 852 daily usage report plus inventory adjustments made at buyer's location. When not consignment, vendor generates EDI document 810 invoice, if needed. Payment is made using EDI document 820. 109 Appendix B - EDI Electronic Data Interchange EDI has been around for more than three decades and has roots in several parallel efforts in different industries. The railroad companies wanted to optimize document transfer between organizations and address quality problems that they were uncovering (Jenkins, 1992, p. 10). It became apparent that the problems they were encountering were not specific to rail transportation. Indeed, several other industries were looking at ways to improve document transfer and reduce errors, and turned to develop electronic systems to accomplish this. When several industry trade groups got together they would form a standard network to exchange data, which would often be run by a third party. Trade groups were not easily compatible, so in 1973 a living standard for EDI was developed to address changing needs (Jenkins, 1992, p. 12). Several industries, including: transportation, shipping, pharmaceuticals, grocery and retail, have worked both independently and together to make EDI a standard over the years. EDI started on mainframes, but the explosion of PCs and accompanying software in the 1980s enabled smaller companies to begin the practice. Ralph Notto, one of the pioneers of EDI defined it as (Jenkins, 1992, p.7): "EDI is the transmission, in a standard syntax, of unambiguous information of business or strategic significance, between computers of independent companies or organizations." Standards are important for the exchange of information and transactions. An agreed upon format is necessary to keep the EDI communications unambiguous. Electronic communication within the same company is not considered EDI even if it follows similar standards, as the participating companies need to be individual entities. EDI includes a client interface, translation software and communication ability. Originally, EDI was accomplished either through direct communication between computers or by use of electronic mailboxes on mainframes. Now EDI can also be done over the Internet using email, 110 web based products, and using technology such as X M L . EDI is practiced by creating a document in a specified format on a computer in one organization, and electronically transferring it to another computer in another organization. The document can be electronically used within the other organization to initiate another business process or a response. The source of the data for EDI can be from OCR, computerized systems (such as POS or POU) or business processes. Data is transmitted over a network of some sort, such as telephone, a value added network (VAN) or the Internet. VANS have the added advantage of providing several related services, such as translation between standards, protocols and security (Bhulai, 1997). This enables the EDI practitioner the ability to outsource some technical aspects. EDI has provided an enabling role in supply chain initiatives by creating standards, and creating efficiencies. With the cost benefits of standardised EDI, companies were willing to explore and implement initiatives that improve their business. This speeds up transference of documents and also reduces error rates. Error identification and resolution is decreased as well. Productivity also increases with the speeding up of processes that use EDI data. The US Treasury describes the benefits as (US Treasury, 2000): Reduction in data entry error rates. ( Improved cash management. Elimination of communication lag time between trading partners. Improved customer service. Expendability of the system to other functions. Within the supply chain, EDI is used for invoicing, ordering, forecasting, shipping notices and several of other documents. Examples of the document sets used in EDI are outlined in Table 32 (Schorr, 1998, p. 147). I l l Document Set # Document Set Description 810 Invoice 820 , Payment/Remittance advice 830 Planning Schedule with Release Capability 8 4 5 ~ Price Authorization Acknowledgement . . _ 1 846 Inventory Inquiry/Advice 850 - i Purchase Order 852 Product Activity Data* W&SSfct' 1 Purchase Order Acknowledgement* 856 Ship Notice/Manifest 860 Purchase Order Change 861 Receiving Advice 1862 : . Shipping Schedule.. . 865 P.O. Change Acknowledgement [§69 Order Status Inquiry 870 Order Status Report * 2 main sets used Table 32: EDI document set for VMI (Modified from original) Many supply chain initiatives rely on the transference of information in a timely and accurate way to increase efficiencies and lower costs. To date, EDI has been the primary method for that information to be transferred. 112 Appendix C - Event Driven Process Diagram to SAP Modelling Notation Name Event Driven Process Diagram Symbol SAP Event Process Chain Symbol Mapping Description Activity f Activity Name ^ (^D.e.c.orop.osition) {agents} [resources] (rules) Function ) The process describes the transformation of the entry state to the target state through a sequence of events and activities. There is no process object in EDPD, so an activity is shown. Activity (to be decomposed) r N (decomposition) i i J T ^ j , ^ . 1st even decompos tin ition / Process ^ J. \ / An activity can be decomposed to further activities, operations and events. An activity to be decomposed is signified with a '+' and the number of the first event in the decomposition. Information f Activitv Name ^ (DjecjomRoj^ on) [resources] (rules) v y Information Object Information objects are specified as data available within an activity, necessary for its execution. Roles /Act ivi ty N a m e \ {agents} I J / [Organization \ I J al Role J Organizational roles are represented as agents within the activity. Agents can be computers as well, so the organizational aspect should be specified if necessary. Table 33: Event Driven Process Diagram and SAP Modeling Notation (continued on next page) 113 Name Event Driven Process Diagram Symbol S A P Event Process Chain Symbol .Mapping Description Event Event Event Events are notable occurrences at a specific point in time in which changes to the state, or information about a state, of one or more objects occurs. The event can be thought of as occurring at the triangle. Control Flow y control flow r The temporal dependencies of events and functions. The direction of the arrow indicates this. Information Flow information flow V y y <information> • < • Describes whether something is read from, changed in, or written to a process. Or T T i i T The logical links between events and processes. And i ;<A>V '<6> J i i • The logical links between events and processes. Table 33: Event Driven Process Diagram and SAP Modeling Notation 114 Appendix D - C P F R Diagrams The diagrams in this appendix are from the website www.cpfr.org (CPFR, 2001). They are used to describe the steps required to create Front-end Agreements and joint business plans for practitioners of CPFR. For more process diagrams and IDEFO function diagrams of CPFR, see the above mentioned website. Develop CPFR Agreement & Statement i Define Service and Ordering Commitments VI Determine CPFR Goals & Objectives II Determine Resource Involvement & Commitments v n Discuss Competencies, Resources & Systems i n Determine How to Resolve CPFR Disagreements 3 VIII Define Collaboration Points & Responsible Business Functions IV Determine Review Cycle for the CPFR Agreement IX Determine Information Sharing Needs V • — Publish Front End Agreement X Figure 33: Develop Front End Agreement (CPFR) 115 Identify Corporate Identify Corporate Strategies i I Strategies -, Develop Partnership Strategy i i. Develop Business Plans Develop Category Roles, Objectives, Goals n Develop Joint Category Strategies / Tactics in Develop Business Plans Develop Item Management Profile IV Key Agree to Joint Business Plan VI Distributor Activities Either/Joint Activities Manufacturer Activities The frequency of Business Planning process will be determined within the Front End Agreement Figure 34: Create Joint Business Plan (CPFR) 116 Appendix E - American Productivity and Quality Center Steps Understand Markets and Customers a. Determine customer needs and wants i . Conduct qualitative assessments • Conduct customer interviews • Conduct focus groups ii . Conduct quantitative assessments • Develop and implement surveys iii . Predict customer purchasing behaviour b. Measure customer satisfaction i . Monitor satisfaction with products and services ii . Monitor satisfaction with complaint resolution iii . Monitor satisfaction with communication c. Monitor changes in market or customer expectations i . Determine weaknesses of product/service offerings ii . Identify new innovations that are meeting customer needs iii . Determine customer reactions to competitive offerings Develop Vision and Strategy a. Monitor the external environment i . Analyze and understand the competition ii . Identify economic trends iii . Identify political and regulatory issues iv. Assess new technology innovations v. Understand demographics vi. Identify social and cultural changes vii. Understand ecological concerns b. Define the business concept and organizational strategy i. Select relevant markets ii . Develop long-term vision iii . Formulate business unit strategy iv. Develop overall mission statement c. Design the organizational structure and relationships between organizational units d. Develop and set organizational goals Market and Sell a. Market products or services to relevant customer segments i . Develop pricing strategy ii . Develop advertising strategy iii . Develop marketing messages to communicate benefits iv. Estimate advertising resource and capital requirements v. Identify specific target customers and their needs vi. Develop sales forecast vii. Sell products and services viii. Negotiate terms b. Process customer orders i . Accept orders from customers ii . Enter orders into production and delivery process Appendix F - Service Level Agreement 117 Aspects of the Service Level Agreement Governing a VMI relationship between a vendor and buyer is a Service Level Agreement. This contract is hashed out between the partners to specify all particulars, such as responsibilities, penalties, legalities, liabilities, waivers and procedures in cases of ambiguity and dispute. It should be as legally valid as possible for liability purposes, but should also be understandable, or at least translatable, for everyday use. This contract should also be a living document to reflect the flexibility that is required in a changing business environment. The contract could be by product/store, product/store type, product/store class, buyer or by whatever level of granularity that is necessary and for whatever length of time necessary. Several factors involved in the service agreement may be related in some fashion. For instance, product availability, pricing and placement in stores may be considered incentives that are used to reward performance measures. Some considerations in designing a contract include the following: Product Pricing and Product Availability A method needs to be determined for pricing of the products and the availability of the goods by the vendor for replenishment. Data The type of data that is shared needs to be specified. For instance, POS data, seasonality data, business plans (marketing, sales, promotional), and forecasts may all be shared between vendor and buyer depending on the type of relationship that exists between them. The manner that the data is shared, the timeliness, accuracy and visibility of the trading partner data are determined and measured as well. The manner of the sharing of the data can be by EDI or some other manner of deep linking into the trading partner systems. Responsibility of upgrades to data sharing technology and terms of use of the shared data would also be of concern. Ownership Goods could be bought outright by the buyer or held on consignment. Consignment is where the vendor owns the goods until they are sold or used up by the buyer. If consignment is used, custodial ownership of the goods needs to be specified to determine who is responsible for the condition of the goods after they arrive at the buyer's site, and before they are sold. If consignment is not used, the method of transference of ownership between the vendor and retailer needs to be determined. For example, whether inventory becomes the responsibility of the buyer upon receipt of good or after payment. Purchasing Terms for payment for products should be specified. For example, Electronic Funds Transfer is often prescribed for payment. Performance measures Measures to evaluate the health of the relationship and the performance of the trading partners should be determined. Timeframes for performance evaluations, criteria for evaluation, and performance improvement plans should also be considered. These measures would be important for deciding penalties and incentives. Penalties Penalties for break of contract and terms for improvement should be unambiguous. Alternatively, poor performance may be captured and 'rewarded' with temporary easing of service level conditions. This is to attempt to meet the business plan goals, while maintaining a trusting relationship between the vendor and buyers. Incentives 118 Incentives could be developed to promote excellent compliance to performance measures. Incentives could be related to factors such as pricing and product facing. Forecasting Procedures Forecasting techniques may also be disclosed. Methods for acceptance or modification of forecasts may also be necessary if the forecasts are shared between vendor and buyer. Evaluation of forecasting techniques may be advisable at certain times. Minimum product replenishment levels may also be determined depending on the forecasting techniques or terms. A determining factor for replenishment is always the amount of inventory the vendor has to sell. In the model of VMI that is being considered, the vendor makes the forecast. However, typical CPFR allows for dual forecasting and the analysis of differences. The value of this could greatly increase the accuracy of forecasts for products with much variability of demand. Products and Replenishment Responsibilities for product replenishment should be specified. For the vendor, specifics of timeliness of order delivery, treatment of new product introductions and old product phase-outs, order fulfillment accuracy and quality should be outlined. Custom orders may be allowed in the contract. Vendors may be responsible for configuring display cases or rainbow pallets for the buyers. Rainbow pallets are pallets of product that are already arranged in some manner for display. Frequency of shipments or deliveries may also be specified or mentioned in the contract, as well as value added services such as the facilitation of rush orders and cross-docking. The retailer has responsibilities as well that can be mentioned in the contract. For example, the placing of the product in the store shelves and the treatment of store transfers of products could be outlined. 119 


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items