Introduction

This white paper demonstrates and discusses solution for fragmented IT, which known as one of the classic IT problems. For demonstrating the problem and solution I chose to use a real life scenario of pharmaceutical IT department. After several acquisitions, following by IT merging, this department found itself operating and maintains three CRM solutions. The target of the described work was to decrease CRM Solutions to one solution. Minimize CRM solution expected to help IT department to decrease IT budget and complexity.

Problem Statement

After several M&A, the customer found himself using People Soft, SAP CRM and SalesForce.com. The Customer basic business units were using People Soft, while different acquired business units were using SAP CRM or SalesForce.com. The described situation caused significant complexity due to the need to integration between different IT solutions, and it also indicates an opportunity for cost reduction (at least for SAP and Oracle solutions). The client looked for a solution that will provide help with the process of deciding which solution should be remained and how to create a roadmap (with resources estimation) for such a project (Migrating from three CRM applications to one).

Previous Options

The client had several unsuccessful initiative with fragmented IT. All the previous initiative included bottom-up exercises, where data was collected from application owners and based on that data a decision has been taken. All of those initiative encouraged issues in implementation phase both from business side and IT side.

Proposed Solution

The Proposed solution was a combination of top-down, bottom-up approach. The solution took in account Business Capabilities, BPM, Business Process reengineering, IT integration needs, needed resources and costs. The described solution is based on Enterprise Architecture as a known and proven methodology to deal with different enterprise needs (Including the need to reduce costs).

Solution benefit: Top-down, Bottom-up approach

Top-down, bottom-up approach covered more areas of potential problems in implementation phase, thus minimize significantly implementation issues.

Solution benefit: taking in account business domain

Starting from the Business and touching business process management helped the client to get better understating of the business needs. Understanding the business helps to identify if IT solutions are duplicated, provided by one solution or not provided by any application. Dealing with business process management helped to adjust easily an IT solution to business capability and even to optimize the business process. 

Solution benefit: Reuse

Using a tool helped the client to use the collected data of this work in other related enterprise architecture work that they have done after the described work.

Solution benefit: Based on proven methodology

Enterprise architecture is a proven methodology that was used successfully by different enterprises in different part of the world. This methodology is based on accumulative experience that was collected by many people and was used by me in different clients. Therefore using EA reduced pitfalls that one might encourage if he is trying to do such a work alone.

Implementation

The proposed implementation is based on three main steps:

1)      Understanding what we have (As-Is).

2)      Analyze data and decision making (To-Be).

3)      Creating a road map and governance.

Understanding what we have:

In this step we followed the four enterprise architecture domains to understand the current CRM situation. We collected just needed architecture building blocks from Business, Information, Application and technology domains as well as the relevant relations between architecture building blocks.

This step is started from collection of relevant CRM business capabilities (Capabilities describe what the business is doing and not how the business is working) and current applications that involved in CRM work (Direct and supported or consumed application). Having business capabilities, we started an effort of mapping information flow between capabilities. We used the identified information entities to validate that all the relevant application collected, and all needed relations captured (this was done by relating each application to entity or entities)

We used the collected applications and Information as input to an exercise that looked for all the relevant technology assets (technologies, databases, servers, storage devices, etc’) that support both information and applications.

Based on business capabilities, Information and application we started to do mapping between application and business capabilities. This task assigned applications to business capabilities based on business user’s data. Note that we have just one business capability model, therefore several applications were mapped to one capability.

The reason behind using business capabilities (What and not How) for mapping as-is was to decrease the time needed for mapping current architecture.

We decided to use EA tool for this work. The tool helped us to finish mapping on time and served as time saver in next steps as well. The tool repository contained all collected data and relations, as well as at least one diagram per architecture domain. Main usage of the diagram was to communicate with different roles in IT and business.

Analyze data and decision making

This task was performed in three work steams in parallel:

1)      Identifying relations between capabilities and applications:

a.       Capabilities with more than one application to support them.

b.      Capabilities with just one application to support then.

c.       Capabilities without any current application to support them.

Using a matrix with applications and capabilities (on X and Y axis) we managed to see current applications support and understood which application provides more coverage to the client business needs. To get better picture if non supported capability could be supported by one of the CRM applications, we add this data to the matrix.

We used BPMN diagrams to model each business capability that had more than one supported application. A business process (how) helped to understand which application has better solution to the business need. If a business process helped to reach more accurate decision, we updated the described matrix.

A BPMN modeling was also used for each unsupported capability. This modeling was necessary to find out which one of the existing application support the capability and to what level.

While performing business process modeling, we also performed business process reengineering. Business reengineering helped us to adopt capability to an existing application or it contributed directly to capability improvement (without any relation to supported applications)

This task might perform complete business process modeling, but due to time constraint it was preformed just to describe capabilities (around 50%).

2)      Identifying relations between supported capabilities applications and other applications

In this step each CRM application, which support capability, was assessed to understand integration to other applications and IT assets. This assessment counted interfaces of each application to other applications. The assessment took in account the direction, type of interface and data that flows. This data was taken in consideration when a decision was taken and for when we created the roadmap.

3)      Based on collected technologies that support the discussed applications, we identified each application current IT costs. We’ve done the work by going through the list of related technologies for each application and collecting all the costs (Maintaining, supporting, licensing) for each technology. This exercise gave us relative estimation regarding the cost of each application.

When all of describes three work streams were finish, and based on collected and analyzed data, a decision regarding the chosen solution has been taken. The decision took in account costs, relations to other applications (amount of work needed to replace the solution) and coverage of CRM business capabilities.

Creating a road map and governance

Based on the analyzed data and the decision we started to create a roadmap, which took in account applications, needed to be replaced interfaces, change in data volume of applications, new supporting technologies, available resources and dependencies between different tasks.

Several alternative roadmaps were introduced to the client, and once the client chooses one alternative we helped him with governance. In other words, we helped the client to make sure that what was decided will be happened in reality

Summary

The described solution has been implemented together with the client within three months. It took us roughly two months to do the first step and one moth to do step two and three. We manage to reach clear cut decision regarding the CRM solution that will be implemented.