DEVELOPMENT, AND IMPLEMENTATION ISSUES

Pergamon 0305-0548(95)00004-6 Computers Ops Res. Vol. 23, No. 1, pp. 63 72, 1996 Copyright 1995 Elsevier Science Ltd Printed in Great Britain. All rights reserved 0305-0548/96 $9.50 + 0.00 A SMALL BUSINESS INVENTORY DSS: DESIGN, DEVELOPMENT, AND IMPLEMENTATION ISSUES Sohail S. Chaudhry,l? ~ Linda Salchenberger2 and Mehdi Beheshtian 3 ]] Department of Management, College of Commerce and Finance, Villanova University, 800 Lancaster Avenue, Villanova, PA 19085, U.S.A. 2Department of Management Science, School of Business Administration, Loyola University, Chicago, 820 North Michigan Avenue, Chicago, IL 60611, U.S.A. and 3Department of Industrial Engineering, Amir Kabir University of Technology, Tehran, Iran (Received May 1993; in revised form December 1994) Scope and Purpose The purpose of this paper is to present a framework for the development of decision support systems for small businesses which incorporate traditional operations research modelling techniques. Despite the widespread availability of information technology, there is a lack of formal methodologies which provide support to the end-user for the development of small business decision support systems. In the proposed framework, the traditional systems development life cycle concept is adapted to the unique requirements of microcomputer-based decision support systems. We present a model-based inventory management system utilizing traditional economic order quantity models which employs the proposed framework. Abstract--The availability of decision support and productivity software is providing opportunities for small businesses to develop systems which utilize operations research models to support decision-making. A framework for the development of small business decision support systems is presented and is applied to inventory management decision support system which utilizes economic order quantity models. Issues related to design, development, and implementation of small business decision support systems are discussed in detail and many aspects of the framework are illustrated using the inventory decision support system in a small business environment. INTRODUCTION Computer-based technologies which can be used to improve the effectiveness of business decisionmaking have experienced tremendous growth in the last decade. Innovations in information technology have resulted in increasing capabilities and decreasing costs of software and hardware, the development of friendly user interfaces, and common representations like spreadsheets and relational databases. Despite the accessibility of sophisticated information technology, the successful implementation of decision support systems utilizing operations research (OR) models in small businesses remains a complex and elusive issue. In this paper, we discuss small business decision support systems (SBDSS) and propose a framework for their development. We present a specific SBDSS which implements OR inventory tsohail S. Chaudhry is an Associate Professor of Operations Management and Management Science at Villanova University. He received his Ph.D from Columbia University in Industrial Engineering and Operations Research. His research interests include location theory, management and control of quality, vendor selection, and decision support systems. He has published articles in European Journal of Operational Research, International Journal c?f QualiO' and Reliability Management. Journal of the Operational Research Society, Location Science, Management Science, OMEGA, and other journals. He is currently on the Editorial Advisory Board of Computers and Operations Research and serving as an Area Editor of International Journal of Operations and Quantitative Methods. Linda M. Salchenberger is an Associate Professor of Management Science at Loyola University Chicago. She received her Ph.D from Northwestern University in Managerial Economics and Decision Sciences. Her research interests include decision support systems and applications of artificial intelligence, including neural networks and expert systems. She has published articles in Decision Sciences, Information and Management, Journal of Applied Intelligence, and other journals. I I M ehdi Beheshtian is an Associate Professor of Industrial Engineering at Amir Kabir University of Technology. He received his Ph.D from University of Texas at Austin in Operations Research and Information Systems. His research interests include expert systems, executive information systems, and decision support systems. He has published articles in Decision Sciences, Information and Management, Journal of Systems Management, and other journals. ++To whom all correspondence should be addressed. 63

