Digitizing the field: designing ERP systems for Triple-A humanitarian supply chains

Abstract

Purpose

The purpose of this study is to explore what design principles need to be considered in Enterprise Resource Planning (ERP) systems for humanitarian organizations (HOs) to enable agile, adaptive and aligned (Triple-A) humanitarian supply chain capabilities and digitize humanitarian operations.

Design/methodology/approach

This study follows an embedded case study approach with a humanitarian medical relief organization, Médecins Sans Frontières (MSF), which engaged in a multiyear ERP design at its humanitarian field missions.

Findings

This research shows that ERP systems for humanitarian organizations should be designed as unique systems addressing humanitarian organizations' challenges and unique missions, their value generation processes, and resource base in an effort to improve organizational performance. This study presents 12 general design principles that are unique for humanitarian organizations. These design principles provide a high-level structure of guidance under which specific requirements can be further defined and engineered to achieve success.

Research limitations/implications

The results of this study are based on a single case study limiting generalizability. However, the case study was analyzed and presented as an embedded case study with five autonomous subunits using different business processes and following different adoption and implementation approaches. Therefore, the findings are derived based on considerable variance reflective of humanitarian organizations beyond MSF.

Practical implications

This study recognizes that HOs have unique routines that standard commercial ERP packages do not address easily at the field level. The primary contribution of this research is a set of design principles that consider these unique routines and guide ERP development in practice. National and international HOs that are planning to implement information systems, private companies that are trading partners of HOs as well as vendors of ERP systems that are looking for new opportunities would all benefit from this research.

Originality/value

This study fills the gap in the humanitarian literature regarding the design of ERP systems for humanitarian organizations that enable Triple–A supply chain capabilities and it advances the knowledge of the challenges of ERP design by HOs in the context of humanitarian operations.

Citation

Falagara Sigala, I., Kettinger, W.J. and Wakolbinger, T. (2020), "Digitizing the field: designing ERP systems for Triple-A humanitarian supply chains", Journal of Humanitarian Logistics and Supply Chain Management, Vol. 10 No. 2, pp. 231-260. https://doi.org/10.1108/JHLSCM-08-2019-0049

1. Introduction

Humanitarian organizations (HOs) work in peculiar and complex environments. Unpredictability of demand, lack of resources, poor infrastructure in the field, and high dependency on donor funding are among the main challenges that affect humanitarian supply chains (Gatignon et al., 2010; Kovács and Spens, 2007). To improve humanitarian response, HOs must respond rapidly to short-term changes such as beneficiaries' demands (e.g. agility), adapt to humanitarian environments which are dynamic and complex (e.g. adaptability), and integrate and coordinate processes with all participating partners (e.g. alignment) (L'Hermitte et al., 2016; Oloruntoba; Kovács, 2015; Cozzolino et al., 2012; Van Wassenhove, 2006).

Agility, adaptability, and alignment comprise the three dimensions of the Triple-A supply chain (Lee, 2004) that have been shown to directly affect supply chain performance (Kabra and Ramesh, 2016; Whitten et al., 2012). These dimensions represent essential capabilities that, when leveraged, allow an organization to sense environmental changes and respond effectively, especially in emerging dynamic markets (Dubey and Gunasekaran, 2016). Information systems such as Enterprise Resource Planning (ERP) systems play an important role in enabling Triple-A supply chain capabilities and should be a central component of successful humanitarian relief operations (Schniederjans et al., 2016; Kovács and Spens, 2007).

Surprisingly in this digital age, many people at the HO field level still rely on paper-based lists, Microsoft Excel files, and other low- or no-tech options to manage operations (Comes and Van De Walle, 2016). Saeed et al. (2011, p. 28) recognize that the lack of enterprise and interorganizational software features (e.g. application integration, data compatibility, analytic ability, evaluation ability) “… related to system integration promotes manual data entry, which substantially affects data quality.” Bad data quality orients the firm toward firefighting rather than managing the supply chain process and relationships. Unfortunately, HOs routinely lack integrated information technologies, with only a small percentage of aid agencies having access to ERP software (Gavidia, 2017; Guire, 2015; Pettit and Beresford, 2009; Blecken and Hellingrath, 2008).

To mitigate their operational challenges and improve humanitarian response, HOs are increasingly adopting and/or improving their information systems, including ERP systems. An ERP system is an integrated set of application software serving the various organizational functions and processes. ERP systems are expected to add value to supply chains that enable integration, improve communication within internal and external stakeholders, and enhance decision-making processes (Stoel and Muhanna, 2009; Wu et al., 2006; Mashari and Zairi, 2000; Mata et al., 1995).

Designing ERP systems in atypical contexts, such as the humanitarian context, is particularly challenging and tends to take much longer than in the commercial sector (Gavidia, 2017; Guire, 2015). As stated by the IT Director of Médecins Sans Frontières (MSF) [Doctors Without Borders in English speaking countries], “ERP in HOs must accommodate the humanitarian routines characterized by a lack of infrastructure and connectivity, speed of distribution versus accurate inventory management, scalability in terms of opening and closing projects, and the specification of relief items like KITs.” Some argue that rather than trying to change routines or patterns that are deeply rooted in organizational and behavioral structures of HOs, it is better to include them in the design of an information system (Comes and Van De Walle, 2016, p. 276).

Research on information system design and implementation that enables Triple-A supply chain capabilities, especially ERP systems for humanitarian organizations, is still in its infancy (Comes and Van De Walle, 2016; Pettit and Beresford, 2009). However, the need for ERP systems in HOs that engage a Triple-A perspective is increasingly important. Therefore, this study attempts to address the research question: What design principles need to be considered in ERPs for humanitarian organizations to enable Triple-A supply chain capabilities and improve organizational performance?

“Design involves solving problems, creating something new, or transforming less desirable situations to a preferred situation” (Friedman, 2003, p. 507). Walls et al. (1992, 2004) refer to information systems design principles offering integrated prescriptions outlining a set of requirements for a class of problems; a set of systems features that meet these requirements; and a guide to design so that the system features could meet the goals. We define an ERP design principles as the directions for constructing an ERP artifact that offer integrated prescriptions addressing a set of requirements for a class of information processing problems in an organization. Given the fact that ERP design that enables Triple-A supply chain capabilities is a new topic in the humanitarian context, we employ a case-based research design to help uncover the phenomenon. We focus on the design and deployment of an ERP at MSF, an international, independent, relief organization that delivers emergency aid to people affected by armed conflict, epidemics, and natural disasters. An embedded case study is used whereby multiple units of analysis are studied within a single case. The sub-units add significant opportunities for extensive analysis, enhancing the insights into a single case (Yin, 2003).

Our research contribution is twofold. First, it helps to fill the gap in the humanitarian literature regarding the design of ERP systems for HOs that enable Triple-A supply chain capabilities and improve organizational performance. Second, it advances the knowledge of the challenges of ERP design by HOs in the context of humanitarian operations. Specifically, national and international HOs that are planning to implement information systems, private companies that are trading partners of HOs as well as vendors of ERP systems that are looking for new opportunities would all benefit from this research.

The paper is organized as follows. In section 2, we outline existing humanitarian information systems literature. In section 3, we present the research design and the case study. In section 4, we present the humanitarian context, the triple-A supply chains and MFS's ERP requirements. In section 5, we present the design principles. In section 6, we present discussions and implications, and in section 7, we present limitations and areas for future research.

2. Humanitarian information system

The use of information systems in humanitarian operations is becoming fundamental to managing the information flows and networks important in crisis response (Pan et al., 2012). However, the use of information systems remains limited (Gavidia, 2017; Kabra and Ramesh, 2016; Pettit and Beresford, 2009). A well-known humanitarian logistics information system that shares some characteristics of ERPs is Helios, developed by the Fritz Institute and implemented by Oxfam. Other applications exist in different organizations and UN agencies, but most of these applications offer specific functional capabilities that are not well integrated and only marginally link the field with headquarters (HQs) via interfaces (Comes and Van De Walle, 2016). As of the writing of this study, except for UN agencies implementing the public-sector version of SAP's ERP system at considerable cost (Guire, 2015), to our knowledge no known international HOs have succeeded in extensively implementing and using ERP at their field level.

Unique design differences exist between readily available commercial ERP systems and the needs of HOs. In this regard, humanitarian literature highlights the crucial role of integrated information systems for humanitarian response and intra- and inter-organizational collaboration and coordination. However, few papers describe the necessary design requirements, or foundational building blocks, of effectively integrated systems in HOs that might allow successful general adaptation (Gavidia, 2017; Comes and Van De Walle, 2016; Gatignon et al., 2010; Pettit and Beresford, 2009; Van de Walle et al., 2009).

