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.