b. Construir relaciones con el cliente b.(1) Gestión de la relación

CPR and the selected MDM applications are compared from three perspectives: (1) three- dimensional model, (2) MDM activities and (3) cost and time for built and implementation of the solutions. These three perspectives are selected to find out: (1) if the custom built CPR follows MDM standards in its structure, (2) if it supports the five activities that were discussed earlier and (3) if CPR development and implementation is worth the invested time and money.

(1)

Table 12: Comparison of MDM architectures and CPR’s three dimensional model Microsoft MDS, SAP Netweaver,

IBM InfoSphere and Oracle MDM Suite

Central Product Register

Dimension

Domain Domain neutral which means that can support every master domain object that business requires

Product Method of use Operational, analytical and

collaborative. Most of the solutions offer operational and analytical but the collaborative style can be achieved when BPM application is integrated in the MDM environment

Operational, analytical and to some point collaborative. Due to the complex product status logic, various workflows are supported. Implementation

Style

Physical master repository, Transactional Hub or Registry

Physical master repository

(2)

62

Microsoft MDS, SAP Netweaver, IBM InfoSphere and Oracle MDM

Suite

Central Product Register

MDM Phases Profile

Profiling is done on data import

There are predefined business rule that determine what data should be imported for product items. Consolidate

ETL processes are mainly used for data import. Bulk loads or imports from excel or CSV files. Key mapping is also included to map master unique key IDs to appropriate data in the external applications.

There is no actual consolidation of data from various client systems. New data import is regulated by user roles. Only persons with full permission can make changes in the master repository.

Govern

Various tools for data quality improvement are used, such as: column analysis, matching, merging. Data is validated through the rules engines that these solutions support.

Most of the data validations are handled though triggers that are activated on incompatible values, types or NULLs. Also, CPR implements complex coding logic to keep the business rules that depend on product statuses. Share All of these solutions implement SOA

architecture to support data retrieval on request. Pull and push mode are supported. Data can be retrieved on client request (pull mode) or distributed by the master repository (push mode)

CPR support only pull mode which means that for every update, client systems need to make a request. Automatic updates from CPR to client systems are performed as scheduled night time jobs.

Leverage Both of the compared subjects provide unified source of data for analytical systems.

(3)

Table 14: Comparison of MDM architectures and CPR’s time and cost

Microsoft MDS, SAP Netweaver, IBM InfoSphere and Oracle MDM

Suite

Central Product Register

Time for development, implementation and testing

Less than 6 months

10 months for development and 3 years for implementation in all countries

63

These last estimations in Table 14 are based on the following facts.

Development for Central Product Register began in May 2011 and it went into production in March 2012, so it took SM 10 months to build and launch the first complete release. Even though this solution is being used for months now, there are still upcoming versions and releases that are improving CPR. Implementation, on the other hand, is a long term process and is planned to happen in the next three years. The reason for this is because Studio Moderna implements changes related to CPR one country at a time. Data transfers, changes in client applications in each country and testing are time consuming processes that need to be done in 21 SM places.

The purchased packaged software is introduced much faster. It usually takes less than six months to finish with implementation of the solution. I spoke with Mr. Boštjan Kos, Information Management Client Technical Professional in IBM, about IBM InfoSphere MDM Solution and his estimations for implementation and testing were following: “Difficulty to say as it depends on InfoSphere product you have in mind and which products are in the scope for specific project. Installation and configuration would take 3-5 days (simple installation on a single server, without high-availability, without disaster recovery, etc.), connecting to data sources and data targets would take another couple of days, data migration depends if it is from source A to target B without any complex transformations is very easy and done on few clicks per table, but if there are complex transformations needed it might take much longer. Training would take 3-5 days per module. Looking the whole migration project I believe it should be finished within 1-6 months, depends from complexity. “

Regarding the cost for these solutions, it is a bit hard to make precise comparison because the numbers given for both “types” of solutions are rough estimations and really depend on the scenario. For CPR I wasn’t able to retrieve the final amount that was invested in designing this solution. There were on average six to seven people working on CPR each month. Four of them were external contractors including consultants (in the beginning of the project). According data from SURS (Statistični Urad Republike Slovenije) the average net salary for programmer is 1200 euros for March, 2011 which is couple of months before the project started. So the least amount that was spent on labor force was 84K euros = (7 programmers * 1200 euros * 10 months). But this is just the minimum amount. The salaries may be higher, there are other people involved in the process like testers and business analysts, also additional software licenses were purchased and so on.

On the other hand, the packaged software looks much more expensive. Three to five years ago (2003-2007) the typical MDM solution cost in excess of $1 million just for the software and an additional $3-4 million for the implementation services during the first year. During 2008, price points and product packaging (we should say “repackaging”) provided more modest MDM functionality and accordingly less complexity which supported market pricing

64

in the sub $500K range. Overall, MDM matured from “early adopter IT project” status to become a mainstay “Global 5000 business strategy” during 2007-08 These new price points are reflective of various types of projects and the related product capabilities, i.e., enterprise MDM initiative vs. very-specific business solution. Moreover market dynamics further drove price differentiation as the market became more sophisticated and understood the price: value ratio of hybrid vs. registry vs. tool kit vs. fully fledged MDM application. (Zornes, 2009, p. 6)