Turoff et al. (2004) were the first to introduce the concept of design requirements for HOs in reference to the Dynamic Emergency Response Management Information System (DEMIS). Rather than focusing on an integrated enterprise resource system for enterprise-wide implementation and decision-support, their study centers on the design requirements and premises required to meet the communication and information needs of emergency and crisis personnel. Comes and Van De Walle (2016) adapted Turoff et al.'s (2004) DEMIS to humanitarian logistics information systems based on historical disasters. They introduced general design principles for logistics information systems for the assessment and coordination of humanitarian operations. Gavidia (2017) proposed a conceptual model for ERPs for humanitarian emergencies using an existing systems development life cycle model from logistics and information systems literature.

We extend and deepen this line of research by attempting to derive design principles for ERP systems for HOs empirically. Our design principles for integrated ERP systems to be used daily in HO field emergency and “routine” missions are based on more than 4 years of research with MSF. Our research concentrates on unique ERP capabilities to enable Triple-A supply chains. Our study does not focus on generic principles for core headquarter-centric application functionalities such as purchase orders, returns, claims, replenishment, finance functionalities such as cashbook, accounts payable, accounts receivable, and journal balance because those core functionalities are offered by all ERPs and do not have to be contextualized extensively to fit the unique characteristics of humanitarian operations. Instead, we focus on those unique functionalities typically not offered in standard commercial ERP software but required by HOs. Our focus is on ERP in HO applications that are field operations-centric since this is where the greatest need for new design principles exists.

3. Research design

We follow a single embedded case study approach to understand the design principles and implementation strategy of an ERP system in the humanitarian sector. MSF was selected for the case study because it is one of the leading medical relief organizations worldwide, and it is currently implementing an integrated open source ERP at its missions across a substantial portion of the enterprise's activities (finance, operations, and supply chain). We employ embedded design that allows for multiple levels of analysis within a single case study (Figure 1). An embedded case study gives us the opportunity to explore our research question under two units of analysis (MSF International at one level and its five semi-autonomous operational centers at another level) to uncover how differences in organizational processes and cultures could affect the design of an ERP. From our embedded case study and the humanitarian literature, we identify important and unique requirements of an ERP for HOs. Then, we derive design planning principles for an ERP for HOs through the lens of Triple-A supply chains.

The structure of our case organization consists of an international entity-MSF International, 24 associations and five operational centers (Paris, Amsterdam, Geneva, Barcelona and Brussels). MSF presents a unique opportunity because it is composed of five operational centers that share the same high-level goals and values but execute in different ways. Hence MSF provides multiple perspectives in deciding how to integrate ERP systems. Each of the five centers has a high level of individual autonomy concerning process design and discretion in resource allocation. Also, each operational center has its own design requirements because of the differences in processes and back office systems and they are free to decide on their strategy and time frame of implementation and training. The “UniField” ERP project was started as an enterprise-wide international effort encouraged and supported by MSF International and was initially planned to be implemented in all the missions of the five operational centers. One of the main challenges of the project according to a Supply Project Manager is that in “the governance model of MSF, we have 5 sections of MSF that are indeed independent, and we have agreed to develop a system, so it is difficult to have everybody agree in terms of requirements and functionalities etc. It is heavier to manage it because there is no final entity that can take the final decision. So, in terms of project management, it is much heavier, you need to adapt to various cases, to meet different needs.”

Our unit of analysis is MSF International and its five operational centers as sub-embedded case units (Figure 1). We are interested in looking at the design of the UniField ERP program considering decisions made by the five autonomous operational centers of MSF in the course of the design of the system. The ability to look at sub-units that are situated within a larger case (MSF International) helps us to explore the case deeply. Using an embedded design, we analyze data within the sub-units separately (within case analysis), between the different subunits (between case analysis) (Yin, 2003). An embedded case study offers the methodological ability to advance theory in the fields of humanitarian operations (Yin, 2003; Fisher, 2007; Martinez et al., 2011). This paper does not cover the entire life cycle of ERPs. We focus on the preparation, analysis, design, and implementation planning phases of ERPs in humanitarian operations (Markus et al., 2002). We do not cover the full implementation, use, maintenance, and support phases. Figure 1 presents the embedded case study design.

The reliability of our case study is improved by using a case study protocol and a comprehensive collection of interview notes and other documentations. The validity of our case study is enhanced by combining results of data received from semi-structured interviews, meetings with the project manager of MSF, internal documentation, presentations, and published information. Our case study is complemented with additional discussions and interviews with two more aid organizations, the International Federation of the Red Cross (IFRC) and GAIN that are partially implementing the components of the ERP software and a private company called CamptoCamp that is the open ERP provider for those organizations. We also had an interview with Catholic Relief Services (CRS) that was in the process of defining the requirements to select an ERP for its operations. We had numerous informal discussions with practitioners from other HOs that are interested in implementing an ERP. It is believed that the general set of problems faced can be generalized beyond MSF since MSF with its five differing OCs possesses some similarities in characteristics with many HOs that offer emergency and long-term missions. Figure 2 presents the research process that we followed to arrive at the proposed design principles. To define and answer our research question, we have followed an exploratory and an inductive phase. We first explored the topic by participating in the MSF ERP project, examined the information system literature, discussed the issue with humanitarian and information systems experts and identified research gaps. This process helped us to define our research question. We then used the lens of Triple-A supply chains and the embedded case study with MSF to define the ERP requirements and address our research question by proposing 12 design principles.

3.1 Data collection and analysis

Our data collection methods involved a combination of interviews, document reviews, and observations in the form of personal interaction with the MSF project. Individual semi-structured interviews with open-ended questions were the major source of primary data. Data collection took place over a four-year period over which time the design concepts were established and implementation planning articulated.

Respondents were selected from the researchers' network, and subsequently by word-of-mouth recommendations of other interviewees, in an attempt to triangulate. It should be noted that one of our study's authors had acted, before entering academia, as a supply trainer running the first ERP implementation pilot with MSF; hence, participant observation data supplemented the study. Additional respondents, especially those outside of MSF, were identified through interviews with MSF respondents who recommended colleagues from other organizations. Many MSF interviewees had worked for the organization for many years, and they knew the organization, its needs, and its characteristics very well. Assisted by the MSF project manager of Geneva, we also organized follow-up interviews and two workshops at a large European university to get project updates and new insights that we had not anticipated.

In total, we conducted 22 semi-structured interviews with key MSF personnel and four semi-structured interviews with personnel from IFRC, GAIN, CRS, and CamptoCamp. The semi-structured interviews lasted an average of 50 min each. Some interviewees answered the initial questions and follow-up inquiries via emails due to technical issues such as lack of connection at the field level. To get a fuller picture, we also accessed information available on websites, a feasibility study of the project, the business model, project requirements, project plans, and the communication strategy and reports from previous failed pilots. Interviews were conducted with people at the HQ level who were involved in the ERP's decision phase – for example, the Logistics Director – and those involved in the ERP's design and development such as the ERP product and project managers. Additional field-level interviewees included supply and finance managers, the main users of the ERP, as well as and employees working in areas like the medical department who will not use the system directly but whose work will be affected.

All interviews were recorded and transcribed, and the interviewees approved the transcripts. If we perceived any ambiguity of interviewees' answers, follow-up questions were asked to attain clarity. Transcripts were subject to open coding to identify and name the dimensions of the phenomenon (Day et al., 2009; Corbin and Strauss, 2015). We analyzed the collected data together line by line and then grouped them into open codes that summarized our interpretation of the data. Next, we compared the interviews, grouped codes together, and formed more abstract themes (Day et al., 2009). Recognizing the nascent stage of knowledge on our topic, we adopted an interpretive approach (Sarker et al., 2012; Sarker and Sarker, 2009; Walsham, 2006, 1995). We compared the answers to identify initial concepts and attempted to link this evolving set of concepts to higher-level categories such as Triple-A supply chain (Sarker and Sarker, 2009, p. 444). The information gathered in the interviews was initially organized into the following dimensions/codes: agility, adaptability, alignment, challenges, effects, goals, requirements. This approach helped us to understand better the characteristics and challenges of HOs and their effect. We summarize the key methodological guidelines used in Table I.

Based on the interviews and the lens of Triple-A, we inductively derived design principles. The initial set of design principles was validated further by discussions with practitioners, and then the design principles were iteratively improved. Appendix 1 includes a breakdown of the major interviews by location, organization level, duration, and position held by the interviewees. Appendix 2 includes the questionnaire that we used for our study.

3.2 Research site and case description