64 Sohail S. Chaudhry et al. models to support inventory management and decision making. We begin by defining small business DSSs and indentifying the special needs of small businesses with respect to control systems, DSSs, and inventory management. In the next section, a framework for the design, development, and implementation of SBDSSs is proposed. We then present an inventory SBDSS developed for a small speciality grocery store. Issues related to its development are discussed, using the framework for SBDSSs which integrate OR models. Finally, we identify factors found to be critical for the successful development of the inventory SBDSS. SMALL BUSINESS DECISION SUPPORT SYSTEMS A decision support system is an interactive, computer-based system which assists decision-makers confront ill-structured problems using data analysis and modelling capabilities [1]. The three essential components of a DSS are model analysis, data management, and the user interface. DSSs differ from traditional systems in their usage since the decision-maker directs the operations of the DSS and utilizes his judgement, experience, and the results generated by interactions with the DSS to solve problems. DSSs support the storage, manipulation, and presentation of information from internal and external data bases which may be very large. OR models are frequently incorporated in the model base subsystem. We will focus on DSSs developed by end-users for applications in small businesses. An examination of the DSS literature of the past decade reveals a variety of such applications. Microcomputer-based systems which support decision-making have been successfully implemented in the areas of accounting, marketing, finance, and manufacturing [2-4]. Spreadsheets, database management systems, and financial modelling packages have been used to develop a variety of systems for decision support [2]. While the potential benefits of DSSs have been documented in the literature, there is evidence to indicate that microcomputer usage in the majority of small businesses remains limited to wordprocessing and spreadsheet applications [5]. One of the barriers to the adoption of DSSs is a reluctance by small business owners to use quantitative techniques to support managerial decisionmaking [6]. Indeed, Floyd et al. [7] note that there continues to be a lack of effective implementation of operations research and production/operations management techniques, even in large businesses. While firms which can be classified as small vary with respect to number of employees, sales revenue, type of industry, and type of ownership [8], all small firms face severe resource constraints and less focus on long-range planning, as compared to larger firms. The installation of SBDSSs must be consistent with the unique features, the competitive environment, and management style of each small business. In addition to improving bottom-line profits, effective DSSs can offer a competitive advantage by providing the small business owner with a better understanding of the organization's operation [8,9]. An effective inventory management system is essential for many types of small businesses and its installation and use can have an immediate impact on profits. Nayar [10] reports that by properly instituting a computerized inventory control system, small businesses can reduce inventory by as much as 20%. In another study, Edwards [11] discusses the benefits of a simple computer-based inventory system developed using dbase software for a small business which significantly reduced the amount of working capital tied up in inventory. Overview A FRAMEWORK FOR THE DEVELOPMENT OF SBDDSs A generalized approach to the design, development, and implementation of SBDSSs is proposed, based loosely on the systems development life cycle (SDLC) concept and rapid prototyping. Because of the unstructured nature of problems supported by DSSs, a development methodology for DSSs will differ from the traditional SDLC in several essential ways. The process itself is shorter and iterative, i.e. the stages are not strictly sequential. DSS designers have long recognized the need for departure from the traditional SDLC and recommend an iterative approach, with extensive use of prototyping [1,12]. The proposed framework requires more active user participation in all stages and employs a

Small business inventory DSS 65 Stage Tasks Project Assessment Define the problem Determine project feasibility Develop project proposal Problem Analysis Analyze decision-making process Select problem solving paradigms Select DSS development software Prototype system to determine system requirements Design Determine logical design of the system Design database Design modelbase Design the user interface Development, Testing, and Documentation Develop application Develop database Load database with test data Refine user interface Implement and test models Perform validation testing Evaluate user interface Develop documentation Implementation Identify an agent of change Provide user training Maintenance Develop maintenance plan and budget Post-implementation review Manage system modifications Fig. 1. Stages of SBDSS development. development strategy which allows for working concurrently on design and development. A fundamental assumption of the traditional SDLC methodology is that the requirements can be completely specified during the analysis phases. This does not translate well to DSS development since the user may not fully understand or be able to articulate requirements early in the life cycle. The process of requirements specification for an SBDSS is best characterized as a learning experience which takes place continuously during development. Since formal methodologies do not exist for DSS development to the same extent as for information systems, the proposed approach is based largely on experience. The phases in the proposed methodology are project assessment, problem analysis, design, development, testing, and documentation, implementation, and maintenance (see Fig. 1). We extend and adapt existing DSS development methodologies to support the special needs of end-user developed systems for small businesses. Project assessment Determining project feasibility is a critical factor for the success of the project since small businesses are often less able to take on risky projects. Projects are initiated in response to a problem or an opportunity to employ new technology. The first task in project evaluation is to carefully define the problem and to determine if the problem is appropriate for an SBDSS. The problem should be neither too trivial nor too complex. If heuristic problem-solving techniques exist, yet some amount of judgment is necessary, it is likely to be appropriate.

