The idea of the Merkava ERP as an integrating mechanism was part of the thinking from its beginning. The first planners and decision makers understood that much of the value and the power of an ERP as infrastructure derives from how it integrates both information and business processes. Obtaining that value depends on increasing information and business process integration across government agencies, which requires major interventions and can have powerful impacts on agency personnel and operations. It is potentially costly and disruptive.

A project of such potential cost and complexity would require a compelling vision. So part of the early planning included picking a name and logo for the project, shown here, to represent integration and power in a culturally meaningful way. The word Merkava, which can be translated as chariot, has deep religious significance in Jewish scripture as well as secular meaning and uses. The scriptural reference is to the vision of Ezekiel that includes creatures with four faces—a man, a lion, an eagle, and a bull—along with a chariot with complex wheels within wheels, all of which move in an integrated way.⁵ The initial development team was aware of the possible resistance to such major changes. So, they employed the logo and its larger meaning to reinforce the idea of a new shared identity for the project and those participating in it. According to Ronny Jacobowitz, “We were trying to push for a very clear message that says, we want to be together in doing this.”

The message appears to have been effective. This logo, developed at the beginning of the work, is used extensively in documents and presentations, reinforcing the distinctive identity of the project. Enthusiasm for the project was high among the early adopters interviewed for the case study. As Jacobowitz put it, “Some people may be against the team or things that are done wrong, but not against the idea itself.”

The metaphorical vision represented by the Merkava logo fits well with what emerged as the practical vision for the Merkava ERP and its place in the overall e-government initiative. Both involve the themes of reform, multiple components working in an integrated way, and multiple layers of complexity.⁶ The place of Merkava in that overall picture is as a layer of cross-cutting functions for all agencies: initially there was reform in the financial management, procurement, and human resource administration. Financial management goals focused on the conversion from a cash to accrual-based accounting system for all agencies, and one that would provide the integrated information base necessary for enhanced transparency, more efficient resource allocation, physical asset management, procurement controls, and more meaningful information for decision makers. Real estate asset management was added to the financial management component. These reform targets have substantial potential to improve the internal efficiency of government and the strategic position of the Merkava ERP in the overall e-government vision.

That overall e-government vision is represented in the five-layer model shown in Figure 2 below. The layers reflect their cross-government design, linking eventually across all agencies. The layers show a certain level of interdependency among the various system and infrastructure components. The capabilities in each layer form a foundation that the functions of higher layers depend on and interact with. The information sharing and integration capabilities of the Merkava.

ERP, for example, depend on the connectivity provided by the bottom Gov@net layer. However, unlike the Merkava layer, the others are not single integrated systems, but rather combinations of applications, infrastructure, facilities, and devices like smart cards. As an overall vision, this model makes clear that the Merkava initiative and those in the other layers have been conceived of as parts of an interrelated whole. That is, the direct public returns anticipated from the service applications available through the eGov Portal layer and Access Centers depend on the successful investment in and implementation of systems in the layers below.

However, at this point in the development of the Merkava ERP, the higher layer capabilities are not all linked to the Merkava operations and applications. For example, the e-procurement system works through the eGov portal and depends on the Tehila citizen connectivity layer, but is not fully integrated with the procurement modules in Merkava. Since these various systems are developed and come on line somewhat independently, the contribution of lower layers to public returns cannot be directly linked in every case to the service layers. This question of linking versus independently developed components is inherent in a comprehensive set of systems such as this and has not been fully resolved in this eGov initiative. This issue does not, however, diminish the public value case for the Merkava project as much as it illustrates the complexity of public value assessment for highly integrated government initiatives.

The overall e-government strategy places enhanced information access and integration, based on the Merkava concept, at the core. The overall goal, in the words of the e-government vision, is to create:

That is, the “information and knowledge resources” available to the “government as a whole” (integrated in Merkava) enable both internal and public returns. That internal efficiency-public return linkage is clear and consistent across the various strategy and goal statements dating from the initiation of the project in 1999-2000 to the present.