Embedded Unit of Analysis Level 1: MSF International: MSF is an international, independent, relief organization that delivers emergency aid to people affected by armed conflict, epidemics, and natural disasters. MSF was founded in Paris, France, in 1971 and is a worldwide movement with programs in 69 countries. MSF is composed of five operational centers (OCs) (Amsterdam-OCA, Barcelona-OCBA, Brussels-OCB, Geneva-OCG, and Paris-OCP), 21 sections, and 24 associations in various countries. They are bound together by MSF International, based in Geneva, Switzerland, which provides coordination and information and implements international projects and initiatives as requested. The five operational centers are independent units that are responsible for their programs or missions around the world. Each mission usually has an office in the capital of a country to coordinate project activities around the country. MSF has its own logistics function, operating European supply centers in France, Brussels, and the Netherlands and regional supply centers in Uganda, Dubai, and Kenya. By having five operational centers MSF has additional costs, but it could also add value to the organization because of the different approaches.

The implementation of an ERP system, called UniField at MSF, came as a result of a mutual initiative between the different OCs led by MSF international. At the time of the UniField project's initiation, the five operational centers were using ten different software packages that did not communicate with each other. The main goal of implementing a new ERP/UniField for OCs was to improve vertical integration of information from field missions to OCs HQ and horizontal integration of information across OCs and business areas such as supply and finance to ensure data cohesion. MSF chose the open source “OpenERP” software and used an internal development team to customize applications by writing the necessary coding beyond what could be easily configured based on existing capabilities in the ERP software provided by the OpenERP.

Embedded Unit of Analysis Level 2: MSF's Operational Centers: OCs have similarities and differences with respect to their way of operating. Each one of the five OCs has their own missions and, in some countries, more than one OC has missions while in other countries like Mozambique OCs collaborate and have joint projects. The five OCs have the same basic organizational structure but, in some cases, different setups regarding functional levels. All of the OCs have a HQ office in Europe. Sections attached to OCs in different countries support fundraising and recruitment of volunteers. Unlike the mission levels, MSF's Operational Centers' HQ offices tend to operate in a more formal and routinized manner, having similarities to a commercial enterprise. They have made use of standard ERPs like Oracle and SAP for such applications as financials and other less known commercial ERP packages like Arcole, a French ERP system used by the Paris OC. At the HQ level, OCs tend to have the necessary infrastructure, a stable environment, standard processes and procedures, qualified personnel and the necessary space and time for people to be trained on the ERP. Also, traditionally, OCs' HQs are the ones to consolidate all necessary information and transactions from the missions for internal and external auditing and need more sophisticated IT systems.

At the mission level, they have a coordination office at the capital of each country and projects in remote areas. For the supply of medicines MSF has its own supply units based in Europe. “… OCs do not have the same set up of finance and supply and they do not use the same IT tools. They have different job descriptions and rules regarding supply and logistics activities. In terms of readiness and how they work it is not the same. Also, in terms of business process maturity, differences between some OCs means some OCs are much more process-oriented than others” a MSF project manager explained. OCs are free to choose the way that they would like to implement UniField and how they train their people in missions. When UniField first started, each OC had its own set of unique requirements. To help address these differences, it took more than 5 years of designing, coding, testing, and tweaking for the UniField ERP to be ready to be implemented in the first mission. Below, we present each one of the five OCs.

Operational Center Paris: OCP: Paris was the first operational center under MSF, founded in 1971. OCP prides itself on focusing on the dynamism of people and operations. It attempts to be less bureaucratic with fewer standardized processes and a less structured supply chain. It also prides itself on being less technology-oriented and not willing to take risk in changing the way they work “…if Excel works well so far, why should we change it?” From the beginning, Paris participated in the UniField project with minimal financial support of the project, but it was not involved in the design or development. From 2009 to 2016 Paris' top management pursued other humanitarian priorities rather than investing resources and time for an ERP system. Very late into the project, in 2019, OCP started implementing the software in their mission worldwide.

Operational Center Brussels: OCB: OCB was founded in 1980 after Paris. The Belgian section was functioning on a financial, human and technical scale comparable to that of its French parent organization when first founded. Overtime however, Brussels focused more on structure with well-documented supply chain and finance processes and higher levels of standardized and customized processes. OCB has participated in the development of UniField from the beginning, but they did not show much willingness to review and adapt their existing processes to the standards embedded in the ERP modules. Instead, they prefer to adapt the UniField ERP to their own way of operating.

Operational Center Geneva: OCG: MSF Geneva was established in 1981. OCG can be characterized as initially having a less mature supply chain. In fact, the supply chain management concept was not introduced at the field level until 2009 to accommodate the UniField project. In an attempt to leapfrog forward to more effective and standardized processes, the Geneva OC displayed a willingness to alter existing operating procedures and IT applications to accommodate the prescribed processes designed inside UniField and/or copy best practice of other OCs. As the project manager mentioned “… OCG was not ready in term of process maturity, resources, communication strategy, there are bottlenecks everywhere.” Since the enterprise-wide UniField project team IT development team was also based in Geneva, OCG had a very close relationship with them and participated strongly as a proponent of continuation of UniField in council with the other OCs. During the development phase of UniField, OCG changed numerous existing work processes to accommodate the UniField proposed way of operating. To expedite implementations, they took the strategy of simultaneously training and testing in the field. This caused some problems encouraging further local customization.

Operational Center Amsterdam: OCA: Although OCA was founded in 1984 after Geneva and Brussels, it quickly was recognized as having very well structured and documented processes. This translated into more organized supply chain management in the field than any of the other OCs. Given the maturity of OCA processes, OCA was less reticent about copying other OCs operating procedures. OCA had their own successful way of operating and they wanted to ensure that the new UniField system would operate at least as good as what it was replacing. For example, at OCA the management of drugs is done by the supply manager and not by the medical department as in other MSF sections “…we have already centralized all the stock management, today we do not separate the medical stocks from the normal stocks” said the Project Manager. OCA was emphatic that the UniField system design would continue to accommodate OCA's way of operating. Involved in the design and development from the beginning of the project, OCA is viewed as a leader in process expertise. Unlike Geneva, OCA follows a very controlled implementation scheme to ensure extensive training and testing before UniField implementations in missions to ensure process quality.

Operational Center Barcelona: OCBA: OCBA was founded in 1989. OCBA was skeptical of implementing UniField and, like Paris, took a wait and see approach. With fewer technical resources and relatively immature existing processes, they questioned the wisdom of designing a customized in-house solution and hoped that an off-the-shelf commercial ERP would satisfy their requirements. In 2017, they decided to withdraw from the project. They had implemented SAP for finance at the HQ level and they have developed a “small tailor-made solution for finance that is connected to SAP.” “One of the requirements of the OCBA was to go with a standard solution. We have a solution for finance (SAP) that covers more functionalities than UniField and we have developed a finance solution for the field level that it is fully integrated with SAP at the HQ” the project manager of OCBA said. For supply chain and inventory control, OCBA continues to rely on a limited, separated, proprietary package that is linked to their financials through the SAP data warehouse. Table II summarizes the differences of the embedded sub-units of analysis.

4. Humanitarian context, Triple-A supply chains, and MFS's ERP requirements

The focus of this research is on the humanitarian post disaster operations that include distribution of medical and food suppliers in “routine” missions and also in the aftermath of international disasters (Holguín-Veras et al., 2012). This research doesn't cover the requirements of ERP systems for organizations that provide development aid. Development aid shares same characteristics with the humanitarian aid but distinguished by focusing in supporting economic growth in long-term level rather than short-term response. Based on our data analysis and the characteristics of humanitarian operations, we identify challenges and their effects on the performance of HOs for these post disaster recovery operations at the mission level.

Like many HOs, MSF follows a decentralized structure with headquarters (HQs) located in developed countries although missions mainly take place in remote areas in developing countries. Political and social conditions, lack of infrastructure, and national and international regulations frequently hinder disaster relief activities (Kovács and Spens, 2009). In addition, HOs have a high personnel turnover rate and frequently suffer from a lack of trained personnel (Kovács and Spens, 2009). Because HOs are not profit-oriented, they primarily depend on donor funding, and the structure of their funding systems impacts the agility and flexibility of their supply chains (Wakolbinger and Toyasaki, 2014). All these characteristics influence technology usage in this context.

Using the lens of Triple-A supply chain as guidance, we identify MSF's ERP requirements and design principles that can overcome these challenges and achieve specific goals (Giessmann and Legner, 2016). Our focus is on Triple-A humanitarian supply chain capabilities and how these capabilities will be enabled by ERP systems to improve organizational processes and ultimately improve organizational performance. The main elements of the Triple-A supply chain are agility, adaptability, and alignment. Below we present the Triple-A concepts and MFS' ERP requirement and how they succeed or failed to be implemented given their organizational structure as described earlier.

4.1 Adaptability