66 Sohail S. Chaudhry et al. SBDSS Project Proposal Problem i. Brief problem statement 2. Discussion of current operations 3. Detailed problem description 4. Detailed assessment effort Proposed System Overview of the system Objectives and scope of the system References to existing systems and relevant research Value of the proposed system Resources required for new system Projected system costs Plans i. Major phases of proposed project 2. Preliminary schedule of tasks and times 3. System deliverables 4. Personnel involved and their roles Fig. 2. SBDSS proposal. Project feasibility should be evaluated by examining project requirements, and technical, operational, and economic feasibility. The project resource requirements include the problem solving knowledge, availability of (or funding for) hardware and software, and access to the necessary personnel in the organization. Management (often the user) must be highly motivated and supportive, able to commit the necessary time, be receptive to change, have reasonable expectations about the results, and understand the objectives and scope of the problem. Technical feasibility is used to determine if the technology (hardware, software, and expertise) exists to solve the problem. The project passes the test of operational feasibility if a new system can be introduced with little disruption to current operations, can be maintained by current staff, and can be integrated with current systems. One approach to economic feasibility is to compare project costs (development and operational) with anticipated benefits. DSS benefits include intangibles like better decisions, more consistency in decision-making, more efficient decision-making, dissemination of problem solving knowledge to others in the firm, reduction of labor or material costs, better use of resources, superior product, superior service, and enhancement of the company image as a leader and innovator. When evaluating the economic feasibility of an SBDSS, it is more useful to use an approach based on value rather than cost justification, like value analysis [13], especially if the investment is small and risk is limited. In this approach, the value of the project is established, in terms of expected benefits and strategic value to the organization, and then management determines if the expected cost is acceptable. An outcome of the project assessment phase is the project proposal (see Fig. 2). It is used to provide guidelines for the progress of the project during development and becomes part of the system documentation. Problem analysis The next stage is devoted to an in-depth study of the key elements of the problem, which should provide both the developer and the user with more insight into the decision-making process. This is accomplished through a series of interviews with the decision-maker. Results are highly dependent on the interviewing skills of the developer and his or her ability to understand the problem domain.

Small business inventory DSS 67 Problems encountered include incomplete or inconsistent decision policies and decision rules which are difficult to articulate or explain and may not be well understood. Assessment of the feasibility of the problem may be necessary if the developer discovers the problem is too narrow or too broad. After an analysis of the decision-making process, the problem solving paradigms and the DSS development environment are selected. Although the decision to use a specific DSS tool is usually deferred to a later stage in large-scale systems development, it is necessary to select the systems development tool at this early stage. The analytical model chosen should be consistent with the user's level of sophistication; if the model is too complex, the user may not use or trust its results. The development environment should be selected by the developer, and existing resources should be given priority. The problem must be matched with the appropriate problem solving tool. Choices for microcomputer-based SBDSSs include programming languages (e.g. C++, Visual BASIC), 4GLs (e.g. FOCUS/PC, NOMAD 2 PC), DSS generators (e.g. IFPS/Personal), decision aids (e.g. Expert Choice) and DSS tools (e.g. spreadsheets, database management systems). For a complete analysis of decision analytic software, see [14]. Factors to consider include nature of the problem to be solved, cost, technical skills of the developer, hardware requirements, user interface, graphics capability, and level of vendor support. The next task is to develop a prototype to assist in determining more detailed system requirements. In a large scale system, the analyst attempts to understand the entire system before any development is started. For an SBDSS, the process is less rigid with prototyping beginning early in the development process. Design The first step in developing the overall logical design of the SBDSS is to construct the main menu and the menu structure. Since the SBDSS is a dynamic system, plans to incorporate changes are made during design. A modular design which will facilitate the addition of new features and modification of existing features is essentiak Object-oriented design is another option which will support future enhancements. The detailed design will focus on the design of the database, the model base, and the user interface. A high degree of user participation is required and the design is presented to the user for feedback. For the database design, a database model is selected. The model subsystem should be designed to provide the user with the ability to create, access, catalog, and integrate mathematical models easily. User interfaces should be designed to include pull-down menus and graphical user interfaces (GUIs) which will meet the needs of all potential users. The menus should present choices in a clear, consistent manner, and the format of the results should facilitate decision-making, and be consistent with the user's mental model of the system. Development, testing, and documentation During development, the application is constructed, data bases are established and implemented, the user interface is refined, and the analytical models are developed and tested. In some cases, the prototype evolves into the new system. The construction stage of the SBDSS is considerably shorter than that of a traditional information system since the tools used are typically application generators which free the programmer from specifying the "how to" of system functions. When developing large-scale information systems, programmers typically develop code using written specifications. For the SBDSS, the developer works closely with the user during the development, working together to uncover deficiencies in the system's problem-solving capabilities. The success of the system is highly dependent upon the team effort. This iterative process continues as the system is enhanced; adding more knowledge of the underlying processes. One development strategy proven to be successful is to identify a key module and develop it completely, deferring development of other modules. The rationale is that if the appropriate module is developed first, the logical structure of other modules are similar to the key module and successful development of the key module is a good indication of overall system success. The user should provide feedback on the user interface and the help screens, validate the decisions made by the system, evaluate the menu navigation logic (how to move between screens) and refine system specifications, if necessary. This task may lead to the recognition that the wrong development tool has been selected, the prototype may be "thrown away", and the design process may be

