Beers, G.

Beulens, A.

van Dorp, C.

English

van Dorp, C.A.

Beulens, A.J.M.

NARCIS 

ERP in Semi-Process: Requirements Capture for Tracking and Tracing.

AIS Electronic Library (AISeL)

Association for Information SystemsAIS Electronic Library (AISeL)AMCIS 2001 Proceedings Americas Conference on Information Systems(AMCIS)December 2001ERP in Semi-Process: Requirements Capture forTracking and TracingC. van DorpUniversity of WageningenA. BeulensUniversity of WageningenG. BeersUniversity of WageningenFollow this and additional works at: http://aisel.aisnet.org/amcis2001This material is brought to you by the Americas Conference on Information Systems (AMCIS) at AIS Electronic Library (AISeL). It has been acceptedfor inclusion in AMCIS 2001 Proceedings by an authorized administrator of AIS Electronic Library (AISeL). For more information, please contactelibrary@aisnet.org.Recommended Citationvan Dorp, C.; Beulens, A.; and Beers, G., "ERP in Semi-Process: Requirements Capture for Tracking and Tracing" (2001). AMCIS2001 Proceedings. 210.http://aisel.aisnet.org/amcis2001/2102001  Seventh Americas Conference on Information Systems 1081ERP IN SEMI-PROCESS:  REQUIREMENTS CAPTUREFOR TRACKING AND TRACINGC. A. van DorpUniversity of WageningenKees-Jan.vanDorp@users.info.wag-ur.nlA. J. M. BeulensUniversity of WageningenAdrie.Beulens@users.info.wag-ur.nlG. BeersUniversity of WageningenGeorge.Beers@users.info.wag-ur.nlAbstractTracking and tracing has got the interest of ERP vendors. Tracking and tracing is concerned with themonitoring and registering of data on goods in the supply chain and the reconstruction of product history.Incorporating tracking and tracing functionality in ERP software is of particular interest to vendors. Amongstothers, tracking and tracing enables ERP customers to optimize process performance with respect to recallmanagement and may also offer better protection against product liability. This paper focuses particularly ontracking and tracing in semi-process industry. A description is given of the functional requirements for trackingand tracing, derived from ERP customers in the Netherlands. Some reference structures are generated toextend existing ERP data models with. Surprisingly, from these structures, a design pattern emerges.Illustrative hereof is the modeling of the bill-of-lots and the bill-of-batches: analogous to the bill-of-materials.Keywords: Tracking and tracing, semi-process, requirements, reference structuresIntroduction Tracking and tracing has made a stand. Tracking registers the history of a product in the supply chain. The registration enablesbackward traceability of as-build information on components, and forward traceability of component usage in end products.Tracking data generated upstream of materials, additionally can be valuable to downstream control of processes: materialproperties registered, can be used to optimize downstream material allocation. Tracking and tracing also generates consumer trustin products. Information on production methods, applied by actors throughout the supply chain, can be put at the consumer'sdisposal. Information may also be aggregated to indicate for example participation of supply chains in certification programs suchas e.g. ISO 9002 or, food specific: Hazard Analysis of Critical Control Points (HACCP). Clearly, implementing tracking andtracing in the organization or in the supply chain has many advantages. In this paper, functional requirements for tracking andtracing are gathered from semi-process industry, for possible extension of ERP applications. Functional requirements describewhat data to process, store and distribute. The paper explains the strategies available for identifying these requirements and thestrategy prominent in the research described. Following, an overview of the requirements found is presented. Finally, conclusionsare drawn on the requirements and on design solutions generated.The Available Strategies for Requirements-Capture Selecting a strategy for requirements-determination depends on the level of contingency of the research domain. Herein,  threetypes of uncertainty are distinguished: (1) uncertainty with regard to the existence and the stability of applicable requirements,(2) uncertainty stemming from the ability of users to specify requirements, and (3) uncertainty stemming from the ability ofanalysts to elicit requirements and evaluate correctness and completeness. Consistent with Davis and Olson (1985), Bemelmans(1994) distinguishes the following strategies, (1) the waiter strategy, (2) the referential strategy, (3) the development strategy, and(4) the evolutionary strategy. If uncertainty is low and problems can be structured well, the waiter strategy is used. This strategyfocuses mainly on questioning users. The referential strategy uses an existing information system as a requirements-mirror insimilar situations (for example a reference model of an existing package). A development strategy is mostly adopted when noreference systems or designs are at hand and the problems are more difficult to structure and average user experience is little. Ifuncertainty is very high, the requirements are gathered, using an evolutionary strategy. Such strategy determines the requirementsthrough design and construction in small incremental steps (prototyping). Each strategy assumes different methods. The waiterEnterprise Systems1082 2001  Seventh Americas Conference on Information Systemsstrategy uses for example interviews and questionnaires, the referential strategy reference control designs and associated systemdesigns, the development strategy Critical Success Factors (CSF), socio-technical analyses and process-oriented methods, andthe evolutionary strategy for example prototyping and data oriented methods. Requirements-capture in the research described,used the waiter strategy, as the purpose was to extent existing, well-known, ERP reference models.Requirements-Capture: ResultsFrom empirical research in the semi-process industry, functional requirements for tracking and tracing are identified. Functionalrequirements to support tracking and tracing, include: (1) complaint management, (2) lot management, (3) materials management,(4) production management, (5) batch management and (6) recipe management. These requirements are discussed next.1. A complaint management function must enable a producer to register a product problem, following a customer complaint,and deal with the problem effectively. On calamity, the producer must be able to localize and recall the products undersuspicion. Hence, to support product tracking and tracing effectively, the function must register the complaints of customerswith a great deal of accuracy. Besides the information on the customer, such function should register information on thearticle number and the batch number to make backward traceability of products possible. When a particular problem occurs,the problem is stored in a database, in relation to the complaint of the customer. The true cause of the problem must bedetermined and the customer be offered a solution. This solution may also be stored in relation to the complaint. Such solutionhowever, may well exist in offering the customer a replacement product. Focus on forward traceability of outgoing productswith defects, is enabled by registration of batch number and/ or origin on the level of individual order-lines within a sales-order. Customers, from who the sales-orders comprise of order-lines containing products derived from the problem-generatingproduct-batch, are then informed effectively.2. The management of lots takes place in a central storage facility or in a warehouse. Lot management is required, as lots maybe split up into multiple smaller lots and/ or be joined together in fewer bigger lots.  Splitting of a lot into sub-lots may forexample take place given a situation in which a number of product-boxes have become damaged. The lot is then no longerof uniform composition. A number of boxes are distinct from the others. In that case, the lot is split-up into two other lots:a lot with undamaged boxes and a lot with damaged boxes. The joining of lots to form bigger lots, may occur when lotsstemming from different suppliers are of similar quality. Anyhow, a lot management function must provide that theregistering of data for initial lots will also take place for the split or mixed lots. To guarantee full traceability of all lots, a bill-of-lots must be maintained. A bill-of-lots can be designed analogous to the Bill-Of-Materials: BOM (Figure 1). A bill-of-lotsregisters the relation between sub-ordinate and super-ordinate lots, to enable retrieval of historic data on all lots. The bill-of-lots is depicted in figure 2A.3. Material management organizes the logistics management of raw materials and components in order to optimize productionefficiency. The swift availability of materials to production depends on the presence, the location and the reservation ofmaterials. With respect to the presence: lot tracking presupposes adequate organization of lot-identification. With respect tothe location: materials may be in stock, rest at a production station (operations unit) or be in transit between successiveproduction stations. With respect to the reservation of materials: lots are kept in reserve when assigned (allocated) to aproduction order. Lot-reservations however must be tracked as materials allocation may change as a result of e.g. customerpriority orders (changing the sequence in which production orders are executed and the assignments of lots). Clearly, inmanaging these material flows, lot tracking from inbound logistics to production must be supported.4. In production, specific data on operations must be registered and related to the batches processed. Different operations' datamust be linked to a batch, important are: batch numbers, start en finish time per batch, the recipe applied, actual processvariables and preset norms, the actual capacity units applied in production, personnel that worked on the batch, theregistration of quality measurements or samples and additional process operations on the batch and/ or any corrective actions,taken on exception. In many production situations, operations are performed on multiple sub-ordinate batches. The batchesare then joined together in a (final) production step. If however the registered data of these batches are only linked to the finalproduction batch, detail will be lost and data is generalized over the sub-ordinate batches. This is not desirable, as it is thenno longer possible to determine the cause of a particular problem.  Hence, data stemming from operations on sub-ordinatebatches must be registered on that batch level, while maintaining the possibility of linking sub-ordinate and super-ordinatebatches for production history reconstruction. To register data on all operations performed on batches in production, a bill-of-operations must be maintained on batch level. 5. Batch management deals with registration of the splitting and mixing of batches in production. A production batch may bedivided into two or more batches because, for example, processing is performed using machines with less capacity. In turnhowever, batches may undergo, together with another batch of raw materials, another production step on a machine with morecapacity. When more machines are used to perform the operation, batches are split. When fewer machines are used, batchesVan Dorp et al./ERP in Semi-Process2001  Seventh Americas Conference on Information Systems 1083Item Bill of MaterialRelationparentcomponent (A) Bill-of-materials(Source: adapted from de Heij, 1996, p. 170)Structure Partsub-ordinatesuper-ordinate(B) Bill-of-materials and its keys  (Source: adapted fromScheer, 1998, p. 101)PNOHPNO, LPNOparentcomponent parentcomponent sub-ordinatesuper-ordinatesub-ordinatesuper-ordinateFigure 1.  Bill-of-Materials (BOM)Lot Structure Lotsub-ordinatesuper-ordinateLNOHLNO, LLNO(A) Bill-of-lots and its keysBatchStructure Batchsub-ordinatesuper-ordinateBNOHBNO, LBNO(B) Bill-of-batches and its keyssub-ordinatesuper-ordinatesub-ordinatesuper-ordinatesub-ordinatesuper-ordinatesub-ordinatesuper-ordinateFigure 2.  BOM Design Analogyare pooled. In order to guarantee full traceability of batches in production, a bill-of-batches must be maintained. The designstructure of the bill-of-batches (Figure 2B) resembles that of the BOM (Figure 1) 6. To optimize the allocation of lots to production, recipe management uses different raw material properties. In allocating lots,to produce a certain amount of end products, recipe management requires data on the quantity of raw materials as well ason the quality of raw materials. Particularly with food products, the quality of raw materials is important. For example, sugarlevel is an important quality aspect of many end products in food. The quality of such end products strongly depends on thesugar level originally present in material lots and any quantitative (corrective) lot-action undertaken on allocation. Recipeoptimization particularly seeks to optimize lot allocation of this type. Lot allocation can be differentiated in time: lotallocation on tactical level (mid-term quality optimization: i.e. weeks or months) and lot allocation on operational level (short-term quality optimization: i.e. day-to-day operations). Organizations with a firmly developed quality management functionwill store the larger part of quality characteristics on lots in a LIMS (Laboratory Information Management System). For suchorganizations, ERP usually doesn't posses enough functionality.ConclusionTracking and tracing has the attention of ERP vendors. The  question on tracking and tracing which was to be answered in thispaper: what functional requirements can be captured to support tracking and tracing in the semi-process industry? The objectiveof research was to generate a (natural language) overview of the functional requirements and to generate some design solutions.This objective has been reached with success. The paper has described the functional requirements captured for tracking andtracing in semi-process industry. The research identified six requirement-areas: complaint management, lot management, materialsmanagement, production management, batch management and recipe management. Further, the requirements captured haveenabled the generation of design solutions with which existing reference data models of ERP packages can be extended. TypicalEntity Relationship Models (ERM) were presented in this paper as reference structures. The reference structures meant are: theERM of the bill-of-lots and the ERM of the bill-of-batches. The reference structures provide a valuable aid in the swiftincorporation of (basic) tracking and tracing functionality in ERP systems. Hence, also from viewpoint of elegance, thesereference structures may be appealing to many different ERP vendors in the field.ReferencesBemelmans, T.M.A. Bestuurlijke informatievoorziening en automatisering, Kluwer Bedrijfswetenschappen, zesde herziene druk,Deventer, 1994 (Dutch title).Davis and Olson. Management information systems, McGraw-Hill, Inc. Sec. Ed. NY, 1985.Heij, J.C.J., de. Assessment of business information systems by data structures, Kluwer Bedrijfsinformatie, Deventer, 1996. Scheer, A. -W. Business process engineering: Reference models for industrial enterprises, Springer-Verlag Berlin, Heidelberg,Germany, 1998.

ERP in Semi-Process: Requirements Capture for Tracking and Tracing

https://aisel.aisnet.org/cgi/viewcontent.cgi?article=1649&amp;context=amcis2001

ERP in Semi-Process: Requirements Capture for Tracking and Tracing

Abstract

Similar works

Full text

Available Versions

NARCIS

AIS Electronic Library (AISeL)