Lee (2004, p. 105) describes adaptability as the ability to “adjust the supply chain's design to meet structural shifts in markets and modify the supply network to reflect changes in strategies, technologies, and products.” HOs operate in conditions where telecommunication and infrastructure are lacking, must follow national and international regulations, and face high personnel turnover and a lack of skilled personnel. The effect of the aforementioned challenges is that HOs are unable to implement standard commercial ERP systems, which results in inefficient, unadaptable response, and the use of inefficient/workaround information systems incapable of handling the diverse requirements imposed by different laws and social conditions. A continuous flow of inexperienced users necessitates frequent trainings.

HOs must adapt to an atypical environment that changes periodically and varies from country to country. To enable adaptability, an ERP requires the ability of the system to work in remote areas and adapt to the characteristics of humanitarian operations. The capability of the ERP to work offline is one of the most successful developments of MSF. MSF has successfully developed in collaboration with the OpenERP editor, a synchronization engine that synchronizes data as soon as connectivity exists and allows users to work offline when connectivity does not exist. As the MSF IT project manager highlighted “this synchronization engine is kind of unique in the existing applications of HOs. Many HOs show a great interest in adapting this engine.” Through this engine, instances of MSF projects, the field and OC HQs will pull or push targeted data, both transactions and master data automatically or on demand.