68 Sohail S. Chaudhry et al. restarted using the new tool. As drastic as this sounds, a more serious error is to proceed with the wrong development environment. While testing a large-scale information system requires specification testing, SBDSSs focus on validation to determine if the system produces the expected results and user acceptance. Results from analytical models and heuristics should be validated using historical data to check if system results are consistent with past decisions. Also, the decision-making process should be validated to determine if the system uses the right model and stated system goals are achievable. One strategy is to load a file containing test cases for each model at the beginning of the development process and continuously test, as different components of the DSS are developed. Unusual cases should be included to uncover difficulties with decision-making logic. Documentation is developed during this stage, with an emphasis on clarity of presentation. DSS documentation should consist of project proposal, input and output screens, reports, model descriptions and formulas, database schema, menu navigation diagrams, results from test cases, and source code. Implementation The development and implementation of the SBDSS must be recognized as a process of organizational change since its installation and use will have a major impact on tactical and operational decision-making. Successful implementation of computer-based systems has been linked to the use of models of organizational change [15]. Lewin's model of organizational change has formed the basis for much implementation research [16]. He identifies the three stages of unfreezing (to increase the receptivity of the organization to change), moving or following a new course of action, and refreezing (to return to a state of equilibrium). A variation of this model, proposed by Kolb and Frohman [17], identifies an individual in the organization as an agent of change who works with the users through all the stages of the process. This model is the basis for the implementation strategy we propose for an SBDSS. In a small business, since there is no formal IS department to provide on-going support, it is essential to identify an individual to act as an agent of change during system installation and to continue to provide support for the DSS. Successful implementation of a DSS has also been linked to user situational variables (user involvement, training, and experience) as observed in a recent study of the literature by Alavi and Joachimsthaler [18]. They estimated, on the basis of their meta-study (study of studies), that when users were involved in the development process and provided with the appropriate training and experience, the rate of implementation success could increase by as much as 30%. Thus, we include these as key ingredients of the development and implementation strategy. Maintenance SBDSSs support decision-making strategies which are evolving over time, as the organization changes to remain competitive. Thus, we stress the importance of providing a systems maintenance plan and a budget for the on-going maintenance costs. The design of the system, choice of development tool, and programming skills of the developer, will affect maintenance costs. If the system is developed by outside contractors, it is recommended that an individual within the organization be responsible for monitoring the system and eventually learning it well enough to perform routine maintenance. An important part of the maintenance effort is a post-implementation evaluation during which the system users and management discuss strengths and weaknesses of the DSS. As users become more sophisticated, they frequently demand more from the DSS and deficiencies with the system may be discovered. Users should report problems and requests for new features to the individual who is responsible for managing the maintenance effort. Security should be added to lock out unauthorized changes. THE INVENTORY DECISION SUPPORT SYSTEM The inventory DSS provides data management and modelling capabilities to assist users in making effective inventory management decisions. The menu-driven system consists of three subsystems; inventory tracking, decision support, and file maintenance (see Fig. 3). Various help screens are provided at each level and may be activated at the user's request.