The path to achieve these goals, however, was not as clear from the start. To achieve these integrated and enhanced knowledge and information resources, the new system had to replace the several separate accounting, HR, and procurement systems in place in late 1999, as well as the separate asset management systems, with a common platform and capability to integrate data. Initially the development team thought the agencies with the best capabilities in each area should develop a system for the rest of the government: Police agency for procurement, Ministry of Finance for accounting, Human Resources Authority for HR, the Real Estate Authority for real estate asset management. However the team soon realized that strategy would not produce an integrated system. Instead they imagined a single system with integrated parts, like a wheel with spokes for each component. Since that image fit the Merkava/chariot vision, they began referring to the integrated components as the “ofan,” or wheel in Hebrew. The wheel would be the key component in the larger integrating and reform chariot, Merkava. One system for the government would be the only way to achieve the desired integration and interoperability, and the ERP model appeared to be the best technical option.

There was some resistance to this monolithic approach at first, but the goal of a highly integrated, consistent system remained the priority. So in May and June of 2000, the development team undertook a series of visits to assess the potential of that approach for their vision. The visits included ERP’s and similar systems at the UN, Germany, the Netherlands, and UK governments. The team was able to see the kind of potential benefits of an ERP system as the core component or ofan. That experience helped solve the build-or-buy issue. So they began developing a tender for acquiring the ERP system for the Merkava project. The tender was published in early 2001, seeking both the software components of an ERP and the related implementation support.

The tender produced proposals from SAP and Oracle, with the decision going to SAP plus implementation support from consultants. In addition to the various technical and cost considerations, the choice of the SAP proposal was driven in part by the strategic vision of using the ERP as a lever for major reform of the government. The development team described the SAP system as a conservative design, based on best practice models, that could be used to impose a high level of structure and conformity in use. This would require agencies and users to develop new work practices as well as to support information integration across agency boundaries. According to Ronny Jacobowitz, “We need a very closed system that forces us to work in a way that we’re not used to.” In explaining what he meant by a closed system, he said , “… not that the SAP product is not adaptable to our needs, but rather that it leads us to use unified and best practice based business processes.” Based on these and other considerations the SAP proposal was selected. There was some delay introduced in moving forward with the procurement and implementation when Oracle challenged the decision in court. However the Israeli courts upheld the decision and implementation began in November 2001.

Obtaining the full range of value envisioned for the Merkava ERP depended on combined technical and organizational change strategies. Working alone, the ERP could generate substantial internal efficiencies. But delivering better service and value to the public, as part of the infrastructure of the e-government initiative, required broader changes. The full scope of the project included not only new technical systems and databases, but also shifts in organizational cultures, work processes, and internal power relationships and controls. Stakeholder participation and support were critical. To include the important stakeholders in project development, a ministerial level management committee was formed for policy and governance issues, and a steering committee of operational and technical managers for day-to-day issues. A project management office was created, under the direction of Ruven Cohen, with a staff that grew to 180, including trainers and developers. Several consultant firms were included as part of the development and support teams along with SAP personnel.

The overall implementation plan proceeded in several steps: The initial implementation strategy includes recruiting key users in each agency to receive initial training, involving IT staff from each agency in the planning and roll-out, and involving SAP and other consultants as team members.

Part of the implementation strategy included keeping the amount of customization of agency implementations to a minimum to keep work practices and system interactions consistent and to control costs. Gilad jokingly described this practice, “We said for 70-75 percent, let’s convince God that you need something that’s not already integrated as a best practice in the SAP system. No, it’s God, it’s not me; it’s a sign from God that you probably don’t need it. It’s religious now, not only a systematic way of thinking.” This approach reduced customization. Where it was necessary, the project management staff developed standard interfaces and templates to connect specialized agency-level systems to the core.

The reform of work processes and requirements sparked by the implementation generated some staffing challenges as well. The conversion from cash to accrual accounting was critical for establishing the value of assets and improving financial management and transparency. However, the bookkeeping staff using the old system typically lacked the advanced accounting skills required for accrual systems. Considerable training and recruitment of staff with CPA-level skills was needed to fully implement the accrual system. Similarly, the new procurement system included an added control that automatically checks whether there is adequate funding for the purchases. If the check determines that enough funding is not available, it raises a “red flag” on the process. Controls were weaker in the old system where reviews of prices and procurement details were done manually. Thus the public value produced by increased transparency and legitimacy in financial management required a combination of new technology, new work processes, and new staff skills and relationships.