Vous êtes sur la page 1sur 4

Merck & Co.

Case Analysis

July 10, 2003


Cindy Branon

Zach Evans

Melissa Holder

Kendall Joseph

Brandon McLain

Shane Morgan

Group 3
Merck Case Analysis Group 3

Situation Analysis

Merck is one of the largest, most successful pharmaceutical companies in the world, a

$5 billion company at the time of the case. Merck pursues a multinational strategy in its global

operations, achieving 47 to 52 percent of revenues overseas, depending on exchange rates.

This multinational approach is the result of the vast array of national regulations for selling legal

drugs, thereby requiring different approaches for each market. The organization of the business

operations and foreign regulations are the drivers for Merck’s Information Technology unit.

Merck operates separate information systems departments in each country, a polycentric

structure, thus mirroring the overall corporate structure.

Merck’s foreign subsidiaries operate autonomously but are required to submit financial

reports monthly to headquarters in New Jersey. The data produced from the reports were used

by top management to plan financial strategy. The three week long manual process of closing

the prior month’s books negatively impact timely decision making by management.

Problems and Opportunities

Merck IS had been tasked with creating a financial reconciliation and reporting system

for corporate headquarters. The project faced numerous obstacles ranging from technology,

culture, language, geography and internal politics. Building consensus to design and implement

a system is difficult when working with diverse and distant staff. The satellite IS departments

were fiefdoms of the local managers and the hardware and software systems across the

company were different and often incompatible. The architecture was highly decentralized and

linking all units posed network and communications problems because of the nature of foreign,

and often government controlled, telecommunications firms. Costs involved with implementing

and maintaining the system also were forecasted to be high.


Management decided to build a system to connect foreign offices with headquarters that

would provide an electronic method for uploading reports. Merck IS decided to build a

July 10, 2003 2 of 4

Merck Case Analysis Group 3

“supersystem” to which satellite offices would connect. The project relied on existing IBM S/34,

S/36 and S/38 minicomputers and would require 700 new programs to be created. The 700

programs needed were just the initial implementation; revisions and new reports would require

constant recoding.

A new management team was assembled to assess the problems of the project and

recognized the work required to make the system function was unreasonable. They decided to

start from scratch with a new team, but for political reasons, let the original project continue.

The new project team decided to write programs for the lowest common denominator, the S/36

systems. The Lotus 1-2-3 type system required only 40 new RPG programs to be created and

won over IS management because it was simpler to implement.

We believe that two other alternatives existed for Merck in the areas of hardware and

software. The first alternative would be the upgrade of all systems corporate wide to S/38, or

even AS/400. This would allow for much easier project implementation by reducing the amount

of interfacing programs required. Although similar to adopting the S/36 programming strategy,

this alternative provides an installed base of modern systems, permitting future growth. A

second alternative would be to evaluate existing external software packages to solve the

financial reporting problem. Software developed in house must be carefully designed, created

and maintained, a potentially time-consuming and high-cost practice.


Our recommendation would be to use Merck’s second system that utilized 40 programs

globally written to the S/36 standard: the system was simplistic in its design, the implementation

was uncomplicated and the productivity increases justified the cost of development. It appears

that Merck’s accounting department killed the system because it worked to well; apparently IS

built a good system. This solution should entail a plan for finding new positions at Merck for any

displaced accounting staff.

July 10, 2003 3 of 4

Merck Case Analysis Group 3

However, we do not believe this to be a final solution. Data, management, staff and

business requirements always change, therefore IS and its systems must be capable of change.

The IS staff should create a systems review team to examine new technologies in light of

present system functions. IS consolidation of the global hardware on one system, perhaps

IBM’s AS/400, in the future may be reasonable, although not cost effective or easily deployable

for the present time. Likewise, software packages that provide centralized corporate data

management may become available. Continually evaluating IS needs may prevent future

situations requiring hurried, inelegant but workable systems.

Actual Implementation

Although the technical challenges were difficult, the project was achievable. However,

the political implications of implementing the system were not understood by IS. The project

was terminated because some accounting staff positions were no longer necessary because of

the efficiency of the system in performing the administrative tasks.

The failure of the project has not deterred global IS efforts at Merck. In 1995 Merck

developed a sales management system named Compass to share sales data amongst sales

staff regardless of location. The system was launched to assist the marketing efforts of

Astra/Merck, a joint marketing venture of Merck and Astra AB of Sweden. 1 Merck built a

Internet based VPN in 1997 to enable company scientist access to research databases from

anywhere in the world.2 A procurement system created by Ariba was purchased in 1998 by

Merck to manage its $2 billion annual purchasing of nonproduction and indirect supplies.3


July 10, 2003 4 of 4