Small business inventory DSS 69 -Inventory Management System (i) Inventory Tracking (2) Decision Support (3) File Maintenance (4) Exit 9ecision Support (i) Generate Reports (2) View Inventory Data (3) EOQ Modeling (4) Exit EOQ Special Price Known Price Increase Quantity Discount Exit Press F1 for help. Fig. 3. Menus for decision support subsystem. The DSS database consists of several major tables. The inventory table contains transaction data (receipts and depletions) for each item in inventory, the product table contains permanent data (e.g. description, cost information, ordering information) for each individual product, the vendor table contains permanent information related to each vendor, and the herb table relates herbs and symptoms. The relational format allows the appropriate associations to be maintained; e.g. products are associated with vendors and vice versa. For more details on the system, see the Appendix. DESIGN, DEVELOPMENT, AND IMPLEMENTATION ISSUES IN THE INVENTORY DSS We briefly describe issues related to the development of an inventory DSS for a small specialty grocery store, using the framework presented earlier. For each stage, we discuss some of the problems encountered, and some lessons learned. Several factors motivated the need to propose an inventory DSS. The major problem was that the existing manual inventory system no longer met the needs of the business. With over 3000 stock items and several hundred vendors, it had become difficult to manage the inventory and monitor vendor performance with the manual system due to the large volume. A dynamic, competitive business environment with fluctuating prices required a more careful analysis of ordering policies to reduce inventory costs. The addition of more sales staff made it necessary to include a subsystem which would allow any salesperson be able to duplicate the owner's knowledge about the products for sale. An analysis of the firm's operations, and interviews with the owner and staff were used to determine project feasibility. The availability of in-house technical expertise and the assurance of user support led to the conclusion that the proposed SBDSS was technically and operationally feasible. Economic analysis showed that the proposed system had a payback period of less than 2 years. More importantly, the total cost, estimated to be around $2000, was consistent with its estimated value which included both tangible and intangible benefits. A project narrative was developed and continuously updated as goals, objectives, and requirements were refined and modified.

