Spring 2007: Genesis of the Project: To SAP or not to SAP….that was the question

The Options
 The last post described the situation at the time Colmobil was creating their IT roadmap for the next decade. They had mostly obsolete hardware and software, and their primary application had morphed into essentially in-house development.

Home-grown, tailor-made applications were, and still are, very common in the vehicle import and wholesale business. This is driven by the complexity of the vehicle trade business. Each vehicle has a unique identity and configuration. The manufacturer must maintain records of every vehicle and all its related data throughout the import, sale, and maintenance of the vehicle over its entire lifetime. The records are required so that necessary services to the vehicle can be provided and to meet regulatory requirements. This complexity, together with different manufacturer specific requirements and domestic regulatory requirements, left no room for a standardized, global software solution that met the demands of the automotive industry. (Until SAP introduced it's Vehicle Management System (VMS) in the second half of 2002 - more about SAP automotive solutions in later post).

By 2006, as Colmobil started exploring future possibilities for IT strategy, there were really only three options:

1. Continue developing the existing system in-house and invest in some "face lifting" and a little reengineering, while rewriting around some weak spots

2. Co-operate with Matrix (who had acquired Nikuv) in upgrading, adapting, and enhancing their version of the system while trying to influence it to include Colmobil-specific requirements. Implement the upgraded version at Colmobil when it was ready

3. Study the SAP solution and implement it if proven to satisfy the company needs

Option 1 raised a difficult question - should Colmobil abandon it's capability to develop home-made solutions and choose an "off the shelf" solution? Will that cause loss of competitive edge, as all the competition can adopt a similar solution?

We had to understand whether or not our software is a business asset and does it give Colmobil added value, or is it a burden we carry that slows us down? The discussion about this was quite emotional, but the conclusion was rational. In today’s world, a company such as ours cannot afford to develop what is essentially a whole ERP solution for itself, it just doesn't make sense. The intensity and rate at which new technologies, opportunities, and requirements are emerging has accelerated exponentially. No company whose primary business is not software development can maintain an application that meets changing market requirements for a reasonable cost, over a substantial amount of time. Thus option 1 was off the table! Needless to say, eliminating this option actually made us understand that replacing the existing system is inevitable and the decision remains only how to do it.


Option 2 raised its own set of issues. It is very difficult – sometimes impossible – to embed functionality for one company’s individual business requirements in an application designed to meet the needs of many different companies. If we went with option 2 it would create a situation where Colmobil was likely to have many requirements not fulfilled by the more generic application. This would lead right back to either trying to manage with an application not sufficient for Colmobil’s needs, and / or the need to develop enhancements to the application with in-house resources. It would also mean that Colmobil couldn’t leverage its IT capabilities to gain competitive advantage because they wouldn’t be any different from all other companies using the same software….. unless they used in-house resources to develop enhancements…

You get the picture. Both options 1 and 2 created a potential loop necessitating continued in-house development, so Colmobil decided to spend the time doing a thorough gap analysis with the SAP system, which was still a “black box” to them.

Gil wanted a third party experienced in the SAP automotive solution to help evaluate the system. He found that the IBM Israel SAP team had some hands-on experience from an SAP automotive implementation project at S.M.L.T (Fiat and Kia importers to Israel), so IBM was hired to do the gap analysis.  During ten intensive weeks, IBM specialists met with Colmobil’s key users and studied the way Colmobil operates in its various functions and lines of business.

Around this time Itai Rotem – the future project manager – became a part of the decision-making process. Itai brought an essential element, extensive SAP knowledge and experience, to the table.

The gap analysis yielded a detailed document specifying the relevant capabilities of the SAP solution and the gaps discovered between SAP best practices and tools and Colmobil's requirements. The gap analysis document was presented and studied by Colmobil's executive management thoroughly. The in-depth review of the gap document was the first measure of commitment and involvement of the management team in the upcoming project, and they all took the review very seriously and became invested in the project.

Strangely enough, had we not decide against option 1, it would have been very difficult to kick-start the decision process. Remember, although the systems were positively obsolete, they were functioning pretty well and, “if it isn’t broken……”

Once the management team understood that replacing the legacy system was really necessary, it became easy to support the decision with all the "IT lingo" facts: the legacy technology does not interface well to modern systems such as CRM which was the next business focus; the software does not support modern architectures such as SOA easily; information security is weak, and all the other arguments that are clear to IT professionals, but may be complete gibberish to decision making business executives.

Despite this, there were still several good arguments against such a replacement:

• It isn’t broken (yet…),
• What is broken can be fixed for a relatively small price.
• ERP projects consume a lot of resources that are currently needed for :
         o Business expansion
         o New products launching
         o Crisis management as required

As the executive management team tried to weigh the two options it became apparent that this was a business decision, not just what was easiest and / or least expensive. Colmobil’s business is automobile import, sales, and service – not IT systems and applications. Colmobil executives had to be brought to a common understanding that there were important business and organizational drivers behind the decision as well as the IT reasons. The next few posts will explore those drivers and discuss the decision and the reasoning behind it.

Go to home page