Guidelines to Decisions on Computerised Drug Management Information Systems A practical manual DRAFT 04-12-10 Guidelines to Decisions on Computerised Drug Management Information Systems TABLE OF CONTENTS CHAPTER 1 ........................................................................................................................................... 1 INTRODUCTION .................................................................................................................................. 1 1.1 BACKGROUND TO MANUAL ....................................................................................................... 1 1.2 AIM OF THE MANUAL .................................................................................................................... 1 1.3 WHO CAN BENEFIT FROM THIS MANUAL .................................................................................... 2 CHAPTER 2 ........................................................................................................................................... 3 DRUG MANAGEMENT INFORMATION SYSTEMS (DMIS) ....................................................... 3 2.1 DRUG MANAGEMENT CYCLE .................................................................................................... 3 2.2 CORE PRINCIPLES OF DRUG MANAGEMENT INFORMATION SYSTEMS ....................................... 4 CHAPTER 3 ........................................................................................................................................... 5 PROCESS IN SELECTING A DMIS ................................................................................................... 5 3.1 UNDERSTAND YOUR BUSINESS .................................................................................................. 5 3.2 IDENTIFY YOUR REQUIREMENTS ................................................................................................ 6 3.3 SCOPE OF PRODUCT ................................................................................................................... 8 3.4 WEIGHT THE REQUIREMENTS AS A MODEL FOR EVALUATION .................................................... 9 3.5 BUDGET LIMITATIONS ............................................................................................................. 10 3.6 COST OF THE PACKAGE ........................................................................................................... 11 3.61 Software .............................................................................................................................. 11 3.62 Additional hardware and installations ............................................................................... 12 3.63 Training .............................................................................................................................. 12 3.64 Recurrent budget for maintenance, upgrades, technical support. ...................................... 13 3.65 Project management consultancy ....................................................................................... 14 3.7 HOW TO APPROACH THE SUPPLIER.......................................................................................... 15 CHAPTER 4 ......................................................................................................................................... 17 EVALUATION ..................................................................................................................................... 17 4.1 DESK STUDY ........................................................................................................................... 17 4.2 DIALOGUE WITH SUPPLIERS / NEGOTIATION ............................................................................ 18 4.3 COST / BENEFIT/ IMPACT ANALYSIS ......................................................................................... 19 CHAPTER 5 ......................................................................................................................................... 20 IMPLEMENTATION .......................................................................................................................... 20 5.1 DEFINE ORGANISATION OF IMPLEMENTATION ........................................................................ 20 5.2 MONITORING AND EVALUATION .............................................................................................. 21 APPENDICES ...................................................................................................................................... 22 APPENDIX 1 ......................................................................................................................................... 23 FLOW DIAGRAM OF PROCESSES IN THE DRUG MANAGEMENT CYCLE.................................................... 23 APPENDIX 2 ......................................................................................................................................... 25 FEATURES AND FUNCTIONS OF AN IDEAL DMIS SYSTEM .................................................................... 25 APPENDIX 3 ......................................................................................................................................... 27 REQUIREMENTS FOR A DMIS .............................................................................................................. 27 A) GENERAL FEATURES ....................................................................................................................... 27 DRAFT B) PHARMACEUTICAL FUNCTIONS ....................................................................................................... 29 C) BUSINESS SYSTEM FUNCTIONS ....................................................................................................... 38 D) INFORMATION TECHNOLOGY FUNCTIONS ...................................................................................... 43 APPENDIX 4 ......................................................................................................................................... 48 EXAMPLE OF A GENERIC QUESTIONNAIRE............................................................................................ 48 APPENDIX 5 MODULES INCLUDED IN THE SELECTED SOFTWARE SYSTEMS ...................................... 57 APPENDIX 6 ......................................................................................................................................... 58 ADDRESSES AND FACT SHEET ON SELECTED SUPPLIERS....................................................................... 58 APPENDIX 7 ......................................................................................................................................... 68 GENERIC CHECKLIST FOR DMIS SYSTEMS (FROM QUESTIONNAIRE) .................................................... 68 APPENDIX 8 ......................................................................................................................................... 70 SAMPLE OF WEIGHTING REQUIREMENTS .............................................................................................. 70 APPENDIX 9 ......................................................................................................................................... 71 APPLICATION OF WEIGHTING SYSTEM IN EVALUATION OF SELECTED SOFTWARE SYSTEMS ................. 71 DRAFT ii Guidelines to Decisions on Computerised Drug Management Information Systems Acronyms AMC Average Monthly Consumption AP Accounts Payable AR Accounts Receivable ASCII American Standard Codes for Information Interchange CIF Cost, Insurance and Freight DMIS Drug Management Information System EIS Executive Information System FAMS Financial and Administrative Information System FMIS Financial Management Information System FOB Free on board FSD Fast moving, slow moving or “dead” IT Information Technology LAN Local Area Network MIS Management Information System NGO Non Governmental Organisation ODBC Open Data Base Connectivity OS Operating System PG Project Group QA Quality Assurance SC Steering Committee UNICEF United Nations Children‟s Fund VAT Value Added Tax VEN-analysis Vital, Essential and Non-essential categories WAN Wide Area Network Y2K Year 2000 DRAFT 3 Chapter 1: Introduction CHAPTER 1 INTRODUCTION 1.1 Background to manual WHO have been contacted on many occasions with the following question….. .``We want to computerise our inventory and procurement systems, can you tell us how do go about it. What sort of Drug Management Information System (DMIS) is required, which particular system should be selected, where can it be obtained from and how much will it cost ´´. The response to this request is highly contextual, there is no one answer that would be appropriate for all situations, but there is a more standard approach that can be used in addressing these questions and that is the focus of this manual. This standard approach can be used at all levels, at the district, regional or national level. 1.2 Aim of the manual Managers are often faced with a need to improve organisational performance. The demand for timely, accurate and appropriate information in order to take effective decisions is crucial in improving efficiency. This may be through computerisation or in setting up or improving manual systems. This publication assumes that basic conditions that support computerisation are already being met in organisations considering introducing a DMIS1, i.e. efficient existing manual systems, and essential reqirements to support the use of computers in any organisation. The aim of this manual is to provide management with some assistance in the decision making processes towards the selection, evaluation and implementation of a computerised DMIS. It will follow a logical step wise approach in addressing this issue. A summary of each stage will be made together with recommendations, and where appropriate, experiences from developing countries will be included. Many countries have already gone through this process, some may be considering it and others may want to improve what is in existence. It is useful to learn from their experiences. In Chapter Two the concept of DMIS is further elaborated. 1 Refer to Chapter 46 of the MSH/WHO manual on Managing Drug Supply (2 nd edition) DRAFT 1 Chapter 1: Introduction Chapter Three will allow managers to examine and describe what is required from a DMIS. Having defined their needs, the issues of costs will be considered followed by how to approach prospective suppliers of DMIS. The process of evaluation will be discussed in Chapter Four describing how a number of systems can be compared with the organisation‟s requirements through a scoring and weighting system. Fnally Chapter Five will draw attention to key issues which need to be taken up during the implemention of any DMIS. 1.3 Who can benefit from this manual The target audience for this manual are managers of drug supply and management systems in the public, semi-public and private sectors of developing countries. They may operate in institutions/organisations at different levels (national, central and district) within a particular country. The scope of manual is not to promote any particular system, i.e. it will not instruct readers in any one particular software or make recommendations for the purchase of a specific piece of hardware or software. Instead, the manual will highlight major criteria that can be used in the process of selection, evaluation and implementation. It will provide some information on some systems that are available, both commerically and non-commercially. However, these are by no means the only systems available and each country will need to carry out their own market research on available systems. Also the criteria used for selection, evaluation and implementation are those of the authors, those in the field may select different criteria to suit their own environment. The selected system will be based on the particular requirements, environment and constraints that individual managers are confronted with in a particular organisation/institution. DRAFT 2 Chapter 2: Drug Management Information Systems CHAPTER 2 DRUG MANAGEMENT INFORMATION SYSTEMS (DMIS) 2.1 Drug Management Cycle Any drug management cycle will include four basic functions: selection, procurement, distribution and use of drugs (Figure 1). Selection Management support systems Procurement Use Storage & Distribution Fig. 1 Drug Management Cycle At the centre of the drug management cycle is a core of management support systems: organisation, financing, information management and human resource management. These management support systems hold the drug management cycle together. It is improtant to note that there are linkages between the support systems and the drug management cycle and that any weak link in any of these areas will ultimately affect the availability, accessibility and affordability of drugs. DRAFT 3 Chapter 2: Drug Management Information Systems This manual will focus on DMIS systems required for organisations whose main functions involve procurement, storage and distribution. However, although there is a focus on the latter functions the same DMIS system can also support the other functions of the drug management cycle, namely use and selection, e.g. with an ABC analysis. Procurement involves the quantification of drug needs, selecting procurement methods, establishing contract terms, and assuring drug quality and adherence to contract terms. Storage involves functions such as inventory control and store management whilst distribution involves clearing customs, collection of consignments delivered by air/sea/road and delivery to drug depots and health facilities. 2.2 Core Principles of Drug Management Information Systems A Drug Management Information System (DMIS) is an organised system for collecting, processing, reporting and using information in decision-making within the context of drugs and medical supplies. Access to reliable information is one of the most important management tools. The build-up of an effective DMIS is important in the process of managing a drug distribution chain, to ensure that available and affordable drugs are purchased and distributed in a timely and cost-effective way. The focus of a DMIS is on the flow of goods from different locations. This means that there is a focus on purchase/receipt, inventory control and on sale/distribution of drugs. Supplier and customer databases are required to handle these transactions, including the need to handle both the quantities of drugs being moved throughout the system and the value of the drugs. Thus, financial control becomes important in tracking drugs from the point of purchase, through storage to the point of sale. Appendix 1 highlights some of the major steps in the process of drug procurement, storage and distribution. This report focuses on Drug Management Information Systems in the following areas: procurement, storage (inventory control and store management) and distribution including sales. This means that the system is an amalgamation of drug management, inventory control, purchase and sales, and financial management information systems. Additional supporting systems can include transport management (as a support to sales) and human resource management (as a support to general organisational management). An ideal DMIS system, a „benchmark‟ providing information on all major business operations is described in Appendix 2. DRAFT 4 Appendix 3: A checklist of features and functions of an ‟ideal‟ DMIS CHAPTER 3 PROCESS IN SELECTING A DMIS 3.1 Understand your business It is important to gain an intimate knowledge of the major operations of the organisation, the processes and tasks that need to be performed to carry out the business objectives of the organisation. This process will involve a thorough analysis of what is currently in place, where there are problems or shortcomings, why they exist and where improvements are required. It will also involve obtaining detailed knowledge of how the organisation‟s DMIS is currently operating, if functioning well or poorly, whether there are manual systems in place and whether these are documented as standard operating procedures (SOP). The next stage is to develop an Information Technology (IT) strategy. It will guide the organisation in defining what kind IT infrastructure is required to be in place/replaced to support the business in general terms. The DMIS system may handle inventory but may require a supporting system, e.g. financial system to manage the accounts. Thus, an IT strategy should link the different functions of the organisation, so that the introduction of any computerised system into any business area is more uniform, and therefore more easy to support. The IT strategy will also consider three main points: distribution boundaries and levels of functionality Some medical stores can comprise a head office and multiple warehouses based in different regional areas. A decision will be required whether to have a centralised system, where data are consolidated from the distributed offices, which would require good communication links or whether to have autonomous regional offices, each with its own complete system. Centralising or distributing systems has an important impact on management organisation and structure and on the implementation of any system The introduction of any computerised system will have certain boundaries that will be dependent on the options selected and also on the human-computer levels available. The latter involves the skills and level of ability of staff within the organisation which may create boundaries on the type of system selected. DRAFT 5 Appendix 3: A checklist of features and functions of an ‟ideal‟ DMIS Finally, computer systems support the operations of the business, thus the level of support that a new/revised system should provide should also be determined. This can be defined in terms of functionality and the level of functionality required from any system. This will be discussed further in Section 3.2. At the end of this stage all the major business processes will have been analysed and an IT strategy developed. At this stage it is important to make a decision whether to look at all areas requiring improvement or to focus in on specific areas, i.e. to computerise finance and accounts ahead of inventory control, procurement, human resource management or transport. Recommend: Look at all major processes in a holistic manner, but try to prioritise in particular areas as it may not be realistic to computerise all areas at once. The main focus in Zimbabwe, Government Medical Stores was to introduce a computerised system for inventory control and procurement (INVEC-2) before a computerised financial system. However, the emphasis in Tanzania’s Medical Stores Department focused on a computerised financial system (Navision) ahead of a system for inventory control and procurement. Both of these countries are now reviewing their existing systems as neither system provides them with the full functionality that they require. 3.2 Identify your requirements After developing an IT strategy, and deciding to focus on a specific area, there is a need to identify the requirements that a system should provide, i.e. the features or facilities that are desired from any system. Requirements may be those that will resolve or reduce the problems in an existing system, and those that are new functional abilities which the current system cannot provide. Requirements are divided here into four main areas of functionality and described briefly in this section and in detail in Appendix 3: Pharmaceutical Business System IT Specific General Under the pharmaceutical, business and IT specifications the terminology ‟essential‟ and ‟desirable‟ are introduced. Essential functions are those, which in the opinion of the authors, are considered as the basic requirements for the organisation to carry out its major busines processess in an optimal manner. The desirable features are those which are not considered as essential, as the organisation can function without them, however their inclusion would improve the overall efficiency of the organisation. The classifications of essential and desirable are contextual and will differ according to the size of the organisation, its environment and its functions. A checklist of features and functions of an ideal DMIS are provided overleaf. DRAFT 6 Appendix 3: A checklist of features and functions of an ‟ideal‟ DMIS What do you need? A checklist of features and functions of the “ideal” DMIS PHARMACEUTICAL CRITERIA BUSINESS CRITERIA Logistic forecasting Finance module 23. Accounting dimensions 1. Drug/budget needs forecasting 24. Audit trial 2. ABC analysis 25. Budgets 26. VAT support Distribution/dispensing drugs 27. Reports 3. Therapeutic category analysis Accounts payable Tender processing module 28. Supplier database 4. Tender request report 29. Integration 1. Adjudication report 30. Reporting 2. Supplier performance monitoring report 3. Tender awards list Accounts receivable 31. Customer database Procurement management 32. Integration 7. Purchase order generating 33. Reporting 8. Calculation of minimum stock 34. VAT calculation 9. Out of stock report 10. Currency conversion and adjustment for trade Reporting terms 35. Previewing reports 11. Order status report 36. Selection criteria 37. Sorting criteria Inventory management 12. Receiving report IT CRITERIA 13. Quality assurance record 14. Product list with specifications 15. Updating inventory databases Technical hardware information 38. Operation system 16. Stock detail report 39. Data entry 17. Inventory adjustment report 40. Printing facilities 18. Expiry stock report 41. Network/Scalability 19. Expiry date analysis or expiry risk report 20. Stock control performance indicators Technical system information Sales and distribution module 42. System base/Adaptability 21. Picking list - Functional list 43. Compatibility and capacity 22. Return goods handling 44. Size of entries 23. Stock allocation by expiry date & batch traceability System/ Data security 45. User ID and passwords 46. User access control 47. Year 2000 Compliance DRAFT 7 Chapter 4: Evaluation Pharmaceutical Specific pharmaceutical functions are related to logistical forecasting, tender management, purchase order, sales order, distribution and inventory modules are described. Points of interest for the purpose of managing pharmaceuticals and medical supplies are for example the capability of handling batch numbers, expiry dates, long product names, traceability of products to suppliers and batch specific quality entry. It is important to consider not only functions that are required at the current time but also those that may be required in the future, with the development of the organisation, e.g. bar coding, print bar code labels, internet electronic commerce, etc. Business System Business system functions include: finance, accounts management, the generation of reports, human resource management and transport management. The requirements for business functions in a DMIS system do not differ from requirements for business modules in most other systems. As in other settings, the need for flexibility in report generation output will be essential. Likewise the systems capabilities of providing standard reports and options for outlining own reports. IT Specific IT specific characteristics are related to technical requirements, hardware, system environment, disaster recovery, data security, integrity and compatibility with other software in other local offices with which the system interfaces, data input and transfer of existing data into a new system. General General requirements are related to issues such as the supplier, training and future developments. Of particular interest to those in developing countries are those suppliers with experience of their systems in these countries, the possibility of local support and the type of layout and language on screens and reports. 3.3 Scope of product Obtaining one system which could fulfill all the organisations‟s requirements would be an ideal solution, but it may not always be possible, at least not to the level of functionality that is desired. Here one may need to consider the advantages /disadvantages of having: a single product which fullfills all requirements, to a lower level of functionality, separate products/modules for different requirements, e.g. for finance and inventory control, DRAFT 8 Chapter 4: Evaluation two integrated systems, e.g. one for drug management /inventory control and a second for financial management. With pharmaceuticals, some basic core functionality is required: stock management, accounting, customer sales, procurement, management of tenders; and perhaps others, human resource management, transport management, and so on. All this functionality may not be found in one product, but the total solution could be obtained from combining a number of different products together. Similarly, some components within a product may be very good, whilst other components may be weak. It may be possible to combine the strong components from different suppliers to make up the whole system. However, the disadvantage in combining components from different sources is the greater risk for something to go wrong. If the system purchased is a single product, then at least it is known that the components do function together. Pulling together the best performing system from multiple products is always a balance between need and risk. If a solution can be accepted from as few products as possible, this will reduce the complexity of the final system. In some cases there may be no choice other than to accept a combination of different products as the solution. Therefore, issues of compatibility and performance must be ensured between these products to a level that covers all the organisation‟s eventualities. In any case, this option will require considerable and thorough investigation and testing, such as investigations of other organisations carrying out similar combinations, and whether vendors are prepared to offer guarantees that the combined solution will perform to the organisations‟ expectations. Finally the enviroment in which the organisation is operating is important as this will decide what type of system and combinations of systems are required, single site / single user, single site / mulitiple users, multiple sites / single user, multiple sites / multiple users. Recommend: Ensure participation in all stages, the more that staff are involved from the very early stages in the decision making processes, the more empowered they will be and the more sustainable the whole process will become. User examples 3.4 Weight the requirements as a model for evaluation From Section 3.2 a list of requirements will have been generated which should form the basis of an ideal system. These requirements can be submitted to a range of suppliers in a common manner and is discussed further in Section 3.8. However, before this is carried out there is a need to look at the requirements and decide what aspects are more important than others and then to weigh them in terms of importance. It is important to carry out this step at this stage as it will form the basis of the evaluation process, discussed further in Chapter 4. DRAFT 9 Chapter 4: Evaluation There are various methods for weighting preferences, one example is provided in Appendices 8 and 9. Note: Weighting future requirements may not be considered to be of high status at the current time but should be included in the evaluation process to determine how the various packages might meet these requirements in the future. Recommend: User examples Summary 3.5 Budget limitations Budget limitations will guide what options an orgnisation has in terms of procuring a commerical or non-commercial system, develop an in-house system or abandoning the project. The costs of the entire operation need to be considered here, not only that of the software (see Section 3.6). It is important to have some idea of the funds available and the prices of the systems, and other related costs, even at this early stage. All commnercial systems are built to satisfy as wide a range of customers as possible, the more a system can be developed to meet everyone‟s needs the more that system will cost. Any financial gap between the needs of the organisations and resources to meet those needs will need to be addressed, and options considered, i.e. look for other sponsors, phase any implementation plan with for example inventory control aspects before financial, downscale the whole programme, abandon. Recommend: User examples: Malawi, Mali, Rwanda, Nepal, West Africa – all developed their own systems, Zimbabwe, Yemen, Cambodia Tanzania and Uganda all used commercial packages. At various stages all used external expertise to either advise, develop, install and/or implement their systems. User examples: Cost of INVEC in Yemen and Zimbabwe. Total implementation costs for INVEC-2 in Yemen, in 1996, was estimated as approximately UD$ 20,000. This involved ? number of sites, number of users per site, using inventory and procurement modiules. In Zimbabwe, in 199?, for a more integrated system of INVEC-2 the total implementation costs amounted to approximately UD$ 640,000. Procurement and DRAFT 10 Chapter 4: Evaluation inventory control modules were used. INVEC-2 was installed in 7 different locations (1 headquarters with 25 users, 2 regional stores with 16 users each, 4 provincial stores with 6 users each). The costs were only for the software and did not include: the network, new servers, training, implementation and support. Tanzania Medical Stores Department are currently (in 1999) investigating the cost of a package that will provide them with ’all’ their needs, Business, Pharmaceutical, Transport, and HRM and include costs for installation and training. Their annual turnover is equivalent to USD . Installations will be required in Dar the headquarters and 8 Zonal stores in different locations around the country. Data will be consolidated on a regular basis at Dar. The funds currently allocated to this project are UDS 0.5 million. This does not include hardware. 3.6 Cost of the Package When considering the entire costs of the package, all the following should be considered: software, additional hardware and installations training recurrent budget for maintenance, upgrades, technical support management consultancy At this stage it may also be useful to consider the costs of developing an in-house system or procuring a commercial or non-commercial package, and the advantages and disadvantges that both would confer. 3.61 Software Pricing of software is extremely difficult, it is multifacted and the way in which companies price their products varies enormously. The licence is normally based on number of users, locations and modules Table: Licence details of selected software systems ERIK System Software Licences based on Modules concurrent users or named users CLM Ver.2.06 Free Concorde XAL Prices available Ver. 2.65 Gemedic Dos Ver Free 2.2 DRAFT 11 Chapter 4: Evaluation INVEC-2 Ver 1.5 Free Navision Financial Prices available Ver 1.3 based on c-shells per granule SAP R/3 Ver 4.0A Get prices Sun Systems Ver Get prices 4.2 Nepal system Free Lawson Prices available Licences are often divided into two types, those which involve ‟concurent users‟ and those which involve ‟named users‟. Concurrent users require less user licences, are more flexible and ensure a high level of accountability, i.e. for the audit trail. For named users, individual licences have to be purchased for each user. This can result in users sharing passwords and is ulitmately less accountable. Note with non-commercial systems where the software is free, what recall does an organisation have if the supplier is not performing well? It is important that even with ‟free‟ software, a contract is drawn up with the supplier, covering all the issues of contractual oblgations. Include price comparison of the different suppliers by providing 2 scenarios of 2 different situations in orde to compare prices. ERIK to action. VR to circulate and obtain feedback. Recommend: Depending on the number of users in any location, it is probably better to purchase licences for concurrent users rather than named users. User example: 3.62 Additional hardware and installations Apart from the hardware requirements, it could be expected that any DMIS used would be carried out in a multi-user environment. This may be in the form of a WAN or one or more LANs. Thus, there is a requirement that the DMIS is capable of handling a network installation and large amounts of data, which are input from a number of locations. Communication using the Internet or other data communication would also be an advantage - both for data entry and extraction. This sets some minimum requirements for hardware and response times, including an operating system which can handle network installations 3.63 Training Training can be split into three areas: DRAFT 12 Chapter 4: Evaluation Training to use the new system Training to use peripheral applications (word-processing, spreadsheets, etc Technical training in supporting the new system and the network Apart from the costs of training staff in the first two categories it is important to consider the costs of training selected staff within the organisation, as technical staff to provide front-line support. This will ensure that the organisation gradually becomes more independent and only refers to the suppliers in difficult situations. User example: Total implementation costs for INVEC-2 in Yemen, in 1996, was estimated as approximately UD$ 20,000. This involved ? number of sites, number of users per site, using inventory and procurement modiules. In 1999, further training was required on the implementaiotn of INVEC-2 in invoicing, the costs for 2 weeks of technical support from MSH Washington amounted to USD ? 3.64 Recurrent budget for maintenance, upgrades, technical support. Maintenance Maintenance plans will add to the overall and continous costs, but they are a matter of negotiation and can make repairs and replacements cheaper in the long term. Costs of hardware failure in terms of the cost of repair as well as the time and effort involved and the overall cost to the business (loss of business) should be considered. Some form of continued assistance may be required from the supplier, once a system is installed, as the process of integration and change is likely to continue beyond the terms of the intial contract to supply and install, these csts should also be considered. Annual maintenance fee for the software licence-- erik Technical support The issue of technical support, whether this is local, regional or international is extremely important, as it is likely that there will be many reasons to contact the supplier: business issues, implementation issues, technical queries, modifications, unfrosen problems…..and so on. Although electronic communication channels are improving, there is often a need to have local support close at hand. This means that the choice of supplier is based on its ability to provide good local support. In order to ensure that a supplier can deliver it is important to consider the following: 1. The size and composition of the supplier 2. Number of staff , number involved in product support, technical support, where these staff are based 3. Qualifications of staff DRAFT 13 Chapter 4: Evaluation 4. Are they accreddited with any international organisations 5. What kind of support do they offer. Future upgrades Whether an in-house system is built or a commercial or non-commercial system is procured, there will always be a question of future upgrades. Questions to consider here are: 1. Is the manufacturer of the system investing in new functionality? 2. Will technical support be provided for a product that customers are no longer purchasing 3. Transfer/convertsion of data from an existing system to an upgraded version 4. Suppport and maintenance of upgrades. Note the more changes that are made to a standard package, i.e. customised to the need of the organisation, the increase in the costs in the long term of future upgrades. Everything depends on the quality of the original standard package. Recommend: Upgrades are more probable where there is a high demand for a system, which is supported by an organisation committed to maintaining state of the art technology. The programming language of the system will offer some indication of the organisations commitment, if it is an obscure language there is a high probability that the manufacturer will not be able to maintain it. User example: Uganda NMS and JMS have customided Navision DOS, a fianancial system to their needs in order to handle pharmaceuticals. Navision Financials Version 1.3 is an updated form of the programme in a Windows version, what do Uganda do? Changing from their DOS version to Windows version may require more funds, can their customised programme be replaced by the Windows version without loss of their functionality?. ’Swedis’ was a DMIS system developed in Sweden and implemented in. Botswana. Technical support for the system was only provided from Sweden. The developer of the system, Pharmasoft are apparently no longer providing technical support, what does this mean for Botswana? INVEC-2 is currently DOS based, MSH are considering changing it to a Windows version, what is the situation for the countries who have invested in the DOS programme? What are the costs involved? 3.65 Project management consultancy This question could be raised at the start of this manual but has been included in this section as it has a cost implication. Selecting and evaluating computerised DMIS involves considerable technical knowledge and expertise, if there is insufficient capacity within organisation to undertake this process, a third party will need to be DRAFT 14 Chapter 4: Evaluation required. The costs of recruiting the third party who may be local, regional or international, even if only to undertake certain aspects of this process, need to be considered with the overall costs of computerisation. User examples: Do it yourself or get external expertise.Examples of costs for external assistance in selecting and evaluating software systems: Tanzania MSD (Coopers and Lybrand) Yemen (Cranfield) Cambodia (MSH) Malawi (expatriate working in medical stores). Recommendation 3.7 How to Approach the Supplier At this stage a small market research exercise is required to determine what systems are available. Contact addresses are given for some systems described in this publication (Appendix 6) but they are by no means the only suppliers and it is advisable to look at what systems are available locally and internationally which would meet the organisation‟s requirements. Once requirements have been identified, the next step is to decide how to approach the supplier. If it is by tender, will it be openly advertised or restricted to a selected list of suppliers. When evaluating different systems it is important to have a method by which all the systems can be compared in a uniform manner. Having the findings in a common format will make it easier to explain or promote the final decsion to senior management or other project stakeholders. The responses from suppliers will never be in the same format unless a common reply structure / format is selected. It is important that the organisation take some time in preparing this presentation and the detail of questions required to ensure a successful implementation so that suppliers are clear on what they are expected to supply. The questionnaire in Appendix 4 may offer some guidance together with the information in Appendix 3 on requirements and supplier information. Some further issues to consider in the tender document could include the following: 1. Template for the proposal to obtain a uniform answer that will help in the evaluation process. 2. System demonstration, using the organisations own test data so that staff can relate to the reports and screens. This may also indicate how easy it is to transfer data from any existing system to the new system. DRAFT 15 Chapter 4: Evaluation 3. Site visits (references of other users). 4. Contract (wording) should stipulate what the client expects to be delivered, how and when, etc. This also applies to what is expected from the supplier in terms of their performance, i.e. what, when and how the supply is undertaken. 5. Ask suppliers to present their software in written form or as a presentation. Let them come up with estimates. Recommend: User example: From zimbabwe - ERIK DRAFT 16 Chapter 4: Evaluation CHAPTER 4 EVALUATION 4.1 Desk Study The evaluation process can take considerable time if carried out properly. It is important that it is fair and transparent process. From Section 3.2 requirements will have been identified for an ideal system. Each of the responses needs to be evaluated and scored against the ideal system. Guidelines should be provided on how to evaluate, what criteria are used and if any weighting of responses is undertaken according to importance or bias (see Appendix 8). At this stage the evaluation should only consist of a desk study, demonstrations and site visit should only be undertaken after this stage is complete. The evaluation process will include strengths and weakneses of each system and how these interface with other systems and will also include an evaluation of the supplier. One point of concern may be the issue of customisation. If one supplier states this is possible and another claims that it is not possible, how is this evaluated?. ERIK Recommendation: User example: Zimbabwe Medical Stores In 1997 it was considered that INVEC-2 could not meet all the accounting requirements of the Medical Store and a search was carried out for a system that could provide both procurement / inventory control attributes as well as accounting needs. Three systems were shortlisted, Navision Financials, SunSystems and MFG Pro. A major reason for shortlisting these companies were the issue of local support in Zimbabwe or the region and the fact that the systems were commercially available.This latter point was considered important for two reasons. Firstly that a sufficient pool of qualified personnel would be available to provide implementation and technical support when required by the client. Secondly that upgrades were more likely to be developed by commercial systems than non-commercial systems, ensuring a future commitment in terms of software. The staff in Zimbabwe looked at their requirements, weighted them and then evaluated each of the systems against the weighted requirements. In their context Navision Financials met most of their requirements (utilising a customised version which was being developed in Uganda that would incorporate inventory and procurement aspects). DRAFT 17 Chapter 4: Evaluation Next the functionality of the systems were compared against the prices of the systems, a cost/benefit analysis. The range of the prices were from 7 –10 million Zimbabwe dollars (1US$ = ? Zimbabwe $). What was the result? That none of the systems were used due to financial problems. Instead a short-term solution was required and a simple accounting package was procured that could meet the basic accounting needs. 4.2 Dialogue with suppliers / negotiation Once a shortlist has been developed from the previous section, demonstrations of systems and field visits to reference sites can be undertaken. It is unlikely that any single system can provide an organisations with all its requirements within its resource envelope, for example, a particular system may cover 80% of the organisations requirements, what decision is taken about the remaining 20% that cannot be covered by the system. There is therefore a need to undertake a dialogue / negotiation with the supplier. Does the organisation have the capacity to handle these negotiatians? Discussions with suppliers will provide some information on their potential to perform, but it is important to have staff involved who understand the technical issues and can provide feedback to senior management. Some of the questions that can be addressed to the suppliers could include the following: can the system be customised towards ones needs will the customisation affect future upgrades can the system interface with other standard packages, i.e. Excel, Access, etc. if system does not provide all the organisations requirements, can one forget about the 20% and use manual procedures will upgrades in the future cover the outstanding 20% Various options will arise from the evaluation process, all these options will have cost /benefit/impact implications. These are discussed further in the next section. Recommend: A brief estimation If package provides< 60% of needs, abandon and develop own system. If package provides > 80% of needs, think about it but consider what to do about remaining 20%. It package provides between 60-80% of needs, consider customising the package or developing own system. User examples: Cost benefit analysis in Zimbabwe DRAFT 18 Chapter 4: Evaluation 4.3 Cost / benefit/ impact analysis A cost/benefit analysis seeks to measure the total costs of the new system against the total expected benefits to be gained. In theory, it is a means of qualifying justification for a new system. In practice, “total costs” can be difficult to measure as they include tangible and intangible costs. Tangible costs are where a direct financial cost can be attributed. It can be the purchase of an item or a service; the costs saved in displacing staff either to perform other duties or being made redundant; or freeing up more time to be able to perform a new business activity. Intangible costs are where no accurate figures can be provided, for example improved customer perception of our organisation‟s performance. Such costs can be difficult to quantify and be realistic. There are many ways of performing a cost/benefit analysis, each as difficult to do properly as the other, and each as much criticised as the other. However, the analysis can provide an indicator of justification if we have the time and resources to carry it out. Example purchase costs are hardware and software, upgrades, network implementation, system implementation, user training. Example operating costs are consumable items, and resources to operate and support the new system. An impact analysis measures the effects the new system may have upon our user environment. There may be required changes to the organisation‟s structure during the conversion phase or afterwards, e.g. the warehouse layout may undergo physical restructure, new departments created or removed. There may be changes to user operating procedures, staff numbers, staff types, and perhaps changes to staff contracts or grades. Depending on the size and complexity of the new system being brought in, it is worth spending effort thinking about how our organisation may change, and the issues, constraints, and advantages this may bring about. The various options highlighted in the previous section will need to be costed. There may be a need to divide the various activites and these can be highlighted when a plan of implementation has been developed. Different items can be tendered for separately with different cost estimates. At the end of this process a choice will be made Recommend: Must consider all the costs possible, not just those of the programme. Also the software should be selected before the hardware. User examples: In Zimbabwe the installation process in GMS included several local companies: *(ERIK) Compulink – cabling network GMS/ Burco/ IDATA – training IDATA – installation MSH – programme DRAFT 19 Chapter 5: Implementation CHAPTER 5 IMPLEMENTATION 5.1 Define Organisation of Implementation The implementation process will involve drawing up an implementation timetable and deciding at what levels within the organisation decision making and implementation actually take place. In this example, the following is suggested: A Steering Committee, Project Group and specific Working Groups should be set up. Membership of these various group, committees will be decided, including their responsibilites, reporting structures, and how often they meet. They are described in more detail below: Steering Committee (SC) Membership The Head of the Steering Committee should be the client with representation from supplier. Functions 1. They identify the Project Group to implement the operations. 2. Develop the strategy of implementation. Have to consider the following: one site /multiple sites one module on all sites at the same time or test it on one site then roll it out onto others more than one module on one site or multiple sites, or test on one site then roll out. run 2 systems in parrlal, how to test double entries of old and new system, then compare results big bang, shut down old system and open with new system 3. Responsibilties include: - monitor progress/performance of the project implementation - handle requests for changes which often have a financial impact - liaise with supplier as necessary Project Group Membership ERIK Function Responsible for the overall plan of implementation. Take decisions on a day to day basis on the running of the system. Report to the Steering Committee. DRAFT 20 Chapter 5: Implementation Working Group Membership ERIK Functions Assigned tasks which are responsible for, e.g. testing of system, supplier side systems development, installation of cables, installation of hardware, etc. Report to the Project Group. Recommned: Include implementation, maintenance, routine operations. Plan progressive implementation (one step at a time) and involve current and future users in the design and implementation process. Develop an implementation plan. User examples 5.2 Monitoring and evaluation An introdcution of a computerised system is assumed to improve overall efficiency and thus performance of the organisation. Therefore indicators should be developed and measured before any installation as well as at regular intervals after the installation to determine the impact of computerisation. Computerised DMIS systems support the business processes by facilitating the more routine aspects of the work, freeing staff to carry out more strategic orientated activity. The results should be evaluated with management with the view to improving other areas of the business process, in an iterative manner. Recommend: Decide on some benchmarks before the implementation process starts, test at regular intervals and make adjustments as necessary. User examples DRAFT 21 Appendicies APPENDICES DRAFT 22 Appendix 1: Flow Diagram of Processes in the Drug Management Cycle Appendix 1 Flow diagram of processes in the drug management cycle In this context the drug management information systems will be defined as all steps included in the process of procurement and distribution. This can be depicted in a flow diagram: STEPS METHODS 1. Estimating drugs/ medical supply needs Quantification of drug requirements must be based on reliable estimates of actual need. The following methods can be used: consumption morbidity data estimated budget requirements adjusted consumption prioritisation based on VEN/ABC/therapeutic category analysis 2. Evaluating financial situation Good, reliable financial management is essential and includes: preparation of long-range plans, budgets, cash-flow and estimates of resource needs control of the collection, safekeeping and use of funds monitoring of proper accounting system, setting of sales prices and efficiency monitoring 3. Purchasing process Good Pharmaceutical Procurement Practices should be applied. In the procurement cycle the following must be considered: procurement method contracts other sources for drugs (donations) comparative drug price date order status supplier performance DRAFT 23 Appendix 1: Flow Diagram of Processes in the Drug Management Cycle 4. Receive / Quality Control In the receive/Quality Control process the following measures must be taken: inspection of shipments laboratory testing expiry date analysis storage conditions lead-time analysis quarantine 5. Storage/ Inventory management the following inventory information factors are essential to the order estimation/reorder system and appropriate storage of goods average monthly consumption supplier lead-time safety stock/ minimum & maximum stock levels storage capacity and locations 6. Transport/delivery In the supply chain, transport management is important in ensuring drug availability to users. Here it is important to consider: transport alternatives planned delivery routes vehicle maintenance manpower planning 7. Distribution /Dispensing Information on rational drug use can be extracted from this level, such as: % of total drug expenditure accounted for by antibiotics/injections % of total drug expenditure accounted for by registered/essential drugs 8. Human resource management Alongside this flow-chart will be the personnel management process, where information will be of major importance to managers in planning and organising the present workload and future tasks. In the human resource management process it will be important to know: job description personnel qualifications/training needs/payroll DRAFT 24 Appendix 2: Features and Functions of an Ideal DMIS Appendix 2 Features and functions of an ideal DMIS system The Ideal Drug Management Information System, defined as a benchmark, will be able to process operational information in all areas of drug supply chain for a complete business environment, from the pharmaceutical functions to the more general areas, such as finance, accounts and personnel information. Other enterprise functions and more detailed pharmaceutical functions are mentioned but will not be discussed further here. Logistical forecasting is an essential feature in a DMIS, since this very complex and time consuming process can be performed much quicker and produce much more accurate data at any given time compared to being done manually. A tender processing module should be given high priority as an essential function since it enables simplification of what is otherwise a complex process. The process is classified as essential, even if it can be done either manually or by use of other tools such as a spreadsheet. Integration of tenders into the overall management systems is regarded as so essential that other methods are hardly acceptable. Procurement management is an essential function providing timely data without the delays inherent in producing data manually. Drug availability is of such importance that ensuring it in the best possible way is vital and for that reason the best tool for this process is an integrated procurement module - regarded as essential. Inventory management will be essential for the purpose of providing timely information to both the procurement and sales department, even if stocktaking has to take place regularly to ensure the reliability of the data. A sales module can provide access to stock information quickly and update stock information immediately an order has been processed. In a decentralised drug distribution system, where financial responsibilities have been delegated to district level, it will be of major importance to provide accurate sales data to the district and a sales module will thus be essential. Financial and accounting management modules will streamline and speed up the data handling process, as well as improving the reliability of the data. Fixed assets are a desirable function, which will often be used together with a financial and accounting module. Transport management is a newly developed software functionality that has been of great value in various vaccine distribution programmes. DRAFT 25 Appendix 2: Features and Functions of an Ideal DMIS Personnel management modules will be of importance in an environment where human resources contribute considerably to the total drug management cost. Other enterprise functions: For the overall management of a business enterprise in the drug distribution chain, some of the following features can be useful, but will not be considered in detail: General-purpose software: word processing, spreadsheet, database Project management Communication: E-mail, Fax Other related functions used in the pharmaceutical sector Other software programs have been developed for the purpose of drug control, but these will not be discussed in the context of software available to the drug distribution chain: Drug registration Drug information Rational drug use Health statistics Data presentation DRAFT 26 Appendix 3: Requirements for a DMIS Appendix 3 Requirements for a DMIS A) General features SUPPLIER INFORMATION Besides general information on the different software suppliers, such as company name, address and contact information, some supplier related information is regarded as desirable and, indeed, essential to establishing a reliable business relationship. Evaluation of information made available to the purchaser will be essential in the process of selecting a computerised Drug Management Information System. Company reliability and sustainability In the process of selecting a company, whatever the company‟s field of operations, essential information must include "number of years company has been established", as this can indicate the sustainability of the company. Additionally, company management capacity and customer satisfaction is reflected in annual turnover and company size. Availability of local support Availability of local support for maintenance of computers and programs is an essential requirement that must be given high priority in the supplier evaluation process. Local support and the presence of other users of this or similar software systems in the region/area are important, as this helps ensure a high level of after-sales service from world-wide distributors. Information on countries in which the company concerned is represented, the world-wide distribution of the system and guaranteed support response time are regarded as essential criteria for evaluation. Company policies and strategies Software companies have their own company policies and strategies. In the supplier evaluation process it is important to ensure that no company policy or strategy is directed against the service level and values preferred by the user. Questions concerning the company support policy, strategic alliances, strategic direction of the company, maintenance policy and distributor selection strategy are all questions essential to the evaluation process. References - appropriateness Through familiarisation with references for the implementation of similar programs, either in part or in whole, new customers will be able to judge for themselves the appropriateness of the software application. The software supplier can also be asked to provide further information. Responses should be used to determine the compatibility of the software with the intended program application. TRAINING Training method Training of staff is the key to maintaining good computer services in the daily operation of the program, and at least two members of staff should be competent to operate each specific computer program in the selected software system. Different methods for implementation of initial and follow-up training exist. The initial training will most often take place as on-site training and therefore training personnel must be suitably qualified. DRAFT 27 Appendix 3: Requirements for a DMIS Training availability and materials To ensure training accessibility, a certain number of training personnel must be available for on-site training. Together with on-screen or manual-based training materials and self-tutorials available for follow-up training after implementation, training availability must be ensured. Measures for training personnel and ensuring materials availability are essential in the company selection process. DRAFT 28 Appendix 3: Requirements for a DMIS B) Pharmaceutical functions LOGISTICAL FORECASTING – ESTIMATING DRUG NEEDS Drug/ budget needs forecasting – Consumption method Essential Of the various methods of drug needs quantification, the final choice of method will be based on the type and reliability of data on drug usage, patient utilisation and morbidity patterns. The consumption- based method is often the first choice, since it provides the most reliable data provided that inventory records are available, reliable and updated. The consumption based quantification formula for determining quantities to be ordered includes information on average monthly consumption, average lead-time, time out of stock, procurement period and safety stock. This function is essential in any automated procurement process, but also the possibility of making manual adjustments to this formula must be considered essential, since components in the formula may change over time, e.g. procurement period Drug needs forecasting for budgetary purposes, e.g. for the coming year, based on previous consumption and expected pack price will be an essential function. For this forecasting method, the option of implementing adjustments to program expansions or strengthening in connection with disease patterns (spread of HIV/AIDS) etc. must be available. Drug needs forecasting using consumption-based methods to facilitate drug distribution at district/community level is regarded as an essential feature. In a decentralised health system many activities will be decentralised, including drug budget financial management. For that reason it is of key importance that financial management and drug management at district level have the possibility to plan and budget accordingly. A needs analysis in accordance with VEN classification is essential for district/community level users with limited budgets, who will need to be able to estimate the cost of purchasing things such as essential items. ABC analysis Essential Due to restricted budgets for drug purchasing in many countries, prioritisation is usually necessary. Various methods can be used for this purpose, e.g. VEN analysis, ABC analysis or therapeutic category analysis. The VEN system is a system for setting priorities for the purchase and for keeping stock of drugs. Drugs are categorised according to their health impact into vital, essential and nonessential categories, and purchasing prioritisation is determined by this categorisation. This grouping is a specific pharmaceutical method and is not used in more general computerised management information systems, as opposed to ABC analyses, which are commonly used for priority setting. The VEN system analysis is not regarded as essential, since it is a fairly simple function that presumably can be easily included in any suitable system. A therapeutic category analysis applies cost-effectiveness and cost-minimisation methods to help select the best drugs for treating common diseases. This type of analysis will be essential/desirable in the process of selecting drugs and preparing essential drug recommendations, but is not appropriate to the drug management cycle under discussion here. An ABC analysis is a method by which drugs are categorised according to their annual usage in terms of unit cost time‟s annual consumption. Under this system, class A drugs are those which account for 75-80% of drug spending (due to high unit price and/or high consumption), class B drugs are those with intermediate usage rates and class C drugs are those with low usage rates (accounting for 5-10% of total drug expenditure). This analysis is essential in a system that has to be capable of rationalising drug expenditure, since this group of drugs accounts for the major part of drug expenditure – a key consideration at all levels. The DRAFT 29 Appendix 3: Requirements for a DMIS ABC analysis will be important in the drug selection process, drug procurement, determining order frequency, monitoring procurement priorities, and in inventory management for monitoring of shelf life, planning of delivery schedules and decisions on the frequency of stocktaking. The argument presented for systems application at national level also applies here. ABC analysis is considered essential at the district/community level with its restricted budgets. Estimating drug needs for multiple points sales Desirable Drug management information network systems set up nationally for different regions cover distribution of similar drugs from several outlets. Where disease and drug use patterns differ from region to region, it is important to oversee drug consumption in all regions, since central warehouse distribution will reflect only the average consumption and not specific seasonal distribution by regions. For example, an outbreak of communicable disease in one region and a corresponding increase in the use of specific drugs can, given extensive knowledge of the country, be extremely useful in drug forecasting for neighbouring regions, and at national level in forecasting the drug types and quantities to be purchased. In the case of a district where a number of health facilities purchase drugs from the same budget, a features for drug needs estimates for multiple points sales will be desirable. DISTRIBUITION/DISPENSING AND RATIONAL USE OF DRUGS Functions will be regarded as desirable rather than essential. There can be several reasons for investigating drug use and drug spending: e.g., to determine current drug use patterns, correct specific drug use problems and/or monitor drug use over a period of time. Expenditure on specific drug groups Desirable System functionality to determine expenditure on specific drug groups can be desirable in the process of identifying problems with regard to drug prescribing patterns for the purpose of correcting the patterns so as to reduce expenditure on drugs at the national/regional level. Therapeutic category analysis Desirable Here the volume and value of various therapeutic categories of drugs are analysed. This analysis will form the basis for decisions on drug selection and drug procurement. It can also be used to identify problems in connection with irrational drug use, such as the percentage of total drug expenditure accounted for by antibiotics or injections, or the use of certain drugs relative to disease patterns, which could indicate misuse of drugs. Analyses of use/expenditure according to department, prescriber or level of care would be essential. WHO drug use indicators NA In 1993 WHO/DAP and INRUD published a manual on "How to Investigate Drug Use in Health Facilities". This publication describes in detail 19 indicators for measuring drug use in health facilities, e.g. % of drugs prescribed by generic name, % of patients treated without drugs. Some of these indicators, desirable for health managers interested in drug dispensing analyses, can be calculated using the computer based system – hence this function is considered desirable for DMIS implemented at district/community level. TENDER PROCESSING In most computerised systems for drug management at international and national level there is a need and an obvious preference for purchasing acceptable quality drugs at the lowest possible price. Open and restricted tenders, rather than competitive negotiation and direct procurement, are known to have DRAFT 30 Appendix 3: Requirements for a DMIS the best effect on drug prices, and for this reason it can be argued that a tender module is highly desirable under virtually any circumstances. A tender module will facilitate easy handling of the tender evaluation, while module integrity with the rest of the system will increase accuracy in integrating tender contract specifications into a procurement module. The first step in the tender process will be to decide on the format of the tender (open or restricted), which drug(s) should be requested in tender papers and in what quantities. These decisions could be based on consumption patterns as described above. The establishment of a tender request report is regarded as desirable but not essential, and the same applies to the tender awards list and the possibility of generating contracts based on this list. The essential elements of the tender module are: Tender Request Essential Quantification of drug needs, as mentioned above, can be based on different methods and can be carried out as a more or less centralised process. A decentralised quantification process can be extremely time consuming and result in estimates being outdated by the time they are incorporated into a final tender request. If reliable consumption data exist at regional/district level, it may be desirable to utilise a tender request module at district level with the possibility of subsequent adjustment, to be forwarded directly to the centralised procurement officer. Alternatively, the tender request report and specified list of items required can be made at central level based on consumption/cost data and reorder levels. Regardless of the level of use, the tender request report can save much time and effort while supplying data with a much higher degree of accuracy, assuming reliability of data entry. Adjudication report Essential To prepare an adjudication report, all information related to offers and suppliers must be entered. For this purpose appropriate numbers and space for entry of evaluation criteria must be available. Evaluation criteria can include product fulfilment of basic requirements concerning strength, unit size, tablet coating etc., and supplier compliance with basic requirements such as delivery dates, previous performance etc. Assuming relevant information input, the software should be able to compile the adjudication report and enable side-by-side comparison of offers. In the event that the tender evaluation committee wishes to weight the evaluation criteria differently, the software should allow for this. This function should be given high priority as a desirable function. Supplier performance monitoring report Essential To ensure the appropriate quality of drugs purchased, not only is careful supplier selection important but also supplier performance monitoring, as this forms the basis for future purchase orders. From the database it must be possible to prepare a supplier performance list, including for each supplier: Previous orders and deliveries Previous quality of products and packaging Previous adherence to delivery schedules, timeliness, supply in accordance with requirements and contract price versus invoiced price Level of service provided, e.g. suppliers return policy on expired drugs A high priority function, not only for the purpose of tendering but also for general procurement activities, is considered desirable. Tender awards list Essential A list of all tenders awarded, whilst a helpful tool for the procurement unit, is much more essential with regard to maintaining transparency in the tender process. By issuing a tender awards list to all bidders containing itemised supplier/price information, non-conformance to tender evaluation criteria can be objected to. This process puts pressure on the tender evaluation committee to make their evaluation criteria objective and to a certain extent enables fraudulent tender evaluation to be avoided. DRAFT 31 Appendix 3: Requirements for a DMIS The tender awards list is essential, but the software system feature that enables such a listing is only rated desirable, since an awards list can fairly easily be drawn up by hand. Manage simultaneous tenders Desirable Depending on the selected procurement method and procurement frequencies, some national drug distributors may wish to have a software system able to mange more than one tender at a time. Tender contract-generating Desirable On the basis of the tender awards, contracts must be drawn up with suppliers in which every condition of the contract is correctly formulated. Many contract terms are standard specifications, but some terms will require additional input, requiring precise and accurate formulation of requirements and specifications, e.g. those pertaining to quality standards, shelf life of products and packaging. A software feature to assist in this process can be desirable but not essential. PROCUREMENT PROCESS Purchase order-generating Essential A purchase order form or reorder report that is generated automatically when the reorder level is reached is essential to avoid out of stock situations. Information requirements for establishing a consumption-based reorder formula can include some or all of the following factors: average monthly consumption (AMC), supplier lead time, safety stock, reorder level, stock position (on hand/on order), maximum stock level and procurement period. This mathematical calculation model is much easier handled by an automatic calculation from data already available in the database than if performed manually - and also results in much more reliable results. The results thus generated are then entered on a purchase order form together with the following information: product description, supplier information (if any), on tender Yes/No, stock situation - on hand/on order, last purchase price, order quantity recommended and order value. Calculation of minimum stock Essential The minimum stock level or reorder level will determine at what time a new order should be calculated and placed. Calculation of minimum stock is, as can be seen, closely related to the purchase order calculation and is equally essential to the purchasing process. It will be only natural to specify software systems that are able to calculate minimum stock, average monthly consumption and reorder quantities. Out of stock report Essential An out of stock report will be a listing of all items in the product range, which are out of stock on the day of printing. Besides information on products and suppliers, this list should also contain information about stock on order and delivery dates. This report is essential as a support function for the purchase reorder generation feature, since in extreme situations it will show when a top-priority purchase is necessary. Currency conversion and adjustment for trade terms Essential In dealing with international trade/tenders, quotations will be given in different currencies. To eliminate a major cause of miscalculation, it is important that the computer can easily handle currency conversion. The possibility of data entry of foreign currency and computer handling of conversion to a common currency is regarded as essential. Since international suppliers submit quotes using different trade terms (FOB, CIF, Flight), it is important in the collating process to allow for these differences, as quoted prices will invariably include major variants based on differing freight payments etc. This is why adjustment for different trade terms is of importance in the procurement/ tender handling module. DRAFT 32 Appendix 3: Requirements for a DMIS Order status report Essential An order status report, purchase order pending or overdue report lists all items, together with their delivery status, where delivery has not taken place or where delivery dates have not been met. These lists are of importance in drawing the attention of suppliers to outstanding matters and are also of benefit in evaluating supplier performance. These reports should allow for searches to be performed covering a given time period per item and/or per supplier. This is an essential function at national level as drugs are usually ordered from many suppliers during international competitive bidding at national level. This information is important in order to avoid emergency procurement, as many suppliers do not stick to the delivery times. Price comparison features Desirable Given the restricted financial resources, which are a feature of virtually all health programmes, the costs of drug procurement are of extreme importance. But there are also other costs related to drug procurement, e.g. loss of products due to poor packaging, replacement costs for drugs that expire in stock, and the cost of suffering and diseases not treatable due to certain drugs being out of stock. A decision on the method of procurement for each drug should take these considerations into account By comparing procurement prices with prices from other systems, e.g. those of neighbouring countries, or the prices listed in International Drug Price Indicator Guide, managers will obtain a picture of the system‟s procurement efficiency, method of procurement and sources of supply. A software feature that can go online to retrieve international drug prices and prepare purchase price comparisons for current stock is a desirable function in a DMIS. But this process will not be regarded as essential, since it can be performed manually and is an activity that does not have to be performed many times a year, but could be done e.g. once a year. Entering pharmaceutical supplies from donors Desirable In many developing countries drug donation will be an issue best handled at national level. Guidelines for drug donation and methods of integrating drug donation into the regular drug supply system should be decided nationally. In some software systems the procurement process is closely linked with inventory management, making the entry of non-purchased drugs a problem. If drug donations are entering the country on a regular basis it is important to ensure a feature that enables computer entries of such drugs. For systems applied to NGO supported units, where drug donation occurs, a feature for entering pharmaceutical supplies from donors will be an essential function. This caused by the requirement from many donors on accountability for donated drugs. Port clearance report Desirable Port clearance procedures are often a time consuming process due to the inefficiency with which many port facilities are run. This process can in many ways be costly in terms of man-hours, port storage charges, tie-up of capital funds, damage to goods, insurance claims handling and delays to drug supplies. A port clearance software feature able to keep track of goods, port clearance papers, port clearance activities, reports of supplier inefficiency in shipment handling, damaged goods and insurance claims, and able to monitor causes of delay, will be a desirable feature which can be a cost- effective tool in dealing with such matters. INVENTORY MANAGEMENT/RECEIPT/QUALITY CONTROL Receiving report. Essential Listing of orders received by item for a day, a specified period or by source. This list will show date of receipt, total quantity, invoice price and any damage or loss. A receiving report is a valuable tool in the receiving process, showing the basic information that must be entered to update the drug master file so that it reflect physical stock changes. The data entered can also be used to check accuracy of invoice DRAFT 33 Appendix 3: Requirements for a DMIS prices, supplier performance/monitoring of timely delivery, quality control data and as a record for insurance claims. Receiving reports will be essential for the smooth running of a receipt unit. Quality assurance record Essential Physical inspections of all shipments and targeted quality control activities will be part of the overall quality assurance (QA) policy implemented at national level in most countries. It is important to maintain clear records of QA activities relating to goods received in stock. Therefore there should be entry fields in the receipt report for QA findings. Depending on the results of quality assurance activities, this entry will result in the product being either released for distribution or kept in quarantine until a final decision on the product flow has been made. This specific pharmaceutical related feature, although considered essential, is not included in many DMIS. This is most probably due to the fact that many DMIS are general management information systems that have been adapted to the pharmaceutical area. Often this problem is circumvented by simply not entering goods with QA problems in the receipt record until a compensatory agreement is reached e.g. with the supplier. This procedure can lead to important management information not being entered into the system. Information is then only available upon request, which is not a satisfactory solution. Product list with specifications Essential Computerised procurement and inventory management on a large scale needs to be handled by a database program. The simplest report from a database will be a printout from the drug master file (the product file in the database). For example, the drug master file can contain identification information on the product (name, dosage form, strength, unit/package size), classification information (ABC/VEN/pharmacology and storage); consumption related information (average monthly consumption, safety stock level, minimum stock) supplier information (previous suppliers) and price information (purchase and sales prices). From this database information it will be possible to compile different reports containing specified information. This will, for example, enable the management to produce an updated stock list with product specifications and sales prices, for use as a product sales list. Investing in a DMIS will result in this type of report making becoming an essential standard request. Updating inventory databases Essential Some of the benefits of computerisation are to simplify and speed up complex tasks, increase data integrity, and update and access information quickly, making information in the system accurate and timely. An essential requirement of the software program will be that the purchasing/tendering program can be integrated with the inventory management system. The automatic updating of the inventory database when procurement has been performed, supplies delivered, stock issued and sales completed, either simultaneously or on a regularly daily basis, will be an essential function. Stock detail report Essential There are numerous simple reports that can be retrieved from the basic database program, which will prove useful tools in daily management. Most of them will be supplied as standard reports as a function of the program, but simple preparation of non-standard reports based on information in the database should also be enabled. An inventory report on the stock balance of all items, with information specified in quantities by item/ batch and/or allocation. This will be a simple essential report compiled from information in the general database. DRAFT 34 Appendix 3: Requirements for a DMIS Inventory adjustment report Essential Either from stocktaking or due to waste of drugs, it can be necessary to make a database inventory adjustment to reflect the physical stock. It will therefore be important to have a stock adjustment function included in the system. An inventory adjustment made available after all stock adjustments have been completed will be essential for the purpose of controlling stock adjustment and, for example, to prevent unauthorised individuals from entering fraudulent changes to the stock balance. At the same time, stock adjustment reports with information on the reason for the adjustment can be an essential management tool for controlling losses and waste. Expiry stock report Essential Another simple and essential database report is an expiry stock report, containing a list of stock items which have expired or are due to expire in the coming months. It will be essential to monitor expiry dates. Follow-up on this information will ensure removal of expired goods in stock, thus avoiding distribution of expired drugs. Expiry date analysis or expiry risk report Essential A more advanced expiry report is the expiry data analysis or expiry risk report, which not only retrieves basic information from the database but also performs simple calculations. An expiry risk report will list all stock items at risk of expiry in stock, based on information on stocks, expiry dates, previous consumption (AMC) and remaining shelf-life for products. An expiry risk report can be extremely helpful in tackling the problem of expiry of drugs in stock, since this report serves to notify managers of the current expiry risk and hence the steps they can take to avoid or minimise projected losses. Stock control performance indicators Essential Several indicators can be mentioned as essential for stock movement information. For example, it will be of extreme importance to know and have indicators for which drugs are fast moving, which are slow moving, which are not moving (dead) - FSD classification - which are overstocked and which are at risk of expiry. This information, combined with the ABC and VEN analyses, will provide the basis on which to decide e.g. purchase frequency. Lead time analysis Desirable A systematic analysis of the components affecting lead-time, i.e. the time that elapses from realising a drug must be purchased until it is in stock. Lead-time will be influenced by factors such as reorder level monitoring, method of purchase, supplier delivery times, port clearance, receiving procedures and any quarantine period. To perform a lead-time analysis, records should be kept for all milestone dates in the purchasing process. This data is then used to perform automatic lead-time analyses, cross-comparisons of suppliers and cross-purchase process analyses in order to identify the major factors affecting lead-time. This, in turn, enables improvements to the purchasing process to be implemented. Receipts report for specific periods Desirable This function can make information available on which items are still physically in the receipt area and to determine the receipt workload for specific periods. This function is considered desirable in the context of overall storage management and personnel time management. Stocktaking forms/physical stock inventory report Desirable Regular stocktaking is necessary, e.g. for the purpose of reordering and determining inventory value. If this process is performed in the computerised system, it is recommendable to perform physical stocktaking from time to time to ensure the accuracy of the data in the computerised system. A helpful tool in the stocktaking process is the production of computerised stocktaking forms – a functional list DRAFT 35 Appendix 3: Requirements for a DMIS that includes information on product, identification code, strength and unit size. The forms also serve as an important stock classification tool, particularly with regard to product storage, racking and shelving, thereby considerably easing the work of stock control, stocktaking and order selection. The use of stock taking forms facilitates both the counting process and the inventory adjustment procedure. Automatic expiry notification Desirable Many software systems enable on-screen notification of activities that have been entered in a calendar. This feature could be desirable for use in connection with drugs that have reached their expiry date but which are still in stock. Such a notification could appear either when the expiry date has been reached or when products within, say, three months of their expiry date are selected for issuing to regional/district or community level health facilities. Multiple warehouse implementation Desirable A desirable feature for users at international/national level could be the possibility of setting the system up in multiple warehouses and from central level being able to monitor drug levels and consumption in each warehouse. This set-up could be desirable in a decentralised system in countries where central level can support the overall organisation of drug distribution and allocation. SALES AND DISTRIBUTION Picking lists - Functional list Essential In all so-called drug distribution, "pull" systems or independent demand system orders of different kinds will be entered in the drug distribution system one level above where the order is given. This is often done by means of requisitions. When orders are entered into the computer system for invoicing, it will be essential to the administration of drug distribution that picking lists be based on both order and by physical location. The possibility of designing a pick list that accords with stock placement ought to be considered an essential feature. Returned goods handling Essential Even in the best handled drug distribution system there will be situations where, for different reasons, drugs will be returned from a lower to a higher level in the distribution chain. At national/district level the system must be able to receive returned goods from a lower level and to handle goods to be returned to suppliers. The computerised drug management information systems must be able to keep records of these returned goods handling procedures and claims, so as to reflect the size of the problem and the reasons why problems are occurring. A returned goods report must describe the situation in relation to the overall size of the problem, the amount of money involved and the reason for the return. Stock allocation during order processing Essential It is desirable to have a computerised DMIS that can allocate stock immediately orders are processed, so as to ensure that stocks are actually available for distribution. Otherwise clients must be contacted and the order adjusted (change of quantity or product specification). Stock allocation by expiry date and batch traceability Desirable To reduce expiry costs, stock-handling procedures such as first-in/first-out or first-expiry/first-out have been introduced. The programmed allocation of stock according to expiry date is considered a desirable reminder for use of this handling method. However, as long as employees are responsible for physically picking stocks from shelves, human error can never be entirely ruled out. DRAFT 36 Appendix 3: Requirements for a DMIS Where products are withdrawn from the market, batch traceability is important. If products are allocated to clients according to expiry date and using batch numbers, and assuming that users adhere to system guidelines, it will be possible to trace batches to the receiver. Client consumption analysis and budget Desirable In sales and distribution, function records will be maintained in the computerised system to facilitate financial administration, invoicing etc. Activities will not be limited solely to procurement management and inventory management. Using the same database program for procurement, inventory management and accounting is recommendable and desirable, since these activities are closely interconnected. Not only is it desirable to prepare financial overviews for each client for the purpose of controlling drug expenditure, but also the preparation of an overview of client drug consumption would be an important indicator of rational drug use. Emergency orders Desirable A situation in which vital drugs are found to be out of stock at a lower level can result in the placing of an emergency order. In this situation it is desirable that the software system is able to prioritise this type of order. This can be done using a special emergency indicator for emergency orders being entered into the DMIS. This indication should appear on the picking list, delivery note etc. It should be made impossible for a delivery to a client to be processed without inclusion of any emergency orders placed by the same client. Stock reservation for sale Desirable Under certain circumstances at national/district level, it may be necessary to reserve stocks of some drugs for specific clients and hence desirable to enter such reservations in the computerised system. DRAFT 37 Appendix 3: Requirements for a DMIS C) Business System Functions FINANCE Accounting dimensions Essential It is assumed that all finance systems have at least one accounting dimension: a Chart of Accounts. However, in larger installations this one accounting dimension is insufficient. Often, departmental and/or profit centre accounting is required as well. The number of dimensions required can vary greatly, but usually two or three are required as a minimum. This is important for control purposes. If multiple dimensions are supported by the system, different levels of control can be assured - heads of departments can track and monitor those expenses, which are directly attributable to them. It is also important that these dimensions are supported throughout the system and in different modules, to ensure that all transactions entered into any of the modules can be „tagged‟ with the correct dimensions. Additional overview of the information retrieved is gained if the different dimensions support a hierarchical structure - i.e. elements can be grouped and subgrouped. Audit trail Essential An audit trail allows users and auditors to track financial transactions, which have been entered into a system. This ensures e.g. that the list of transactions entered into a system is detailed enough to allow for „backtracking‟ of financial entries. Based upon the audit trail, the chronological order and method of entering financial transactions into the system should be able to be recreated. This allows e.g. for errors to be tracked and corrected. In addition to keeping track of every transaction entered into the system, there are a number of additional facilities, which may also assist the process. This includes ensuring that only balanced transactions may be entered into a system and that, once entered, transactions cannot be modified in any way. Also, checks for entering vouchers twice and allowing templates to be entered may further reduce the risk of errors being entered into the system. Budgets Essential One of the main aims of utilising a computerised financial management system in an organisation is to increase managerial information for better decision making. In this respect, financial budgeting and control is an important issue. If a system is capable of handling budgets and budget comparisons, it increases the system usability. Budgets can be made on several different levels - in particular with relation to the accounting dimensions (e.g. departmental budgeting) - and over different time periods. As a minimum, a budget system must allow budget figures to be entered for selected cost items (from e.g. the Chart of Accounts) on a monthly basis. Variations on this can include departmental or project budgets prepared on a weekly or quarterly basis. If different budgets can be handled simultaneously, it is possible to make budget comparisons based upon e.g. different revised budgets. VAT support Essential In the purchase and sales of drugs, VAT calculation will become an issue in certain situations. The finance module must ensure that VAT can be added and deducted at set rates in order to fulfil the necessary reporting requirements. This should be integrated with any accounts receivable or payable modules. Reports Essential In any financial system, there are a limited number of reports, which should be included in order to view financial transactions, which have been entered into the system. These include a finance journal, which lists all transactions entered chronologically, and a trial balance, which displays the balances for all accounts in the Chart of Accounts. Additional reports include budget reports, which print budgets, and also compare entered budgets with actual balances. Finally, most organisations produce Profit and Loss Statements and Balance Sheets. There are a multitude of additional reports which may be DRAFT 38 Appendix 3: Requirements for a DMIS produced from a finance system, including e.g. ledger cards displaying transactions entered for a particular account, forecasting, cash flow analysis reports and other statistical reports. ACCOUNTS PAYABLE Supplier database Essential The heart of any Accounts Payable system should be an extensive supplier database, which allows storage of information pertaining to the suppliers. This becomes increasingly important with time as historic data related to suppliers can form the basis for the decision making process related to purchase of new items. This database may also simplify the printing of reports and preparing of mailing lists. Integration Essential An accounts payable system can add different degrees of functionality to a system. This can range from having a supplier database to controlling the entire purchasing process, from receiving quotations to receiving goods and issuing payments. The system may automatically generate entries in the General Ledger (i.e. the relevant ledger entries are processed in the system when a payment is registered in the Accounts Payable module). Alternatively, the system may allow users full control over the process. The Accounts Payable module may also be integrated with other sub-systems, such as inventory management or cash management. The level of integration between an Accounts Payable Module and the remainder of the system is less critical at district/community level than it is at national/international level, as the number of transactions and number of suppliers are expected to be far greater at national/international level than at district/community level. Reporting Essential There are a number of reports, which are required in any accounts payable system. A journal report gives a record of all transactions related to suppliers. This serves as an audit trail for supplier transactions. A list of suppliers can be used for a number of purposes, including mailing lists. An age analysis report shows all outstanding payments, their value and when they fall due. These may be listed by either due dates or by suppliers. Finally, purchase statistics (e.g. value or quantity of purchases) can be helpful in determining repeat orders and negotiating supply contracts. Generating payment schedules Desirable Depending on the cash available, historic requirements, outstanding payments and payment terms and conditions, payment schedules can be optimised. A MIS may provide some automation in relation to this. ACCOUNTS RECEIVABLE The Accounts Receivable module shares most of the required features and functionality of the Accounts Payable module, which is described above. VAT calculation Essential In an accounts receivable system, which is integrated with an inventory module, automatic Value Added Tax (VAT) calculation would be an essential part of the system as this eases the financial control of the sales and distribution of inventory items. DRAFT 39 Appendix 3: Requirements for a DMIS Interest calculation When issuing invoices to customers, different terms of payment may be specified, e.g. cash on delivery, 30 days credit. In addition to this, interest may be charged on overdue payments. If this functionality is partly of fully automated in the system, control and interest calculation is simplified and gives the system users a better overview and control of outstanding invoices. This is particularly true in the case of larger outlets with a large number of customers. REPORTING In addition to the essential reports described above, there are some reports, which are unique in relation to customers and are desirable in such a system. This includes the possibility of automatically generating account statements, reminders to customers and printing of receipts. Previewing reports Essential The industry standard for any application, which outputs information onto paper, is that the expected result can be previewed on-screen before committing to paper. This is essential to save both time and money. Selection criteria Essential At large installations, it is necessary that relevant information can be extracted from the DMIS when needed. As the amount of information increases, the need to be able to specify and limit information becomes important. If information cannot be limited in the form of e.g. an SQL SELECT statement, the information desired and required could not be extracted from a database without producing a large number of reports. In the daily use of a system, the need for information is dynamic and often specific. By including a selection option combined with e.g. different grouping and sorting criteria, specific information required as a basis for decision making can be extracted from the system. This may be combined with e.g. a built-in report generator (see below). Sorting criteria Essential ??? Report generators Desirable When a system is installed at international or national level, it is expected that individual reporting requirements be identified at some sites. If an application has a built-in report generator, localised installations can produce their own reports when required. This minimises involvement from and dependency upon both the supplier and the headquarters. Information in the DMIS can then be tailored to suit precise needs for reports. This increases the quality and usability of a system. If a „Report Wizard‟ or similar tool is available, new reports can be generated without specific computer programming skills being required. Graphical output Desirable Graphical output may be desirable not only at management level but also for public use, as charts and graphs are better at conveying certain aspects of information in some cases. This can be important when comparing information and conveying statistical data to non-technical persons. It is an added advantage if a system can produce graphical output, but there are several graphic presentation tools available on the market, which can be used independently of MIS. DRAFT 40 Appendix 3: Requirements for a DMIS FIXED ASSETS Depreciation Desirable In larger organisations the number of fixed assets used (e.g. vehicles, houses and warehouses) may make the automatic registration and depreciation of fixed assets in a MIS desirable. In addition to registering information pertaining to fixed assets (e.g. description, purchase price, location) the main functionality which can be gained from such a system is the automatic calculation of the depreciation of fixed assets to ensure that the correct net book values are registered. There are a number of different depreciation methods (e.g. straight line, percentage, fixed) and rates which can be employed. The system should be able to handle all of these methods. In the case of sale, theft or disposal of assets, the system should also be able to register the financial consequences. Integration Desirable A fixed assets module may be integrated at a number of different levels. This may be from keeping a register of fixed assets to automatically registering purchases of fixed assets, calculating depreciation rates and preparing the correct general ledger entries. Maintenance and insurance Desirable Fixed assets are often of a nature, which requires maintenance and insurance cover during their use. A system may include a facility to register this type of information and prepare forecasts of when service or insurance is due again. The historical costs related to this may also be included. Reporting Desirable Fixed asset reports should include details regarding fixed assets, for e.g. control purposes. Book values and depreciation to date should also be reported. Finally, if maintenance and insurance details can be added to the system, reports should be available that list historical costs and details involved. TRANSPORT MANAGEMENT Route planning and costing Desirable A transport management system is chiefly used to assist in the efficient use of vehicles for transportation of goods between different locations. This may be for the distribution of goods from one main location to several locations or a combination of delivery and pickup. A transport management system will assist in calculating the maximum usage possible based upon a number of factors, including manpower availability, load possibilities, route distances and number of stops. Cost calculations based on selected routes may also be automatically calculated by the system. In addition to this, a route planning system may store information pertaining to vehicle use and maintenance if this is not stored in e.g. a separate fixed assets module. Integration Desirable Transport Management can affect several areas of an application: transportation and movement of inventory items, use of fixed assets, use of human resources, incurred running costs etc. Once again, different levels and degrees of integration with the remainder of the system can range from storing data pertaining to transport management to automatically generating entries related to the delivery and location of goods, consumption of petrol and use of fixed assets and other resources. This will ultimately lead to different levels of information being available within the system. DRAFT 41 Appendix 3: Requirements for a DMIS HUMAN RESOURCE MANAGEMENT Personnel records Desirable The basis for any personnel management system is information pertaining to employees. This may range from basic information such as name, address and employee ID to storing all information relating to an employee‟s educational background, employment record, next of kin etc. The amount of information required in a personnel management system will depend upon the organisation which is using it. However, as organisations become larger, the amount of information, which can be stored locally generally, becomes more important. The information store in such a database may be used when e.g. handling promotion and career planning. Resource planning Desirable In work areas where manpower or machine input is required, a resource-planning module may become important. Employees are generally only available for a limited number of hours during a week and allocating these limited resources efficiently can be aided by using a resource planning system. In this system, the total availability of resources during a period is entered and these resources can then be reserved for specific jobs. Machine or non-human resources may be handled similarly and in conjunction with the manpower planning system, e.g. loading a vehicle requires not only manpower, but also a loading bay and a forklift. Being able to view planned and actual usage gives management a view not only of the efficiency of resource usage, but also areas or periods of time where additional resources are required. This type of system becomes important when dealing with resource intensive tasks. Payslips All organisations, which employ people, must prepare some form of pay slip when issuing salaries. The complexity of these payslips will depend on the organisation concerned and the statutory reporting requirements of the country in which the organisation is operating. In most cases there are a number of earnings (e.g. gross pay, bonus, benefits) and deductions (e.g. tax, pension and/or union contribution) which must be tracked and reported. Depending on the size of the organisation, a computerised system may be financially beneficial to an organisation as it enables these earnings and deductions to be automatically calculated. In addition to automatically preparing individual pay slips, total income tax payable by the organisation can also be automatically calculated. In addition to this, a computerised payroll system may also automatically generate the correct entries in the general ledger and/or cashbook. DRAFT 42 Appendix 3: Requirements for a DMIS D) Information Technology Functions TECHNICAL HARDWARE INFORMATION Operating system (OS) - Data input/output Essential It is imperative that the system be able to run on a modern OS. At international level, the ability to run on a choice of large-capacity operating systems such as Unix or its derivatives (e.g. IBM-AIX, HP-UX) and Windows NT is essential. The possibility of entering data into the system via devices such as laser/infrared light barcode readers or magnetic strip sensory devices will allow for greater speed compared to standard keyboard registration. The system should be able to print to all kinds of printing devices: older types such as matrix printers and more recent types such as inkjet printers and laser printers and plotters. This interfacing should be possible using standard printer drivers for the system. The ability to run under a modern OS must be considered as essential to all users. At the district/community level the system should be able to run under a DOS or DOS/Windows 95 OS. Network installation/scalability/ single user installation Essential The system must be available in a network version in order to cater for the needs of large international customers. The network types should be modern, high capacity networks, able to support a large amount of concurrent users. As the number of users rises, so do the requirements to the system, network and hardware. Network installations will require larger investments in hardware and the focus will have to be on optimising the size of the network to the configuration of the hardware. If the hardware configuration is insufficient relative to the system requirements and number of users, access time to the system will become too high. On the other hand, hardware capacity comes at a premium and should not be over-dimensioned. It should be possible to expand a system in tandem with the expansion of other activities. Such scalability could relate to different aspects regarding the use of the system, such as: The basic functionality of the system: Is the system modular in its basic construction? Is it possible to start off with a limited functionality and later purchase additional modules when the need arises? Increasing transaction volume: Are activities expanding in a way that lead to an additional transaction load? The system should be prepared to cater for this, e.g. by enlarging the underlying database Increasing number of concurrent users: Should the need for additional concurrent users linked to the system occur, the system should be able to accept such an expansion. It is important to attempt to estimate such potential needs from the very start of the system assessment in order to ensure that the system in question not only complies with actual needs, but also will be able to handle possible additions within the scope of future expansion. When used at smaller sites, it is imperative that the system is able to run as a single user installation on a stand-alone desktop computer. Data entry?? Printing Facilities?? DRAFT 43 Appendix 3: Requirements for a DMIS Internet ability Desirable Since retrieval and transfer of information via the Internet is becoming increasingly more widespread, it would be a desirable option to have such Internet abilities in the system. The Internet may be used for many other purposes than simple search and retrieval of generally available information. Some systems will allow the user to access specific databases on other locations via the Internet, which could be of great use to an international/national distributor. TECHNICAL SYSTEM INFORMATION System base and adaptability Essential A software product can be developed in a multitude of programming environments. Different programming languages, from different generations, with differing degrees of popularity. In general, it will be an advantage if a known, modern programming language has been used in developing the system. A well-known environment will minimise the cost of external consultancy, since the availability of knowledgeable persons within this field will be greater than compared to an older, more obscure language. The system should allow for individual customisation of its functionality – preferably even the development of entire “tailor-made” modules, in order to cater for specific needs. Such modules can even be made by third parties, in cases where certain needs for some areas have been identified but which are perhaps too specialised for the System Supplier itself to engage in the development of. In many cases only some small degree of customisation will be necessary. For example, only minor adjustments in the fields of a ledger card are required to make the day to day use of the system considerably more flexible and thus inspire the end user to make full use of the system‟s advantages. System compatibility and capacity Essential A description of the system data compatibility, i.e. the ways in which the system can communicate with other software systems, is relevant when assessing the system‟s potential to co-exist and exchange information with other applications. If one wants to retrieve rough data in one system and e.g. present it graphically via another software tool, the two systems will have to speak the same language, e.g. the widespread ODBC (Open DataBase Connectivity) or ASCII (XX). Many information systems have the ability to retrieve information from a variety of database formats. The ability to support a well-known database other than the producer‟s own individually developed database offers the same advantages in terms of the availability of skilled consultants/technicians as described above. Another dimension in the capacity of a system is the size and type of entries that are understandable to the system. Basic limitations in the size of the recognisable input can strongly inhibit the system‟s abilities to operate, e.g. in countries with high currency denominations. It goes without saying that the system must comply with all „Year 2000‟ requirements. This means, that the system must be able to handle all transactions perfectly, regardless of the current year or the year being used in the transaction in question. Lack of a guarantee from the supplier that the system in question is 100% year-2000 (often seen referred to as “Y2K”) compliant should automatically disqualify any computer system, software or hardware! If the system allows for connection to the user‟s intranet (internal electronic information network), the system‟s handling of the protection of information on this intranet via use of a “firewall” should be documented. DRAFT 44 Appendix 3: Requirements for a DMIS System/Data security Essential Data security and integrity are fundamental issues to be addressed when dealing with system assessment. Data security refers primarily to protection from unwanted viewing of and/or tampering with data. Data integrity refers to protection from corruption of data, e.g. due to erroneous or invalid input. Securing data from unauthorised viewing can be obtained by using strict login procedures incorporating unique passwords. Each user will be assigned certain capabilities of viewing, modifying, inserting and deleting data within the system, and the password will be the external key to the system. The system should keep track of the user‟s activities, recording these in a user entry log. In order to secure data from corruption, the system must have certain integrity functions, ensuring for instance that the system accepts only valid input and is not left in an inconsistent state. Such a function could be that the system always arranges its postings to the general ledger in a finance module as completed postings, thus not allowing incomplete postings to be stored in the database. Should a power failure occur on a platform not protected by an UPS (Uninterruptible Power Supply), the system must be able to fully recover without damage to the database structure and subsequent loss of data. User Ids and passwords Essential In any installation where data pertaining to an organisation or operation is stored, limiting access to data is vital. This can be done at several levels - e.g. hardware (booting name and password), netware (logon name and password) or application (application user name and password). In some cases, data security requirements can be covered by other means (hardware or netware), but added security and flexibility is achieved by the application also having an access control system. For example, this allows users to gain access to a system from a number of different locations, which can be extremely important in, say, a networking environment. User access control Essential Although user IDs and passwords are essential for controlling access to a system, the amount of access given to a user should also be controlled. For example, sales persons will rarely have the need to enter details of supplies and suppliers into the system, although they will need to access stock levels and customer details. This is essential when working with larger installations with a number of users - both to ensure data consistency and integrity, and also to restrict access to specific information stored in the system. User tracking log Desirable A user-tracking log allows a super user or system administrator to view the progress of users within a system. This can be important when tracking errors made or attempts at accessing restricted areas. A log can pinpoint which users were using a system at a particular time and (in cases where detailed logs are concerned) can pinpoint which actions specific users (e.g. system areas accessed) carried out. This type of information is desirable when maintaining a system and can provide information related to a specific application which is not provided by e.g. network user tracking. User specific menus Desirable It is essential that user access to the system is controlled and the addition of user specific menus is a desirable addition to this. User specific menus simplify the user interface as only areas, which are relevant to a user, are actually visible. Data input validation Desirable Data input validation can be performed using a number of different methods. By using „look-up‟ functions for data entry where possible, the accuracy of data entry is increased. Input values may also be suggested based on default system values. This can decrease repetitive data input and can also more easily ensure data integrity. Large codes which may otherwise be difficult to remember (e.g. 12-digit DRAFT 45 Appendix 3: Requirements for a DMIS item codes) can be searched for and verified at the time of data entry. For example, when entering an order form for a large number of different items, it eases data entry if the user can search the database from the order entry form for the required item codes. The correct items can be verified by looking at e.g. product descriptions. Errors in data entry may be minimised using this type of facilities. Power failure protection Desirable Power failures are part of the daily routine in a number of countries around the world. To ensure only a minimal amount of data loss, there are a number of precautions, which can be taken, such as installing uninterruptible power supplies for all workstations. However, additional safety in the form of data recovery, backup systems and error correction can increase the sustainability of a system operating in an unstable environment. Remote access Desirable In some cases it is possible to gain access to a remote network via e.g. a dial-up connection or the Internet. If a DMIS supports this function, data input and information retrieval can be made more efficient in an international environment. This may be the case when there are a number of workstations distributed over large distances or where access to up-to-date information from virtually every location is a prerequisite. Complete log Desirable The ability to retrieve a complete log of all transactions entered into the system within a given time period would be a desirable feature for larger operations. When many users are operating the system, such a log would facilitate the tracking of errors. When errors are tracked in this way, future mishaps will be easier to avoid. GENERAL Integration of data Integration and transfer of data between programs are essential since there is most often an overlap of data used in the different programs. For that reason it is essential to ensure data integrity between the different modules in the software system. If the software systems do not contain all modules used at the enterprise, integrity with other, separate modules should be considered. A final decision on the range of modules to be purchased will depend on the extent of data integrity required between different modules and those already installed. The import and export of data between various and similar standard packages can also be regarded as an essential asset if computerised data already exist and there is a need to transfer old data to the new package. Languages The reason for computerisation will most often be to speed up complex tasks, increase accuracy in spelling and calculation, automate repetitive tasks, streamline processes, and update and access information, quickly providing managers with information for decision making. For most users the language used on screen and in reports will be essential for the easy use of the program and for the functionality of reports. To be able to evaluate the language used on screen and in reports and to have the possibility of adding specific languages are essential prerequisites for decisions on which software to purchase. Documentation and help function Properly documented software is essential in any operation. Although system users are expected to undergo proper training, questions in connection with detailed system functionality arise regularly. On a long-term basis, new users may also be introduced to systems through the use of proper DRAFT 46 Appendix 3: Requirements for a DMIS documentation. System maintenance personnel may also require proper documentation as a basis for their work. Proper documentation also increases user independence from suppliers. In these situations, clarification is sought in either printed documentation or on-line help facilities, as opposed to contacting the system suppliers. From a daily user‟s point of view, on-line help facilities ease system use. The user does not need to leave the workstation to consult manuals. Context-sensitive on-line help facilities ease searching for information, reducing time spent away from workstations even more. Protection against entry of incomplete transactions The quality of information extracted from computerised systems in the form of e.g. management reports depends on the quality and completeness of data entered into the system. For example, if expenditure budgets are prepared at departmental level, departmental expenditure can only be compared to budget figures if they are „tagged‟ or identified as departmental expenditures. If a system can ensure that transactions entered into it have identifying tags or codes attached to them, the consistency of the data in the database can be maximised and hence the quality of information retrieval enhanced. On-line query There are many situations where specific details are required „at a glance‟. This can be eased through an on-line query facility, as this avoids the need for printing out reports in hard copy. In some cases, having a „preview report‟ function can cover this, while in other cases accessing e.g. item details can be done by viewing an item record in the database on screen. Data import/export Often, data stored in a particular database application must be used in conjunction with other data analysis tools. The output of one system may serve as the input for a second system. Data migration from one system to another is eased. For example, it is easier to keep one shared customer database updated than three databases for use with three different systems. Integrated reporting tools may require data from a number of different sources and applications. In these cases, data must be able to be extracted in a usable format. This may be in the form of a comma delimited text file or through ODBC (Open Database Connectivity - a standard for data interchange between different sources). When data can be merged from different sources, the quality of information available to management increases. A number of figures from, for example, different departments can be compared. For instance, information related to geographical distribution of healthcare drawn from one system may be compared to availability of funds from a different system. This becomes more important as the size and diversification of an operation increase. Certification A charted accounting company or an operating systems supplier may certify a system. Such a certification shows that the system has been tested and approved by the relevant company. This may ease system compatibility issues involving different operating systems and statutory requirements. DRAFT 47 Appendix 4: Example of a generic questionnaire Appendix 4 Example of a generic questionnaire The following questionnaire was used to obtain information from software companies/developers of computerised systems that could be used in a drug supply business environment. It provides an example of the type of questions that could be requested from suppliers, however it must be clear that when any such questions are designed, the evaluation of the responses must also be considered together with the capability of the organisation undertaking this process. Section A - Supplier Information 1. Your company name and address? 2. When and where was your company founded? 3. What was your annual turnover over the last three years? 4. Can you provide your annual accounts for the last three years? 5. How many employees do you have world-wide? 6. How many countries are you represented in? 7. In which countries are you represented? 8. How many installations do you have world-wide? 9. In how many countries is your system installed? 10. What local support is available? 11. What type of after sales support do you offer? Please describe your support policy, organisation and escalation procedures from your agent to your parent company. 12. What are your guaranteed support response times? 13. How many people are involved with Research and Development of your product? 14. Does your company have any strategic allies? 15. Do you have a declared strategic direction for your product for the future? 16. How are your agents or distributors selected? 17. What investment do you require from your agents or distributors in terms of training, organisation and equipment? 18. Could you give any reference installations related to Drug Management Systems? 19. Could you give any reference installations related to Drug Supply Systems? 20. Could you give any reference installations related to Inventory Management Systems? 21. Can you give any additional reference installations? 22. What is your maintenance policy and what are the costs involved (e.g. your upgrade release cycle and your maintenance fee)? 23. Please give your recommendation on staffing and their qualifications of a support organisation for the system? 24. On which level(s) would you recommend your system being utilised; International, Regional, and/or Community Section B - Technical Hardware Information 1. What type of operating system(s) does your system support? DRAFT 48 Appendix 4: Example of a generic questionnaire 2. What type of data input devices does your system support? 3. What type of printers does your system support? 4. Is your system available in a single user installation? 5. What are the minimum hardware requirements for this type of installation? 6. What are the recommended hardware requirements for this type of installation? 7. Is your system available in a network version? 8. What type of network does your software support? 9. What is the maximum number of users possible? 10. What are the minimum hardware requirements for this type of installation? 11. What are the recommended hardware requirements for this type of installation? Section C - Technical System Information 1. In what development environment was your system developed? 2. Which Programming language was used? 3. Can your system be customised for different types of installations? 4. Does you system allow for third party add-on products? 5. Who is qualified to carry out system customisation? 6. In case of individual customisation, how do you ensure compatibility with future releases? 7. Is the system source code available for viewing and how is it updated? 8. How easily can fields be added to the system? 9. What data compatibility does your system offer? (i.e. ODBC, ASCII files) 10. What database formats does your system support? 11. Is your system Year 2000 compatible? 12. How large are your unique identifier fields? 13. Are they alphanumeric? 14. What size are your strings? 15. What is the largest decimal number, which your system can calculate with? 16. What is the largest number of digits, which your system can display on screen? 17. How many different versions are available? 18. How many different versions are released each year, on average? 19. What versions are you currently supporting? 20. What is the name and latest version number of your software system? 21. Quality control. Which procedures do you follow before a new version is released? 22. How do you ensure version compatibility? 23. What additional functionality have you planned for future versions? 24. What are the possibilities for upgrading in the future and how future-proof is the system? 25. What connectivity to the Internet/e-mail services does the software support? 26. Does your system offer Intranet connectivity and if so, how is the firewall controlled within the system? 27. Does your system comply with ISO or OSF standards? 28. Do you have a demonstration version available free of charge? Section D - Training 1. Do you conduct your own training? DRAFT 49 Appendix 4: Example of a generic questionnaire 2. What qualifications do your training personnel hold? 3. How many training personnel do you have world-wide? 4. How are your training programmes carried out? 5. What type of training material is available for your system? 6. Are self -paced tutorials available? 7. Please describe a recommended training plan for the system users and administrators. Section E - General 1. How are the different system components linked? 2. Does your system support multiple currencies? 3. In how many different languages are the system available? 4. Can these languages be used concurrently? 5. Can additional languages be added to e.g. reports? 6. What type of help facility is available within the system? 7. Is there an on-line help facility? 8. What type of user documentation is available? 9. What type of system documentation is available for the system? 10. What facilities are available to protect against entry of incomplete transactions? 11. Does the system suggest inputs where possible? 12. Does the system allow for on-line inquiry without having to print a report display? 13. Does the system support data import/export facilities? If yes, do these facilities apply to the entire database? Section F - Reporting 1. Does your system have a built in report generator? 2. Are there any supporting features built into this? (e.g. Report Wizard) 3. Can you preview reports before printing? 4. Does your system provide graphical output? Please specify (e.g. graph, chart, pie, 3D) 5. What types of selection criteria are available when extracting data from your system? (e.g. SQL statements) 6. Can you specify sorting criteria? 7. Can you specify grouping criteria? 8. Can you specify calculation criteria? 9. Can you specify which fields to print? Section G - System/Data Security 1. Does your system allow for user IDs and passwords? 2. Does your system allow for a user-tracking log? 3. Can the system produce a complete log of all transactions and modifications done in e.g. one day? 4. Does your system provide user-specific menus? 5. Is it possible to restrict user‟s access to data entry and/or data retrieval? DRAFT 50 Appendix 4: Example of a generic questionnaire 6. What additional data security features does your software offer? 7. Is there data input validation available where possible? 8. How is data validated? 9. How does the system ensure data integrity? 10. How does your system react to power failure? 11. What type of error correction is supported by your system? 12. Does your system have a native data/software backup system? 13. Does the system allow for remote access by customers? If yes, how are they restricted to view and modify their own data only? Section H - Estimating drugs needs - Logistical forecasting If the answer is no to the first question, go on to next section. 1. Does your system have a calculation model for estimation of drug needs? And is it able to forecast needs in e.g. one months time or for the coming year? 2. On which parameters is this formula based? What information is used to generate order quantities? 3. How will adjustments to this formula be activated? 4. Could estimation of needs be adjusted and prioritisation made, based on e.g. ABC analysis or change of service levels? 5. Does your system allow for drug need estimation and forecasting for multiple point sales; consolidated and individually? Section I - Distribution / Dispensing and rational use of drug 4. Does your system provide possibilities for generating reports on drug costs spent on specific drug groups? 5. Can the system perform calculation of WHO drug use indicators? Section J - Tender Processing If the answer is no to the first question, go on to next section. 1. Does the system include a tender processing module? 2. How many evaluation criteria can be entered? 3. How can criteria be weighted? 4. Can the module generate a tender request report? 5. Can the system monitor outstanding quantities by item for the order as well as for the complete tender awards? 6. Can tender quotations be entered and an adjudication report be made? 7. Can a tender award list be prepared? 8. Can a tender contract be generated based on the awards? DRAFT 51 Appendix 4: Example of a generic questionnaire Section K - Procurement process If the answer is no to the first question, go on to next section. 1. Does the software include a procurement module? 2. Can the system automatically create purchase orders based on previously calculated needs and forecasts? 3. Is it possible to enter supplies, which have not been purchased, such as donations? 4. Does the software have automatic calculation of minimum stock? 5. Can the module generate the following reports: Port clearance report Order status report Out of stock items Price comparison with on-line imported international prices Supplier performance based on previous quality control entry? Section L - Inventory management/ Receipt / Quality Control If the answer is no to the first question, go on to next section. 1. Does your system have an inventory management module? 2. How is this module integrated with the remainder of the system? 3. Does this module automatically generate entries in the General Ledger? 4. What kinds of inventory classifications are available? 5. Does the system allow for monitoring of stock levels and consumption for multiple branches? 6. Can you transfer stock items between different warehouses or locations? 7. Does the system allow for receipt of items into stock without immediate costing? 8. What kind of stock control performance indicators does the system support? 9. Are minimum order levels suggested? 10. Can the module perform a lead-time analysis report? 11. Can stock be reserved for sale? 12. Does the module give space for a quality control entry per received unit? 13. Is there a lock to ensure that quarantined products are not processed or where quality control results have not been entered? 14. Does the system include an automatic expiry notification/not to be issued warning? 15. Can the module reproduce a receipt report? 16. How does the system handle returned goods? 17. Can your system monitor claims related to e.g. damaged/expired goods? 18. How are claims processed in your system? 19. Can the software monitor expiry dates and generate Expiry stock reports? Expiry date analysis? Expiry risk report? (Stock items at risk of expiring in stock) 20. Can the module generate: Journal? List of Items? Turnover? DRAFT 52 Appendix 4: Example of a generic questionnaire Picking Lists? Stock Lists? Physical stock status report? Stock detail report? Stock taking forms? Inventory variation report after inventory adjustment? Invoicing? Stock Ledgers? ABC analysis? Stock level projection by branch and consolidated? Section M - Financial Module If the answer is no to the first question, go on to next section. 1. Does your system have a finance module for entering cash and financial transactions? 2. How many accounting dimensions does the module support? 3. Do these dimensions support individual hierarchies? 4. Are all dimensions supported throughout the system? 5. What identifying fields can you enter for each transaction? 6. Can you prevent direct entries into the General Ledger? 7. Can unbalanced debit/credit transactions be entered into the system? 8. Does the system allow posting to multiple accounts to be done in one transaction? 9. Can input journals be set up for recurrent transactions? 10. Does your module have an audit trail? 11. Can you book the same voucher twice? 12. Can you modify entries once they have been booked in the system? 13. Has your system been certified or approved by any operating system manufacturer or charted accounting company? Please give details. 14. Does you module allow for the entry of Financial budgets? 15. On what time frame are these budgets entered? (E.g. daily, monthly, quarterly) 16. Can you have more than one active budget at any one time? 17. Can the Finance module support VAT? 18. Can you post entries in previous accounting periods? 19. Which of the following reports are present in your module: Journal or Cash/Bank Book Accounting Codes (e.g. Chart of Accounts, Accounting Dimensions) Trial Balance Profit and Loss Accounts Budget Reports Balance/Budget Reports Ledger Cards Cash Forecasting Liquidity Reports DRAFT 53 Appendix 4: Example of a generic questionnaire Section N - Accounts Payable If the answer is no to the first question, go on to next section. 1. Does your system have an accounts payable module? 2. Does your module have a supplier database? 3. Can the system suggest supplier payment conditions based upon cash available and supplier payment terms? 4. How is this module integrated with the remainder of the system? 5. Does this module automatically generate entries in the General Ledger? 6. What functionality does this module add to the system? 7. Which of the following reports are present in your module: Journal List of Suppliers Age Analysis Purchase Statistics Section O - Accounts Receivable If the answer is no to the first question, go on to next section. 1. Does your system have an accounts receivable module? 2. Does your system have a list of customer details? 3. Does the system calculate interest rates on overdue payments? 4. How is this module integrated with the remainder of the system? 5. Does this module automatically generate entries in the General Ledger? 6. What functionality does this module add to the system? 7. Can the system calculate Value Added Tax (VAT) automatically? 8. Which of the following reports are present in your module: Journal List of Customers Age Analysis Sales Statistics Reminders Statement of Accounts Receipt of Payments Vouchers Section P - Fixed Assets If the answer is no to the first question, go on to next section. 1. Is there a fixed assets module in your system? 2. Does it handle automatic depreciation? 3. What types of depreciation methods are supported? 4. Can you enter your own depreciation calculation method? 5. Can your module handle sales and theft of Fixed Assets? 6. How is this module integrated with the remainder of the system? 7. Does this module automatically generate entries in the General Ledger? DRAFT 54 Appendix 4: Example of a generic questionnaire 8. Does the module support maintenance history? 9. Does the module handle insurance details? 10. Which of the following reports are available in your module: List of Assets‟ Details Depreciation to Date Cost of Maintenance to Date Insurance Section Q - Transport Management If the answer is no to the first question, go on to next section. 1. Does your system have a transport management module? 2. Does the module assist with route planning in relation to local conditions/ accessibility to certain roads etc.? 3. Possibility of cost comparison of different transport methods? 4. Record keeping for vehicle use and maintenance? 5. Possibility of manpower planning? 6. Can the system handle load management? 7. How is this module integrated with the remainder of the system? 8. Does this module automatically generate entries in the General Ledger? Section R - Personnel Management If the answer is no to the first question, go on to next section. 1. Does your system include a personnel management module? 2. Does the module include detailed personnel records? 3. Can the system handle formal education and training information? 4. Does the system handle notes on personnel career ambitions? 5. Does your module handle resource management? 6. Can it suggest hourly allocation? 7. Can your module prepare payroll calculations? 8. Can your module prepare pay slips? 9. How is this module integrated with the remainder of the system? 10. Does this module automatically generate entries in the General Ledger? Section S – Sales and distribution 1. Can the system allocate stock when processing orders? 2. Can stock automatically be allocated by expiry date? 3. Is it possible to override automatic allocations? 4. Can pick list be made based on both order and by location? 5. Does the system allow issuing of non-cost items? 6. Does a sales order processing performance monitoring system exist? 7. Does the module facilitate the trace of specific batches? DRAFT 55 Appendix 4: Example of a generic questionnaire Section T – Pricing 1. What is the price of your system? 2. If it is of a modular composition, could you specify your pricing structure with a few examples? 3. What is the price of your after sales support? 4. What is the price of you training programmes? 5. How do you price on-call support? 6. What is the pricing structure of system customisation? DRAFT 56 Appendix 5: Modules inlcuded in the selected software systems Appendix 5 Modules included in the selected software systems FEATURES CLM Concorde Gemedic Invec-2 Navision SAP Sun Lawson Nepal System ESSENTIAL Logistical forecasting YES YES YES YES NO YES NO Tender processing module NO NO NO YES NO YES NO Procurement management YES YES YES YES NO YES YES Inventory management YES YES YES YES YES YES YES Financial management NO YES NO MIN. YES YES YES Accounts Payable NO YES MIN. MIN. YES YES YES Accounts Receivable NO YES MIN. MIN. YES YES YES Sales and Distribution YES YES YES YES YES YES YES DESIRABLE NO YES NO NO YES YES YES Fixed Assets YES NO NO NO NO NO NO Transport management NO YES NO NO YES YES NO Personnel management DRAFT 57 Appendix 6: Addresses and fact sheets on selected suppliers Appendix 6 5) Addresses and fact sheet AEDES GEMEDIC DOS ver. 2.2 on selected suppliers Agence Européenne pour le Développement et la Santé 34 Rue Joseph II 1) B-1000 Brussels, Belgium Lawson Software Lawson Insight Att.: Daniel Vanderbergh Phone 32 2219 0306 1300 Godward St Fax 32 2219 0938 Minneapolis MN E-mail USA Attn: John Townsend 6) Phone 1 800 477 13 Systems Union Group Ltd. SunSystems Fax 1 612 379 7141 Ver. 4.2 E-mail Info@lawson.com No 1 Hammersmith broadway London W6 9DL 2) England Navision Financial Navision Att.: Niell Young Ver. 3.56a Phone 44 1252 378837 Frydenlunds Allé 6 Fax 44 1252 371559 DK 2950 Vedbæk E-mail Neil_young@systemsunion.com Denmark Att.: Jens Lykkegaard 7) Phone 45 45 65 50 00 Columbus IT Partners Concorde XAL Fax 45 45 65 50 01 Ver.2.65 E-mail Jlh@navision.com Krudtlobsvej 1 1403 Copenhagen K 3) DK – Denmark SAP AG SAP R/3 Att.: Martin Garbrecht Ver. 4.0A Phone 45 70 25 07 00 Neurottstrasse 16 Fax 45 70 25 07 01 D-69190 Walldorf E-mail Mgr@columbus.dk Germany Att.: Renate Giese/ Leo Schneider 8) Phone 49 62 27 340 CLM CLM Ver 2.06 Fax 49 6227 34 1282 Management Sciences for health E-mail Dirk.email@example.com 165 Allandale Road Boston, MA 1973 4) Att.: Anne C Williams MSH INVEC-2 Phone Ver.1.5 Fax Management Sciences for Health E-mail Awilliams@msh.org 1515 Wilson Boulevard, Suite 710 Arlington, VA 22209, USA Att.: Julie McFadyen 9) Phone 1 703 524 7893 Nepal Own system Fax 1 703 524 7898 Medical Stores E-mail Jmcfadyen@msh.org Att: Phone Fax E-mail DRAFT 58 Appendix 6: Addresses and fact sheets on selected suppliers CLM Version 2.06 Supplier Information The system was developed by Management Sciences for Health, Boston, Massachusetts, USA. The system is currently installed at 7 locations in 7 countries (e.g. Peru, Nicaragua, Nepal, Kenya, Madagascar), used by e.g. National Immunisation Programmes and Family Planning NGOs and available in three different languages English, French and Spanish. Allies include the Pan American Health Organisation. The software is available as a non-commercial system, with a possible strategy for an upgrade to a Windows platform. Pharmaceutical Features CLM software was developed for the purpose of medical supply handling, and has no installation related to drug management or drug supply. In this relation the system has the weakness of no tender module, no space for quality control entry per received unit and no standard ABC analysis or inventory variation report after inventory adjustment is available in the system. Without accounts receivable module the system is weak in a sales function e.g. without the possibility of making clients consumption analysis and budget. The systems strong asset is the transport management module, making it attractive for vaccines handling. Business Application Features This system does not support the entry of financial transactions and has no Finance, Accounts Receivable or Accounts Payable modules. However, there are Equipment and Transport Management modules in the system. The system does not have a Personnel or Fixed Assets system. The reporting system includes a report generator, supports user selection and allows new reports to be added to the system. The system does not support graphical output. IT Specific Features CLM offers excellent possibilities for use of user ID‟s and passwords, but no features for restricting users access to data entry and/or data retrieval. The system addresses small installations and doesn‟t support large, high-capacity Operating Systems. There are no network-capabilities. The system is developed in an older generation environment, and doesn‟t allow for any customisation or add-on products. Only the supplier is allowed to make changes to the program. The CLM system only offers limited system compatibility. CLM states that its date fields allow for 4 digit years. Pricing Cost involved in implementing this system is based upon paying for consultant time used in installation and training. They plan to have a free demonstration version available within the next six months. DRAFT 59 Appendix 6: Addresses and fact sheets on selected suppliers Concorde XAL Version 2.65 Supplier Information Damgaard International, Birkerød, Denmark developed the system. The system is installed at over 1000 locations in 17 countries and available in the following languages at present: English, Danish, German, Norwegian, Swedish, Dutch, Russian, Polish, Czech, Lettish, Latvian, Lithuanian, Hungarian and Chinese. They have alliances with Microsoft, Oracle and IBM. Pharmaceutical Features The system was developed as a financial, inventory system applied to customers with similar distribution and logistics processing as in the drug management and drug supply-handling sector, but with no medico companies on their reference list. Concorde system does not include specific tender features, and does not include standard field for quality control entry, making supplier performance reports weak only based on delivery adherence. Procurement management, Inventory management and Sales modules include almost all the essential and desirable features in an eligible DMIS system. Business Application Features The system has an integrated Financial system including General Ledger, Budgeting, Accounts Receivable, Accounts Payable and Fixed Assets. The system also has a Payroll module. The system does not have any Transport Management module. The system has an integrated and flexible report generator, which allows for the addition of any number of user-defined reports. It includes support for graphical output on the screen only. IT Specific Features Concorde has excellent features for system/data security. The system supports a wide variety of operating systems, offering a very good scalability and network capacity. The system offers a very good data compatibility, and allows for extensive modifications and add-on solutions. The customer can perform some modifications after buying a separate tool – more elaborate customisation is performed by the supplier/consultants. Concorde XAL is Year 2000 compliant. Pricing The price of the system depends on the number of modules used, operating system used and number of concurrent users – in addition to consultancy involved related to installation and training. They have a demonstration version available for USD 100 (to cover media costs). DRAFT 60 Appendix 6: Addresses and fact sheets on selected suppliers GEMEDIC Version 2.2 Supplier Information The system was developed by AEDES (Agence Européenne pour le Développement et la Santé) scrl, Brussels, Belgium as a non-commercial software. The system is installed in 7 countries both at national and regional level (Chad, Central Africa, Liberia, Cameroon, Guinea, Cambodia and Democratic republic of Congo) and available in a French and English version. The companies‟ strategic direction is no further development of GEMEDIC DOS version, but with extension of the existing commercial system will there be placed emphasise on an accounting management centred system. Pharmaceutical Features This system has as most of the others no tender processing module, together with the lack of financial and accounting management it makes a software package with lack of many essential features. The inventory management module is presenting the most appropriate features in the system even without the quality assurance record, while the logistical forecasting and procurement management lack important functionalities. Business Application Features The system does not have a Finance module, but has some support for following up on Accounts Payable and Accounts Receivable, including printing a number of related reports. The system does not have any Fixed Assets, Transport Management or Personnel Management modules. The system has a report generator, which allows the user to select from a finite number of combinations. The system does not support graphical output. IT Specific Features Gemedic has no facilities for user ID‟s and passwords, nor any possibility of controlling access to the system. The system only supports the most basic operating systems, and has no network capabilities. Gemedic has possibilities for addition of functionality, requiring specially educated staff or consultancy assistance. The system offers fair data compatibility, but only supports one type of database. Gemedic is Year 2000 compliant. Pricing System software available free of charge. Cost involved in implementing this system is based upon paying for consultant time used in installation and training. They have a demonstration version available free of charge. DRAFT 61 Appendix 6: Addresses and fact sheets on selected suppliers INVEC-2 Version 1.5 Supplier Information MSH Drug Management Program, Arlington, Virginia, and USA developed the system on a non-commercial basis. The system is currently installed at 17 locations in 11 countries (e.g. Cambodia, Grenada, Commonwealth of Dominica, St Lucia, St Vincent, Haiti, Zimbabwe, Zambia, Eritrea and Yemen) with the latest version only available in English. The Company‟s strategic direction is for the time being taken up to revision. Pharmaceutical Features The software system were developed for the purpose of drug management at national level and have many specific pharmaceutical functionalities inclusive a tender module. Weakness in the system is its lack of standard entrance field for quality control activities and consequently poor supplier performance report possibilities. The system is by the supplier recommended for use both at national and district/community level, but has a higher score on essential features for users at national level than for a lower level user group. Business Application Features The system has limited support for entering financial transactions and allows for the entry of yearly budgets, but cannot produce financial reports. Both Customer and Supplier databases exist. The system does not have any Fixed Assets, Transport Management or Personnel Management modules. The system has a report generator, which allows user queries to take place. The system does not support graphical output. IT Specific Features Invec-2 possesses excellent features for system/data security. The system mainly addresses smaller to medium installations and doesn‟t support large, high-capacity Operating Systems. Invec-2 is developed in an older generation environment, and only features limited system adaptability and compatibility. All modifications have to be made by the manufacturers own staff, and the system has a very limited choice of databases. The system only allows for limited addition of extra functionality, to be developed by producer. The system only offers limited system compatibility. Invec-2 is Year 2000 compliant. Pricing Cost involved in implementing this system is based upon paying for consultant time used in installation and training. They have a demonstration version available free of charge. DRAFT 62 Appendix 6: Addresses and fact sheets on selected suppliers Navision Financials Version 1.3 Supplier Information The system was developed by Navision Software a/s, Vedbæk, Denmark. They are represented in 27 countries and are installed at ca. 30,000 locations in over 75 countries. Their reference list related to Drug management include Pharmacia Upjohn and related to Drug supply systems - Medical Store in Tanzania. They have alliances with Microsoft, Citrix, TimeLine, Siemens-Nixdorf and IBM, and the software are available in 18 different languages. Pharmaceutical Features The system is developed as a financial management system only slightly modified to a drug management information software. The system has a fair amount of inventory management features, but lacks some essential specific pharmaceutical characteristics e.g. tender handling, logistical forecasting and procurement module are all missing. Among the inventory management features in their standard software there is no space for a quality control entry or supplier performance monitoring report. Business Application Features The system has an integrated Financial system including General Ledger, Budgeting, Accounts Receivable, Accounts Payable and Fixed Assets. The system also has a Personnel Management module. The system does not have any Transport Management module. The system has an integrated and flexible report generator which allows for the addition of any number of user-defined reports. It does not include direct support for graphical output. IT Specific Features Navision Financials (NF) is a modern financial management information system, based on previous experience from earlier systems. NF is based on technology with excellent features pertaining to system/data security and choice of operating system. NF‟s scalability and network capacity is quite good, since the system is suitable for different sizes of operations, ranging from single user stand alone installations to large network installations of approximately 250 users. The system has a high degree of system compatibility, due to its utilisation of market standards for data transfer, however only two specific types of databases are supported by the system (ver. 2.0). The possibilities for individual customisation is very good, even though major modifications require specially trained staff or consultancy assistance. NF is certified Year 2000 compliant. Pricing The price of the system depends on the number of modules used, operating system used and number of concurrent users – in addition to consultancy involved related to installation and training. They have a demonstration version available free of charge. DRAFT 63 Appendix 6: Addresses and fact sheets on selected suppliers SAP System R/3 Version 4.0A Supplier Information SAP AG, Walldorf, Germany, developed the system. They are represented in ca. 90 countries, the system are available in approx. 30 different languages and have some 600 installations in 8 countries related to Healthcare Institutions. Among their references can be found several hospital-pharmacies in Germany. Pharmaceutical Features Among the specific pharmaceutical criteria almost all-essential features can be found in the SAP R/3 system – Materials Management module. A missing feature that can be mentioned is no tender award list can be made. Unfortunately some questions were unanswered by the company, and for that reason a complete picture of the software system can not be made. Business Application Features The system has an integrated Financial system including General Ledger, Budgeting, Accounts Receivable, Accounts Payable and Fixed Assets. The system also has a Personnel Management module. The system does not have any Transport Management module. The system has an integrated and flexible report generator, which allows for the addition of any number of user-defined reports. It also includes support for graphical output. IT Specific Features SAP is a highly developed management information system, which features excellent system/data security on all levels. Due to the fact that SAP mainly cater for large and even very large installations, SAP‟s choice of Operating Systems isn‟t very well suited for small installations. The network scalability is quite good, when larger installations are in focus. SAP supports a wide variety of large standard databases, and features the possibility of a high degree of customisation to suit each customer. This customisation has to take place in SAP‟s own programming environment, and is typically carried out by consultants or specially trained staff. The system handles almost any size of entries. SAP is certified Year 2000 compliant. Pricing The price of the system depends on the number of modules used, operating system used and number of concurrent users – in addition to consultancy involved related to installation and training. They do not have a demonstration version available free of charge. DRAFT 64 Appendix 6: Addresses and fact sheets on selected suppliers SunSystems Version 4.2 Supplier Information Systems Union Limited, London, UK, developed the system. There are over 15,500 installations in 172 countries, and the company is represented in 65 countries. They have alliances with Microsoft, IBM, Sybase, Oracle, HP and Digital and 24 languages are currently available. Pharmaceutical Features In the SunSystem no tender module is provided and no function for estimating drug needs. Else almost all other essential pharmaceutical specific features can be found in the software system and the inventory management system is in particular strong. Business Application Features The system has an integrated Financial system including General Ledger, Budgeting, Accounts Receivable, Accounts Payable and Fixed Assets. The system does not have any Transport Management or Personnel Management modules. The system has an integrated and flexible report generator, which allows for the addition of any number of user-defined reports. It also includes support for graphical output. IT Specific Features SunSystems has excellent features for system/data security. The system supports a wide variety of operating systems, offering a good scalability and network capacity. SunSystems is a packaged product and customisation of the core product is not permitted. The system does allow for third party add-ons. There is a high degree of data compatibility, and the system supports several of different databases. SunSystems is Year 2000 compliant. Pricing The price of the system depends on the number of modules used, operating system used and number of concurrent users – in addition to consultancy involved related to installation and training. Information regarding a demonstration version is available on request. DRAFT 65 Appendix 6: Addresses and fact sheets on selected suppliers Lawsons JYTTE Supplier Information Pharmaceutical Features Business Application Features IT Specific Features Pricing DRAFT 66 Appendix 6: Addresses and fact sheets on selected suppliers Nepal Medical Stores Jytte Supplier Information Pharmaceutical Features Business Application Features IT Specific Features Pricing DRAFT 67 Appendix 7: Generic checklist for DMIS Appendix 7 Generic checklist for DMIS systems (from questionnaire) 1) General classification characteristics Training methods/ availability D – 1-4 Training material D – 5-6 Multiple languages E - 3-5 Documentation/ On-line help E – 6-9 2) Specific pharmaceutical characteristics (Essential functions and features) Drug/ budget needs forecasting – Consumption method H-1, H-2, H-3 ABC analysis L-20, H-4 Tender request report J-4 Adjudication report J-2, J-3, J-6 Supplier performance monitoring report K-5 Tender awards list J-7 Purchase order generating K-2 Calculation of minimum stock K-4 Out of stock report K-5 Currency conversion and adjustment for trade terms E-2 Receiving report. L-15 Quality assurance record L-12, L-13 Product list with specifications L-20 Updating inventory databases L-1, L-2, L-3 Stock detail report L-20 Inventory adjustment report L-20 Expiry stock report L-19 Expiry date analysis or expiry risk report L-19 Stock control performance indicators L-8 Picking lists - Functional list L-20 Returned goods handling L-16, L-17, L-18 Stock allocation by expiry date and batch traceability S-2, S-7 Therapeutic category analysis Not in questionnaire 3) Desirable specific pharmaceutical functions and features as addition to the ideal system Drug need estimation for multiple point sales H-5 Drug cost spending on specific drug groups I-1 Manage simultaneous tenders Not in questionnaire Tender contract generation J-8 Order status report K-5 Price comparison features K-5 Entering donated pharmaceutical/ supply K-3 Port clearance report K-5, L-17, L-18 Lead-time analysis L-10 Receipts report for specific periods L-15 Stock taking forms / physical stock inventory report L-20 Automatic expiry notification L-14 Multiple warehouse implementation L-5, L-6 Stock allocation during order processing S-1 Clients' consumption analysis and budget O-8 Emergency orders Not in questionnaire DRAFT 68 Appendix 7: Application of weighting system in evaluation of selected software systems Stock reservation for sale L-11 WHO drug use indicators I-2 DRAFT 69 Appendix 8: Sample of weighted requirements Appendix 8 Sample of weighting requirements In analysing the essential business, IT specific and general areas of various systems a number of functions can be highlighted in each, e.g. accounting dimensions, audit trail, budgeting, VAT support and reports in the Finance module. Each function can be evaluated in relation to each of the systems and given a score from 0 to 5 depending upon its existence and its properties. Based upon these marks, each area could score a maximum number of points in each system, e.g. 25 points for the „Finance‟ module, 20 points for the „Accounts Receivable‟ module and 20 points for „Technical Hardware Information‟. However, the points available do not reflect the relative importance of each functional area. For example, the functionality of the Finance module may be deemed more important than the Accounts Receivable module; therefore a weighting system is required. In this example 200 points in total were allocated to the evaluation of the systems, i.e. an ideal system would score 200 points. A greater focus has been placed on the Pharmaceutical criteria which have been allocated half of these points (100 points), with the Business System and IT Specific criteria allocated 45 points each and the General criteria allocated 10 points. The weights allocated to each overall area are further sub-divided into each of the essential functions within these areas; i.e. the Finance module is given 20 points, and the Accounts Payable and Accounts Receivable modules 5 points each. Once again, these points indicate the maximum attainable. After this was completed, the actual scores given for each feature were converted into a weighted value. For example, the area „Technical System Information‟ was evaluated based upon three criteria of 5 points each, giving a total maximum score of 15. The weighted value of this are was 10. Thus, the weighted value was attained using the following formula: W=A/M*V where: W is the Weighted value, A is the Actual score attained, M is the Maximum possible score and V is the maximum weighted Value possible. As an example, a system may score 12 points on Technical System Information from a maximum of 15 points during evaluation. As this overall area is weighted at 10, the value must adjusted to fit into the range from 0-10. The score of 12 will thus be adjusted using the above formula: 12 / 15 * 10, which is equal to 8 out of a possible 10. DRAFT 70 Appendix 9: Application of weighting system in evaluation of selected software systems Appendix 9 Application of weighting system in evaluation of selected software systems The evaluation of the selected Drug Management Information Systems is based purely on the information provided from the software suppliers from the questionnaire shown in Annex , and following additional information requested from the suppliers involved. No demonstration of any of the systems has been undertaken in this evaluation, therefore the figures should be viewed with some caution as actual application and use of the systems has not been evaluated. SOFTWARE SUPPLIER CLM Ver. 2.06 Management Sciences for Health, USA Concorde XAL V. 2.65 Columbus IT Partners, Denmark Gemedic Dos Ver.2.2 Agence Européenne pour le Developpement et la Santé, Belgium Invec-2 Ver. 1.5 Management Sciences for Health, USA Navision Ver. 3.56a Navision Financial, Denmark SAP R/3 Ver. 4.0A SAP AG, Germany Sun Systems Ver. 4.2 Systems Union Group Ltd., UK Lawson Nepal Medical Stores The intent of this evaluation is to compare the functionality of several different storage- and information-systems, in order to establish their suitability as a Drug Management Information System, and assess their individual performance with a strong pharmaceutical bias. Evaluation sheets on the selected evaluation criteria are to be found in Annex ? and the weighted results can be found below in Table 5. DRAFT 71 Appendix 9: Application of weighting system in evaluation of selected software systems Table 5: Application of weighted system in evaluation of selected software Essential Functions Weight CLM Concorde Gemedic Invec-2 Navision SAP Sun Lawson Nepal Systems Specific pharmaceutical Criteria Logistical forecasting 15 10.5 13.5 7.5 15 7.5 13.5 4.5 Tender module 20 0 3 0 15 0 15 0 Procurement management 15 9 15 3.8 11.3 3.8 15 13.5 Inventory management 50 39 46.4 38.2 40.9 43.6 45.5 45.5 Pharmaceutical Total 100 58.5 77.9 49.5 82.2 54.9 89 63.5 Business System Criteria Finance Module 20 0 18.4 0 5.6 18.4 19.2 18.4 Accounts Payable 5 0 4.7 3.3 4 5 5 4.7 Accounts Receivable 5 0 4.8 2.5 3.3 5 5 4.8 Reporting 15 15 15 9 15 15 15 15 Total 45 15 42.8 14.8 27.9 43.4 44.2 42.8 IT Specific Criteria Technical Hardware Information 10 5 8.5 5 6.5 9.5 8 6.5 Technical System Information 10 4 8 6.7 6 8.7 8.7 7.3 Year 2000 Compliance 10 8 10 10 10 10 10 10 System/Data Security 15 7.5 15 0 15 15 15 15 Total 45 24.5 41.5 21.7 37.5 43.2 41.7 38.8 General Training 5 1.5 3 1.5 2 3.5 4.5 3 Miscellaneous 5 3 4.5 2 2 4.5 4.5 4.5 Total 10 4.5 7.5 3.5 4 8 9 7.5 Other Criteria Total 100 44 91.8 40 69.4 94.6 94.9 89.2 Overall value 200 102.5 169.7 89.5 151.6 149.5 183.9 152.7 DRAFT 72 To all: should we put in these individual evaluations? Evaluation sheets on the selected evaluation criteria The first sheets included shows the actual scores obtained by each of the systems for the overall essential and desirable features for specific Pharmaceutical criteria, the Business System, IT Specific and General criteria which were measured. The final sheet shows the weighted values obtained for the essential features. As the same Business System, IT Specific and General criteria are generally deemed essential for both International/National and District/Community level, no distinction is made between the two user levels. While some specific pharmaceutical criteria will distinguish between the two different user levels, and the evaluation results will be separated for users at International/National level and for users on District/Community level. Feature CLM Concorde Gemedic Invec-2 Navision SAP Sun Lawson Nepal Essential Features Systems Specific pharmaceutical characteristics Logistical forecasting H - 1-3 Drug/budget needs forecasting 5 4 5 5 0 4 0 L-20, H-4 ABC analysis 2 5 0 5 5 5 3 Tender module J-4 Tender request report 0 0 0 5 0 5 0 J-4 Adjudication report 0 0 0 5 0 5 0 K-5 Supplier performance monitoring 0 3 0 0 0 5 ? report J-7 Tender awards list 0 0 0 5 0 0 0 Procurement management K-2 Purchase order generating 2 5 5 0 0 5 5 K-4 Calculation of minimum stock 5 5 0 5 0 5 5 K-5 Out of stock report 5 5 0 5 0 5 3 E-2 Currency conversion 0 5 0 5 5 5 5 Inventory management L-15 Receiving report 5 5 5 5 5 ? 5 L-12-13 Quality assurance record 0 3 0 1 0 5 5 L-20 Product list 5 5 5 5 5 5 5 L-1-3 Updating inventory databases 3 5 3 3 5 5 5 L-20 Stock detail report 5 5 5 5 5 5 5 L-20 Inventory adjustment report 4 5 5 5 5 5 ? L-19 Expiry stock report 5 5 5 5 5 5 5 L-19 Expiry data analysis/risk report 5 5 5 5 5 5 5 L-8 Stock control performance ind. 3 3 1 2 4 5 5 L-20 Picking list 5 5 5 5 5 5 5 L-16-18 Returned goods handling 3 5 3 4 4 5 5 Essential Features Feature CLM Concorde Gemedic Invec-2 Navision SAP Sun Lawsons Nepal Systems Business System Criteria Finance Module M-2-4 Accounting Dimensions 0 5 0 1 3 5 5 M - 5-7,10-12 Audit Trail 0 5 0 3 5 5 5 M - 14-16 Budgeting 0 3 0 3 5 4 4 M – 17 VAT Support 0 5 0 0 5 5 5 M – 19 Reports 0 5 0 0 5 5 4 Accounts Payable N–2 Supplier Database 0 5 5 5 5 5 5 N - 4-5 Integration 0 5 2 5 5 5 5 N–7 Reporting 0 4 3 2 5 5 4 Accounts Receivable O–2 Customer Database 0 5 5 5 5 5 5 O - 4-5 Integration 0 5 2 5 5 5 5 O–8 Reporting 0 4 3 3 5 5 4 O–7 VAT Calculation 0 5 0 0 5 5 5 Reporting K-5 Order status report 5 5 0 5 0 5 5 F–3 Previewing Reports 5 5 5 5 5 5 5 F–5 Selection Criteria 5 5 3 5 5 5 5 F - 6-9 Sorting Criteria 5 5 1 5 5 5 5 Essential Features Feature CLM Concorde Gemedic Invec-2 Navision SAP Sun Lawson Nepal Systems IT Specific Criteria Technical Hardware Information B-1 Operating Systems 3 5 2 3 5 4 5 B-2 Data Entry 2 4 2 2 5 4 2 B–3 Printing Facilities 3 4 4 4 5 4 3 B – 4-11 Network/Scalability 2 4 2 4 4 4 3 Technical System Information C – 1-8 System Base/Adaptability 2 4 3 2 4 4 3 C – 9-10 System Compatibility/Capacity 2 4 3 3 4 4 4 C – 12-16 Size of Entries 2 4 4 4 5 5 4 Year 2000 Compliance C – 11 Year 2000 Compliance 4 5 5 5 5 5 5 System/Data Security G–1 User IDs and Passwords 5 5 0 5 5 5 5 G-5 User Access Control 0 5 0 5 5 5 5 Essential Features Feature CLM Concorde Gemedic Invec-2 Navision SAP Sun Systems General Training D - 1-4 Training Methods/Availability 1 3 1 2 4 4 3 D - 5-6 Training Material 2 3 2 2 3 5 3 Miscellaneous E - 3-5 Multiple Languages 2 4 3 1 4 4 4 E - 6-9 Documentation/On-Line Help 4 5 1 3 5 5 5 Desirable Features Feature CLM Concorde Gemedic Invec-2 Navision SAP SunSystems International and national user level Specific pharmaceutical characteristics Estimating drugs needs H-5 Drugs estimate multiple point 0 3 0 3 0 3 0 Distribution/ dispensing drugs I-1 Spendings on specific drugs 4 4 5 4 0 4 0 Tender processing J-8 Tender contract generating 0 0 0 0 0 5 0 Procurement process K-5 Price comparison features 0 4 0 0 0 0 K-3 Entering donated drugs 5 5 5 5 0 5 5 K-5, L-17-18 Port clearance report 0 5 0 0 0 5 3 Inventory management L-10 Lead-time analysis 3 4 0 5 5 5 2 L-15 Receiving report specific periods 5 5 5 5 5 ? 5 L-20 Stock taking forms/inventory rep. 5 5 0 5 5 5 3 L-14 Automatic expiry notification 0 0 5 5 0 5 1 L-5-6 Multiple warehouse implement. 3 5 0 3 5 5 5 Sales and distribution S-1 Stock allocation during process. 5 5 5 5 5 5 5 S-2, S-7 Batch traceability 5 4 0 5 0 5 5 O-8 Clients' consumption 0 5 5 0 5 5 3 L-11 Stock reservation for sale 5 5 5 5 5 5 5 Desirable Features Feature CLM Concorde Gemedic Invec-2 Navision SAP SunSystems District and community level users Specific pharmaceutical characteristics Logistical forecasting H-5 Drugs estimate multiple point 0 3 0 3 0 3 0 Procurement process K-5 Order status report 5 5 0 5 0 5 5 K-3 Entering donated drugs 5 5 5 5 0 5 5 Inventory management L-20 Stock taking forms/inventory rep. 5 5 0 5 5 5 3 L-14 Automatic expiry notification 0 0 5 5 0 5 1 Sales and distribution S-1 Stock allocation during process. 5 5 5 5 5 5 5 S-2, S-7 Batch traceability 5 4 0 5 0 5 5 O-8 Clients' consumption 0 5 5 0 5 5 3 I-2 WHO drug use indicators 0 0 0 0 0 0 0 Desirable Features Feature CLM Concorde Gemedic Invec-2 Navision SAP SunSystems Business System Criteria Accounts Payable N-3 Generating Payment Schedules 0 3 0 0 5 0 3 Accounts Receivable O-3 Interest Calculation 0 3 0 0 4 5 3 Fixed Assets P - 2-5 Depreciation 0 3 0 0 5 5 3 P - 6-7 Integration 0 5 0 0 5 5 5 P - 8-9 Maintenance and Insurance 0 5 0 0 5 4 2 P - 10 Reporting 0 5 0 0 5 5 3 Transport Management Q - 2-6 Route Planning and Costing 2 0 0 0 0 0 0 Q - 7-8 Integration 3 0 0 0 0 0 0 Personnel Management R - 2-4 Personnel Records 0 5 0 0 5 5 0 R - 5-6 Resource Planning 0 5 0 0 5 4 0 R - 7-8 Payslips 0 5 0 0 5 5 0 Reporting F - 1-2 Report Generators 3 5 3 4 5 5 5 F-4 Graphical Output 0 2 0 0 0 5 5 Desirable Features Feature CLM Concorde Gemedic Invec-2 Navision SAP SunSystems IT Specific Criteria System/Data Security G - 2-3 User Tracking Log 3 5 0 5 5 0 5 G-4 Use Specific Menus 0 5 0 0 5 5 5 G - 7-8 Data Input Validation 5 5 5 5 5 4 5 G - 10 Power Failure Protection 0 4 1 1 5 4 3 G - 13 Remote Access 0 5 0 0 5 5 5 Appendix 9: Requirements for a DMIS To all : Do the current sections need to be expanded with this information? Connectivity with Other Systems Either the system should link directly with another computer system, internal or external to our organisation, or there should be the facility to export the data into another system. Equally, we may need to import data into the new system from an external source. For example: we have built up a number of useful data manipulation programs to aid management reporting; we are required to export data to an external organisation for audit purposes; at times we may be required to bulk load the system with new data. Report Generation Most systems should come with some means of generating reports, and in fact should hold a standard library of reports, e.g. ABC analysis type reports. However, the ease, flexibility, and power of reporting may vary quite considerably from one system to another. We may also need to perform quite complex ad hoc queries. Should we decide to choose a system with relatively poor reporting capabilities, there may be third party reporting tools that can be purchased to extend reporting ability. Again, we should ensure compatibility between the two. Conversion of Legacy Data Current and archived data are still important information for us: current data to close off end of year processing and archived data for management reports and trends analysis and for statutory reasons. We should ensure the data tables of the new system will be able to store our required information, and we need to investigate who will be able to perform the conversion: either ourselves, the supplier, or someone else. Security The security of the new system should reflect, or improve on, our current business model of which user has what type of authority and responsibility, and to what level. If we have or intend to have a sizeable number of users, we should consider how user friendly is the system in maintaining user security. For example, a system may specify security only at the individual user level, or it can specify security at a group or multi-group level. If we had to change access rights for every member of a group, the former would require changes to each individual; the latter just to the group(s). Disaster Recovery Disaster recovery encompasses: the ability to retrieve data that is as up to date as possible in the event of data loss The ability to continue with business processing in the event of primary system failure. The first is to do with ensuring we have some means of backing up our critical data on a regular basis, being able to store these backups in a safe place (we may wish to store a copy in a separate location from our office for additional security), and being able to restore this data and recover from the original problem with the minimum of delay. The second is dependant on how crucial is our requirement to have a computer system running all the time, i.e. can we make do with a manual system during the period of system failure and catch up later, or must we have a duplicate running system that is immediately activated as the primary one fails. The latter example would entail the parallel running of a secondary server system and the complexity of maintaining two concurrent data sets. An expensive option, which I don‟t think, many of us will require, though we should consider how the business would respond during periods of computer failure. Appendix 9: Requirements for a DMIS Hardware We may specify hardware requirements if we need to abide by policies or statutory requirements, or if there were any specific hardware requirements we need. If we have insufficient skills within our organisation to make any judgements on this issue we can refer suppliers‟ recommendations to known third parties. The later section, Technical Options, provides further details on this.
Pages to are hidden for
"Accounts Receivable Excel 3D Pie Chart"Please download to view full document