70 Sohail S. Chaudhry et al. Problem analysis was conducted through interviews with the owner and observation of the current manual system. It was discovered that while experience and heuristics were used to develop ordering policies, results from fundamental inventory theory were not utilized, resulting in large, unnecessary holding costs. It was decided to incorporate three variations of the EOQ model in the DSS. First, one of the problems identified with the current inventory management system was poor inventory control. Items requested by customers were frequently out-of-stock, while less popular items were occupying valuable space. Items varied substantially with respect to cost; some exotic herbs are very expensive and proper ordering decisions were critical to reducing inventory holding costs. Using an EOQ model was feasible since the holding costs and the ordering costs could be easily identified, and the demand could be assumed to be relatively stable and could be determined. Secondly, the relationship between the holding and the ordering costs was not clearly understood by the owner. With the ability to catalog and display models, assumptions and the economic consequences of following specific policies could be analyzed and empirical evidence of the costs associated with different policies provided to the owner. Since the essential requirements included data management and query capabilities, the project team decided to use a database management system as the prototyping and development tool. The developer was experienced in using the tool, it was relatively inexpensive (under $300), provided the capabilities needed, and would run on existing hardware. Prototyping was used to facilitate the detailed requirements analysis and design. By presenting the owner with a series of menus, he was able to establish which functions he considered to be essential. Prospective users worked through the prototype and assisted with an appropriate menu navigation scheme as a first step in the DSS design. The ability to point and click and use pull-down menus was determined to be an essential feature for the user interface. The first step in the design of the relational database for the inventory system was to develop tables for products, vendors, and inventory transactions. Several refinements of the tables were required to establish the relationships, normalize the relationships, and relate the data items to the appropriate input and output screens. Testing was an on-going process, to establish reliability of the decision models. On-line helps and pop-up error messages were developed to assist the user and a tutorial module was included, so new or infrequent users could acquaint themselves with the system. Validation checks for appropriate input ranges and data types were included to insure the quality of the input data. Documentation included the original project proposal, menu navigation diagrams, relational tables for the data base, source code, and EOQ model descriptions. The greatest challenge proved to be the implementation of the system. There was the dual problem of replacing a manual system with a computer-based system, which required major organizational changes, and introducing the use of quantitative models, a new approach to operational decision-making. The capability which allowed the user to perform sensitivity analysis turned out to be critical in gaining user acceptance. Since there was initial resistance to a quantitative approach for determining order quantity and timing, this provided the opportunity for the owner to become aware of the potential cost reductions which could result using the quantitative models. Consequently, he became more receptive to the use of operations research techniques and developed confidence in this component of the DSS. The modelling activity itself became a source of learning for the decision-maker. A post-implementation evaluation of the system revealed that inventory costs declined by about 20% during the first year of operation. The "Known Price Increase" module of the DSS has proven to be the most useful. Because of access to timely inventory information provided by the queries and reports, the owner reports having more control and more flexibility in responding to changes in the environment. He indicated that he has learned more about managing and controlling holding costs (his greatest expense) with the SBDSS. He has requested that access to forecasting models be added to the current system. SUMMARY AND CONCLUSIONS Many important factors which contributed to the successful development and implementation of the inventory SBDSS may apply to other end-user developed DSSs as well. First, the inventory management system selected for development was a high profile application needed to meet business

Small business inventory DSS 71 needs which the current manual inventory system was incapable of supporting. Thus, priority was given to the system development and the owner was motivated to devote time and resources to the project. Secondly, a key individual was identified in the organization who championed the project and was actively involved in its design and development and continued to provide support throughout implementation and usage. Third, the changeover to this new approach to inventory management was planned and recognized as representing a major organizational change. The development methodology relied, to a great extent, on prototyping and can best be characterized as an iterative process typical of DSS methodologies. Building the system in stages, with user feedback provided continuously, contributed greatly to user acceptance of the system. In addition, the construction of this SBDSS was selected to match the user's skill level, the availability of organizational resources, and the nature of the DSS. The database management system, selected as the development tool since a large component of this system required data management and analysis, provided easy access to information for the nontechnical user. The on-line interactive query capabilities of the system simplified the use of the system and increased user understanding of the underlying models. Insights into the consequences of order decisions were developed as the user performed sensitivity analysis by revising inputs and observing the effects on outputs. This what-if analysis capability provided a comfortable learning experience for the user who was initially resistant to using quantitative models for decision-making. Flexibility was achieved through a modular structure of the system and the system can be enhanced to include more quantitative models as the need develops. Some of the resistance to the use of quantitative models by small business managers can be reduced with a decision support environment which provides easy access to models and model management and presents the opportunity to experiment with models. It is our belief that this approach will make OR tools and techniques accessible to a wider audience of users, enhancing their decision-making effectiveness. REFERENCES 1. R. H. Sprague and E. D. Carlson, Building Effective Decision Support Systems. Prentice-Hall, Englewood Cliffs, New Jersey (1982). 2. P. N. Finlay and C. J. Martin, The state of decision support systems: a review. Omega 17, 525 531 (1989). 3. D.J. Lincoln and W. B. Warberg, The role of microcomputers in small business marketing. J. Small Business Mgmt 25, 8-17 (1987). 4. L. F. Simmons and L. Poulos, DSS: the successful implementation of a mathematical programming model for strategic planning. Comput. Ops. Res. 15, 1-5 (1988). 5. J. N. D. Gupta and T. M. Harris, Decision support systems for small business. J. Syst. Mgmt 40, 37-41, 34 (1989). 6. W.L. Gordon and J. R. Key, Artificial intelligence in support of small business information needs, J. Syst. Mgmt 38, 24-28 (1987). 7. S. A. Floyd, C. F. Turner III and K. R. Davis, Model-based decision support systems: an effective implementation framework. Comput. Ops Res. 16, 481-49t (1989). 8. Y. P. Gupta, Linking small business and modern management techniques. Ind. Mgmt Data Syst. 18, 13-19 (1988). 9. W. H. DeLone, Determinants of success for computer usage in small business. MIS Q. 12, 51-61 (1988). 10. R. R. Nayar, Computerized inventory control. Small Business Rep. 13, 30 (1988). 11. W. F. Edwards, A microcomputer inventory system for the small business. J. Syst, Mgmt 38, 18-23 (1987). 12. P. G. Keen, Adaptive design for decision support systems. Data Base 12 (Fall, 1980). 13. A. Money, The quantification of decision support benefits within the context of value analysis. MIS Q. 12, 223-236 (1988), 14 D.M. Buede, Superior design features of decision analytic software. Comput. Ops Res. 19, 43-57 (1992). 15. M. A. Ginzberg, Key recurrent issues in the mis implementation process. MIS Q. 5, 47 60 (June 1981). 16. K. Lewin, Frontiers in group dynamics. Human Relations 1, 5-41 (1947). 17. D. A. Kolb and A. L. Frohman, An organization development approach to consulting. Sloan Mgmt Rev. 12, 51-65 (1970). 18. M. Alavi and E. Joachimsthaler, Revisiting DSS implementation research: a recta-analysis of the literature and suggestions for researchers. MIS Q. 95-116 (March 1992). 19. R. J. Tersine, Principles of Inventory and Materials Management, pp. 89-113. Elsevier, Amsterdam (1988). The Inventory Management SBDSS APPENDIX The inventory DSS consists of three subsystems: inventory tracking, decision support, and file maintenance. The inventory tracking system controls daily processing by updating an inventory file with information related to receipts and returns. Date of transaction, time of transaction, shipments received, daily sales, spoilage, and returned goods are used to update the inventory file. By maintaining up-to-date information on additions and deletions to inventory stock, the firm is able to control and track inventory levels and adjustment activity. CAOR Z3-1-F

