Guidelines for Implementing Computerized Logistics Management Information Systems (LMIS) Second Edition

Publication date: 2006

GUIDELINES FOR IMPLEMENTING COMPUTERIZED LOGISTICS MANAGEMENT INFORMATION SYSTEMS (LMIS) SECOND EDITION July 2006 This publication was produced for review by the United States Agency for International Development. It was prepared by the DELIVER project. GUIDELINES FOR IMPLEMENTING COMPUTERIZED LOGISTICS MANAGEMENT INFORMATION SYSTEMS (LMIS) SECOND EDITION The author’s views expressed in this publication do not necessarily reflect the views of the United States Agency for International Development or the United States Government. DELIVER DELIVER, a six-year worldwide technical assistance support contract, is funded by the U.S. Agency for International Development (USAID). Implemented by John Snow, Inc. (JSI), (contract no. HRN-C-00-00-00010-00), and subcontractors (Manoff Group, Program for Appropriate Technology in Health [PATH], and Crown Agents Consultancy, Inc.). DELIVER strengthens the supply chains of health and family planning programs in developing countries to ensure the availability of critical health products for customers. DELIVER also provides technical management of USAID’s central contraceptive management information system. Recommended Citation DELIVER. 2006. Guidelines for Implementing Computerized Logistics Management Information Systems (LMIS). Second Edition. Arlington, Va.: DELIVER, for the U.S. Agency for International Development. DELIVER John Snow, Inc. 1616 North Fort Myer Drive, 11th Floor Arlington, VA 22209 USA Phone: 703-528-7474 Fax: 703-528-7480 Email: Internet: CONTENTS iii CONTENTS ACkNOwLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v PURPOSE OF ThESE GUIDELINES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 What Is a Computerized LMIS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Guidelines Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 RECOMMENDED COMPONENTS OF A COMPUTERIZED LMIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Recommended Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Recommended Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Recommended Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Recommended Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS . . . . . . . . . . . . . . . . . . . . . 9 Need for a Development and Implementation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Overview of the Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Roles and Responsibilities of Process Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Analyzing User Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Designing the LMIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Designing the LMIS for Multiple Distribution Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Developing the LMIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Testing the LMIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Documenting the LMIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Deploying the LMIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Training LMIS Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Modifying the LMIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 DEVELOPMENT OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Buying Packaged Off-the-Shelf Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Buying the Services of an IT Consultant or Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 BUYING ThE LMIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Communicating Your Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Preparation for Competitive Bidding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Process of Evaluating Offers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Deliverable Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 COMPUTERIZED LMIS OPERATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Placing the Computerized LMIS within the Central Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Managing Computerized LMIS Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Providing Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 1. Lessons Learned in Implementing a Computerized LMIS (June 2002) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2. Recommended LMIS Reports and Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3. LMIS Development Process Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4. User’s Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 5. Technical Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 6. Training Curriculum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 TABLES 1. Recommended LMIS Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Basic Calculated Data Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 iv GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION 3. Recommended Computerized LMIS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Recommended LMIS Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Recommended LMIS Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Computerized LMIS Development Roles and Responsibilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Use Case Extensions and Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. LMIS Database Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Software Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Deployment Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. Two-Pronged Training Method for a Computerized LMIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. Data Items and Reports in a Defect and Enhancement Tracking Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13. Types of Severity of Software Defects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 14. Checklist of Needs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 15. Example Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 16. Example Deliverable and Payment Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 17. Example Deliverable Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 18. Advantages and Disadvantages of Location of the Computerized LMIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 FIGURES 1. Distributed Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2. Central Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3. Central Online Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 ACkNOwLEDGMENTS v ACkNOwLEDGMENTS Edward Wilson, Ashraf Islam, and Mimi Whitehouse updated these guidelines in 2006. Leslie Rock was the primary author of the original guidelines (2003). The first version benefited from contribu- tions by Kip Eckroad, Ashraf Islam, Karen Ampeh, Larry Bailey, and Edward Wilson. The following people also reviewed and contributed ideas to the original guidelines’ section on computerized LMIS development and implementation: Lisa Blankenship, Jeff Leiner, Gideon Nzoka, John Zingeni, Mercy Maina, Moses Muwonge, Kim Peacock, and Laurie Lyons. Barbara Felling, Bill Felling, and Edward Wilson reviewed and commented on draft versions of the original guidelines. vi GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION PURPOSE OF ThESE GUIDELINES vii PURPOSE OF ThESE GUIDELINES These guidelines are intended for program managers who understand how logistics systems operate and who are planning to computerize all or part of their logistics management information systems. The creation of a computerized system—any computerized system—is a process and not an event. This guide should provide program managers with enough information to understand the process of creating a computerized LMIS; it is not, however, intended to make a program manager an information technology (IT) specialist or a business analyst. The authors suggest that, whenever possible, the program manager work with a business analyst who has experience in successfully managing the development of computerized information systems. viii GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION INTRODUCTION 1 INTRODUCTION what Is a Computerized LMIS? A logistics management information system (LMIS) collects, processes, and reports logistics data. A well-functioning LMIS provides decision makers throughout a supply chain with accurate, timely, and appropriate data. The LMIS can be manual (paper based), partly computerized, or entirely computerized. In a computerized LMIS, computers take the place of humans in aggregating logistics data—performing calculations and producing reports and graphs for analysis. A computerized LMIS provides several important benefits over a manual LMIS: n No mathematical errors. Unlike their human counterparts, computers never make mathematical errors. Human LMIS operators may make calculation errors that cause them to report inaccurate movement of stock, stock on hand, and rates of consumption, which may lead to forecasts and procurement plans that are wildly off base. A well-designed computerized LMIS includes methods for the computer to validate manual calculations submitted on LMIS reports. n Rapid aggregations and calculations. Not only do computers calculate and aggregate logistics data with 100 percent accuracy, but they also perform the calculations and aggregations rapidly. Rapid processing means that logistics information is available to managers and decision makers in a timelier manner. n Rapid production of reports and graphs. Computers can also produce reports and graphs on the spot to meet the information needs of logistics managers and decision makers. Graphs, in particular, provide valuable, at-a-glance information to high-level managers who do not have time to peruse reams of LMIS reports. At the same time, there are disadvantages associated with a computerized LMIS: n Dependence on design. Even more than the logistics systems it serves, a computerized LMIS relies on a good design. A design that is rushed or poorly thought out can ruin a computerized LMIS. A poor design may not be immediately visible to logistics managers, and it may make the LMIS awkward to use or, worse, cause the LMIS to provide wrong information. n Dependence on technology. A computerized LMIS needs more than a steady supply of pens and paper to stay in operation; it needs computer hardware, printers, data backup mechanisms, and reliable electricity. All these things cost money, which may reduce the feasibility of a computerized LMIS in many public health organizations. n Dependence on technicians. To keep the software in good working order, successful computer- ized LMISs rely not only on hardware but also on regular support from computer techni- cians. Logistics managers generally cannot learn how to provide this support by participating in a short course. Without locally available technical support, a computerized LMIS is likely to become unusable. It is important to consider the advantages as well as the disadvantages when deciding whether to introduce a computerized LMIS. � GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Guidelines Overview These guidelines cover several key topics related to a computerized LMIS in the following chapters and appendices. n Recommended Components of a Computerized LMIS refers to recommended LMIS data, calculated data items, functions, reports, and graphs. Together, these components represent the basic elements of a well-designed computerized LMIS. n Development and Implementation of a Computerized LMIS outlines a process that encom- passes a number of essential activities, including analysis of information needs, LMIS design, software testing, and user training. Without a defined development and implementation process, a computerized LMIS project runs the risk of failure. A computerized LMIS at multiple levels of a distribution system is also addressed in this chapter. To be most effective, a computerized LMIS at multiple distribution levels requires an electronic exchange of LMIS data among levels. Several options for configuring a computerized LMIS to enable electronic data exchange are discussed and evaluated. n Development Options briefly describes the three options for developing a computerized LMIS: using in-house developers, buying off-the-shelf software, and buying the services of an IT consultant or organization. n Buying the LMIS outlines the steps needed when buying outside services to computerize the LMIS. This includes preparation necessary for competitive bidding, a process for evaluating offers, and deliverable schedules. n Computerized LMIS Operations describes the activities required for computerized LMIS operations after the LMIS has been implemented. LMIS operations include routine data management as well as technical support. This chapter also addresses the placement of a computerized LMIS in an organization’s central office and weighs the advantages and disad- vantages of several options. n Appendix 1 presents lessons learned from computerized LMISs that were developed and implemented by John Snow, Inc.’s (JSI) Family Planning Logistics Management (FPLM) project in five countries: Bangladesh, Jordan, Kenya, Nepal, and the Philippines. The lessons are organized into three areas: organizational context, mechanisms and resources for software maintenance and modification, and utilization of LMIS data for decision making. n Appendix 2 displays template reports and graphs for a computerized LMIS. n Appendix 3 includes a number of template documents for use during the process of developing and implementing a computerized LMIS. Readers are free to use these documents as models. n Appendix 4 provides a sample outline for developing a user’s guide for a computerized LMIS. n Appendix 5 presents an outline for preparing a technical manual for a computerized LMIS system. n Appendix 6 outlines a curriculum for training users of the system. RECOMMENDED COMPONENTS OF A COMPUTERIZED LMIS 3 RECOMMENDED COMPONENTS OF A COMPUTERIZED LMIS A computerized LMIS contains data that describe the logistics system and data that track the movement of products through that system. In most systems, the descriptive data are provided by system managers and the information on product movement comes from periodic reports prepared by the personnel in the facilities who manage the products. Using these data, the computerized LMIS calculates essential stock status indicators and provides information in the form of reports and graphs to decision makers to assist with the monitoring of logistics system performance and the planning of future product and logistics system requirements. Recommended Data In any computerized LMIS, there are two kinds of data: data that describe the logistics system and data that describe the movement of products through that system. Descriptive data will include, at a minimum, information on facilities, desired inventory levels, number of reporting periods used to calculate average monthly consumption, and products. Other data may be included as needed (e.g., unit of measure, language). Data describing the movement of products through the system will include reporting periodicity and summary logistics data by facility for each period. For any logistics system, there are three essential LMIS data items: (1) quantity of stock on hand, (2) quantity of stock consumed (dispensed to users), and (3) losses and adjustments. Other items may be added depending on the needs of the users. Table 1 lists recommended data groups and items. Table 1: Recommended LMIS Data Data Group Data Items Logistics system n Reporting/delivery period (monthly, quarterly, or other) n Number of periods to use in calculating average monthly consumption n Unit of measure (English or metric) Facilities n Facility name n Facility address n Contact person n Facility type n Supplying facility n Distribution role (warehouse or service delivery point) n Distribution level n Active/inactive Facility types n Facility type name n Maximum and minimum months of stock Products n Product name n Active/inactive n Product category n Indicator/not indicator n Dispensing unit Summary logistics n Report name n Stock on hand reports n Reporting period n Issues/quantity dispensed to users n Facility reporting n Receipts n Opening balance (optional) n Losses and adjustments 4 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Calculated Data Items Calculating data items is an important function of a computerized LMIS, perhaps the most important function. Calculated data items appear on reports and graphs to facilitate decision making and are used as a means of validating data entry. Stock on hand, available months of stock, and average monthly consumption are the most commonly calculated items. In determining the calculated data items needed, the designer of a computerized LMIS has to answer the following questions: What calculated data items do I need? Where are they used? How do I calculate them? How long do I keep the results? The calculated data items needed will be determined by the reports, graphs, and software checks that the users specify. Table 2 lists the basic required items. Table �: Basic Calculated Data Items Average monthly consumption For each facility and product, calculate average monthly consumption on the basis of the quantities dispensed to users in several consumption reports over a period of time . The number of reports to use in the calculation is generally included as a system parameter . Months of stock on hand For each facility and product, divide the reported (or calculated) stock on hand at the end of a given period by the calculated average monthly consumption . Quantities to resupply For each facility and product for a given period, multiply the calculated average monthly consumption by the maximum stock level and subtract the reported stock on hand . Reporting rates For each reporting period, calculate the percentage of active facilities that have submitted reports . Calculated data items can be stored in the database of a computerized LMIS. However, it is generally preferable not to store calculated data unless the responsiveness of the computerized LMIS is compromised by the time required to do the calculations. Calculated data items depend on the values of their component data items and are subject to change whenever the values of the component data items change. It is best to perform the calculations, as needed, for display on a computer screen or in reports. One exception to this rule is the storage of calculated data that are used to validate logistics data reported by facilities. If the software needs to check that logistics managers at a facility are performing the calculations correctly, it may be desirable to store a computer-generated calculation to facilitate com- parison with the reported values during data entry. Recommended Functions Table 3 lists the recommended functions that a computerized LMIS should carry out. RECOMMENDED COMPONENTS OF A COMPUTERIZED LMIS 5 Table 3: Recommended Computerized LMIS Functions Function Description Manage facilities Enables users to add, edit, and inactivate facilities in the logistics system . Manage products Enables users to add, edit and inactivate products in the logistics system . Manage other Enables users to add, edit, and inactivate other descriptive data used by the system. descriptive data Manage logistics data Enables users to add, edit and delete individual summary logistics reports reported by each facility submitted by facilities . on a scheduled basis Print reports and graphs Enables users to print reports and graphs both to the screen and a printer Export data Enables users to export data in at least some fixed formats for analysis outside of the computerized LMIS . Back up and restore Enables users to back up and restore data from the computerized LMIS . system data Archive system data Enables users to back up data for a period and then delete that data from the computerized LMIS . Manage users Enables an administrator to create, update, and inactivate users and assign and permissions permissions to and revoke permissions from those users . Recommended Reports Reports are the main outputs of a computerized LMIS. Logistics managers use them for evidence-based decision making, and high-level managers may rely on them to implement policies affecting the national supply chain. But, the process of implementing a computerized LMIS often focuses on data entry operations—in other words, how to get data into the computer rather than how to get data out of it. An approach to LMIS implementation that focuses on reports as well as data entry stands a better chance of meeting the needs of higher-level decision makers. (A two-pronged approach to training both data entry operators and users of LMIS data is discussed in the Training LMIS Users section of the chapter on Development and Implementation of a Computerized LMIS.) Reports are designed to answer the following key questions about the stock status of a particular facility or product and about the overall performance of the logistics system: n What is the national stock status for a particular product? n What is the stock status of a particular facility? n How much of a particular product is distributed to each facility? n How much of a particular product should be resupplied to a facility? n What is the status of reporting for a particular period? n Are there any errors in reporting by facilities? � GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION n Are there any errors in data entry? n Are any facilities not stocked according to plan—i.e., overstocked, understocked, or stocked out? n Are there any unusual patterns of losses or adjustments for a particular product or facility? Table 4 describes recommended LMIS reports. See appendix 2 for samples of recommended reports. Table 4: Recommended LMIS Reports Report Description Quantity to supply or quantity Lists the quantities to resupply a single facility for all the products that the requested by facility facility is authorized to manage . Managers may use this to issue instruc- tions to a warehouse to pack and ship items to a facility . Stock status by distribution level Summarizes the stock status for one or more selected products at each distribution level in the logistics system . This report answers the questions— what is the national stock status for a particular product? and, what is the stock status at a particular distribution level for a particular product? Supply status by facility Lists the stock status of all products for each facility in the logistics system . Logistics managers may use this report to determine whether a facility is stocked according to plan . Supply status by product Shows the status of a particular product at all facilities in the logistics system . Logistics personnel may give this report to program managers to monitor the status of one or more products used by their program . Consumption averages by product Shows the average monthly consumption for one or more products for a period of time . For each facility and product, this report shows calculated average monthly consumption based on several consumption reports over a period of time . Distribution discrepancies Identifies potential errors in reporting by facilities . when the reported issues from a supplying facility do not match the sum of receipts for the facilities it supplies, the report flags those records for investigation . Data entry errors Notes potential data entry errors . This report flags facility reports in which one or more columns contain a math error that caused the computer to generate an adjustment, allowing the software operators to first validate their data entry before contacting the facility to resolve the error . Non-reporting facilities Identifies facilities that have not submitted reports for a selected reporting period . Software operators or managers may view this report frequently during the reporting period to contact facilities whose reports have not arrived . This report may also be useful in forecasting future needs based on logistics data; forecast quantities can be adjusted in cases where data are from fewer than 100 percent of facilities . Stock imbalances Indicates imbalances in the supply status at every facility in the distribution system: overstocks, understocks, and stockouts . Managers can use this report to identify facilities that are not stocked according to plan and take action to correct the imbalances . Adjustments summary Summarizes adjustments by product and by adjustment type . Logistics managers may view this report to identify any unusual adjustments for a particular product or by a particular facility . RECOMMENDED COMPONENTS OF A COMPUTERIZED LMIS 7 Recommended Graphs Graphs can convey essential information on logistics system performance in a quickly understood visual format. This format is particularly suited to high-level decision makers who do not have time to analyze tabular reports. Table 5 lists recommended graphs for a computerized LMIS. See appendix 2 for sample graphs. Table 5: Recommended LMIS Graphs Graph Description Dispensed to users Displays quantities of a selected product dispensed to users over a selected period of time . This graph can be displayed as either a line or bar graph showing quantities dispensed over time . Stock status For a selected product, displays percentage of facilities that are stocked accord- ing to plan over a selected period of time . May also include percentage of facilities stocked out or overstocked . This graph is best displayed as a stacked bar graph in which each type of status (within plan, stocked out, and overstocked) is a compo- nent of the bar . It can be further refined by setting the height of each bar to the reporting rate percentage during that period . Average stock levels Displays the average stock level of a selected product over a selected period of time . This graph can be displayed as a line or bar graph showing average stock level expressed as number of months of stock . � GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS 9 DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS Need for a Development and Implementation Process A defined development and implementation process is essential to the success of any computerized LMIS. It is essential for three primary reasons: (1) communication, (2) quality assurance, and (3) learning. n Communication. Computerized LMIS implementation requires the active participation of many people—sponsors, end users, developers, testers, and product managers. A clearly under- stood process facilitates communication among these participants and is especially important when participants are geographically dispersed. n Quality assurance. Implementing a computerized LMIS is a complex task and prone to errors. The later these errors are discovered, the more costly they are to fix. A process that includes reviews of outputs at every stage of the project can reduce costs and improve software quality by early detecting and correcting of errors. n Learning. The most difficult aspect of computerized LMIS development is determining what the software should do. Typically, this learning process spans the entire life of the project. A well-documented process allows project participants to incrementally adapt the software development and implementation to best meet users’ needs and objectives. Overview of the Process The widely recognized need for software implementation processes has spawned hundreds of pre- packaged methodologies during the past 30 years. A brief summary of these methodologies follows: Waterfall model. The development process begins with requirement analysis and then flows through other phases of development: design, implementation, testing, integration and maintenance. The process is characterized by distinct phases with milestones and deliverables for each phase. It is often criticized as inflexible for adapting to the real world environment in which full requirements may not be known at the beginning. This methodology gained popularity in the 1970s. Top-down model. This development process attempts to achieve complete understanding of the application before beginning actual coding. This approach gained popularity in the 1970s. Bottom-up model. The emphasis here is on development by components. Detailed specifications are developed for individual components, and development can begin before all the components of the system are fully understood. This approach often leads to frequent recoding of components until they are fit into a coherent whole. Object-oriented programming of the 1980s made this approach popular. 10 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Prototyping model. After initial requirements collection, a prototype is prepared for user feedback. Incorporating the first round of feedback, the programmers build a second prototype. This cycle continues until a finished product is achieved. Agile software development. This approach focuses on achieving smaller deliverables within a compressed timeframe—for example, weekly—with frequent communication within the team and with users. This methodology gained popularity in the mid-1990s. Extreme programming. Programmers pair with each other and develop in incremental and iterative builds in a way that fine-tunes the code and testing methods along the way. It keeps the customer (or users) very closely involved and ensures that customer feedback goes into each iterative build. Extreme programming is the most popular of several agile software development methodologies. This methodology has gained popularity since 1999. Iterative and incremental development. Programmers using this process develop software in an incremental and iterative approach. Each iteration incorporates an additional set of features but is in a stand-alone, deliverable state. The customer is encouraged to begin using the system. Developers incorporate the learning and user feedback from the previous iteration to improve the next iteration and make design modifications as needed. The finished product is achieved after a couple of iterations. This is a derivative of extreme programming. This methodology gained popularity in early 2000. While the above methodologies vary greatly in their approaches and techniques, they generally include the following basic activities: n gathering user needs n analyzing user needs n designing a software solution n building the solution (or finding a packaged solution) n testing the software n writing reference materials n deploying the software n training users. The development process starts as soon as the need for a new or improved information system has been identified. The existing information system may be manual, computerized, or a combination of both. And the need for a new or improved system may be identified by the user, an outside consultant, or a technical assistance provider who later participates in the development or implementation of the software. Regardless of the type of existing information system and the impetus for considering a new or improved system, the user must be involved from the start and continue throughout the process. This chapter describes a software implementation process that encompasses the activities listed above and that can be used to implement a computerized LMIS. It includes justification for completing each activity and a brief description of the activity. Appendix 3 provides sample documents that support each activity. DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS 11 Roles and Responsibilities of Process Participants The process of developing and implementing a computerized LMIS depends on the contributions of a number of participants with important roles to play: n Project sponsors provide funding and may also provide high-level managerial support to the computerized LMIS project. n The product manager facilitates and coordinates all software development and implementation activities. n Users are the intended users of the software or its outputs. They work with the other participants listed here to define or redesign business processes and to specify what the software must do to support those processes. n Developers analyze information needs in collaboration with the other participants, then design and build software to meet those needs. n Testers verify that the software does what it is designed to do and tell the developers when the LMIS does not work according to the design. n Documenters develop reference materials for end users and technical support personnel. (The technical support function is described in the final chapter, Computerized LMIS Operations.) In many cases, participants play more than one role; for example, users often serve as testers of the delivered software before the software is implemented. In some cases, one role is shared among several people; in larger projects, the developer role may be played by a team of people—led by the product manager—who analyze needs, design a software solution, and then build the solution. Regardless of the number of people involved in the project, it is essential that all the roles are filled; otherwise, the software project is likely to fail. Table 6 displays the roles and responsibilities of project participants. Analyzing User Needs Analysis is the first activity in the process of implementing a computerized LMIS. The major goal of analysis is to answer in detail the following questions: n How does the existing LMIS (whether computerized or not) work? • How is the information collected, processed, and presented? At what periodicity? • What decisions are being made and at what level? • What information is needed to make those decisions? n Who uses the LMIS and why? n What is the scope of the LMIS? • What products are distributed? • Which distribution systems does it cover? 1� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION n What problems exist with the LMIS? • Why do these problems exist? • What are their root causes? n What is needed to solve the problems with the existing LMIS? • Is a new or improved LMIS the best solution? • Is the best solution manual or computerized? Role Likely Participants Responsibilities Project sponsor Product manager Users Developers Testers Documenters • Provide funding and other resources required by the project . • Review and provide feedback on key outputs during the course of the project . • Provide high level endorsement . • Allocate project resources . • Assign participants to project activities . • Monitor and review project activities . • Facilitate communication among project participants . • Share detailed information on current procedures and information needs . • Review and provide feedback on outputs during the course of the project . • Collaborate with product manager and end users to identify and prioritize software requirements . • Design and build software according to identified requirements . • Communicate with product manager and end users about feasibility, cost, and resource needs of requirements . • Test software to confirm that it meets requirements . • Find bugs or problems and report them to developers . • Verify bug fixes . • Develop user’s manuals or job aids for end users . • Develop technical documentation for technical support personnel . • high-level managers within the client organization • International donors or donor repre- sentatives • Manager within the client organization • Donor representative within the client organization— • Data entry personnel • Logistics personnel • health program personnel • Individual consultant • MIS unit personnel • IT company personnel • Data entry personnel • MIS unit personnel • IT company personnel • Program personnel • Product manager • IT company personnel Table �: Computerized LMIS Development Roles and Responsibilities Analysis is often the most challenging activity in computerized LMIS implementation, because the root problems of an existing LMIS are difficult to uncover and because requirements for a computerized LMIS are equally elusive. When the client and sponsor initiate a software project, they have a sense that something is wrong or needs improvement but find it difficult to articulate those problems and to specify what the new system should do. During analysis, the task of the software team is to elicit these requirements in collaboration with the user. DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS 13 You may find reviews of the existing information system in previous assessments of the logistics sys- tem. If no previous studies have been conducted, DELIVER’s Logistics Management Information Systems Assessment Guidelines (available to read on the DELIVER website at suggests a process for reviewing the current LMIS design and operations. Not every situation will warrant a computerized LMIS. An assessment of the existence of a functioning paper-based manual system, data volume, technological infrastructure, and skill levels of available per- sonnel may lead to a recommendation to computerize. If a computerized LMIS is the recommended solution, you should consult the first sample process document in appendix 3, the requirements assess- ment, which specifies sections for the written output of an analysis or requirements gathering exercise. This document is shared with the client and sponsor as a way to clarify users’ business objectives and to gain agreement on the focus and scope of the proposed software implementation. Sharing the re- quirements assessment with the user at this early stage enables the user to provide feedback to the team so that errors or misunderstandings are eliminated well before they are written into software code. Two of the most valuable sections of the requirements assessment are the system functions and the illustrative outputs. The system functions, or use cases, depict the interaction between the users and the new, computerized system to accomplish a particular objective. It is not necessary to cover every single possible use case in the requirements assessment—most software applications ultimately encompass hundreds of use cases—but only those that represent the basic functions of the computerized system, such as receiving and issuing products. Guidelines for writing use cases are included below. The second item in a requirements assessment is illustrative outputs, which present sample reports using real data where available. These sample reports are useful in letting the users see what they will get out of the system. Use Cases A use case shows a user and a computerized system interacting to reach a goal. Use cases are meant to be read by a potentially wide range of team members and are therefore written in text prose, unaccompanied by technical symbols or notations. The first step in writing a use case is naming the case, using a simple, action-oriented, verb-object phrase. Examples of use cases for LMIS or warehouse management systems (WMSs) include “receive products” or “issue products.” A sample use case is displayed in box 1. Use Case Extensions The main course of events section of the use case is often alternatively called the success scenario. Because many interactions do not end in success but rather failure, or end in another way, these other interactions are documented separately. A separate section of the use case—extensions—provides a place to address how the user and system will handle unexpected or alternative events. Table 7 lists possible ways the main scenario can fail, followed by examples. Guidelines for Writing Use Cases Above all, use cases are written in a clear and concise manner to represent users’ goals and computerized system actions to reach these goals. The following guidelines list rules-of-thumb for focusing the use cases solely on user and system actions and, at the same time, eliminating wordiness.1 1. Cockburn, Alistair. 2001. Writing Effective Use Cases. Boston: Addison-Wesley. 14 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Receive Products Summary When shipments are received, warehouse staff put them away and note their storage location on the receiving document (invoice). Main course of events 1. User selects the account to which the receipts should be credited (for example, common stocks, or other facility). 2. User selects or enters the following: • supplier • supplier’s reference number (invoice number) • date of receipt. 3. User selects or enters the following information about each item received: • item number • expiration date • location • quantity. 4. User continues to select or enter information for each additional item received. 5. System adds the items to inventory. Extensions 3a. Shipment is a donation to particular facilities (e.g., Direct Relief International): .1 User selects a location designated for donations. Box 1: Use Case Example n Use simple grammar. Short, action-oriented, subject-verb-object sentences are the clearest way to present the story. n Show clearly who “has the ball.” Include a subject in all your sentences. Otherwise, others may have a hard time deciphering who does what to whom. n Show the process moving forward. Don’t include minute actions (e.g., “user hits tab key”) that slow down the use case. n Show the user’s intent, not the movements. Don’t describe the user’s movements in operating the user interface; instead, focus on the user’s intent in interacting with the system. This strips out extraneous—and premature—user interface specifications. n Include a reasonable set of actions. Each step in a use case represents a transaction, which con- tains four parts. Look for opportunities to combine these parts into less than four steps; this makes the use case easier to read and saves space. n Provide positive validation. The main use case is a success scenario, so use words such as “vali- date,” not “check whether”; don’t include tasks that lead to use case failure. Instead, include failure points in the extensions section. n Use idiom: “User has System A alert System B.” Many system requirements include the need to interact with other computerized systems. This phrase is the simplest way to convey that the user has control over the interaction, without specifying how the interaction is initiated. DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS 15 Table 7: Use Case Extensions and Examples Use Case Extension Example Alternate success path User types a shortcut code . Incorrect user behavior Invalid password . User inaction Time-out waiting for password . Any time the phrase “the system validates” appears Invalid item number . in the main scenario—implying that there will be an alternate path if the validation fails Unusual or failed response from a supporting system Time-out waiting for response . Internal failure within the system under design that Incomplete or missing data in the database . must be detected and handled as part of normal business Unexpected and abnormal internal failure that Corrupt database . must be handled Critical performance failures of the system that Response not calculated within ten seconds . must be detected n Use idiom: “Do steps X-Y until condition.” In many use cases, one or more steps can be repeated. List this repetition at the end of the step or steps being repeated; to make the use case easier to read, do not number the repetition. Appendix 3 includes an outline for a requirements assessment, a sample assessment, and a sample use case. Designing the LMIS After the project participants agree on the requirements for the new, computerized system, develop- ers begin to create more detailed descriptions for how the new system will look and act—descrip- tions or template images of all user screens, reports, and other user interface objects, as well as the database underpinning it all. (Often, developers begin this work before the requirements have been finalized, but they should always update their work on the basis of any subsequent changes to the requirements.) These descriptions are provided in the following documents: n Database entity-relationship diagram. This document shows the structure of the database: major data groups (entities), relationships between these groups, and the data items (attributes) com- posing each group. Appendix 3 displays a sample entity-relationship database diagram. n Sample screen layout. The sample screen layout is a draft of what the user will see when operat- ing the computerized LMIS. Appendix 3 provides a sample screen layout. n Site map. The site map shows the relationship among screens in the computerized LMIS. The site map is useful in communicating to users where particular LMIS functions will be ac- cessed. See appendix 3 to view a sample site map. n Sample reports. Sample reports depict the expected outputs of the computerized LMIS. High- level logistics managers and decision makers may never see the software itself but will only 1� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION see its outputs. Showing these key users sample reports during the design phase can bolster high- level support for the development process. Appendix 2 includes sample LMIS reports. n Business rules. Business rules are the critical behind-the-scenes rules that the computerized LMIS must follow—for example, adherence to the product list managed by the central medical stores. In many cases, business rules can be incorporated into the use cases. Some business rules may need to be documented separately if they do not directly relate to the user interac- tions described in the use cases. Of these, only the user interface prototype, site map, and sample reports might be shared with end users and project sponsors. Together, these documents act as a two-dimensional prototype of the new system, enabling users to see how the system will look and what it will produce. At this point, users can provide invaluable input to developers to modify the design, well before the prototype becomes a full-blown application when changes could entail costly modifications. Designing the Database If project participants decide to develop customized software, the next major focus of their work is on designing the database that stores the users’ data. Several participants who can find and fix potential design flaws should carefully review any proposed design for the database. Software based on a flawed database may end up containing numerous data errors that cause the system to crash or, worse, perform erratically without the user’s knowledge. Databases should be designed to meet third normal form, which applies to every table in the database. This means— n All columns in each table must be atomic or contain only one value (first normal form). n Every nonkey column in each table must be fully dependent on the (entire) primary key (second normal form). n All nonkey columns in each table are mutually independent, i.e., no columns contain calculations or values that are dependent on the contents of other columns (third normal form). Selecting the Programming Language When choosing a programming language, project participants tend to go with the language they know best. The main advantage to this approach is that the developers’ learning curve is much shorter or even nonexistent. But, the best-known language may not be the best option in all software development projects. Before selecting a programming language, project participants should attempt to answer the following questions: n What is the client’s standard programming language (if any)? n What language meets most, if not all, of the requirements of the software to be developed? n Is knowledgeable, local technical support available, other than the original developer? This support can be information technology staff within the client organization, individual consultants, or software firms based locally. DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS 17 While the answers to all three questions are important, the answers to the first and third bullet should be weighted most heavily, because they indicate the capability of the user and the local environment to adopt and support the software. Defining Minimum Requirements Any software application—including a computerized LMIS—has some minimum set of hardware and software requirements. The three most basic requirements, listed below, should be defined during the design phase, so developers know the required parameters. n Operating system. Microsoft Windows 95®, 2000, or NT are the most common operating sys- tems to design for. n Hardware. Minimum requirements in terms of CPU, memory, hard disk space, and CD/ DVD ROM. n Screen resolution. In many resource-constrained environments, the highest available screen resolution may be 800 × 600. Developers should plan to design user interfaces that are readable at the lowest screen resolution that will be available. Creating a Prototype Developing a prototype of the user interface is the major activity in the design phase. Prototyping helps in the following ways: Provides a real life look and feel. A prototype of a data-entry form or report using the actual programming tool, interface design, menu structure, and navigation provides a basis for the design team and users to provide feedback. It also helps in making final decisions about the application’s general look and feel, color scheme, menu structure, navigation, layout, branding, logo, legal statements, and so on. Enables the team to participate in the design process. A prototype with enough visual elements allows the group to co-design the application and help generate interest and initial buy in. Enables iterative and incremental development. Recent software development methodologies put heavy em- phasis on developing an application incrementally and iteratively with very frequent communication among team members. In each iteration, additional features are added over the previous build, until the application emerges in its finished form. A prototype depicts interface elements—computer screens, paper reports, and other inputs or outputs—to show the users how the application will look and act. Periodic meetings of the product design team, developers, and users to review progress and gather feedback are often the best way to keep development moving forward. In such meetings, design, interface, menu structure, business rules, and associated elements of the application can be discussed and made final. Developers can then go back and incorporate agreed-upon changes and produce the next iteration of the prototype. This cycle continues until the application is fine tuned and determined to be the finished product. 1� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Designing the LMIS for Multiple Distribution Levels Electronic Exchange of LMIS Reports Many software applications involve communication of some sort: communicating with the database over a network, exchanging data among different installations of the software, or sharing data with other applications, such as an accounting system or health management information system (HMIS). Developing and testing these communication links is surprisingly complicated and time-consuming. A general rule of thumb is to communicate electronically only when necessary. If there is a non- electronic way to convey the same information—via a paper report, for example—project partici- pants should choose that option first. There are cases when electronic communication offers significant benefits over other forms of communication. JSI is currently developing a two-tiered version of a computerized LMIS in which district medical stores exchange data electronically with the central medical store. The alternate, paper-based method would require each district to fill out and send to the central medical store paper copies of reports for the hundreds of health products consumed by every health center it sup- plies. This would likely cause a potential bottleneck at the central medical store, which has to process reports from each and every health center throughout the country. In this case, electronic exchange of data between the region and center would help avoid the bottleneck and is thus worth the extra time and cost to develop upfront. Questions to consider when developing communication links— n Who manages what data? Exchanging data between two different installation sites or two different software applications can result in bad data if all sites can add, update, or delete the same data. If two or more sites change the same data record, whose record is the final record? Before setting up a two-way exchange, the project team must clearly define which installations have the right to add, update, or delete data. The assigned rights must be mutually exclusive, so that any changes to data are sent in one direction only. n When are data transmitted—on a regular or ad hoc basis? In an LMIS, reports are sent on a regular basis—usually monthly or quarterly. Typically, some facilities report later than the cutoff date for submitting aggregated reports up the supply chain. How does the software transmit reports that have arrived behind schedule? Do those reports wait until the next scheduled reporting period, or are they sent as soon as they are received? n What data are transmitted—all data or only data that have changed since the last transmission? In many software applications, users not only add new data but also modify or delete existing data. How are all these changes transmitted? Sending the entire database is the safest way to ensure that all data changes are transmitted. But, if data are sent over the Internet, sending a database may eventually overwhelm the available bandwidth in resource-constrained environments. n What happens when data are re-sent—are they ignored or do they overwrite existing data? For example, if the user accidentally sends an older copy of the database or transmission file, how does the software note the age of the data when they are received at the other end? n How do users check the status of transmissions? If the software includes routine data exchange, then some users will be responsible for monitoring the status of data transmissions. How DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS 19 will they monitor transmissions, and will they take any follow-up actions that require support from the software? n How reliable is the proposed communications medium? The Internet is the medium of choice for long- distance electronic communication. Yet, this communications medium often relies on the high-quality services of Internet service providers (ISPs). It also relies on other components of the communications infrastructure, such as telephone lines. Before designing a com- puterized LMIS based on electronic exchange of data, project participants should consider whether the proposed communications medium is sufficiently reliable to support the routine transmission of LMIS data. Database Configuration Options There are basically two options for configuring a database to enable electronic sharing of LMIS data among distribution points within the logistics system. This is done by (1) installing a separate copy of the database at the distribution point (distributed database) or (2) allowing each distribution point to access a central database via the Internet (central online database). In a third configuration, implemented by JSI in several countries, a database is installed in one central location for collection of data from paper reports (central database). This third option does not automatically allow electronic sharing of LMIS data but, technically speaking, is the easiest to implement. Distributed Database In a distributed database configuration, the computerized LMIS is installed at multiple locations in the distribution system; each location has its own copy of the software and database. In this configuration, data are exchanged electronically in place of paper-based LMIS reports. Among distributed databases, LMIS reports can be exchanged in several ways: n attached to an email sent via the Internet n copied onto floppy disk, recordable CD, or thumbdrive and sent via postal mail n sent to the central database via the Internet using a built-in database synchronization utility. A distributed database configuration is the most difficult to design, develop, and test because it relies on an exchange of electronic LMIS reports between separate databases. Before developing and implementing a computerized LMIS based on distributed databases, project participants must address the questions listed in the previous section, Electronic Exchange of LMIS Reports. Figure 1 depicts the configuration of a distributed database. Central Database JSI has used a central database configuration to develop and implement a computerized LMIS in several countries. (See appendix 1 for lessons learned in implementing computerized LMIS in five countries.) In this configuration, the computerized component resides in a central processing location—typically, the procurement and logistics unit of the Ministry of Health (MOH)—and all facilities submit paper-based reports to the central location. Figure 2 depicts the configuration of a central database. �0 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Central Online Database A central online database configuration offers the best of both worlds—the technical ease of a single database combined with the ability to make logistics information immediately accessible to managers who make operational decisions at lower levels of the distribution system. In this configuration, the computerized LMIS and database are accessible to lower levels via the World Wide Web. Lower levels use the computerized LMIS to enter, update, and delete logistics data, but their changes are recorded in a central database. Figure 1: Distributed Database Figure �: Central Database DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS �1 The primary disadvantage of a central online database configuration is that it relies on a fast and reliable Internet connection at each location that accesses the computerized LMIS over the Web. Reliable Internet capability is generally not feasible in resource-constrained environments. Figure 3 depicts the configuration of a central online database. Table 8 lists the advantages and disadvantages of each configuration option. Figure 3: Central Online Database Table �: LMIS Database Configuration Options Central Database Distributed Database Central Online Database Advantages Disadvantages • Easier and less costly to support one database as opposed to 10 or �0 databases . • Organization can concen- trate skilled and trained staff at central level . • Data transfer is simple and not prone to technical glitches . • Mid-level facilities relieved from manually aggregating data and performing calculations . • Facilitates monitoring (nonreporting, stockouts, or overstocks) at lower levels . • May facilitate more timely data entry . • Best of both worlds: lower levels have access to computer system (benefits of distributed system), but system is maintained centrally, and user doesn’t need to worry about data transfer (benefits of system) . • Difficult to provide timely information for opera- tional decision making . • Presents ongoing challenge of keeping distributed databases synchronized . • Need to define procedures for updating data—for example, what happens when previously submitted data are changed? • At lower levels, constraints in human and technical resources increase the complexity and cost of training and technical support . • Requires reliable and reasonably fast Internet connection; may not yet be feasible in many resource-constrained countries . �� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Developing the LMIS After project participants have agreed to a design for the computerized LMIS, the development process begins. The systematic approach to development described in this section will enable development of the computerized LMIS according to the original design and in a reasonable time. A computerized LMIS developed in this way will be easier to use, enhance, and maintain. Ease of maintenance is important because in many cases someone other than the original programmer will maintain the computerized LMIS during its lifetime. For any programming language or environment, a systematic development process includes the fol- lowing activities: n applying naming conventions to software objects n applying coding standards to software code n controlling the software code. Applying Naming Conventions to Software Objects Using naming conventions simplifies coding, code review, code reuse, and maintenance. Depending on the programming language and database platform, programmers should adopt a naming convention for all the software objects listed in table 9. It is best to adopt the most popular naming conventions available for a particular programming language and database. The industry standard naming conventions for several programming languages are described here. There are a number of naming conventions available for different programming environments. Hungarian notation is the precursor of many type-based naming conventions originally developed for C and C++ and later adopted for use in Visual Basic and Microsoft Access programming environments. The Leszynski/ Reddick naming convention, a popular variant of Hungarian notation, is used for Visual Basic and Access Basic programming environments. According to the Leszynski/Reddick convention, syntax for each software object should follow this format: [prefixes]tag[Basename][Qualifier] For example, a product name in the database would be tblProduct.strProductName. More information on the Leszynski/Reddick convention is available at For Java programming projects, naming conventions are available at The Java naming convention focuses on a few simple case rules to distinguish the functions of identifiers—pack- ages, classes, methods, variables, and constants. Packages are named as the organization’s domain name in reverse. As an example, a utility program for a computerized LMIS would be named com.jsi.lmis.util. This approach provides a globally unique identifier for each software object, making the object easier to identify and reference in code. DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS �3 Table 9: Software Objects Software Object Type Software Objects Application objects Main LMIS application Application modules Application submodules Database objects Permanent tables Temporary tables Columns Stored procedures Sequences Indexes Constraints Presentation objects Forms Reports Canvas Display objects widgets Form items Program objects Libraries Program units Record groups Blocks Queries Cursor Local variables Global variables Passed parameters Received parameters Applying Coding Standards to Software Code Coding standards help ensure that the software code appears visually consistent, can be easily read and understood by other programmers, and can also be read by tools such as javadoc to automatically generate program documentation. Coding standards typically cover the following areas: n syntax and placement of comments n indentation n commands from your program variable and literal n differentiation of global and local variables n code structure, including— • declarations • code body • exception handling • exit points • division of code into logical units • function return values • error handling. �4 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Popular naming conventions discussed in this section address some of these coding standards. Best practices, coding guidelines, and sample codes can be found in Microsoft MSDN, Sun’s Java websites, the W3W consortium, the Apache website, and ColdFusion and open source communities. A common best practice is to write template code based on coding standard best practices for a particular programming language and platform. You may want to write several templates that represent your typical programming scenarios. When developing template code, developers should plan to conduct code reviews to ensure that the code rigorously follows the naming convention and coding standards; otherwise, developers may inadvertently introduce codes that are nonstandard. Another best practice is conducting periodic code reviews with experienced programmers. During code reviews, several developers should jointly review the code for the quality of the logic and the consistent application of naming convention and coding standards. These reviews provide several benefits: developers learn from one another; more efficient coding algorithms are developed under experienced guidance; and more than one developer becomes familiar with the code, thus facilitating maintenance. Controlling the Software Code Some large computerized LMIS projects may require the efforts of multiple developers. And, after the first implementation, all computerized LMISs—large and small—will undergo various bug fixes, patches, and versions. All situations require a source code control system to prevent inconsistencies in the software code that arise when many developers are contributing code or when the code is being changed over time. Choice of a source code control system often depends on the particular database and/or programming language that the computerized LMIS is based on. A source code control system stores the code base in a central repository. It allows individual developers to check out source code files to work on. Developers can lock files in the repository to prevent others from working on the same file at the same time. When unlocked files are being worked on by multiple developers, the repository applies rules to track which changes were made by which developer. Source control systems also enable version management. Developers can manage different versions of the software code by naming them version 1.0, 1.1, and so on. For the Microsoft programming environment, Visual Source Safe is a popular choice. For the Oracle environment, Oracle Software Configuration Manager is a common option; it handles binary file formats used by several Oracle development tools. Various third-party source control systems are also available for the Oracle environment. Concurrent Versions System (CVS) is the de facto standard tool in the open source community. Recently, Subversion, a variant of CVS, is gaining ground in the open source community. When a source code system is used, a typical development scenario can follow the steps below: n Development manager creates a module in the source code repository. n Programmer writes initial code and checks in the file. The original programmer or other pro- grammers can check out that code, do further work, and check back the code. The repository handles conflicts related to the same code being updated by more than one person. DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS �5 n Development manager creates branches, such as maintenance release and hot fixes, to track different versions. The development manager can merge such branches together to bring the code base of different branches together—for example, to produce the final build of a major version. n Development manager or programmers can retrieve any specific version of the code from the repository. Testing the LMIS Testing software before it is put to use is a critical activity in developing and implementing a computerized LMIS but often is not given the full resources needed. In many cases, testing is done informally by the developer as each function of the LMIS is developed or enhanced. This informal approach is not adequate to ensure that the LMIS meets the client’s objectives. To ensure software quality, a more formal and rigorous approach to testing is required. Managers should plan on providing the resources needed to conduct testing. At a minimum, it is recom- mended that the manager have users gather input data, understand what the expected values and outputs should be in the new system, and then review these transactions together with the software developers. By going through scenarios that mimic daily use and exceptions together with the software developers, managers and users can better articulate and review the way the system should act. During testing, testers focus on verifying that the software does what it is designed to do. Other major goals of testing include— n uncovering defects (bugs) in the software n ensuring that the software does not do what it is not supposed to do n creating confidence that the software performs adequately n understanding how far a system can be pushed before it fails n understanding the risks involved in releasing a system to its users. Types of Testing There are two general types of testing techniques: positive testing and negative testing. These tech- niques are complementary, and both should be used in the testing process. Positive testing focuses on the main goal of testing mentioned above—confirming that the software does what it is supposed to do. The main tool for positive testing is test cases that are based on the requirements assessment document developed during the earlier phases of the software project. A well-written requirements assessment document proves invaluable at this point, because writing test cases may be as simple as adding a column for the tester to record the results of the test. Appendix 3 includes an example of a test case. Conversely, negative testing aims to make sure that the software does not do what it is not supposed to do. An example of negative testing would be to verify that the software does not let the user record a negative value in a field for recording monthly stock receipts. A useful tool for negative testing is the list of business rules that the system must adhere to; this list is compiled during the design phase of the project. �� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION As a general rule, a computerized LMIS that will be widely distributed or that will have a large number of users should undergo extensive negative testing. The reason for this is that some of these users will likely have less experience or training and will, therefore, make mistakes with the software; the system should detect these mistakes and alert the user. Otherwise, unexpected user input may cause the system to record bad data or crash without warning. For systems with a very limited number of users, minimal negative testing may be acceptable, although it is always preferable to conduct as much negative testing as resources permit. Positive and negative tests may be applied during any of the following tests, which may be conducted during the development process. Unit testing, integration testing, and acceptance testing are the most often encountered in development. Regression testing, load or stress testing, top-down testing, accessibility testing, and usability testing are less often encountered. Unit testing. Tests the individual program unit, module, object, or set of object-related objects. Typically, this is done by the developer (rather than the program manager or end user). Integration testing. After all individual elements are unit tested, the whole system is built and the integrated system is tested. The whole interface of the application and flow among elements with simulated data are tested. Typically, a set of related units is tested, then new elements are added one at a time, and the system’s stability is verified before the next element is added to the mix and retested as an integrated whole. Acceptance testing. Checks and verifies that a delivered system meets requirements originally specified. The customer conducts this test. Regression testing. Retests a particular item. When something has changed, the system is retested to verify that what worked before is still working. Load or stress testing. Tests the load-bearing ability of a system. Typical usage scenarios are developed and loads are added to the system in the form of additional users or processes, to assess up to which point the system can provide acceptable response time. Automated tools can be used to simulate huge system load. Top-down testing. Tests the entire system, from beginning to end, from the user’s perspective. Accessibility testing. Checks whether a person with disabilities will be able to use the application. For example, a person with vision impairments may use a screen reader to use the application. Various resources exist on the Internet to serve as a guide on how to build an application that is accessible to a disabled person. Similarly, testing guidelines exist to check for accessibility issues. Usability testing. Tests an application’s ease of use and intuitive use of navigation and placement of information. Test Cases and Test Plans One way to bring structure to a testing process is to prepare test cases and test plans. A test case depicts a usage scenario. It provides instructions on how to test a particular system func- tion and provides detailed steps. A test case also ensures that the test is repeatable and reproducible. DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS �7 A formal test plan can be developed for each module, form, report, or functional area. This plan can outline all sorts of tests to be performed. It can contain test cases, test data to be used, and expected outcomes. As mentioned above, it is recommended that, at a minimum, users gather input data, understand what the expected values and outputs should be in the new system, and review these transactions with the software developers. By going through scenarios that mimic daily use and exceptions with the software developers, managers and users can better articulate and review the way the system should act and provide direct feedback to developers. Independent Testing Before the computerized LMIS is released for use, it is vital that someone other than the developer performs the tests. Not only does this serve as a quality check on the developer’s work, but it also enables testing from the users’ perspective, with the testers as surrogate users. In large software projects, a dedicated team of testers may fill this role. In smaller projects, the tester may be another developer, the product manager, or the users themselves. Frequent Communication during Testing The testing process requires frequent communication between testers, developers, and the product manager to report and fix defects and to verify fixes. The tester identifies defects or issues and reports them to the product manager or developer. The product manager, with input from the development team, prioritizes defects. The developer then fixes or addresses the defects and reports to the tester to test the fixed version. Often, there is additional back-and-forth communication between the tester and developer before a defect is completely addressed. Incident Tracking System The need to track individual defects through a sometimes lengthy testing process makes a computerized incident tracking tool—for example, a database—especially useful. Such a tool enables testers, developers, and the product manager to monitor the status of individual defects as well as the testing process itself. An incident tracking system helps in maintaining a product’s life cycle. Typically, after deployment, users report bugs and ideas for improvements. If an incident tracking system exists, it will support the logging of bugs and enhancements on an ongoing basis. Periodically, the product manager can prioritize bug fixes and product enhancements from the list of incidents. One example of an incident tracking system is an open source solution called bugzilla. Acceptance Testing The last step in the testing process is user acceptance testing. This is performed by one or more user representatives to confirm that the software works correctly and is usable before it is formally delivered to the end users. During user acceptance testing, users try the system by performing typical tasks that will be carried out during the course of their workday. Wherever possible, to simulate real usage, actual data should be used for testing. User acceptance testing should also include reviews of any associated documentation, such as user manuals. �� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Clients or user representatives have the responsibility to ensure that the software undergoes user acceptance testing before it is implemented. They also have the right to detailed information on the overall testing process: the testers, test plans, and test results. If the development team cannot provide this information, it is an indication that a systematic testing process is not in place. In that case, they may need to plan for more extensive user acceptance testing before the software can be delivered to end users. A final note on testing: all newly developed computerized LMISs—even the most well designed and thoroughly tested—contain defects that users will uncover during operations. After the computerized LMIS has been implemented, the mechanism for tracking defects should remain in place; this will allow both users and developers to report and fix any defects that are uncovered. Documenting the LMIS If a computerized LMIS has been well designed and developed (or bought), it may be in operation for many years after its initial installation. Future users may not have been involved in the development of the software and may not know how to perform basic tasks. Even users who did participate in development may need help with advanced tasks that they perform infrequently. At the same time, over the life of the software, users will request modifications and enhancements— especially if they are using high-quality software and want it to expand to do more tasks. The developers hired to modify the software may not have been involved in the original development work and will need to learn the software’s underpinnings—the code, database, and overall structure—before beginning any modifications. This is where documentation comes in handy. Documentation comes in several forms, including online help files, user’s guides, and technical manuals. When planning a budget to develop new software or enhance existing software, be sure to include sufficient time and resources to produce the documentation. Documentation—particularly the user’s guide—may be the first thing prospective users or sponsors see, and it should reflect the high quality of the software itself. The project manager should approach the software’s documentation as an of- ficial publication, with all corresponding steps and timeframes required to produce such a document. Online Help Online help files are the first place users can go when they encounter problems or are not sure how to do something while using the software. When users have questions, they can access the help file directly from within the software application and look for the answer or answers there. A major advantage of online help is that users can quickly find potential answers to their questions, without having to locate and search through a paper-based user’s guide. Help files generally contain two sections: the help contents (divided into books and topics) and the index. The contents outline major tasks, while the index allows users to search for and view all help topics for a particular word or phrase. The most basic help file may contain only the help contents but no index. In a development project that has well-developed use cases, help contents can be based on those use cases. DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS �9 User’s Guide A user’s guide helps a user understand application features. This guide is written in a way so that, when wanting to perform a specific function, the user can open the guide and follow steps to perform a desired function. A technical writer typically writes a user’s guide with inputs from others. This guide illustrates the steps by using screenshots from the application. User’s guides also explain— n user interface n export to file (if applicable) n menu organization n online help n toolbars n logging in/security n navigation mechanism n reference tables. n printing (if applicable) The user’s guide can be a paper-based variant of the online help file, or it can be an independent guide with additional features. It should accompany or immediately follow the initial delivery of the software. In addition to the contents found in the online help file, the user’s guide may include minimum hardware requirements, installation instructions, and one or more tutorials. But, like online help, the majority of user’s guides are detailed descriptions of software functions. Appendix 4 provides a sample outline for a user’s guide. Technical Manual While the online help files and user’s guide are intended to help users operate the software, the technical manual helps programmers modify it. Unlike the help files and user’s guide, the technical manual targets a limited audience. The technical manual should be written by the developers who are most familiar with the program- ming conventions, modules, and database structure that the manual will cover. Typically a technical manual covers— n entity relationship diagrams n description of tables n data types of columns and restrictions on what types of values a column can hold n description of programming packages, procedures, and functions, along with their public interface and parameters n usage of tables/columns in various programming objects n off-line batch processes n security n system architecture. 30 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION The technical manual may also include details related to server installation and configuration steps, firewall setup, a deployment guide, description of configuration files, and all other technical issues that should be documented so that others can run, program, and maintain the system using this manual. Appendix 5 provides a sample outline for a technical manual. Deploying the LMIS A professionally developed LMIS application should be self-installable and should be distributed through CD or DVD with an option to download and run from a website. An installation guide, CD label, brochure, and/or readme files should provide assistance with the installation process. When an application is installed through self-installer, the installation process should emulate the installation process of popular software that installs through wizards. The user should be informed of all changes made to the system and should be allowed to override default values. If the installer program installs common or dependent tools, the user should be notified of them. When a system is installed through a self-installation program, it should follow operating systems guidelines for such installations. For example, all Windows installations should automatically register the program in such a way that the user can find the application in add/remove programs. Users should be given prompts to select whether and where to locate program icons. If the application has auto run, the user should be able to disable it. On uninstall, the program should clear everything and should ask the user whether to uninstall any common or dependent tools. If the application is not self-installable, then at a minimum, it should be deployable through automated scripts. An installation guideline that is well documented should accompany such a deployment option. During acceptance testing, particular attention should be given to verify that the application can be installed or uninstalled by using the steps provided. An application developed for a few users may evolve over time and may end up being used by a diverse group of people in different countries, locations, or computer environments. It is important, then, that the LMIS application is targeted for a supported environment, operating system, or versions of common files from Microsoft and tested for all such supported environments. Typically, an application developed to run on Microsoft Access 97 may not run on other versions of Microsoft Office or other common database files from Microsoft. The LMIS application should be tested under all supported environments and should clearly state any known issues or unsupported environments through a readme file. Table 10 summarizes the items to consider as one plans for deployment of the software. DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS 31 Table 10: Deployment Checklist Deployment Type Activity Quality assurance Ensure that the application is ready for deployment: • Review all test results and verify that all agreed-upon bugs have been fixed . • Verify that the application was tested under a configuration representative of the actual production environment . • Document installation and configuration steps . Data Review data migration needs: • Back up data from the existing system . • Convert data to new format, if needed . Telecommunications Assess telecommunications requirements: • Determine whether changes to network setup will be required . • Determine whether web server/firewall changes are required . • Ensure that Internet dial-up access is available from all sites, as required . Platform Determine platform needs: • Upgrade operating system, and/or other dependent programs, as needed . • Upgrade server and user PC hardware, as required . Security Plan for a secure setup: • Determine access level of groups and users, as needed . • Determine whether code base needs to be digitally signed . • Ensure that the application or its configuration setup does not compromise security . Rollout Plan for actual rollout: • List sites and PCs where the application will be installed . • Prepare self-installable CD along with step-by-step instructions . • Inform all concerned and give adequate notice about date and time and any potential loss of service . • Distribute rollout package: what’s New list, brochure, user’s guide . • Ensure that managers understand in advance the changes that will take place and the benefits of those changes . • Ensure that any promotional or launch event is planned . • Install, test, and conduct data migration at each site, as required . Training Plan for training needs: • Develop a detailed plan for training . • Determine training objectives . • Identify groups of people to train and suitable level of training . • Develop training materials . • Conduct training . User support Determine what type of user support should be available: • Develop a support plan . • Consider vendor-provided support during post-production period . • Ensure that users are aware of support options and have contract information . • Put in place a mechanism to record, respond, and track all support incidents . • Ensure that qualified and trained personnel are available to respond to support calls . • Put in place a mechanism to track support call volume, peak levels, average response time, incidence of emergency calls . 3� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Training LMIS Users Training Methods Typically, just before a new or enhanced software application is delivered, the intended users are trained how to operate it. Two major ways can be used to convey to these users, potential users, and project sponsors how to operate the software and access the data it contains: n Structured on-the-job training is a planned process in which specific tasks are carried out at the work setting with the use of job aids and, in some cases, assessment tools. The instructor (usually the supervisor) guides the learner through the steps required to complete certain tasks, such as entering data, preparing to run a report, or placing an order for supplies according to data in a report. This is an appropriate method to ensure ongoing performance improvement. n Competency-based training is designed to ensure that the knowledge and skills required to operate or use software (competencies) are developed under the guidance of an instructor. This type of training generally takes place in a formal classroom setting. Throughout the training session, the instructor provides participants with simulations and case studies that contain exercises meant to develop competency for specific tasks, such as entering data reported by facilities or generating summary reports. Testing of skill acquisition can be done at selected points throughout the course. What Method Is Best for Training People to Operate the LMIS? Every computer configuration is unique. Often, expert knowledge of the software is required to configure it to work on a particular computer. In addition, the number of people to be trained to operate the software is usually small—at most two people at each installation. Taken together, these imply that the most suitable type of training on software operations may be on-the-job training provided by a member of the development team or by a person specially trained by the development team. However, JSI’s experience in implementing software has shown a major weakness in applying this as the only approach to training. It neglects to demonstrate to end users—program managers, officials, donors, and policymakers—how the software’s data can be used to guide and support key decisions on product selection, procurement, resource allocation, and financing. The result is that the software operates where it has been installed but is not used to influence major logistics decisions. In 2002, JSI conducted a review of implementations of an LMIS in two African countries, which concluded that “there needs to be a focus on the use of data by logistics managers and policymakers early in the implementation process, in order to create demand for system outputs and to generate support for system operations.” The next section of this chapter will discuss a possible way to bring the software and its outputs to the attention of major end users. Competency-based training has proven effective in developing essential skills in classroom settings, and it is worth considering how to incorporate competency-testing exercises into on-the-job training. One option would be to create exercises that test the learner’s ability to (1) navigate the application, (2) enter typical data, and (3) find data that answer a particular question. DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS 33 What Method Is Best for Training People to Use LMIS Data? As stated earlier, instructing software operators to enter and retrieve data is not an adequate training approach. To be successful, a training approach must also focus on demonstrating to end users how to use the software when making key logistics decisions. Yet, in many cases, end users do not have the time or inclination to attend a traditional, competency-based training session in a classroom. A viable training approach for these end users is to present outputs of the software’s data—reports, charts, and graphs—at regular meetings or forums in which key logistics decisions are being made. These meetings will vary by country but may include quarterly (or annual) meetings of the logistics coordinating committee, donor coordination meetings, and gatherings of high-level officials to re- view or change national policies governing health care. The logistics decisions typically made at such meetings are based on the following questions: n How much of a particular product do we have nationwide? n How much of a particular product is used on average per month/quarter/year? n Are we going to stock out of a particular product? When? n How much of a particular product should we procure? A well-designed LMIS can help answer all these questions. Although such an LMIS contains the data needed to calculate the answers, additional reports, graphs, or other outputs tailored to the information needs of a particular distribution system may be required. New or customized reports are generally modest changes to the software, and the software should provide the capability to create them as needed. Table 11 lists training topics for two audiences. Table 11: Two-Pronged Training Method for a Computerized LMIS Training Topic Type of Client Software operators Decision makers Configuring the software 3 Entering background data 3 Entering transaction data 3 Generating reports 3 Requesting reports 3 Monitoring stock status 3 Determining quantities of supplies to procure 3 Supervising employees 3 Modifying the LMIS Most computerized LMIS implementation activities deal with the ongoing and never-ending tasks of fixing and enhancing existing applications. Note that, when faced with enhancing the application with a 34 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION significant upgrade, the system is really undergoing a new cycle of development. All steps described above regarding development of the LMIS also apply to upgrades and should be followed accordingly. Since supporting an existing application is ongoing, project participants need a tool to continuously record software defects or suggested enhancements, to assign them to upcoming versions of the software, and to track their status during testing. Tracking Defects and Enhancements After a computerized LMIS is operational, its continued successful operation depends on the regular collection and tracking of two types of software issues: n Defects are faults in the software that prevent or hinder users from efficiently performing their tasks. n Enhancements are suggested by users or the product manager to improve or expand software performance, often in response to a change in the business environment. Both types of issues can be tracked in the incident tracking database, but may require very different responses from the developers, depending on the severity of the issue reported. Some defects may need to be fixed as soon as they are reported—especially any critical defects that prevent users from performing an essential task; others can be grouped with the enhancements awaiting development of the next version of the software. In the latter case, following the steps listed below can help to ensure that new versions of the software are released on schedule and within budget and also contain all the enhancements and defect fixes that users expect. Recommended Components of a Defect and Enhancement Tracking Tool The tool used for tracking defects and enhancements should, at a minimum, track the data items and generate the reports listed in table 12. The severity data item describes the impact of an issue, as outlined • Person reporting the issue • Date the issue was reported • Application and module where the issue was encountered (if more than one application is supported) • Severity of the issue (see table 13) • Priority of the issue • Summary description of the issue • Detailed description of the issue • Target software version • Person assigned to address or resolve the issue • Date the issue was addressed or resolved • Description of the resolution • Date the resolution was verified • Open (unresolved or unverified) issues by application and module • Closed (resolved and verified) issues by application and module • Issues by severity • Issues by priority • Issues by target version Table 1�: Data Items and Reports in a Defect and Enhancement Tracking Tool Data Items Reports DEVELOPMENT AND IMPLEMENTATION OF A COMPUTERIZED LMIS 35 in table 13. The list of reports should provide basic support to the product manager and other project participants in planning and managing new releases of existing computerized LMISs. See appendix 3 to view a paper-based enhancement specification form. Table 13: Types of Severity of Software Defects Severity Description Blocker Blocks development and/or testing of work Critical Software crashes, loss of data, severe memory leak Major Major loss of function Normal Average bug Minor Minor loss of function or other problem where an easy workaround is present Trivial Cosmetic problem such as misspelled words or misaligned text Enhancement Request for enhancement Initial Steps in Modifying a Computerized LMIS n Establish a target release date. The product manager establishes a target release date for the next version, according to the schedule of activities in the work plan (if it exists). n Review and decide priorities for the list of defects and enhancements. The product manager reviews all enhancements and defects currently listed in the issue tracking tool and closes any that are no longer relevant or that do not apply. In consultation with users and project sponsors, the product manager prioritizes the list for inclusion in the next software version. n Estimate time required to make requested changes. The product manager gives the prioritized list to the developer, who then estimates the time required to make all the changes requested. n Finalize the list of enhancements for the next version. The product manager completes the list of enhancements based on the existing budget and the estimated developer effort. The prod- uct manager may then defer some proposed changes until later versions if the developer effort exceeds the current budget for releasing a new version. n Establish a preliminary schedule for releasing the next version. The product manager develops a preliminary schedule based on estimated developer effort, the target delivery date, and availability of the developer and testers. 3� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION DEVELOPMENT OPTIONS 37 DEVELOPMENT OPTIONS There are three options for developing a computerized LMIS: in-house developers (if applicable), packaged off-the-shelf software, or the services of an information technology consultant or orga- nization. Using in-house resources is helpful since developers are nearby and often already familiar with many of the LMIS needs. Buying packaged software is an attractive alternative for implement- ing computerized systems that have common features across multiple organizations and environ- ments. Hiring an external consultant or organization may likewise be a suitable approach for clients with limited human resources or information technology skills. Previous chapters covered the steps involved in developing a computerized LMIS; those are the steps to follow when using in-house developers. This chapter provides a brief review of the latter two options, and the following chapter outlines the steps involved in buying services to develop the LMIS. Buying Packaged Off-the-Shelf Software In general, it is better to buy packaged software than to develop software, for these reasons: n Lower maintenance costs over the long term. While the initial cost for licensing and technical sup- port may appear daunting, the long-term costs for maintaining packaged software are lower than the costs for custom-developed software. The cost for maintaining packaged software is spread across a large number of clients, so each client’s share of that cost is small compared to the cost for maintaining software developed specifically for one client. n Faster implementations. Packaged software has already been tested by the vendor as well as by numerous clients, so unlike custom-developed software, it does not need to be tested thoroughly before implementation. It was also designed to be installed in a wide variety of client environments and includes utilities to facilitate installation. n Access to upgraded versions of the software. Vendors continuously develop new versions of packaged software to fix identified defects and to include suggested enhancements from clients. Clients can then choose to upgrade to the latest version of the packaged software rather than spend time and resources developing custom modifications. n Access to product and user support. When clients buy a software package, they also have the option of purchasing support from the vendor for some period of time, usually one year. This support helps address any technical problems clients experience using the software. In addition to support agreements with the vendor, clients can find answers to their questions from other users of the software, often via Internet-based discussion forums set up for that purpose. Although all of these are powerful incentives to buy rather than develop software, even when pur- chasing an off-the-shelf software package some amount of customization to fit the organization’s functional needs is still required. Buying the Services of an IT Consultant or Organization Another way to implement a computerized LMIS is to purchase the services of an outside consultant or company to custom-build a solution. JSI has used this approach in several countries: Bangladesh, 3� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Honduras, Mozambique, Nepal, Philippines, Tanzania, and Zimbabwe. (See appendix 1 for lessons learned in implementing computerized LMISs in several of these countries.) This can be an effective approach to computerized LMIS implementation in public health organizations that have limited or no information technology skills. It also allows these organizations to benefit from the skills of outside consultants or companies who have experience implementing computerized systems for a number of clients in a variety of settings. BUYING ThE LMIS 39 BUYING ThE LMIS When buying outside services for computerizing an LMIS, the program manager should plan to spend time preparing a detailed statement of needs so that the service provider can make a more accurate estimate of cost and time. After that, the manager should follow a clearly defined series of steps to make sure that what has been communicated is what is being built. In the end, a well-pre- pared statement of needs and processes will serve as a solid foundation for a computerized LMIS that will meet the program’s information needs. Following are steps in the process, as well as as- pects for consideration. Please note that this section attempts to assist a manager in better planning for, and communicating, the needs for an LMIS; it is not meant to cover contractual requirements regarding purchases (e.g., sole source, international competitive bidding, etc.). Please review your procurement requirements and involve others as required by your organization. Communicating Your Needs A well-documented description of the flow of information, structure, and functions being supported is necessary for the service provider to estimate the time and cost of building the computerized LMIS solution. Depending on procurement requirements, this description could be included as part of a Request for Proposal/Quotation (RFP/Q) or as background to a sole source justification. Regardless of the method of purchase, the document should include, at a minimum, background information about one’s business (e.g., volume, number of transactions, how often information is coming in, how many people enter and use information, etc.), a description of the functionality expected in the system itself, and other requirements that must be met during, and after, the solution-building process. Use cases are the preferred format in which functionality is captured. Please refer to the chapter on the Development and Implementation of a Computerized LMIS, which outlines the process and steps that a vendor will take. The section on Analyzing User Needs provides a description of use cases and examples. Table 14 below provides a checklist of two types of items to communicate: (1) the components that should be included or considered when designing the system and (2) other requirements expected to be met during and after the building of the system. 40 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Table 14: Checklist of Needs Needs Description I. Components for the System Design Background • Describe the flow of products and information, including the total number of facilities, how often information will be entered, the flow of information, organizational structure, and users of the information . Use case • Describe the expected interaction between user and application, with one use case per specific change to the system (e .g ., updating facility information, entering facility data for a specific date, running a report, etc .) . Restrictions • List any restrictions . hardware • List any requirements for purchasing new hardware, or comment on whether existing hardware must be used, and if so, a description of the hardware . Platform, Operating • If applicable, describe any restrictions regarding the platform, operatiing Software (O/S,) Coding system, screen resolution, and language in which the application must be developed . Describe also if the application should be multiuser or single-user and if there are any data transmission and synchronization requirements and what they are . If there are no restrictions, do not mention them . Users • List number of total users, computer and logistics literacy of the users, number of concurrent users (how many people at the maximum may be using the system at the same time), and location of the users (in the same office, in different cities or countries, etc .) . Volume • Provide the number of expected transactions (provide average as well as maximum) in a given timeframe . Telecommunications • For web-based products and those requiring synchronization or data transmission, describe the type of connectivity on hand at each site (provide the norm as well as the minimum level of connectivity available) . II. Other Requirements Data migration • If information has already been captured in a computerized system and is desired in the new system, describe what exists . For example, 500 purchase orders over three years, which translates into 1,500 lines in the database . Training • If training by the service provider is desired, describe the number of people to be trained and their location for training . Documentation • List the types of documentation required as part of the service provided . Documents such as a user’s guide and technical guide are standard . User support • If post-production support is desired, describe how long the service is expected, number of hours, and means by which support should be given . Upgrade and/or maintenance • If ongoing maintenance is desired, describe how the future work should be undertaken . The next section describes aspects to consider in preparing for a competitive bidding or contracting process and for evaluating proposals. If you have determined that the LMIS service provider will be selected through a competitive bidding process, you may wish to review these guidelines. The final BUYING ThE LMIS 41 two sections review the steps involved in managing the process and are relevant to any computerized LMIS purchase (sole source, competitive bidding, etc.). Preparation for Competitive Bidding Once the needs and process are detailed as described earlier, if your organization has determined that the best way to proceed is through a competitive bidding process, a number of other decisions should be made before announcing the request. Those decisions are explained further below: 1. Determine selection criteria. To be transparent, it is important to list the criteria by which bidders will be evaluated. On the basis of these criteria, a more detailed list should be prepared for evalua- tion that should include the following categories: n functions that the software must perform n outputs (reports and graphs) that the software must produce n hardware, operating systems, other software, and network that the software must work on or with n number of users to be supported n deployment plan required (installation, setup, testing, data migration, and training) n special requirements (language, accessibility, and interface with other software) n total cost for purchase and installation n post sales/installation support (service, response time, and cost). For each category, the selection committee should specify the minimum acceptable criteria, addition- al desirable criteria, and scores for both the minimum and desirable criteria. In addition, the commit- tee should identify which criteria are essential, so that any package that fails to meet these will not be a candidate for selection. A sample of criteria and their weighting is given in table 15. However, you should review for your own purposes the various facets of service provision and their relative weights for the project. Table 15: Example Selection Criteria Criterion Definition Maximum Points 1. Personnel • Quality of key personnel 1� 2. Deliverables • Responsiveness • Approach • Functionality • Timeliness 40 3. Hardware • Conformance with computing hardware specifications �0 4. Support contract • Follow-on support contract 3 5. Cost • Overall cost of the proposal as compared with other bidders • Clarity with which the costs are presented • Reasonableness of individual items in the cost breakdown �5 Total 100 4� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION 2. Select a bidding process. Select how the bidding process will take place—either open local competition, open regional competition, short-listed competition (local or regional), or sole source. Such a process must be consistent with the procurement rules in effect. If companies are short-listed, then this can either be through a formal expression of interest and evaluation process or through a more informal market survey. The documentation needed to justify the selection of companies will be determined by the procurement rules, but a large enough pool should be selected to guarantee a reasonable level of competition. 3. Determine dates. Select the dates for the various steps along the award process, including, but not limited to, the deadline for questions, when a bidders’ conference will be held (if applicable), when proposals are due, and when decisions will be made or a shortlist will be selected. 4. Develop a submittal process. Describe where, how, and when you would like proposals to be sub- mitted. For example, some agencies require several copies to be submitted, along with separate technical and cost proposals, CDs of the proposals, and no email submissions. 5. Form a selection committee. This committee should include the program manager, at least one per- son with enough information technology experience to judge the technical quality of the vendors’ proposals, and a member of the funding agency if it is other than the program itself. Others can be added, as needed, but avoid adding too many people or anyone who will not be able to techni- cally or programmatically judge the quality of the proposals. Committee members will identify and evaluate candidate packages and select one package for implementation. 6. Observe standard clauses. As mentioned previously, depending on one’s funding source and organi- zational requirements, certain standard clauses and procurement processes must be followed. This should be coordinated with your organization’s procurement and contracts officer. 7. Host a bidders’ conference. Holding a bidders’ conference has many advantages. It allows the man- ager to determine whether potential vendors understand the requirements, allows for clarifica- tion of any unclear portions of the RFP, and can contribute to higher quality proposals. A bidders’ conference should generally be organized within a week or two of issuing the RFP to allow the vendors time to review the proposal and formulate questions but not so long after the issuance that vendors will have invested heavily in preparing a response. 8. Plan for responding to questions. In general, the RFP process should include a period during which vendors can submit written questions. The manager or committee should then provide a copy of all questions and responses in writing to all those who collected the RFP. The only questions that should be answered are those submitted in writing, and the answers should go to all vendors to avoid any issues of procurement integrity. Process of Evaluating Offers Any offers received by the deadline are evaluated. The evaluation is a more or less formal process that includes the steps described below. The goal of the evaluation is usually to select the most technically sound proposal that presents the best value to the program. Price is important but not the most important criterion. BUYING ThE LMIS 43 1. Verify that proposals have met the requirements listed in the request. Are the proposals complete? If not, then a proposal should be rejected. 2. Convene the committee and review those proposals that are complete. The committee normally reviews the technical proposals first and scores the proposals with the evaluation criteria agreed on above. Typically, the committee members would meet and agree on a consensus score for each vendor and then rank the vendors by a consensus technical score. If the committee cannot meet together in one place, an average score can be used instead. During the evaluation process, the committee can choose to submit written questions for clarification to one or more vendors. All communication with the vendors should be done in writing or via email and the documentation saved in case questions of interpretation arise. 3. Some vendors may offer a custom-built solution, while others may offer a commercial off-the-shelf (COTS) package that can be customized. For those COTS packages, if desired, the committee can request demonstrations to understand better what functionality already exists and what modifica- tions will be needed to meet the program’s needs. Prior to the demonstration, the committee should develop a list of questions for the vendor(s) to answer and features that they would like to have them display. The committee may want to document each vendor’s responsiveness and suit- ability after the demonstrations to use as part of the final technical evaluation. 4. Open the cost proposals if they are submitted separately and score them. This may be done by the same committee or could include additional members with financial expertise. The same consensus or averaging process as described above should be used. The cost scores are added to the technical scores to derive composite scores and a final ranking. The committee would then normally either negotiate with the top scorer or award them the contract. After an award, the contract must be managed proactively to avoid problems. The next section offers guidance on completion of stages, which can be tied into payment schedules. Again, please note that this should not replace any contractual guidance or regulations required by your organization. Deliverable Schedule There are several stages in the development of software when you and the builder of the computerized LMIS should both agree on where you are in the process and what you expect to happen next. These stages are marked by a deliverable, which should be reviewed thoroughly by someone who understands what is desired in the end. Attention to details at every stage is important, as the next stage builds upon the information contained in the previous stage. In addition to development, these deliverables often are linked to payment schedules. Table 16 provides an example of a schedule. 44 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Table 1�: Example Deliverable and Payment Schedule Deliverable No. Deliverable Due Date Payment ($U.S.) 1a Project Charter July �, �004 �0,000 1b System Analysis and Design July �9, �004 45,000 2a System Development: September 14, �004 140,000 Financial Management 2b System Development: Planning, October �9, �004 140,000 Procurement and Distribution 2c System Development: December 14, �004 1�0,000 warehouse Management 3 Testing of System February 14, �005 �5,000 4 Deployment of Production April 14, �005 90,000 Award Total $�40,000 Table 17 provides an example deliverable schedule that lists each stage along with a description and deliverable. “Company” as used in table 17 refers to the solution provider. Timeframes, which are not included in the table, will vary for each project. Table 17: Example Deliverable Schedule Stage Description and Deliverable Project kickoff • The company will identify all stakeholders and hold a meeting to define roles, responsibilities, management, and project objectives . Notes from the meeting, in hard and soft copy, must be provided in a draft and as a final document after all stakeholder comments are incorporated . Specification development • The company will work with stakeholders to define the specifications for the new system . The company will provide a hard and soft copy of the document, in a draft and in a final document, outlining all known specifications, before beginning the next step . This document will include use cases that detail the step-by-step actions between the user and the system, covering system validations and alternate cases . Design prototype • The company will begin designing the system and provide a docu- ment and walkthrough . The document will contain, at a minimum, wire frames, diagram of the architectural design, initial entity relationship diagram, and data dictionary . Test preparation • The company will provide test scripts for review based on all known behaviors and the use cases developed during specification develop- ment . This will be the test plan for acceptance testing along with any new cases discovered during development . The company will provide a hard and soft copy of the document, in draft and final . Please see Testing the LMIS in the chapter on Development and Implementation of a Computerized LMIS for background on the types of testing recommended when developing software . BUYING ThE LMIS 45 Functional prototype review • The company will deliver and install the software and will work with staff to perform testing to verify functionality and validate data integrity of both new and migrated data . The company will document all incidents, work with [name of your organization] to prioritize them, and deliver that document for review and acceptance . The company will resolve critical defects before delivery of pilot software . Acceptance testing • The company will ensure that the latest version of the software, which will include bug fixes identified in initial testing, is available before acceptance testing begins . The company will work with [name of your organization] to perform acceptance testing to verify functionality and to validate the data integrity . Any problems will be documented and resolved before payment is made . A comprehensive acceptance test plan must include, at a minimum, but not be limited to, test objectives, acceptance criteria, functional test procedures, input functionality, output functionality, and results review . • The company will provide a hard and soft copy of the document, in draft and final . The document will include a list of all bugs, their status, and plans for the future (fix, future enhancement, in progress, etc .) . [Name of your organization] will have 30 days to identify bugs, and will prioritize them (list categories: critical, major, normal, minor, etc .), and the company must fix all critical bugs before payment . Please see Tracking Defects and Enhancements in the chapter on Development and Implementation of a Computerized LMIS for more information . Training, support, and documentation • The company will provide training to new users . Prior to training, the company will provide the following documentation in draft for review: user manual, training guide, and technical manual . Training will be conducted by the company using the final approved manu- als as a guideline . The company will provide a hard and soft copy of each document, in draft and final . Please see Training LMIS Users in the chapter on Development and Implementation of a Computerized LMIS for more information . Post-production maintenance • The company will fix critical bugs for a period up to six months from the date when acceptance testing has concluded and the software has been officially in use . Support • After installation of the system in production, the company will provide support for a period up to 1�0 days (six months) at no charge and will respond to user queries . Management • The company will provide updates regarding progress to work plan dates, and meet regularly with [name of your organization] to brief the project on progress and issues . 4� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION COMPUTERIZED LMIS OPERATIONS 47 COMPUTERIZED LMIS OPERATIONS Efforts to design, develop, and implement a computerized LMIS may take months, or even years, and involve many people. But, the hard work does not end after the LMIS has been implemented. Successful ongoing operation of an LMIS requires several activities: placing the LMIS within the central organization, managing LMIS data, monitoring data quality, and providing technical support. These activities are described in more detail in this chapter. Placing the Computerized LMIS within the Central Organization There must be one organizational unit at the central level where the computerized LMIS is physically and administratively located. The LMIS could be located in one of three possible units: n The department that has responsibility for procurement, storage, and distribution for all pharmaceutical and medical supplies. n The department with responsibility for information technology and management informa- tion systems (IT/MISs). n The programmatic department responsible for delivery of the health supplies that will be used by the health services. There are advantages and disadvantages associated with placing the LMIS in each of these units. The procurement and logistics unit is the first and natural choice for several reasons. First, it is the source of most of the data on storage and distribution of supplies. Second, it is the primary user of the information generated, which is the basis for deciding when, where, and how much to ship. But, a major disadvantage of locating the system in the logistics unit is that logistics personnel may not have the information technology skills and resources required to operate and maintain a computerized system. Conversely, locating the system in the IT/MIS unit can ensure that both the hardware and software that make up the system will receive adequate technical support. Placing the system within this unit also facilitates integration or comparison of logistics data with data on service delivery or other health indicators. At the same time, giving the IT/MIS unit primary responsibility for the system leads to a major disadvantage: the users of the data in the system—logistics managers and managers of various health service delivery programs—may not be able to access the data in time to make key decisions affecting supply. In that case, the logistics information system loses its main usefulness. Housing the LMIS within a health service delivery program confers a major advantage: these programs are the ultimate clients of the logistics system and, therefore, the ultimate beneficiaries of high-quality logistics information. They are responsible for the rational use of supplies, and they rely in part on logistics data to monitor and evaluate the effectiveness of their work. But, like personnel in the procurement and logistics unit, program personnel may lack the technical skills to maintain a computer-based system. In addition, these programs may focus on high-profile, donor-driven health information systems (HISs) and neglect the LMIS system. 4� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION The precise location of the LMIS within a program unit may depend on whether or not the logistics function is integrated across all programs or is managed vertically by program. If the LMIS is, or is likely to become, integrated across some or all programs, it should be placed high enough within the organization to represent all the programs it will serve. Ultimately, organizational politics may dictate the location of the LMIS, without much weight given to these technical considerations. Nevertheless, it is important to consider the advantages and disad- vantages of each location to anticipate problems that might arise because of the particular location. For example, if the system is to be located within the IT/MIS unit, steps must be taken to ensure the timely flow of data into the system and to ensure that both logistics managers and program managers have timely access to information in the system. Table 18 summarizes the advantages and disadvantages of each unit as the possible location of a computerized LMIS. Table 1�: Advantages and Disadvantages of Location of the Computerized LMIS Organizational Unit Advantages Disadvantages Procurement and logistics unit Information technology/ management information systems unit Program unit • Original source of data on inventory and distribution . • Primary user of logistics information system data . • Personnel have information technology skills . • Facilitates integration or comparison with other sets of information managed by the unit (for example, service statistics) . • Personnel gain direct access to logistics data to monitor and evaluate effectiveness of their programs . • Personnel may not have information technology skills or resources . • Logistics information system may receive little attention compared to higher-profile hMISs . • Personnel may not have informa- tion technology skills or resources . • Low priority of procurement and logistics function within the organization may lead to low visibility of the LMIS . • Logistics managers and program managers may not have timely access to logistics data for deci- sion making . Managing Computerized LMIS Data Operation of a computerized LMIS includes the following key tasks: n Collecting, entering, and validating routine LMIS data. A successful LMIS relies on routine collec- tion and processing of LMIS data received from facilities in the distribution system. It also relies on routine monitoring of receipt of data from each facility and procedures to resolve erroneous, incomplete, or late reporting by facilities. COMPUTERIZED LMIS OPERATIONS 49 n Distributing routine LMIS reports. In addition to data entry, LMIS procedures should include the routine distribution of logistics reports to provide feedback or enable decision making. Together with data collection and entry, this task is the most important ingredient in a successful computerized LMIS. (See table 4 for a complete list of recommended LMIS reports.) n Responding to special requests for LMIS data. Occasionally, LMIS users or other organizations request LMIS reports that do not currently exist in the computerized LMIS. Procedures should be in place for handling these requests in a timely manner. Technical support personnel may need to assist with this task in some cases—for example, by developing special reports tailored to meet a particular request. n Identifying and reporting software defects. Like all software, LMIS software will contain defects. A key task in LMIS operations is identifying and reporting these defects as they occur. Depending on its severity, the defect may be fixed immediately or added to the list of modifications for the next version of the software. (For more information, see Tracking Defects and Enhancements in the section on Training LMIS Users in the chapter on Development and Implementation of a Computerized LMIS.) n Identifying improvements for the next version of the software. Like all software, LMIS software will periodi- cally need to be improved or modified in response to changing requirements. LMIS opera- tions must include a way to document suggested improvements and modifications as ideas for improvements arise. Operational procedures must also include a way to specify the suggested improvements in more detail before developing the next version of the software. As an example, special requests for LMIS data may join the list of improvements if they are requested repeatedly by users. (For more information, see Recommended Components of a Defect and Enhance- ment Tracking Tool in the section on Modifying the LMIS, in the chapter on Development and Implementation of a Computerized LMIS.) Monitoring the Quality of LMIS Data Despite the expression garbage in–garbage out, there is a universal tendency to accept as true anything that comes out of a computerized system. It is common to overlook the actual quality of data being collected. By the time data are entered into a computer, it is often too late to control many problems with data quality. The most valuable data in a computerized LMIS—particularly data on consumption and availability of products to clients (stock on hand)—originates at service delivery points (SDPs). Since SDPs are unlikely to have computers, there will be at least one degree of separation between data generation and data entry if the district level is computerized and two or more degrees of separation if the LMIS is computerized at the central level only. Because many, if not most, problems of data accuracy and validity occur at the point of data collection, data quality monitoring and control must focus on SDPs. If SDP staff view the collection of LMIS data as nothing more than a bureaucratic requirement, they will give less care and attention to that task. In contrast, if LMIS data collection is designed and carried out in a way that supports decision making at the local level, then SDP staff will pay more attention to the accuracy of the data they collect and report. Otherwise, the quality of data that reaches the computerized component of the LMIS may be compromised. A well-designed program of training and supervision, combined with an LMIS design that emphasizes the use of data at the point of data collection, will help minimize problems of data accuracy and validity. 50 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Routine monitoring of data quality—for example, monitoring indicators, such as the number of errors detected in computerized validity checks and timeliness of reporting by facilities—may also help increase the accuracy of LMIS data. Providing Technical Support Effective computerized LMIS operations rely not only on routine data collection and reporting but also on technical support for backing up the database to ensure continuous smooth operation of the computerized LMIS and for fixing defects and making enhancements. Technical support comprises the following key tasks: n Backing up the database. When the hard drive containing the database for a computerized LMIS crashes, the data may be lost forever. One of the most important elements of technical support is ensuring that LMIS data are backed up regularly—perhaps daily—to avoid losing data as a result of hard drive failure. Technical support providers should plan to regularly back up LMIS data on an external storage medium, such as a zip disk or tape drive. Forgetting to back up data routinely is a common mistake when implementing a computerized LMIS. During implementation, clients and other project participants should look specifically at mechanisms and procedures for backing up LMIS data. n Managing user access. Computerized LMISs, like other information systems, may assign roles and privileges to different users as a way of protecting the integrity of LMIS data. Some users might only enter and update data, others might only view reports, and one or two users may have rights to do anything (administrative rights). Technical support personnel should put procedures in place for adding or inactivating users and assigning roles to these users. In some computerized LMISs, a user with administrative rights may manage user access. n Fixing software defects. When LMIS users identify and report software defects, it is the responsibility of technical support personnel to fix these defects, depending on the severity of each defect— immediately, in the case of a severe defect—or during the next scheduled round of enhance- ments and modifications. n Making enhancements and modifications. Technical support personnel are also responsible for making enhancements and modifications reported by LMIS users. These are typically gathered into a list to be included in the next version of the software. For more information, see the sections on Testing the LMIS and Modifying the LMIS in the chapter on Development and Implementation of a Computerized LMIS. GLOSSARY 51 GLOSSARY atomic A characteristic of a column in a database table, signifying that the column contains only one value. Good database design strives to make all database columns atomic. An example of a nonatomic column is Products Distributed, which might contain multiple values such as amoxycillin, cotrimoxazole, and paracetamol. bug A defect in software that prevents the software from behaving or appearing as expected. Bugs range in severity from blocker (prevents continued development and/or testing of the software) to trivial (cosmetic problem such as misspelled words or misaligned text). (See table 13 for a list of types of severity of software defects.) business rules Critical behind-the-scenes rules that a computerized LMIS must follow, such as adherence to a specified list of products managed by the central medical stores. code A system of symbols and rules used to represent instructions to a computer. A major activity in the development of a computerized LMIS is writing code that instructs the computer how to store, present, and manipulate logistics data. column A data element contained in a database table. Also known as an attribute. computerized Describes an information system that is partly or wholly based on computers. Use instead of automated. development The activity of writing code for a computerized LMIS. fidelity The degree to which a user interface prototype resembles the software that will eventually be implemented. implementation The activity of putting a computerized LMIS into first operation. information system Any system used to collect, aggregate, and report information for decision making. An information system may be completely manual, partly computerized, or wholly computerized. nonkey column Any column in a database table that is not part of the primary key. primary key A column in a database table that uniquely identifies each record in the table, so that information in the table can be found quickly and accurately. A primary key may be a single value, such as the product code, or a combination of values, such as the facility code plus the reporting date. In a well-designed database, all tables have a primary key. 5� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION prototype A model of the user interface of the proposed computerized LMIS, showing all software elements that the user interacts with. requirements Descriptions of how an information system should behave or of a necessary system characteristic. Participants in software development or implementation attempt to gather the requirements as completely as possible at the beginning of a project to implement a computerized LMIS. site map A visual or textually organized model of an information system’s content that allows the users to navigate through the site to find the information they are looking for, just as a traditional geographical map helps people find places they are looking for in the real world. table A data group in a database that describes one object in the real world, such as facility or product. Also known as an entity. third normal form A type of database in which all nonkey columns in each table are mutually independent, i.e., no columns contain calculations or values that are dependent on the contents of other columns. use case A brief description of the interaction between a user and a computerized system to reach a particular goal. A collection of use cases represents the behavioral requirements of a computerized system (i.e., what the system is required to do to meet the user’s business needs). user interface The elements of a computerized LMIS that are displayed to the user for interaction via a computer monitor. wire frames Sketches of the user interface that avoid using layout and colors but emphasize information and placeholders. These user interface-planning tools aid in the development of content and are the basis for user interface design. APPENDIx 1 53 APPENDIx 1 LESSONS LEARNED IN IMPLEMENTING A COMPUTERIZED LMIS (JUNE �00�) Background Appendix 1 reviews existing computerized logistics information systems in five countries—Bangladesh, Jordan, Kenya, Nepal, and Philippines. The goal of the review was to compile a set of updated les- sons—universal truths and best (or worst) practices—that will guide DELIVER’s work to advise on the development and management of computerized LMISs in more complex settings. Research methods were limited to reviews of documents and interviews of staff with mostly historical and, in some cases, current knowledge of the systems in question. After an initial review of documents, three areas stood out as worthy of investigation: (1) organizational context and its effect on sustainability of LMIS operations; (2) mechanisms and resources for development, maintenance, and modifications of the software; and (3) utilization of LMIS data in decision making. These three areas are discussed in the following pages. Organizational Context Organizational context refers to the agency or agencies responsible for operating the LMIS. The context of an LMIS includes the history of its organizational home. Organizational context also refers to the position and status of the LMIS agency within the broader host organization, other functions the agency performs, and the personnel responsible for carrying out these functions. Following are descriptions of how these contextual factors have affected LMIS operations in each of the five countries. Bangladesh Development of the computerized LMIS in Bangladesh began in 1987. From 1987 to 1995, the system was housed at JSI offices and managed by JSI staff. During this period, an MOH employee—the assistant director of the MIS unit of the Directorate of Family Planning (DFP)—was seconded part-time to work with LMIS staff at JSI. At the end of 1995, LMIS computers and operations were transferred to the MIS unit of the DFP. During the first year after the transfer, JSI seconded two of its staff to help ensure continuity of LMIS opera- tions. JSI also paid for consumables (paper, diskettes, and printer toner) during this transition period. Before the transfer took place, JSI decided to simplify LMIS operations. For example, six separate monthly reports were consolidated into one; processing of annual physical inventory data was eliminated; and processing of a form for tracking other health supplies—which had a low reporting rate—was also eliminated. These efforts to simplify were intended to adapt the LMIS to the reduced human resources 54 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION available in the MIS unit; MIS staff were also responsible for processing and reporting on service statistics and thus were not available to manage the LMIS full time. In 1999, the MIS unit in the DFP was transferred to the Directorate of Health Services (DHS) and incorporated into the DHS MIS unit. This was done on the recommendation of the World Bank and other donors, who advocated the integration of previously separate functions within each director- ate. Currently, the MIS unit is one of the few integrated facilities at the central level. Jordan Design and implementation of a logistics information system grew out of a 1997 workshop facili- tated by JSI, in which the MOH and two other host country organizations redesigned the national contraceptive logistics system. The computerized Jordan Contraceptive Logistics Information System (JCLIS) was initially implemented that year at the logistics unit of the Maternal and Child Health (MCH) Directorate (MOH’s maternal and child health arm). While JSI provided the technical resources to implement the system, MOH staff managed many routine system operations, including data entry and report generation. JSI also assisted the MOH in analysis of LMIS data. Kenya Before 1988, distribution of contraceptives fell under the purview of the MOH Medical Supplies Coordinating Unit (MSCU), which was generally responsible for the warehousing and distribution of all public-sector medical supplies. However, the contraceptive logistics system was widely considered to be in poor condition, with problems throughout the supply chain. This situation was generally attributed to the low priority placed on family planning services by both service providers and high-level policymakers. To address the problem, a Logistics Management Unit (LMU) was created within the then Division of Family Health (now the Reproductive Health Division) expressly for the purpose of managing contra- ceptives. This established a separate, vertical logistics system for contraceptives within the MSCU. A computerized LMIS was first implemented in the LMU in 1988. For the first several years, devel- opment and operations of the LMIS were managed predominantly by JSI and other non-MOH staff. Gradually, MOH staff were incorporated into the work of the unit. As of 2002, MOH employees manage most LMIS operations, although JSI still plays a key role in technical and management areas. For most of its history, the LMIS has served mainly two vertical programs: family planning and, later, HIV and sexually transmitted infection (STI) commodities. As a result, it has served a narrow set of regular clients within the MOH, but it has also maintained a focus on donors and nongovernmental organizations (NGOs) as clients. The LMU unit itself has remained institutionally part of the Repro- ductive Health Division. Despite this, it continues to be heavily staffed by non-MOH employees, and there are no MOH counterparts to LMU senior managers and technical staff. The LMU and the LMIS have been identified as potentially playing a key role in the development of an integrated logistics information system. Integration of commodity distribution has been under discussion since 1996 but has not progressed much as of 2002. With the recent expansion of the scope of DELIVER’s activities in Kenya, the computerized LMIS has been moved into an Oracle-based system designed to manage reproductive health commodi- APPENDIx 1 55 ties (for family planning, STI, and HIV/AIDS); tuberculosis (TB) and leprosy products; and several other pharmaceutical and nonpharmaceutical products. The system includes an integrated inventory control and distribution module and commodity-type specific forecasting and quantification modules that support the integrated use of storage, distribution, and basic inventory control forms while still generating reports and providing quantification methods specific to particular health programs. The system has also moved from the Reproductive Health Unit of the MOH to the Kenya Medical Supplies Agency (KEMSA), the new parastatal organization formed to take over the functions of the MSCU. The focus in LMIS development has likewise shifted to capacity building of staff at KEMSA, not only to operate the computerized LMIS but also to further develop it. The goal is for KEMSA to become a logistics services solution center within the MOH, working with different units of the MOH to forecast, procure, store, manage, distribute, and deliver commodities, and collecting essential data on consumption and distribution for use in decision making. Nepal Efforts to develop a computerized LMIS in Nepal began in 1995. At that time, an LMIS unit within the MOH was created specifically to manage the LMIS. While design and development of the LMIS was carried out by JSI, the implementation and operation of the LMIS was contracted out to a local NGO (New ERA) for the first five years (1995–1999). Beginning in 2000, as the New ERA contract came to an end, JSI contracted with another local company, MASS, to manage LMIS operations. Since 2000, MASS has operated the LMIS unit, with USAID funding. The MOH has provided one counterpart staff member, who assists with data management (reviewing and sending feedback reports). JSI continues to provide technical personnel for system maintenance, in addition to some materials and supplies. At the time of its creation, the LMIS unit was institutionally and physically linked to the Logistics Management Division within the MOH. This institutional link has remained stable over time; since its inception, the LMIS unit has been part of the LMD and has not been transferred to other departments. In 2002, it was situated at the highest level of the LMD organizational structure, which gives it responsibility for all logistics information functions within the MOH. One unusual feature of the Nepal LMIS is that from the outset it was an integrated system: it tracks not only contraceptives but also some essential drugs and medical supplies. This is in contrast to the other systems reviewed here, all of which started as strictly vertical systems for tracking contraceptives. Because of the wider scope of products it tracks, the Nepal LMIS potentially serves a diverse group of stakeholders within the MOH and in the NGO and donor communities. The fact that the LMIS is integrated has likely enabled its high position within the logistics division of the MOH. On the other hand, there is some concern about the future viability of the LMIS unit. JSI’s review of accomplishments and lessons learned in Nepal (2000) noted that “at the central level, the LMIS is threatened because of the informal nature of the LMIS unit, its staffing, and its funding.” Although it appears to be well positioned within the LMD and enjoys a wide base of support, it relies almost entirely on donor funding. 5� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Philippines Development of the computerized Philippines Contraceptive Distribution and Logistics Management Information System (CDLMIS) began in 1991. From 1991 through 1998, the CDLMIS was managed within several different departments within the Department of Health (DOH). Within each department, a unit for managing the CDLMIS was specially created. (In other words, it was not incorporated into an existing MIS unit, as was the case in Bangladesh.) During that time, JSI provided all financial sup- port and staffing to operate the computerized system. Beginning in 1999, there was a gradual reduction in JSI staff assigned to help manage the CDLMIS. At the same time, CDLMIS operations were transferred again within the DOH, in this instance from the Family Planning Service (FPS) to the Procurement and Logistics Service (PLS). The transfer included the reassignment of five FPS staff to the PLS to operate the CDLMIS, although the budget to support these staff remained with the FPS. JSI continued to provide 11 staff on a part-time basis to supplement the work. At the time of the transfer of the CDLMIS from the FPS to the PLS, there was some confusion about what specific tasks would be transferred. Originally, the FPS planned to retain responsibility for training and monitoring, in which case it would continue to be an important consumer of CDL- MIS information. Then, there was a change of director at the FPS, and the new director transferred all logistics responsibilities to the PLS. During the 1990s, DOH experienced two agency-wide events that affected CDLMIS operations. The first was decentralization, in which significant decision-making responsibility—including pro- curement—was devolved to the 16 regions. The second was a reengineering effort at the DOH to rectify a shortage in skills in the newly empowered regions. This reengineering effort resulted in ma- jor staffing changes in Manila, including the transfer of many staff trained in logistics and CDLMIS operations to other jobs within the DOH. During these events, the CDLMIS continued to operate as a centralized system at the PLS. By mid-2000, the CDLMIS was being managed fully by DOH/PLS staff with DOH funds; JSI staff were no longer supplementing the work. During 2000, the CDLMIS staff of seven was reduced to two. As a result, CDLMIS data processing was seriously backlogged by six months or more. To determine quantities to resupply, the remaining CDLMIS staff used historical data from a year ago or more, rather than data submitted recently. Lessons Learned n Early host organization commitment and involvement—in the form of staff, in particular— can help integrate the LMIS into the organization’s operations. • In Bangladesh, the MOH contributed the part-time services of one MIS manager when the computerized LMIS was initiated in 1987. When the LMIS was formally transferred to the government in 1995, the MOH provided all operations staff and offices. As of 2002, the LMIS has become an integral part of government operations, although JSI continues to provide significant support in the form of occasional software upgrades and modifications. • Similarly, the MOH in Jordan contributed staff to operate the computerized JCLIS. JSI provided essential technical assistance (especially in the form of software development) APPENDIx 1 57 but, otherwise, did not play an operations role that it would have to transfer to the MOH at a later stage. In addition, a design workshop helped establish host-country ownership of and commitment to the logistics system before JCLIS was created. Within a few years of its inception in 1997, JCLIS had become an essential component of MOH logistics activities. • In contrast, the Philippines computerized CDLMIS was developed and staffed by JSI with donor funds for most of its operational life, so that it largely came to be perceived by the DOH as a donor activity rather than an integral part of DOH operations. As a result, the CDLMIS has not been able to take firm root within the government and, as of 2002, faces the prospect of total collapse. n Incorporating computerized LMIS operations into an existing host organization unit, rather than a specially created unit, gives the LMIS access to established resources and may pro- mote host organization ownership and commitment. n In Bangladesh, the computerized LMIS was transferred into a well-established MIS unit of the MOH that also managed other information systems, including a system for tracking ser- vice statistics. To facilitate the transfer, the LMIS was adapted to the resources available in the MIS unit, which included the part-time contributions of experienced data entry operators and technical support personnel. n In cases in which host organization commitment or resources are lacking, the creation of a new unit within an existing institution can help the computerized LMIS get the resources it needs for initial development and operation. At the same time, additional actions or decisions may be required to promote the longer-term viability of the LMIS. • In Kenya, the creation of a special LMIS unit staffed by JSI was followed by the gradual incorporation of MOH employees into LMIS operations. Despite this, the unit continues to rely heavily on non-MOH employees, and concerns remain about its future within the MOH. However, the LMIS unit has mitigated this risk by expanding its clientele beyond the MOH to include donors and NGOs—additional stakeholders with an interest in con- tinued LMIS operations. • Likewise in Nepal, the LMIS unit was created at JSI initiative especially for the computerized LMIS. The unit has benefited from having the same organizational home for the duration of its existence; this has helped establish the LMIS unit within the MOH. As in Kenya, the Nepal LMIS has reduced risks to sustainability by catering to a larger group of interested parties—in this case, other health units within the MOH, in addition to the family planning unit. • In the Philippines, as well, a unit was specially created to manage the computerized LMIS. But, unlike in Nepal, the unit did not have a stable organizational home; instead, it was transferred to several different DOH departments. Because of this, and because the unit lacked high-level support within the DOH, the unit was not able to become established in the DOH and continued to rely on donor support. Mechanisms and Resources for Software Maintenance and Modification All systems, including well-designed and well-functioning ones, need technical support—to fix defects or malfunctions in the software or hardware, or perform routine system maintenance. In addition, 5� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION systems need technically skilled people who can modify, enhance, and adapt them to constantly changing environments and evolving information needs. Often, it is the successful systems—the ones that do the tasks well that they are designed to do—that come under pressure to expand, as users seek to apply that success to other tasks. Local resources are important to the process of designing and implementing modifications as well as to more routine technical support activities. This section describes briefly the history and current status of technical support for the LMIS in each country and the process for making enhancements to the system. Bangladesh The LMIS started as a spreadsheet application in 1987 and was rewritten in several different platforms over a number of years. Since 1992, the LMIS application and database have been in Oracle, which is the standard technology platform of the MOH. All of these development activities were funded by USAID and carried out by JSI staff through a combination of long-term assistance and short-term visits. After the transfer of the system to the MOH in 1995, MOH staff were trained to provide basic maintenance. JSI continued to provide backup technical support and to plan and implement modifications to the system. Two major modifications occurred within a few years. First, in 1999, to be Y2K compliant, JSI subcontracted with a local technology firm to rewrite the entire application in a newer version of Oracle. Toward the end of the work, JSI/DC staff made a short-term visit to review the work of the subcontractor and provide guidance to JSI staff in Dhaka concerning acceptance testing of the rewritten application. This visit revealed a number of serious software defects that were corrected before the new application was installed. Then, in 2001, the application and database were modified to accommodate the planned unification of family planning and health programs. Two JSI staff (Bangladeshi nationals) based in Dhaka car- ried out development and testing. As of 2002, JSI provides resources and personnel for technical problems that MOH staff are unable to address, as well as any modifications to the system, such as the unification of family planning and health logistics data. Jordan The Jordan LMIS started in 1997 as an implementation of a software application developed by JSI for projects in Thailand and Brazil. For two years, after initial implementation of this application— renamed the Jordan Contraceptive Logistics Information System, or JCLIS—MOH staff actively participated in discussions with JSI about possible enhancements to the LMIS. These discussions centered on JCLIS outputs that would be useful to logistics managers in monitoring system perfor- mance. JSI staff through short-term assistance visits then developed agreed-upon enhancements. At one such visit in early 1999, JSI staff identified the need to hire a local firm or individual to provide technical support to the system. Several months later, JSI’s resident advisor reported that “finding competent computer programming and technical support has been difficult and has slowed down the programming needs of the project.” While there appeared to be competent technical support within the MOH, the MCH Directorate—where JCLIS was located—did not have the clout to access it. APPENDIx 1 59 During the last six months of the JSI resident advisor’s tenure in Jordan, USAID funded the creation of an umbrella health project. After discussion, an informal agreement was reached stating that the new project’s MIS advisor would provide on-call technical support to the MOH senior logistics officer. Kenya As in Jordan, the computerized LMIS in Kenya began in 1988 with an implementation of an existing software application—the Contraceptive Commodity Management Information System, or CCMIS, developed by the Centers for Disease Control. After several years, it became apparent that this system had neither the functionality nor the flexibility to meet local needs. As a result, work began in 1993 on a new system developed in Clarion, which at that time was (and still is) a standard database platform within the MOH. LMU staff (both JSI and MOH staff), who had first received Clarion training in the United States, developed the new LMIS. Development of the new system continued for about two years. Since about 1995, the LMIS has operated smoothly with regular maintenance and minor modifications carried out by LMU staff (JSI employees). Nepal JSI and a local NGO, New ERA, initially developed the computerized LMIS in 1995, with funding from USAID. By 1999 it consisted of three separate components: data entry developed in FoxPro for DOS; reporting on facility errors and on annual dispensed-to-user data developed in FoxPro for Windows; and feedback reporting developed in MS Access 97. In 2000, JSI hired a local consultant to integrate the three components into a single system in MS Access 97. As of 2002, technical support is provided through a JSI bilateral project funded by USAID. Philippines Like the Bangladesh system, the Philippines CDLMIS evolved through a number of technology platforms after it was first developed in 1991. The CDLMIS was maintained and modified by JSI staff or contractors hired by JSI for the duration of FPLM assistance (1991–2000). Donor support for the CDLMIS, through JSI, ended in 2000. Initial development, implementation, and support activities took place without the involvement of the MAS (later renamed IMS), the IT unit of the DOH responsible for supporting the DOH computer network and applications. In an effort to facilitate future support from IMS, in 1996 the application was redeveloped in PowerBuilder with a Sybase database backend, which are DOH standard technologies. Despite this and other efforts to institutionalize technical support (including a formal agreement between USAID and the DOH), the continued lack of technical support from the IMS remained a major issue of concern during the last few years of FPLM assistance. In 1999, the IMS belatedly assigned two programmer-analysts to support the LMIS part-time, although JSI consultants expressed concern that this level of support would be insufficient. In 1999, JSI hired a local technology firm (an affiliate of Sybase) to migrate the CDLMIS to newer, Y2K-compliant versions of the application and database. Several months later, JSI provided short-term �0 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION assistance to upgrade LMIS hardware (server and client workstations). At that time, it was expected that JSI’s role would be to assist the IMS in upgrading the hardware, but the IMS ended up participating only at the end of the upgrade work, mainly because of a failure by PLS staff to coordinate upgrade plans with the IMS. After reports of poor LMIS functioning, JSI staff traveled to the Philippines in early 2002 to assess system performance. During the visit it was noted that the CDLMIS was receiving no support from IMS staff. One of the two remaining CDLMIS staff was providing basic maintenance. Lessons Learned n Implementing an existing application and then adapting it to local requirements can enable a basic LMIS to operate from the outset while LMIS staff gain the knowledge and experience necessary to guide the design of modifications and enhancements. • The Jordan LMIS was based on an application developed for projects in other countries. After implementation of this imported system in 1997, MOH staff worked with JSI for more than two years to identify and design software enhancements that would meet the particular needs of Jordan’s logistics system. • The LMIS in Kenya also began with the introduction of an existing application with pre- defined functionality. The LMIS unit then made a single transition to another technology platform that conformed to MOH standards, after several years of identifying require- ments for LMIS functions specific to Kenya. n Compliance with local technology standards may facilitate the provision of staff by the host organization but does not guarantee the provision of adequate technical support. • In Bangladesh, the conversion of the LMIS to Oracle prompted the MOH to assign employees to support the LMIS, but these employees did not have the skills to fully support it. JSI has continued to provide critical technical assistance to maintain and upgrade the software. • In Kenya, the LMIS was redeveloped in Clarion, the MOH database technology standard, but continues to rely on technical support from JSI. • The Philippines CDLMIS was rewritten in the DOH technology standard within a few years of its initial development, but it has never received regular or adequate support from DOH computer support staff. In this case, the technical capacity exists in-country, but DOH decision makers are not committed to ensuring that the CDLMIS can access it. n Backup technical support can be an effective donor contribution to computerized LMIS operations that are otherwise operated and supported by the host organization. • In Bangladesh, Jordan, and Nepal—where the computerized LMIS is operated with host country resources—donor funding supports essential technical assistance that is either unavailable or difficult to obtain within the host organization. n In organizations where the computer support unit is separate from the unit operating the LMIS, mechanisms that enable the LMIS unit to buy services from the computer support unit may help ensure technical support. • In the Philippines, the unit formally responsible for computer support (the IMS) is insti- tutionally and physically separate from the PLS, the unit that operates the computerized APPENDIx 1 �1 CDLMIS. Such a configuration can be beneficial, because it enables DOH to pool techni- cal resources and skills and make them available to the entire organization. But, in the absence of mechanisms for the PLS to buy services from the IMS, there is little incentive for the IMS to support the CDLMIS. n Outsourcing to local technology firms may be the most feasible and efficient way to make software modifications. This enables the government to buy services from the private sector, as needed, rather than trying to compete with it for technically skilled people. • In Bangladesh, Nepal, and the Philippines, JSI hired local technology firms or consultants to make major software modifications. This approach serves as a model for host organi- zations to follow for future modifications. n Even when the computerized LMIS is managed and supported locally, short-term external assistance can continue to play a vital role through the transfer of skills in software develop- ment process management. • In Bangladesh, JSI provided short-term assistance to review and guide software modifi- cations being done by a local contractor. This visit facilitated the transfer of skills in the critical area of software testing. Utilization of LMIS Data for Decision Making The ultimate measure of an information system is how the information is used to make logistics decisions—both routine operational decisions and longer-term strategic decisions. This section examines the use of data from computerized LMISs in each of the five countries. Also of interest are activities to address information use during the initial design process and activities (formal and infor- mal) to promote information use during the implementation process. Both are important proactive steps to ensure that the LMIS provides useful information and that logistics stakeholders are aware of and understand how to use this information. Bangladesh The main output of the computerized LMIS in Bangladesh is the Family Planning Monthly Logistics Report, which is sent to family planning managers in Dhaka and to managers of central, regional, and district warehouses (a total of 21 facilities). This report presents results by facility on stockouts and potential stockouts, reporting rates, stock status, and consumption trends. The report also ranks warehouses on the basis of the performance of months of stock on hand and provides feedback to the central, regional, and district warehouses on how they can improve performance. At the central level, issues and stock status data are used to inform procurement decisions at donor coordination meetings. A relatively large donor community—consisting of bilateral and multilateral donors—contributes contraceptives to Bangladesh, and LMIS data have proven essential to the complex task of coordinating donor activities. The computerized LMIS enables the MOH to orchestrate the components of this task—namely, determining quantities to order and planning shipment schedules. Central, regional, and district warehouses use this report to compare their performance to other facilities and identify ways to improve their own performance or the performance of facilities they supervise. In theory, higher-level facilities can also use the report to determine quantities to issue to the facilities they supply and to monitor stock balances. �� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION In practice, the report arrives too late to be useful to warehouses in determining quantities to supply to lower-level facilities. To get the timely information they need, some warehouses have developed their own computerized systems for calculating issue quantities. These systems capture the same information that is processed by the central LMIS, but they are used to drive immediate supply decisions rather than longer-term procurement and shipping decisions. Jordan The Jordan LMIS includes a variety of reports designed for use by the Senior Logistics Officer to assess performance of the overall logistics system as well as the performance of individual facilities. The reports are grouped into three types: (1) administrative reports, which include a report listing nonre- porting facilities; (2) graphs, which display average countrywide stock level, couple-years of protec- tion (CYP), dispensed-to- user and service statistics (new and continuing users) by month; and (3) logistics reports, which include aggregate stock movement and facility stock movement. Kenya The Kenya LMIS is comprised of four modules, each of which produces outputs for operation and management of the logistics system. The Forecast module generates about 12 reports that include ag- gregate information on commodity projections, donor commitments, and order tracking from com- mitment through customs clearance. The Inventory Control module produces a variety of reports to assist in the distribution of commodities. The Distribution Resource Planning module produces reports for monitoring and planning distribution of commodities. Finally, the Present module is a tool for organizing reports from other modules into customized presentations, enabling presentation of data targeted to specific decision makers. At the central level, LMIS data are used primarily to plan distribution of commodities to the districts. The data are also used to forecast contraceptive requirements and to identify potential stockouts at the national level so that emergency procurement orders can be placed. At lower levels, district logistics management teams and service delivery providers have received extensive training on operating the manual components of the LMIS. It is not clear to what extent this training focused on data collection versus the utilization of information for improved decision making. Nepal Outputs of the computerized LMIS in Nepal are primarily geared toward central-level managers and to a lesser extent toward managers at the regional level. The system produces several reports that enable managers to assess system operations on a quarterly basis—the reporting status and stock status of each facility in the distribution system. Another quarterly report highlights inconsistencies in submitted reports. In addition, annual reports provide dispensed-to-user data by district, region, or the entire country. These reports have demonstrated significant improvements in logistics management in the country since 1995—most notably a reduction in stockouts. At the central level, they are used primarily to provide dispensed data for procurement planning of selected commodities and to determine quanti- ties to push to districts on an annual basis. At lower levels, the quarterly reports are sometimes used to identify stock imbalances among facilities and to redistribute commodities accordingly. APPENDIx 1 �3 For the manual components of the system, in operation at the regional and district stores and SDPs, JSI has sponsored extensive logistics training focused on data quality and use of information for decision making. Despite these training efforts, JSI’s lessons learned report (2000) states that “within the record system, inaccuracies and errors were common and the reports were not being used for decision making.” In addition, a 1998 donors’ report on the state of the logistics system notes that “there have been complaints from some MOH decision makers, USAID, and other donors that the LMIS feedback reports, as currently formatted, are of limited practical use because they are too long and contain too much raw, unanalyzed data.” Since 1998, annual reports produced by JSI have included summary reports and graphs on quantities dispensed of selected commodities over a five-year period, stockout rates of selected commodities over a five-year period, and projected contraceptive needs. It is not clear to what degree these annual reports address the needs expressed by donors for more summary analyses of LMIS data. Philippines The Philippines CDLMIS produces two major reports designed to assist logistics operations: (1) a summary delivery report, which lists stock status and usage for each facility, and (2) a feedback report designed to alert provincial and regional family planning managers to current or potential problems, such as stockouts, low stocks, calculation errors, or reporting inconsistencies, in the facilities they supervise. The first report has been used by CDLMIS managers to determine quantities of contraceptives to supply to provinces and cities. This determination is based on aggregated consumption reported by all the facilities within that province or city and the stock on hand at the provincial or city warehouse. Total average monthly consumption for all facilities has also served as the basis for estimated annual consumption in the contraceptive procurement tables used by USAID to guide procurement and shipments. Both the summary delivery report and the feedback report are sent to family planning managers in regions, provinces, and cities, every quarter. In theory, they are invaluable tools for monitoring the performance of each facility, identifying and correcting problems, and providing guidance and super- vision. However, it is not clear how regularly and extensively these reports are used by managers to manage the facilities under their supervision. During the first years of CDLMIS implementation, JSI designed a number of reports that calculate CYP, determine the peso value of shipped commodities, and flag unusually high or low consumption for types of facilities or individual facilities. As of 1994, none of these reports were being utilized. In recent years, problems associated with host organization staffing for the CDLMIS (described earlier) have adversely affected the utilization of data. In particular, a chronic shortage of people to enter and manage data has caused a severe backlog of forms. This problem was first noted by JSI consultants in 1997 and was reported to persist by the most recent visit in early 2002. As a result of the backlog, summary delivery reports are not available to help determine quantities to supply to provinces and cities. Instead of using current LMIS data to make these decisions, logistics managers are using historical data or their own judgment. �4 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Lessons Learned n To continue to operate successfully, a computerized LMIS must provide data to support at least one vital logistics decision. • In Bangladesh, the computerized LMIS produces information essential to coordinating the activities of various donors. This has created a large and appreciative audience and helped to sustain demand for LMIS data. • For most of its existence, the Philippines CDLMIS primarily performed one essential task: providing data to central managers to determine quantities to resupply to provinces and cities. As data entry became backlogged in the late 1990s, the CDLMIS could no longer perform this task and, consequently, lost its main usefulness to logistics managers. n There is always some time delay between collection of LMIS data and the availability of the data in a central computerized LMIS. Making this data available in time for routine resupply decisions at lower levels may require significant changes to the computerized LMIS. • In Bangladesh, the monthly LMIS report produced centrally and then sent to lower levels is not timely enough for resupply decisions made at those levels. Longer-term solutions being explored include (1) sending data electronically to lower-level facilities immediately after processing by the central computerized LMIS and (2) moving data processing—and thus the computerized LMIS—down to lower-level facilities. n Successful computerized LMISs include reports and graphs that summarize and present data in ways that are meaningful to analysts, managers, and policymakers. • LMISs in both Bangladesh and Kenya generate reports and graphs that highlight overall logistics system performance, such as total quantities dispensed and stockout rates over time. Both systems have gained the notice and support of policymakers and other donors. • In Nepal, MOH policymakers and donors have in the past complained about a lack of reports that summarize and analyze data from the computerized LMIS. • In the Philippines, the CDLMIS includes reports of potential interest to policymakers within the DOH—such as a report calculating CYP—but these reports were never utilized. The lack of demand for CDLMIS data among DOH decision makers appears to be a major factor in the failure of the CDLMIS to gain political and financial support within the DOH. APPENDIx � �5 APPENDIx � RECOMMENDED LMIS REPORTS AND GRAPhS �� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION APPENDIx � �7 Q U A N T IT Y T O S U PP LY O R Q U A N T IT Y R EQ U ES T ED B Y F A C IL IT Y M in is tr y of h ea lth R un D at e �� -O ct -0 5 A R V D ru g Lo gi st ic s M an ag em en t R un T im e 9: �� A M D is tr ic t R ep o rt a nd R eq ue st fo r D ru gs M on th s C ov er ed : A ug us t �0 05 D is tr ic t: h os pi ta l Z on e: _ __ __ __ __ _ N am e of D T LS : _ __ __ __ __ __ __ __ __ __ __ __ __ __ _ S ig na tu re : _ __ __ __ __ __ __ __ __ __ __ __ __ __ A B C D E F G H D ru g Be gi nn in g Ba la nc e R ec ei ve d T hi s R ep or t Pe ri od Is su ed Lo ss es o r A dj us t- m en ts En di ng B al an ce Ph ys . I nv en to ry (A + B- C )+ /- D Q ua nt ity N ee de d Q ua nt ity Is su ed R em ar ks St av ud in e3 0/ La m iv ud in e/ N ev er ap in e 33 � �, 00 0 1, �9 � �0 0 5, �4 0 0 St av ud in e4 0/ La m iv ud in e/ N ev er ap in e 3, 54 0 1, 0� 0 1, 9� 0 0 �, �4 0 1, �� 0 Z id ov ud in e/ La m iv ud in e (A Z T /3 T C ) 30 0 1, 74 4 0 �� � 0 1, 11 � 1� 0 Z id ov ud in e (A Z T ) 30 0m g T ab le ts 1� 0 0 1� 0 0 0 54 0 Z id ov ud in e (A Z T ,Z D V ) 10 m g/ m l S yr up 0 7, �0 0 0 0 7, �0 0 0 La m iv ud in e (3 T C ) 10 m g/ m l S yr up 37 ,9 �0 4� 0 0 0 3� ,4 00 0 St av ud in e (D 4T ) 30 m g C ap su le s 0 1� 0 0 0 1� 0 �, 40 0 St av ud in e (D 4T ) 40 m g C ap su le s 0 �4 0 0 0 �4 0 4� 0 D id an os in e (D D I) �5 m g T ab le ts 0 0 0 0 0 0 D id an os in e (D D I) 10 0m g T ab le ts 0 0 0 0 0 0 D id an os in e (D D I) �0 0m g T ab le ts 0 1� 0 0 0 1� 0 0 N ev ir ap in e (N V P) � 00 m g T ab le ts 0 0 0 0 0 0 N ev ir ap in e (N V P) 1 0m g/ m l S yr up 15 ,1 �0 9� 0 0 -4 ,3 �0 11 ,7 �0 0 Ef av ir en z (E FV ) �0 0m g T ab le ts 1, 9� 5 0 31 5 0 1, �5 0 0 Lo pi na vi r/ R ito na vi r 13 3 . 3/ 33 .3 m g C ap su le s 1� 0 54 0 0 0 7� 0 0 N el fin av ir ( N FV ) �5 0m g T ab le ts 0 0 �0 0 �0 0 0 13 ,7 70 La m iv ud in e (3 T C )1 50 m g T ab le ts 0 0 0 0 0 4� 0 Is su ed b y: N am e: __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ _ S ig na tu re : __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ D at e: _ __ __ __ __ __ __ __ _ A pp ro ve d by : N am e __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ _ S ig na tu re : __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ D at e: _ __ __ __ __ __ __ __ _ R ec ei ve d at z on e by : N am e: __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ S ig na tu re : __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ D at e: _ __ __ __ __ __ __ __ _ R ec ei ve d at d is tr ic t by : N am e: _ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ S ig na tu re : __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ D at e: _ __ __ __ __ __ __ __ _ �� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION STOCk STATUS BY DISTRIBUTION LEVEL Ministry of health Run Date: ��-Oct-05 ARV Drug Logistics Management Run Time: 9:34 AM Aggregate Stock Movement by Level Report Period: August 2005 All Facility Types Product Opening Closing Months of % of Level # Balance Receipts Issues Adjustments Balance Stock Total ARCOMBIFDC Zidovudine/Lamivudine (AZT/3TC) 1 � �9,5�0 0 1�,4�0 0 71,1�0 1 .0 43 � 145 �3,�30 4�,540 37,1�0 -�74 94,33� 1 .4 57 Totals 147 173,�10 4�,540 55,5�0 -�74 1�5,49� ARDIDAN100 Didanosine (DDI) 100mg Tablets 1 � 13,440 0 1,3�0 0 1�,1�0 13 .7 90 � 145 �15 7�0 15 0 1,3�0 1 .� 10 Totals 147 14,055 7�0 1,335 0 13,500 ARDIDAN200 Didanosine (DDI) 200mg Tablets 1 � �9,�40 0 �3,4�0 0 4�,3�0 � .0 59 � 145 3�,957 1�,�00 15,�9� -1,7�0 31,941 1 .4 41 Totals 147 10�,797 1�,�00 39,35� -1,7�0 7�,3�1 ARDIDANO25 Didanosine (DDI) 25mg Tablets 1 � 73,500 0 �,4�0 0 �7,0�0 10 .0 �5 � 145 1�,050 5,��0 5,1�4 0 1�,0�� 1 .� 15 Totals 147 �5,550 5,��0 11,��4 0 79,10� AREFAVI600 Efavirenz (EFV) 600mg Tablets 1 � 11,5�0 0 �,��0 0 4,��0 0 .1 10 � 145 3�,�59 �3,040 1�,035 454 45,71� 1 .4 90 Totals 147 49,779 �3,040 ��,�95 454 50,57� ARKALET133 Lopinavir/Ritonavir 133.3/33.3mg 1 � 405,900 0 �1,1�0 0 3�4,7�0 4 .� 7� � 145 �7,300 3�,��0 57,1�9 ��,�50 93,041 1 .� �� Totals 147 493,�00 3�,��0 13�,349 ��,�50 417,7�1 ARLAMIV150 Lamivudine (3TC)150mg Tablets 1 � �07,900 �13,540 ��,400 0 395,040 31 .� 99 � �7 �� 3,0�0 �0 0 3,0�� 0 .� 1 Totals �9 �07,9�� �1�,�00 ��,4�0 0 39�,1�� ARLAMIVSYR Lamivudine (3TC) 10mg/ml Syrup 1 � 4,�15,9�0 �,415,3�0 93,�00 0 �,937,��0 �1 .7 95 � 145 310,�00 97,440 ��,��0 -1�,3�0 3�5,040 4 .3 5 Totals 147 4,9��,7�0 �,51�,�00 1�0,4�0 -1�,3�0 7,30�,7�0 APPENDIx � �9 SU PP LY S TA T U S BY F A C IL IT Y M in is tr y of h ea lth R un D at e: � �- O ct -0 5 A R V D ru g Lo gi st ic s M an ag em en t R un T im e: 9 :� � A M R ep o rt P er io d: A ug us t 20 05 A ll F ac ili ty T yp es A ll R ep o rt in g G ro up s Fa ci lit y: h os pi ta l T yp e: S ou th -D is tr ic t h os pi ta l M in im um M on th s of S to ck : 1 .0 Su pp ly in g Fa ci lit y: N at io na l M ed ic al S to re s M ax im um M on th s of S to ck : � .0 A dj us te d A ve ra ge O pe ni ng A dj us t- C lo si ng M on th s M on th ly M ax im um R eo rd er P ro du ct s B al an ce R ec ei pt s Is su es m en ts T yp e B al an ce of S to ck C on su m p. S to ck A m ou nt St av ud in e3 0/ La m iv ud in e/ N ev er ap i A R T R I3 0F D 33 � �, 00 0 1, �9 � �0 0 + 5, �4 0 � . � �, 53 � 5, 0� 4 0 St av ud in e4 0/ La m iv ud in e/ N ev er ap i A R T R I4 0F D 3, 54 0 1, 0� 0 1, 9� 0 0 �, �4 0 1 . � �, �3 0 4, 4� 0 1, �� 0 Z id ov ud in e/ La m iv ud in e (A Z T /3 T C ) A R C O M BI F 1, 74 4 0 �� � 0 1, 11 � 1 . � �� � 1, �5 � 1� 0 Z id ov ud in e (A Z T ) 30 0m g T ab le ts - A R Z ID O V 30 1� 0 0 1� 0 0 0 0 . 0 �4 � 4� 4 54 0 Z id ov ud in e (A Z T ,Z D V ) 10 m g/ m l S A R Z ID O V S 0 7, �0 0 0 0 7, �0 0 99 .9 0 0 0 La m iv ud in e (3 T C ) 10 m g/ m l S yr up A R LA M IV S 37 ,9 �0 4� 0 0 0 3� ,4 00 99 .9 0 0 0 St av ud in e (D 4T ) 30 m g C ap su le s -A R ST A V U D 0 1� 0 0 0 1� 0 0 . 1 1, �4 0 �, 4� 0 �, 40 0 St av ud in e (D 4T ) 40 m g C ap su le s -A R ST A V U D 0 �4 0 0 0 �4 0 0 . � 31 0 �� 0 4� 0 D id an os in e (D D I) �5 m g T ab le ts - A R D ID A N O 0 0 0 0 0 0 . 0 0 0 0 D id an os in e (D D I) 10 0m g T ab le ts - A R D ID A N 10 0 0 0 0 0 0 . 0 0 0 0 D id an os in e (D D I) �0 0m g T ab le ts - A R D ID A N �0 0 1� 0 0 0 1� 0 99 .9 0 0 0 N ev ir ap in e (N V P) � 00 m g T ab le ts - A R N EV IR �0 0 0 0 0 0 0 . 0 0 0 0 N ev ir ap in e (N V P) 1 0m g/ m l S yr up A R N EV IR S 15 ,1 �0 9� 0 0 -4 ,3 �0 - 11 ,7 �0 99 .9 0 0 0 Ef av ir en z (E FV ) �0 0m g T ab le ts - A R EF A V I� 0 1, 9� 5 0 31 5 0 1, �5 0 3 . 5 47 0 94 0 0 Lo pi na vi r/ R ito na vi r 13 3 . 3/ 33 .3 m g A R k A LE T 1 1� 0 54 0 0 0 7� 0 3 . 9 1� � 37 � 0 N el fin av ir ( N FV ) �5 0m g T ab le ts - A R N EL FI �5 0 0 �0 0 �0 0 + 0 0 . 0 �, �0 0 13 ,� 00 13 ,7 70 La m iv ud in e (3 T C )1 50 m g T ab le ts - A R LA M IV 15 0 0 0 0 0 0 . 0 19 4 3� � 4� 0 C om m en ts C om pu te r G en er at ed A dj us tm en t of : � 00 on 0 �- �� -� 00 5 at 1 5: 47 :0 7 fo r St av ud in e3 0/ La m iv ud in e/ N ev er ap in e (D 4T /3 T C /N V P) 3 0/ 15 0/ �0 0m g T ab le ts C om pu te r G en er at ed A dj us tm en t of : - 43 �0 on 0 �- �� -� 00 5 at 1 �: 13 :5 0 fo r N ev ir ap in e (N V P) 1 0m g/ m l S yr up 70 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION S up pl yi ng F ac ili ty F ac ili ty F ac ili ty T yp e R ec ei pt s Is su es / D is pe ns ed C lo si ng B al an ce M o nt hs o f S to ck A ve ra ge M o nt hl y C o ns um pt io n N at io na l M ed ic al S to re s C en tr al w ar eh ou se 4, 95 �, �� 0 45 5, �� 0 9, 4� 3, 0� 0 1� .9 55 7, �1 0 h os pi ta l M un ic ip al ity -D is tr i �, �4 0 1, 95 0 5, 97 0 � . 1 �, �� 0 D is tr ic t h os pi ta l D is tr ic t h os pi ta �, 34 0 7, 40 0 4, 53 4 0 . 4 10 ,� 7� D is tr ic t h os pi ta l N or th -D is tr ic t h 0 4, 55 � 1, �0 0 0 . 4 4, 55 � h os pi ta l N or th -D is tr ic t h 0 0 0 0 . 0 5, �0 4 h ea lth C en te r IV h ea lth C en te r 0 0 0 0 . 0 1, 47 0 D is tr ic t h os pi ta l D is tr ic t h os pi 0 �4 0 5, 5� 0 13 .0 4� � R eg io na l R ef er ra l h os pi ta l M un ic ip al ity -R eg io na l 0 �, 94 0 �, 94 0 0 . 5 �, 04 0 h os pi ta l ( N G O ) h os �0 0 4� 0 5, �4 0 5 . 4 1, 04 0 h os pi ta l N or th -D is tr ic t 1, �� 0 �, 5� 0 �, �� 0 0 . � 3, �� 0 h ea lth C en te r IV So ut h- h ea lth 0 0 0 0 . 0 0 h os pi ta l D is tr ic t 1, �0 0 1, �� 0 1, 74 0 1 . 1 1, �� 0 h ea lth C en te r IV h ea lth 0 54 0 �, 34 0 1 . 9 1, �� � A dv en tis t h os pi ta l w es t- D is tr ic t 9, 1� 0 �, 5� 0 4, 74 0 1 . 1 4, 44 0 h os pi ta l So ut h- D is �, 00 0 1, �9 � 5, �4 0 � . � �, 53 � h os pi ta l M un ic ip al ity -D is tr ic t h o 1, �0 0 �� 0 �, 1� 0 3 . � 1, 59 0 In de pe nd en t h os pi ta l ( N G O ) M un ic ip al ity -D is tr ic t h o 3, 1� 0 �� 0 �, 5� 0 � . � 97 0 D is tr ic t h os pi ta l M un ic ip al ity -D is tr ic t h o �, 7� 0 1, �0 0 1, 5� 0 1 . 3 1, �0 0 R eg io na l R ef er ra l h os pi ta l M un ic ip al ity -R eg io na l 0 �, �4 0 �, 73 5 0 . 3 7, �3 � R eg io na l R ef er ra l h os pi ta l R eg io na l R e 15 ,1 �0 7, 41 0 1� ,9 00 1 . 1 11 ,7 50 SU PP LY S TA T U S BY P RO D U C T M in is tr y of h ea lth R un D at e: � �- O ct -0 5 A R V D ru g Lo gi st ic s M an ag em en t R un T im e: 1 0: 35 A M R ep o rt P er io d: A ug us t 20 05 A ll F ac ili ty T yp es • A ll R ep o rt in g G ro up s St av ud in e3 0/ La m iv ud in e/ N ev er ap in e (D 4T /3 T C /N VP ) 30 /1 50 /2 00 m g T ab le ts APPENDIx � 71 CONSUMPTION AVERAGES BY PRODUCT Supply Chain Manager Run Date: 14-Nov-05 Ministry of health Run Time: 1:15 PM Report Period: August 2004 Health Centre North Health Centers Facility: Area Minimum Months of Stock: 1 .0 Type: health Centre Maximum Months of Stock: 3 .0 Supplying Facility: (Central) Products Average Monthly Consumption A0�30 Albendazole, �00mg - 1000 ��7 A0039 Amoxycillin -1000 10,�71 A00�� Aminophyllin -1000 �,334 A004� Aspirin - 1000 15,005 A0110 Chlopromazine �5mg - 100 ��7 A010� Chloramphenicol �50mg - 1000 0 A0114 Chlorpheniramine - 1000 1,��� A0405 Cotrimaxozole tablet 4�0mg - 1000 11,004 A0141 Diazepam 5mg - 1000 0 A01�5 Ferrous Sulphate �00mg - 1000 4,003 A01�9 Frusemide 40mg - 1000 0 A01�1 hydrochlorothiazide �5mg - 100 3�9 A0�14 Indomethicine �5mg -1000 5,00� A0��� ketakonazole �00mg - 100 0 A0��� Magnessium Trisilicate 4,��� A0��5 Nalidixic 500mg - 1000 0 A00�� Nicotinamide 50mg - 1000 0 A0�9� Paracetamol 500mg -1000 10,337 A030� Penicillin �50mg -1000 �,000 A03�1 Phenobarbitone 30mg - 1000 0 A03�5 Phenytoin sodium 100mg - 1000 0 A033� Praziquantel �00mg - 1000 0 A0334 Prednisolone 5mg - 1000 ��9 A0344 Promethazine hydrochloride �5mg - 100 �51 A0345 Propanol 40mg - 1000 1,��7 A0353 Pyridoxine �0mg - 1000 1,334 A03�7 Quinine 300mg/ml - 1000 1,��7 A0377 Salbutamol 4mg - 1000 3,��9 A0395 Sulfadoxine + Pyrimethamine 500+�5mg - 1000 �,��� A0444 Vitamin A 100,000iu - 1000 0 A044� Vitamin B complex - 1000 3,��9 7� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION DISTRIBUTION DISCREPANCIES Ministry of health Run Date: ��-Oct-05 hIV Test Logistics Run Time: 10:45 AM Report Period: May-June 2005 All Facility Types AIDS Determine hIV ½ Supplying Facility Facility Type Issues Receipts National Medical Stores Central warehouse 157,�00 hospital Municipality-District 3,�00 heath Center IV health Center IV 0 health Center IV health Center IV 0 hospital District hospital 1,500 hospital North-District hos 0 health Center IV health Center III 0 health Center VI health Center IV 0 District hospital District hospital 0 Regional Referral hospital Municipality-Regional Re 0 health Center IV health Center IV 0 hospital District 0 health Center III Central-health C 0 health Center III Central-health C 0 health Center IV Central-health C 0 hospital North-District hos 0 Reproductive health Bureau North-Uganda Re 1,000 health Center IV South-health Ce 0 health Center III health 0 health Center III health 0 health Center III health 0 health Center III health 0 hospital District 1,�00 health Center IV health C 957 health Center III health 400 Medical Center East-Clinic 0 health Center III East-health Ce 100 health Center IV East-health Ce 700 hospital west-District h �00 health Center III health Cent 0 health Center IV health Cent 300 health Center IV North-health 300 health Center III North-health 0 continued APPENDIx � 73 Supplying Facility Facility Type Issues Receipts health Center IV North-health �00 health Center IV North-health 400 health Center III North-health Cent 0 health Center IV North-health Cent �00 hospital Municipality-District hosp 0 Regional Referral hospital Municipality-Regional Ref 0 hospital District hospital 0 health Center III health Center III 0 health Center IV health Center IV 0 Regional Referral hospital Regional Refer 0 health Center III health Cente 0 health Center III health Cente 0 health Center III health Cente 0 health Center IV health Cente 0 health Center IV health Center �0 health Center IV health Center IV 0 hospital South Family Pl �00 health Center IV health Center 0 health Center III health Center III 100 health Center III health Center III 100 hospital work Place Fac 300 health Center III East-health Center IV 100 health Center IV East-health Center IV 300 health Center IV East-health Center IV 300 health Center IV East-health Center IV 0 health Center IV west-health Center 0 Regional Referral hospital west-Regional Refe 3,300 health Center III health Center III 100 health Center III health Center III 100 health Center III health Center III 0 health Center IV health Center IV 300 health Center IV health Center IV �00 health Care Foundation Municipal-health Cent 0 Regional Referral hospital Municipal-Regional Ref 0 health Center II health Cen 0 health Center III health Cen 0 continued DISTRIBUTION DISCREPANCIES (continued) 74 GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Supplying Facility Facility Type Issues Receipts health Center III health Cen 0 health Center III health Cen 0 health Center III health Cen 0 health Center III health Cen 0 health Center IV health Cen 0 health Center II health Center 0 health Center III health Center 0 health Center III health Center 0 health Center III health Center 0 health Center III health Center 0 health Center IV health Center 1,�00 hospital Municipal-District ho 700 health Center II Municipal-health Ce 0 Reg . Referral hospital Municipal-Regional 1,�00 health Center IV health Ce 0 Maternity health Clinic Central Division-Clini 0 District hospital Division-Di 5,400 health Center IV Division-h 0 health Center IV Division-h 0 National Referral hospital Division-R 0 hospital Division-Di 100 Medical Center (FBO) Division-M 1,�00 Police health Center IV Divison-he 0 Community health Center III Division-he 0 health Center IV Division-he 0 District Military hospital Division-Milit 0 Referral hospital Division-Pris 700 Reproductive health Bureau Division-Ug 1,�00 hospital Division-Dist 0 health Center III Division-hea 0 Youth Anti AIDS Association Division-VC 0 Mission hospital North-District 0 health Center IV health C 300 hospital District hos 0 hospital west-District 0 hospital South-Distr 500 health Center IV health Center 0 continued DISTRIBUTION DISCREPANCIES (continued) APPENDIx � 75 Supplying Facility Facility Type Issues Receipts health Center IV South-healt 300 health Center IV health Ce 1,400 health Center IV health Ce 1,500 hospital District hospit 0 health Center IV health Center 1,500 health Center III health Cent 0 health Center IV health Cent 100 District hospital Central-District �00 health Center IV health Center 0 health IV health Center 300 hospital District hospita 0 hospital District hospita 0 hospital District hospital 0 health Center IV health Center I 0 hospital District hospital (N 0 hospital District hospital 0 health Center IV health Ce �,�00 health Center IV health Ce 1,100 health Center IV health Cent 3,000 health Center IV health Center IV 0 health Center IV health Center IV 0 FP Municipality-Family Planni 0 Assemblies Of God Municipality 0 health Center IV health Center IV 0 health Center IV health C 0 health Center III North-health 100 health Center IV North-health 400 health Center III South-healt 0 health Center IV South-healt �00 District Military hospital South-Militar 0 District hospital District hos 0 health Center III health 100 health Center III health 400 health Center IV health 100 hospital (FBO) East-District 0 health Center IV East-health 0 continued DISTRIBUTION DISCREPANCIES (continued) 7� GUIDELINES FOR IMPLEMENTING A COMPUTERIZED LMIS: SECOND EDITION Supplying Facility Facility Type Issues Receipts hospital Municipal-District hos 3,000 Regional Referral hospital Municipal-Regional R 500 hospital District hospit 1,000 District hospital District hospit �00 health Center III East-health Ce 0 health Center IV East-health Ce

View the publication

Looking for other reproductive health publications?

The Supplies Information Database (SID) is an online reference library with more than 2000 records on the status of reproductive health supplies. The library includes studies, assessments and other publications dating back to 1986, many of which are no longer available even in their country of origin. Explore the database here.

You are currently offline. Some pages or content may fail to load.