In addition, adaptability requires the ability of the system to adapt to national and international regulations with respect to data encryption (some countries allow encrypted data transfers and other do not, the current version of MSF's application supports activation and deactivation of encrypted data transfers to meet specific country requirements) and multicurrency support since MSF and HOs are working in several countries and track cash movements in different currencies. In MSF, each OC has a consolidation currency (which is Euro for all OCs except MSF Switzerland that uses CHF) and all transactions must also be converted into the consolidation currency with its counterpart value. The ERP must provide the possibility to manage orders in several currencies and provides counterpart value in reference currency. For example, in MSF projects, when local staff buys items from local markets, they pay and enter the invoice in the local currency. Multiple exchange rates related to grants and budgets are challenging and ERPs should offer the flexibility of using different exchange rates.

To enable adaptability, an ERP system requires the ability to adapt to high personnel turnover and personnel cultures: As pointed-out by an MSF finance director “finding and keeping staff that are qualified to do the job required is one of the biggest challenges” …“people go to the missions for 6–12 months and then they leave and someone new is coming and we have to keep training people. Therefore, the challenge is to have software that can be learned quickly and also to have a training system that can teach people quickly.” MSF's initial requirement was to have a user-friendly application, “…that presents an attractive and intuitive user interface, a quick response time, shortcuts, wizards, proposed or automated actions, default values, with the level of functionalities adapted to the user profile.” To overcome these effects, ERP systems must be designed to work offline, to adapt to country regulations, and to support end users from different backgrounds (see: Design Principles 1,2,3 elaborated in detail in the next section).

4.2 Alignment

Lee (2004, p. 110) describes alignment as the ability of firms to “align the interests of all of the firms in their supply chains with their own,” Humanitarian aid almost always is funded, distributed, and governed in ways centered on the donors' desire for transparency and accountability (Oloruntoba and Kovács, 2015, p. 709). An ERP system to enable supply chain alignment needs to have the ability to align with donor requirements for transparency and reporting. MSF reports to private donors through publications based on standard accounting. As a logistics director mentioned: “Private donor reporting relies on the project based analytical tree that provides sufficient information of expenditure by country, project and activities.” HOs in general must be able to provide reports for donors, linking all transactions with report documents and to grant requirements. This was emphasized by the senior director of CRS who mentioned, “a big difference with the humanitarian sector is donor demands and donor requirements and how reports are configured…What's really challenging in the humanitarian sector is that different donors often have different reporting requirements. If the donors can be more consistent with their reporting requirements, it would be easier to implement the effort.”

As donor funded organizations, HOs typically are obligated to announce procurement tenders and follow strict bidding processes. E-tender modules to accommodate HOs' requirements for tendering have been successfully designed into MSF's ERP system. Grant management is also complicated for MSF. Grants are managed both at OC, HQ and country capital levels and as indicated in an ERP requirements document “The main task related to grant management which must take place in the mission is the allocation of expenses to the relevant funding dimension in order to follow-up consumption and anticipate reporting to donors.” In addition, when multiple donors fund the same project or a project starts with private donations but continues with institutional donations, grant management becomes more complex and demands great accuracy for correct financial reporting (see Design Principle 4).

The decentralized governance models that many HOs follow limits intra-organizational functional coordination and integration. The ERP system should support connections among organizational entities such as local projects, coordination centers at country missions, and headquarters (see Design Principle 5). HQ needs access to all mission data; the missions only need access at the country level and projects only need access to their own transactions as well as expenses made at HQ or coordination level on behalf of the project. In MSF, each HQ has its own ERP system and there are no plans to change it at the moment. Users at the HQ level have access to a central UniField database to check stock at the different levels and also to complete some transactions that need HQ approval. Also, purchase orders from the field will be synchronized to HQ and from there will be forwarded to the European distribution centers. As soon as the distribution centers execute the orders, users at the HQ level enter them to UniField and they are synchronized at the field level. In addition, in MSF the integration of finance and supply chain processes was important because as we mentioned previously, they used to have standalone systems that they were not connected.

In addition, in many humanitarian crises, multiple HOs are involved and there is little coordination and collaboration among them. ERP should support the integration and coordination of data and information with external systems of other HOs (see Design Principles 6). Especially for MSF that has five operational centers, connection between them and mutualized resources is an ERP requirement. It is often the case that the different OCs need to exchange stock at the field level when stock shortages occur. MSF achieves this via the synchronization engine. MSF succeeded in developing an ERP that connects OCs and thus, is capable of sharing information and transactions between all entities, thereby facilitating supply chain alignment capabilities.

4.3 Agility

Lee (2004, p. 105) describes agility as the ability to “respond to short-term changes in demand or supply quickly and handle external disruptions smoothly.” Humanitarian literature repeatedly argues that supply chain agility is an essential requirement in humanitarian operations (Dubey and Gunasekaran, 2016; L'Hermitte et al., 2016; Oloruntoba and Kovács, 2015; Charles et al., 2010). Being agile helps HOs quickly and flexibly respond to demand fluctuations, supply disruptions, and changes in suppliers' delivery in different types of humanitarian disasters, varying geographical areas, and dissimilar populations (Dubey and Gunasekaran, 2016; Samabamurthy et al., 2003).

HOs typically operate in chaotic environments characterized by unpredictability, uncertainty, ad-hoc supply chains, and rapid deployment on demand. These factors create high project turnover, resulting in rapid changes to supply chain set-ups and technology usage and leaving organizations unable to expand and adapt to emergency needs. An ERP system must be scalable and modular to meet the operational requirements of users and data and transaction volume (see Design Principle 7). MSF needs a scalable solution that can be used by more than 4,000 users around the world. “We face high turnover of projects, we close and open 25 percent of projects every year worldwide and, thus, an ERP should be able to scale according to the demand” said a logistics director of MSF. In terms of modularity, MSF needs to “develop tailor-made modules that can be connected or disconnected from the core solution” according to the unique needs of differing OCs and emergency situations. However, thus far, MSF has failed to create modular applications that allow OCs to turn on and off features and functions dependent on their operating differences.

Furthermore, to avoid duplication of efforts and poorly timed deliveries, ERP systems should be designed to manage the particular transportation requirements of specialized relief items. MSF and other HOs use KITs to respond rapidly to disaster needs. A module in ERP that supports KITs, kitting and de-kitting processes is necessary. KITs can be handled as single items such as an order, but it can also be “multi-leveled,” meaning that a KIT can be composed of other KITs. This functionality was successfully implemented by MSF. An additional characteristic of humanitarian operations are in-kind donations that HOs are receiving and that must be managed to ensure supply chain agility. As stated in the ERP requirements document of MSF, “MSF regularly receives goods from donors and partners, which must be traced within the stock at a value that is consistent with the items bought from MSF. From an accounting point of view, such donations must increase the value of stock and have a counterpart in an in-kind donations revenue account” (see Design Principles 8,9).

HOs operate in insecure and dangerous conditions where a lack of asset visibility leads to poor asset management. Consequently, HOs need systems that carefully and flexibly track their assets. MSF's OCs have different depreciation rules for their assets which made the development of the module challenging (see Design Principle 10). Another aspect of humanitarian operation is the assessment that HOs immediately conduct when a disaster occurs to identify the affected population and their needs. To respond quickly, HOs must be able to coordinate and integrate all information from assessments and deliver and track monetary and in-kind relief (see Design Principle 11). Finally, supply chain agility may be achieved if, by designing an ERP that supports big data analytics, HOs can analyze event transactions data and possible outcomes through simulation (see Design Principle 12).

5. ERP design principles for HOs

We present 12 design principles that are specific to the HO context. The first eight design principles were derived directly from observations in our embedded case study. We complement these eight with four additional design principles derived primarily from the literature and humanitarian needs as discussed in the field. For example, we derive Design Principle 1 (discussed in detail in the next section) as follows: We observed that HOs missions operate in areas where there is little telecommunication and electricity infrastructure (challenge). Current information systems cannot adapt to such an environment (adaptability to local infrastructure), creating inefficient response (effect) when organizations are unable to communicate electronically. The ERP requirement is to adapt to the local infrastructure. Hence, we derived Principle 1: Design for using replication and synchronization technology that allows online and offline transaction and data storage. The goal of this design principle is to have widely available offline synchronization and system usage in humanitarian missions (Table III). Design principles are implemented either by software configuration of customizable capabilities offered through the existing ERP package (in essence turning on and off functionality switches prebuilt into the ERP software; or, by customizing the existing system through new programming to offer completely new capabilities not previously present in the system). For example, the first design principle is done by customization coding but the second by mostly configuration of the software available with the Open ERP system with some more modest customization coding.

5.1 Design principles to enable supply chain adaptability

Principle 1: Design for using replication and synchronization technology that allows online and offline transactions and data storage: ERP systems used in humanitarian operations in remote areas must be able to support offline capabilities and provide a high level of robustness and reliability. In standard ERP systems, data are collected once “during the initial transaction, stored centrally, and updated in real time” (Hendricks et al., 2007, p. 77). This ensures appropriate planning based on operational conditions of the organization. The risks associated with low Internet connectivity in field offices should be carefully assessed, managed, and mitigated for all HOs that are planning to implement an ERP. In MSF and other HO cases, data must be stored locally, and once connectivity exists, all data must be synchronized and updated. This design principle allows HOs to overcome the challenges of the external environment and facilitates accessing information in remote areas, tracing and tracking capabilities, increasing visibility and quality assurance of deliveries to beneficiaries. These capabilities do not come easy, with a majority of ERP systems used at the field level not offering the possibility of working off-line. Yet these capabilities are critical, for example, UNICEF spent considerable funds to implement SAP as their ERP yet stated in a humanitarian conference in 2017 that they “invested a lot of money in having advanced ERP systems but they ended up working with Excel files and now they are trying to develop a module to work off-line.”

Principle 2: Design for activation and deactivation of encrypted data transfers, support of multi-currency and exchange rates, preset customs, and clearance: Government regulation and politics should be taken into consideration for the design of an ERP system for HOs. HOs are often operating in more than 60 countries and they hire local personnel and make local purchases. In many cases, HOs face strict regulations on transporting and importing goods, information exchange and customs clearing procedures (Kovacs and Spens, 2009). Import regulations vary in different countries and the ERP should be able to provide all necessary documents for facilitating import processes. Different tax policies dramatically increase the complexities of ERP implementations. Also, some countries have regulatory restrictions regarding the sharing of encrypted data. This presents unique design considerations. In such cases, the activation and de-activation of the encryption of data according to the country must be a component of the design. In essence, encryption must be strong enough to prevent conventional hacking but flexible enough to accommodate various governmental encryption policies and also not be so onerous in its difficulty to use that it prevents access to data from people who need it in an emergency. Standard ERP packages do not handle these variations and developers must rewrite the source code in order to fit with their business (Sheu et al., 2003). ERPs designed for HOs must support multi-currencies, the ability to manage several exchange rates and date/time. All transactions must be converted into a consolidation currency with its counterpart value and the systems should offer the ability to activate/enable currencies at the mission level. Tax and labor laws in different countries pose another challenge for HOs attempting to use standard ERP packages because each country where HOs operate has its own taxation systems and laws. This principle helps organizations to increase their supply chain adaptability by accommodating to local characteristics, supporting data sharing with local governments and other actors, and making reliable reporting possible.

Principle 3: Design for multi-language support, online training, user friendliness, and easy, centralized installation and maintenance: One of the biggest challenges that affects the implementation and effective use of an ERP is the high staff turnover, which is mentioned by all interviewees both at the international and national level. High staff turnover and the lack of trained personnel requires user-friendly ERPs that have an intuitive, transparent and easy to use interface. Provision of interactive help and e-learning possibilities to minimize the time that users navigate the system to perform certain tasks and business processes are also essential for HOs. Automatic functionalities and processes like the auto creation of orders based on replenishment rules such as min and max quantity, threshold values, which could be set centrally or locally can help untrained users and minimize mistakes of non-appropriate forecasting. Multi-language capabilities for local and international users as well as for documents generated from the ERP are needed. Centralized updates and releases of new versions and backups would be a great benefit for HOs. Those features empower end-users to take action in operations to improve their service levels. In addition, they are in accordance with the humanitarian principles of accessibility and inter-operability as presented by Van de Walle et al. (2009). “Humanitarian information and data should be made accessible to all humanitarian actors by applying easy-to-use formats and by translating information into common or local languages” (Van de Walle et al., 2009). This principle could help HOs minimize mistakes, duplications of payments and efforts, and provides their personnel with easy to learn and use software.

5.2 Design principles to enable supply chain alignment

Principle 4: Design for high transparency, reporting and grant management specifications and requirements: Most of the HOs are facing financial constraints that seriously limit technology investment and they are highly dependent on donor funding. Humanitarian organizations need to compete for the resources that are available, and, in many cases, donations are earmarked which means that donors put conditions on how their donations could be used (Toyasaki and Wakolbinger, 2014). Donors prefer to support emergency programs and typically do not provide sufficient funding for planning, preparation and information systems which leads to inefficiency and increasing operational costs (Van de Walle et al., 2009; Beamon and Balcik, 2008). In many cases, HOs have to postpone or cancel IT projects because of lack of funding, or they have to justify to donors why they need additional funding. This is a process that takes time. As explained by the CamptoCamp director (an IT vendor of OpenERP), HOs have to “define the scope of the project, define the budget and then go to donors to find the money, while private companies after the definition of the scope and budget are ready to start the projects.” Due to this limitation and dependency, projects such as an ERP must be implemented at minimum costs.

Donors also are interested in making sure that their donations are used in the best possible way and since they cannot directly observe the quality of an aid agency they are asking for more transparency and accountability. This leads to increasing reporting requirements for HOs (Wakolbinger and Toyasaki, 2014; Beamon and Balcik, 2008). Allocation of costs has to be done automatically according to the business functions (supply, finance, HR, medical department) based on the item code; this is not always supported by standard ERPs (Chou et al., 2005). Ad hoc reports to improve operational decisions and standardized reports for donors should be easily accessible to all users. The logistics director of MSF goes a step further and suggests more unified reports “ideally, we all should try to impose a simplified kind of reporting format to donors through the use of information systems and why not give access to donors to our databases.” In the case of HOs, donors are also “customers” to be satisfied (Blecken, 2010). By following an ERP design that takes into consideration resource limitations and donor requirements, HOs facilitate accountability and transparency and thus increase funding from donors that leads to better responses. Therefore, this design principle enables the agility of the organizations that leads to better financial performance.

Principle 5: Design for supporting decentralized governance: Many international humanitarian organizations follow decentralized governance structures and most have to manage geographically dispersed units/teams. The use of ERP systems in decentralized operations involves unique technical and managerial challenges (Markus et al., 2002). Usually, a HQ is located in a western country and a mission office operates from the capital of each mission country that coordinates the activities of the projects in remote areas. Decision-making is spread across different levels with a high degree of autonomy. The decentralized governance from an IT point of view means decentralized databases and accounting systems and the potential for a lack of transparency both vertically and horizontally across countries and missions. The ERP architecture should meet these operational requirements and provide a median for transparency between units for better communication and control. This will help HOs minimize duplication of efforts and increase efficiency. To apply this guideline, ERPs must be compatible and connected with existing systems to ensure a variety of sources so as to provide varied perspectives for addressing problems and recommending solutions.

Principle 6: Design for inter-organizational collaboration between HOs: Inter and intra-organizational coordination has become an increasing challenge in humanitarian operations and the literature highlights the importance of collaboration between actors involved to improve humanitarian response (Van Wassenhove, 2006; Kovács and Spens, 2007; Balcik et al., 2010). This was confirmed also by MSF's logistics director “Yes, we see a trend that organizations should share. And, of course when we try to integrate information from different organizational systems, ERP facilitates these processes.” A lack of coordination among actors has been shown to increase inventory costs, lengthen delivery times, duplicate efforts, and may result in loss of lives (Balcik et al., 2010). The sooner the different actors are able to collect, analyze and disseminate critical information, the more effective a response can be and the more lives are potentially saved (Tchouakeu et al., 2011). Cross-linking systems that support an integrated view of data from regional and central warehouses and from other organizations in the field allow for greater information transparency to exchange real time information about stocks and to place orders electronically. ERPs designed in this way are in greater accordance with the humanitarian principles of inclusiveness, accessibility and inter-operability as descripted by Van de Walle et al. (2009). This kind of system, hence, facilitates coordination within and across organizations and enables supply chain agility.

5.3 Design principles to enable supply chain agility

Principle 7: Design for scalability across a wide range of needs from field to HQ and modularity allowing local and regional customization: HOs operate in highly uncertain and dynamic contexts where conditions change frequently. Scalability is identified as a basic requirement for successful ERP development in humanitarian operations especially in developing countries. ERPs should provide HOs with a scalable solution that is flexible and can expand according to the operational requirements in terms of users and volume of data and transactions. It is often the case that HOs need to expand their activities in many geographical areas and to increase the number of users and transactions. ERPs must be designed to support a large volume of transactions. All data and transactions should be stored in a data warehouse that facilitates efficient access to data for multi-dimensional analysis and reporting purposes and ensures the integrity, consistency and control of data. Modularity relates to the degree to which different module-components of the system work independently and interchangeably. Designing to be modular is difficult and requires acceptance of diverse inputs across a decentralized organization. Faced with urgent needs specific units of HOs should be able to place emergency orders that may include exempting steps necessary under normal conditions. Additionally, “different modules or functionalities may be required for different levels in the humanitarian supply chain” (e.g. local/project, level, regional/coordination level and headquarter levels) (Blecken, 2010, p. 220). Open source development offers some promise in design of systems permitting easier addition and modification of new modules that can be connected or disconnected from the core solution as needed. These design principles enable supply chain adaptability of humanitarian operations and empower HOs to respond to changes effectively and efficiently.

Principle 8: Design for relief items specifications, stock management and in-kind donations: Supplies of relief chains primarily consist of supplies pre-positioned in warehouses, supplies procured from suppliers, and in-kind donations. Suppliers ship from different locations worldwide to central warehouses and then distribute to different projects in remote areas. ERPs must integrate all supply chain processes and offer stock management capabilities for the different warehouse locations as well as last mile distribution to beneficiaries. An ERP that integrates humanitarian supply chain processes manages in-kind donations and KITs, stock and inventory management, helps increase beneficiaries' service levels, efficiency, and flexibility. An ERP module that supports KITs, kitting, and de-kitting processes is necessary because, as explained by one of MSF's directors, a HO may “need to send 10,000 KITs/items in one line which is not offered by many ERPs.” Thus, it enables supply chain agility and allows HOs to respond effectively to dynamic environments.

Principle 9: Design for supporting relief vehicle routing and scheduling in the field operations (fleet management module): Fleet management provides support to humanitarian assistance by enabling timely, efficient and effective transportation of goods and personnel to affected areas. Transportation is the second largest overhead cost to humanitarian organizations after personnel. A considerable proportion of transportation demand uncertainty is due to the lack of coordination in vehicle scheduling and routing (Eftekhar and Van Wassenhove, 2016; Martinez et al., 2011). Fleet scheduling and routing is very challenging in humanitarian operations and depends on many factors such as weather conditions and types of disasters. During the rainy season, the transportation network may be destroyed since non-paved roads may become impassable. A flood or an earthquake may trigger landslides. A fleet management module should include fleet administration, fleet use, and maintenance. Monitoring and tracking vehicles based on GPS mapping systems, routes and drives, delivery locations and items would improve delivery performance and speed. The tracking of humanitarian vehicles can improve fleet management and relief logistics through enhanced transparency by providing locations and paths followed by vehicles from origin to destination (Delmonteil and Rancourt, 2017). GPS can communicate real-time data such as current positions, continuous movements, and predetermined reports and alerts (Delmonteil and Rancourt, 2017). This design principle results in better monitoring, visibility, scheduling and reduction of costs.

Principle 10: Design for tracking assets and valuable items in insecure field environments: An ERP module for asset management assists organizations in creating and maintaining documentation for their equipment such as computers, servers, vehicles, medical equipment, generators, wash, and sanitation equipment. Asset management requires accurate, comprehensive, documented details of the identity, operating, and maintenance parameters of equipment. This information is utilized throughout the life cycle of the equipment and is very important for HOs since they bring very expensive items to the field where conditions have become increasingly dangerous. The value of humanitarian assets is considerable and it is often the case that HOs become targets of armed groups which are considering the assets as economic resources (Guire, 2015; Stoddard et al., 2009) HOs need to know where exactly their assets are located and they need to get reports regarding their valuation, depreciation, operational and maintenance costs. Such a module provides more transparency of the usage of equipment and minimizes operating costs of HOs.

Principle 11: Design for assessing needs after a disaster occurs, registration of beneficiaries, and Cash Transfer Programming: Assessing the needs of the affected areas after a disaster occurs is one of the first and very important phases of humanitarian response. Assessment provides a holistic understanding of the situation and needs of people affected by a disaster. It gives the necessary evidence-base to design and implement responses (Comes and Van de Balle, 2016). ERPs for HOs should include a module for assessments that can support HOs in better planning for the delivery of goods. Having this information, field staff can check what “supplies are available for beneficiaries, either in local warehouses, pre-positioned emergency stocks or from local and international markets” (Howden, 2009, p. 4). In some cases, HOs provide beneficiaries with cash instead of relief items. This is an alternative to in-kind assistance, and it has become a priority of the humanitarian community and donors. Basically, a CTP is the transfer of cash that empowers the affected population to decide on their own how to meet their own needs using available local resources. CTP has different forms including, cash in hand, vouchers, and electronic transfers (Cross and Johnston, 2011; Harvey and Bailey, 2015). For HOs that use CTP, a module on their ERP that manages cash transfer allows them to establish standard operating procedures and financial controls and coordinates better all activities that were given to external providers. In addition, an ERP for HOs should include a module for registering beneficiaries and track deliveries to them, either in-kind assistance or cash. ERP systems that integrate and coordinate assessment information, in-kind assistance or cash transfer as well as beneficiaries' information increase visibility and agility.

Principle 12: Design for big data analytics and simulations for humanitarian operations: Big data management and data analytics is an emerging topic both in the humanitarian world. Big data can be an essential tool in humanitarian response for organizations because it allows responders to develop insights into humanitarian trends. By utilizing large datasets such as telephone and census records, geo-positioning data, social media data, and others in combination with traditional datasets, big data can enable deeper analysis of the humanitarian system: It can help identify when and where people are in need of relief (Whipkey and Verity, 2015). Data generated in ERP systems “includes historic demand and forecasting data, replenishment lead times, service levels, holding costs, and fixed costs” (Souza, 2014, p. 602). This data is helpful for simulations, what if scenarios and allows HOs to plan better. Resources can be allocated more efficiently and effectively with this knowledge in hand. An ERP that offers the opportunity to humanitarians to analyze their data and simulate different scenarios would be very helpful for humanitarian operations and will increase supply chain visibility and agility.

Table III summarizes our findings and represents the logical process by which we derived our design principles. First, based on empirical data and the lens of Triple-A supply chain, we identify a set of challenges and their effects on the performance of humanitarian aid organizations and ERP requirements. Next, we propose actions to solve potential problems and achieve specific goals.

6. Conclusions, discussion, and recommendations

The purpose of this paper is to present overarching design principles of an ERP to enable Triple-A supply chain capabilities and improve humanitarian responses. To guide this study, we conducted an embedded case study with MSF. The main findings of our research are that ERPs for HOs should be designed as unique ERP systems addressing HOs' challenges and unique missions, their value generation processes, and resource base in an effort to improve organizational performance. We presented 12 general design principles that are unique for HOs. These design principles provide a high-level structure of guidance under which specific requirements can be further defined and engineered to achieve success. While these design principles originate empirically from our case data and are supplemented by literature, we do not claim that list is exhaustive. Additional individual design principles based on characteristics, processes, and size of HOs could be identified in future research.

Our research shows that HOs have unique routines and that standard ERP packages do not easily adapt to these routines at the field level. From the perspective of HQs, standard ERP packages may fit. However, operations in the field and at remote areas require offline capabilities and the majority of standard ERP systems do not offer these capabilities. Furthermore, ERPs for HOs need to follow a decentralized architecture “where in every site the system can work in an autonomous way when the connection is not working properly… and if you look at the market there are very few actual ERPs that offer the capacity to add a decentralized architecture with the synchronization of the data” mentioned an MSF IS Director. Decentralized architecture and offline capabilities are something that is not offered by standard ERP packages and has to be customized. Also, the distribution and the management of relief items such as KITs are challenging and are not offered by standard ERPs. HOs in time of crisis prefer to speed the distribution rather than focus on the accuracy that would be required for standard ERP and inventory systems. Another unique characteristic of humanitarian operation is the closing and opening of missions and the software licensing issues related to this. As mentioned by an MSF IT director “standard ERPs have a kind of complicated license system that may not be as flexible and scalable as HOs require to be.” Other unique characteristic of HOs such as beneficiaries' registration and cash transfers interventions should also be integrated into the ERP.

HOs can use our proposed design principles when evaluating features and functionalities of existing ERP software, whether open-source or commercially provided. The proposed design principles should also be of value for ERP vendors that seek to address the need of HOs by developing ERP software especially designed for the HO context. This also applies to open source developers and open source communities. ERP vendors like “CamptoCamp” recognize that there is a business opportunity in the humanitarian sector. When presented the theoretical approach used by the researchers, the director of CamptoCamp stated, “there are generic features and functionalities for all, private and HOs, specific to each HOs and generic to humanitarian sector. It is important for us to understand these and create a community for HOs in which we can in the future share some new development and save money and time.”

Beyond design principles our embedded case study revealed project governance issues that HOs should consider before undertaking a large-scale ERP project such as (1) the extent to which they should undertake standardizing and improving their supply chain processes before designing and implementing an ERP, (2) if and to what extend should different constituents be involved in the definition of the ERP requirements. For example, how deeply should end/mission users be involved in the definition of the requirements and how open are organizational units to change business processes and/or use new advanced technologies, and (3) who has the ownership of the ERP project and how do you drive participation and consensus building.

For small HOs with limited resources and/or technical constraints, open source ERPs possessing attributes of our design principles may present a solution with an open architecture, lower costs, and easier adaptability. Meanwhile, standard commercial ERP systems seem to be more suitable for the HQs of HOs that operate in a more “business” like fashion and are not facing infrastructure and operational constraints. If commercial ERP vendors (such as SAP and Oracle) incorporate the design principles outlined in this study into their humanitarian version of their ERPs, then we expect that commercial/standard software offerings for HOs will be a more attractive option if not too pricy. However, if a HO has a very unique mission requiring very high levels of customization then a proprietary or home developed application tailored to its unique needs might be best. Of course, higher costs and effort come with this approach. A secondary benefit of customized development may be greater asymmetry in service delivery quality and flexibility compared with other HOs.

The experience gained from MSF showed that a high risk of failure exists for HOs undertaking large-scale ERP design and implementation. As we saw at MSF, OCs like Amsterdam, Brussels, and Geneva desiring a more structured focus on processes also were more open to using new technologies to achieve this goal. Their OC top management remains very supportive and open to taking the risks to increase efficiency and effectiveness. OC Paris seemed to be more risk averse and to have less top management support for implementing an ERP. OC Barcelona remained on the fence concerning implementing UniField preferring to spend less effort using less than optimal commercial ERP. Clearly, not all personnel and all top managers of the five MSF OCs supported UniField project. During the years since its inception numerous managers pursued other priorities, emphasizing that “MSFs energy and resources should be focused on delivering medical care to people in need and not developing IT applications.” Decision-making regarding the project was often slow. Without universal buy-in the project started with two of the OCs (OCP and OCBA) not really participating in design and development. This led to even more delays and a higher budget than planned. Despite this weakness, MSF persevered in developing and implementing an ERP that generally works to their project specifications.

Our recommendations to HOs that are planning to implement ERPs in their operations is to review their processes before starting to implement ERPs, and identify the benefits of the ERP and promote the project to the field. Change management and top management support are essential. Project governance may demand a more top-down approach rather than bottom-up decision-making as MSF followed. Of course, this is challenging given HOs are based on humanitarian ethics and democratic decision-making an additional recommendation to HOs, based on MSF's experience is to try to implement the ERP for the entire organization, from HQ to the field projects and if possible to distribution centers to ensure integration of all functions and organizational entities. From our research, it is clear that HOs have their own unique organizational and behavioral structures that must be accommodated by unique design principles for their software systems if they are to achieve the benefits of a Triple-A supply chain.

7. Limitations and future research

As with any research, there are several limitations to be considered when interpreting the results of this study. First, although augmented by literature and external interviews, our findings are primarily based on a single embedded case study limiting generalizability. But, since the case study was analyzed and presented as an embedded case study with five autonomous subunits using different business processes and following different adoption and implementation approaches, we strongly believe that our findings are derived based on considerable variance reflective of HOs beyond MSF. The majority of HOs operating in the same environment as MSF possess limited infrastructure and face security, financial and cultural constraints. They follow decentralized structures and open and close missions frequently, which demands specific design principles for their information systems similar to MSF.

Also, while we have conducted an in-depth case study of one HO complemented by two other organizations that are partially implementing aspects of the same software and one ERP vendor, the private sector side of ERP design and implementation might be under-represented in our research. While not the focus of the paper, the purely technical IT components of the ERP are not discussed in detail. In addition, the size and structure of MSF might not be representative for very small organizations that may face additional challenges that are not presented here. A further validation using additional qualitative and quantitative empirical studies should be conducted to validate our findings. Validation processes could also examine if the set of requirements that we identified present a complete set or if alternative sets exist. Despite these limitations, however, we believe that this study provides value to all actors involved in HOs and to the humanitarian community at large.

Figures

Figure 1

MSF embedded case study design

Figure 2

Research process

Table I

Methodological guidance adapted from Sarker and Sarker (2009, p. 445)

Study aspects	Methodological consideration	Goals	Illustrations
Case organization	Choose an HO to be used as a case study	The goal was to study a representative organization in terms of the phenomenon	MSF was chosen because is widely acknowledged as a leading HO and it is currently implementing an ERP in its humanitarian missions (field level) worldwide. In addition, MSF is an international coordinating and oversight organization but also possesses five distinct and autonomous operational centers with their own headquarters and field operations. This allowed us to gain insights from an embedded case study of five unique operational centers and decision-making scenarios
Data collection	Selection of the interviewees	Respondents were suggested by the project manager of the ERP project across operating units, who also helped set up many of the interviews Relevant respondents were also identified by other respondents (snowballing technique)	We balanced the perspectives by interviewing employees in a variety of roles and with varying experience. We interviewed workers from both the field and the HQs
	Interview methods	Flexibility	We rescheduled or shortened meetings to fit interviewees' time We used an open discussion style in the interviews We did face-to-face interviews, Skype interviews, and accepted written answers when there were connection issues in the field
	Researcher involvement in the study	Data collection involved a long-term engagement of the researchers	Our data collection was undertaken over 4 years with 22 in-depth interviews, two workshops organized by a project manager of MSF's ERP project, significant informal interactions with project participants, and personal participation in the project by one of the researchers
Data analysis	Refining concepts through comparison	The scope is to see if the data support categories	We analyzed the collected data on a line-by-line basis and grouped them into codes that summarized our interpretation of the data
	Triangulation	To ensure triangulation, we compared responses across respondents, locations and secondary data of the organization	We tried to make sure all information used in this study was suggested by multiple respondents in both the same and different locations, namely HQ and field
	Member validation	Validating research interpretation	We sent the results of our research to interviewees for validation and presented them in the workshops that we organized

Table II

Case study sub-units of analysis

Variables	OCA-Amsterdam	OCB-Brussels	OCG-Geneva	OCBA-Barcelona	OCP-Paris
Culture towards achieving mission	Highly bureaucratic and quality focused culture. Focus on standardized processes that deliver efficient and effective operations throughout organization that missions will leverage	Initially less bureaucratic and quality focused culture. Transformed to have a considerable focus on standardized processes that deliver efficient and effective operations throughout organization	Supportive change culture. Seeks to improve operations' effectiveness and efficiency through standardized processes as a critical part of ERP implementation. Willing to invest heavily in process change towards long-term outcome	Modestly bureaucratic and quality focused culture. Seek to improve operations' effectiveness and efficiency but not willing to heavily invest in process change. Wants to ensure resources for mission. Lower risk strategy	Less bureaucratic and central operations focused. People culture. Focus on dynamism of operations and adaptability to humanitarian context. Non-technology driven. Mission oriented with local autonomy and flexibility
Process maturity and structure	Very structured and well-documented supply chain and finance processes. High maturity in terms of standardized and customized processes	Structured and well-documented supply chain and finance processes. High maturity in terms of standardized and customized processes	Moderate/low maturity in terms of standardized and customized existing processes. Looking to set up standard supply chain and finance processes	Structured finance processes and far less structured supply processes. Moderate/Low maturity in terms of standardized and customized processes	Less structured and formalized processes. Seek flexibility and adaptability, largely through people's proximate actions. Low maturity in terms of standardized processes
Buy versus make	Make ERP to fit to unique processes. No willingness to review and adapt business processes to standard ERP modules. Sought to customize ERP to their way of operating	Make ERP to fit to unique processes. Little willingness to review and adapt unique processes to standard ERP modules. Open in configuring some standard ERP modules	Willingness to review and adapt business processes to standard ERP modules. Customize system to best practices as observed in other OCs/ Open in configuring standard ERP modules	Buy standard ERP. High willingness to adapt business processes to standard ERP modules. Little interest in customizing software to unique business processes	Make ERP to fit to unique processes. No willingness to review and adapt processes to standard ERP modules. Little interest in building or buying, rather wanted to cobble through with what they have
Governance model and top management support	Strong top, middle and field management support providing resources and priority to ERP project	Strong top, middle and field management support providing resources and priority to ERP project	Strong top, middle and field management support providing resources and priority to ERP project	Low top, middle and field management support for UniField. Some support for commercial ERP solutions	Low top, middle and filed management support. Paris has other priorities. ERP has less support in terms of resources and allowed more local –field level autonomy to cobble solutions that fit the context
Technological change and risk propensity	Medium openness to take the risk of changing existing IT systems with an integrated ERP to achieve better organizational performance and competence as long as they conformed with their existing processes	Moderately high openness to take the risk of changing existing IT systems with an integrated ERP to achieve better organizational performance and competence as long as they conformed with their existing processes	High openness to take the risk of changing existing IT systems with an integrated ERP to achieve better organizational performance and competence	Low openness to take the risk of changing existing IT systems with an integrated ERP to achieve better organizational performance and competence. Low willingness to use the customized ERP that other operational centers use	Low openness to take the risk of changing existing IT systems with an integrated ERP to achieve better organizational performance and competence. Their moto is “if something works, for example Excel, why should we change it. Our mission is to save lives and not change IT systems”

Table III

Design principles of ERP systems for HOs

Challenges of humanitarian environment	Effects	Requirement to enable Triple-A supply chain	Design principle	Goals
Lack of telecommunication and electricity infrastructure	Inability to communicate electronically limits the use of standard ERP systems, which leads to paper-based work and results in inefficient and unadaptable response	Adaptability to local infrastructure	Principle 1: Design for using replication and synchronization technology that allows online and offline transactions and data storage	Widely available offline synchronization
Diverse political and social conditions Varied national and international regulations	Unitary information systems that cannot adapt to diverse requirements imposed by different laws and social conditions	Adaptability to local laws and regulations	Principle 2: Design for activation and deactivation of encrypted data transfers, support of multi-currency and exchange rates, preset customs, and clearance	Flexible and adaptable in the political and governmental regulations of hosting countries
Volunteer nature of the business leads to high personnel turnover and lack of trained and skilled personnel	Continued flow of inexperienced users that lead to the need of frequent trainings and mistakes	Adaptability to users' skill level	Principle 3: Design for multi-language support, online training, user friendliness, and easy, centralized installation and maintenance	ERP system can be used by all users efficiently
High dependency on donor funding	Need high level of transparency and accountability not supported by standard ERP systems	Alignment with donors	Principle 4: Design for high transparency, reporting and grant management specifications and requirements	Automatically generated reports based on donor requirements
Decentralized governance and organizational structure	Lack of intra-organizational functional coordination and integration	Alignment with organizational entities	Principle 5: Design for decentralized governance by connecting and integrating diverse internal systems	Integration of internal systems
Lack of coordination and collaboration among multitude of actors involved	Lack of cross-linking systems and information exchanges between actors	Alignment with other HOs	Principle 6: Design for inter-organizational collaboration between HOs	Integration and data exchange with external systems
Unpredictable demand	Inability to expand and adapt to emergency needs	Agility to respond to uncertainty in demand	Principle 7: Design for scalability across a wide range of needs from field to HQ and modularity allowing local and regional customization	Quick and flexible response to operational requirements in terms of users and volume of data and transactions
Need to bundle items for quick distribution in emergency situation	Inefficient distribution and duplication of efforts	Agility to respond to variant relief item specifications	Principle 8: Design for relief items specifications and stock management (KITs, in-kind donations)	Ability to manage specifications of relief items
Highly variant routing and transportation needs	Inabilities to deliver on time	Agility to respond to uncertainty in transportation needs	Principle 9: Design for supporting relief vehicle routing and scheduling in the field operations (fleet management module)	Support for vehicle tracking and routing
Insecure and dangerous conditions and lack of asset visibility	Poor asset management Duplication resulting in higher costs	Agility to respond to uncertain conditions for relief assets	Principle 10: Design for tracking assets and valuable items in insecure and dangerous conditions (asset management module)	Support for asset tracking
Rapid needs assessment, in-kind and monetary relief	Fragmented and unreliable systems to deliver aid that may not meet the need	Agility to respond to uncertainty with respect to beneficiaries' needs and type of intervention	Principle 11: Design assessment modules and modules for beneficiary registration and Cash Transfer Programs	Support for tracking in-kind and monetary relief to beneficiaries
High amount of data and information in time of emergencies	Inefficient use of existing data	Agility to respond to uncertainty with respect to data amount and quality	Principle 12: Design for big data analytics and simulations for humanitarian operations	Support for analyzing big data and conducting simulations

Table AI

List of interviews

Organization	Country	Level	Position	Data
MSF	Switzerland	HQ	Medical Referent	Semi- structured interview
MSF	Switzerland	HQ	Project and Program Manager	Semi-structured interview
			Supply Project Manager
			IT Project Support
IFRC	Switzerland	HQ	Project Manager	Semi-structured interview
MSF	Austria	HQ	Program Director	Semi-structured interview
GAIN	Switzerland	HQ	Project Manager	Semi-structured interview
MSF	Greece	Field	Logistics Coordinator	Semi-structured Interview
MSF	Greece	Field	Field Coordinator	Semi-structured interview
MSF	Greece	HQ	Director of Medical Operational Support	Semi-structured interview
MSF	South Sudan	Field	Supply Officer	Written answers
MSF	Swaziland	Field	Logistics Coordinator	Written answers
			Supply Officer
			Supply Manager
MSF	Switzerland	HQ	UniField Supply Trainer	Semi-structured interview
MSF	Kyrgyzstan	Field	Supply Manager	Written answers
MSF	Switzerland	HQ	Finance Trainer	Semi-structured interview
			Finance Director
			Logistics Director
CamptoCamp	Switzerland	Field	Director	Semi-structured interview
MSF	Belgium	HQ	Supply Referent	Written answers
MSF	Spain	HQ	Deployment Manager	Semi-structured interview
			Deputy DG Organization and Systems
MSF	Geneva	HQ	Project Manager	Workshop in Vienna
CRS	United States	HQ	Senior Director of Global Solutions	Semi-structured interview
MSF	Netherlands	HQ	UniField Project Manager	Semi-structured interview
MSF	Netherlands	HQ	Head of Programme Management Office	Semi-structured interview
MSF	Geneva	HQ	Project Manager	Workshop in Vienna
MSF	Geneva	HQ	IS Director	Semi-structured interview

Appendix 1

Appendix 2: Example questions used at different times throughout longitudinal case study

1. What is the main goal of the implementation of UniField? What are the main goals from a supply chain perspective? How could UniField enable supply chain agility, adaptability and alignment?

2. Could you please describe MSF's operational model and structure? Who are the main actors across the network and what is their role in the decision-making processes? How is this model affected by the design of UniField?

3. Do missions have the right to reject or delay the implementation of UniField? Can missions reject to use UniField after implementation?

4. What are the critical success factors of designing and implementing an ERP at MSF?

5. Why are only three HQs out of the five operational centers implementing the software? Will the software be universally used across all areas within the three HQs? Is it more a financial or political decision?

6. How do the five operational centers differ in terms of operations and processes? How are they different in terms of developing and using UniField? What is your unique approach to adopting and implementing Unified?

7. Why have you chosen open source and not a package software like SAP? Do you think that standard ERPs could be adapted by HOs? Why/Why not?

8. Why did the design and implementation of UniField take so many years?

9. What are the main design principles that drive UniField and how do those principles strengthen the assets and capabilities of the organization? Are these principles intergraded in the UniField design?

10. What are the main capabilities of UniField in comparison with the old system? Have you done an analysis comparing what was agreed and what is finally delivered?

11. Does UniField improve the work of all operational centers? Do you see differences between the 5 centers? How do you compare yourself to the other operational centers in terms of implementation?

12. We categorized the Amsterdam operation as having higher process maturity/ structure than other centers such as France. Is this true? Please elaborate.

13. Why do you think Spain wanted to stay with SAP? Did their processes need more improvements than the processes of other operational centers?

14. What are the major risks and benefits of Unifield?

15. Do you believe that the strongest arguments for Unifield are: Autonomous and distinct divisions allow for variance; High individual autonomy concerning process design; Discretion of resource allocation. If so why? If not, what is missing?