72 Sohail S. Chaudhry et al. Edit Go to Exit 1 I Special Order Quantity Product ID 11245 Assumptions Demand 8000 Item cost i0.00 Order Cost 30.00 Holding Cost 0.30 Rate Discount 1.00 Order Policy Order Quantity 400 (no discount) Order Quantity 3407 (discount) Annual Costs Savings $ 1525.85 Note: If special order must be placed before regular order time, order if special order quantity exceeds: 426 Press Control F3 to see a complete list of products available. Database: PRODUCT Form: SPEOQ Table: product Field: productid Page: 1 Fig. 4. Specialpricescreen. The decision support subsystem provides on-line query and management reports in a variety of formats (see Fig. 3). The user may request information about items in inventory, vendors, current inventory levels, and special herb information. In the grocery query subsystem, the user can query the herb table by providing a symptom or group of symptoms, and a list of recommended products or herbs is produced. The third option on the Decision Support submenu allows the user to access a variety of traditional OR inventory models. Four EOQ models were selected to support the specialized needs of the store inventory system: the traditional EOQ model, the special price model, the EOQ model with all units quantity discounts, and the EOQ model with known price increases (see Fig. 4). For details of the assumptions and results of each EOQ model, see [19]. Computing safety stock was deferred, because the store is small, and the owner uses a heuristic for defining safety stock levels. In addition, the store is located in a large metropolitan area where a middleman acts as supplier for most exported goods, thus reducing lead times to about 1 week. The issue of joint order costs was also deferred. With multiple items ordered from a single supplier, the quantity discount model can be modified to determine ifa discount offered by the supplier when an order exceeds a specified dollar amount should be taken. For a thorough analysis of the optimal ordering policy with joint orders, see [19, pp. 99 100]. The user can access these models interactively, review the results of changing parameters and then may choose between exiting without saving or adding the new data to the database. The file maintenance subsystem maintains the tables and the model base. Records in the inventory table, product table, herb table, and vendor table can be added, deleted, or modified by making the appropriate menu choices.