How They Did It: Pfizer's Transition from 50 Document Management Systems to One

Like many other pharmaceutical companies, Pfizer has been through numerous mergers, acquisitions and divestitures. Two notable ones were the acquisition of Warner Lambert in 2001 and Pharmacia in 2003. The mergers, acquisitions and silo work practices fractured Pfizer's highly regulated and controlled documentation over many sites and systems. This included our GxP Standard Operating Procedures, product labeling, submissions management and trial master file systems.

Shortly after the Pharmacia acquisition, Pfizer's Research and Development divisions commenced independent document management consolidation initiatives. These were focused at identifying and resolving "in-line" document management issues. It soon became apparent that there would be a significant "cross line" benefit and the multitude of disparate efforts were brought together under one restructuring project in September of 2005 called "GDMS," or the Global Document Management System.

The vision for GDMS was to create a single, globally accessible document management system that facilitates information sharing across Pfizer and enables timely and accurate access to highly regulated and controlled documentation.

In doing so, GDMS was designed to help us build trust with regulators and legislators by enabling us to respond quickly and accurately to their requests for information. GDMS also reduces document duplication, improves content re-use, and eliminates much of the ongoing costs of maintaining and supporting multiple legacy systems.

Over the past three years we have moved from 50+ systems and departmental file shares to three. GDMS houses our highly regulated and controlled product documentation. Microsoft Sharepoint contains Pfizer's highly collaborative business essential project team content and Document Long Term Storage, or DLTS, provides for archival of inactive documents that have yet to reach the end of their lifecycle.

The GDMS program has been delivered over three time horizons. During the first horizon, we concentrated on developing the business requirements for the repository and building an initial system that would support the core document management functionality to enable us to move the majority of the legacy systems and file shares.

The second horizon involved building additional functionality to support key application extensions, such as global product label management and submissions assembly and publishing. The third horizon, which is ongoing, involves the retirement of the legacy systems that have been deployed into GDMS. Retirement is dependent upon us moving the remnants of "inactive" content into Long Term Storage.

In terms of organizational scope, this was truly a pan-Pfizer initiative with representation from the business lines in research and development as well as the regulatory, safety and clinical operations components of over 100 Pfizer country offices.

Our goal was to generate a single content model and requirements document that would address the needs of all Pfizer regions, business lines, sites and countries. In order to ensure this objective, we put the needs of Pfizer above any one region, business line, site or country and developed these guiding principles for the system design:

First, simplicity is key. The more requirements we have, the more complexity we would end up building. We wanted to focus on what was necessary, not what was possible.

Second, we wanted the system to be organizationally agnostic. We wanted to build a system and process that didn't have to change when we reorganized. This is almost continual these days. Drug development has not changed that much for many years and as such the document management system that supports it should be equally stable.

Third, we wanted one repository. GDMS would become Pfizer's only official repository of highly regulated and controlled documentation. "If it isn't in GDMS, it doesn't exist." (With the exception that paper documents may exist that do not have an electronic equivalent).

Finally, we wanted the solution to be fit for purpose - meaning it doesn't have to be perfect. The goal was to develop a good basic system without a lot of bells and whistles. We wanted to leverage as much out-of-the-box technology as possible and keep the customizations to a minimum. Wherever possible we wanted people and process to help manage exceptions, not software.

GDMS is based on a Documentum 5.3 repository and utilizes a modified Web top client. We purchased a product from Glemser Technologies called xmLabeling which supplied much of the customizations required to support product label content management in our system.

IBM Global Business Services and Glemser Technologies partnered to integrate xmLabeling as well as to develop the remainder of the GDMS customizations and application extensions.

We've also just completed the integration of ISI publisher for paper and report level publishing in GDMS as well as eCTDXpress for eCTD publishing. We are using Microsoft's FAST search engine and Adlib for rendering.

We employed two basic techniques to help ensure that the content in the system was authoritative and remained that way. The first was to mandate user compliance. We used SOPs and senior management communication to help reinforce the fact that content that was in-scope for GDMS must be stored and managed in GDMS and nowhere else.

To help facilitate this we adopted a "burn the boats" strategy whereby, once a legacy system or file share had its active content migrated to GDMS, we removed all user access to it, and where possible, immediately retired it.

The second technique employed to preserve the authoritative integrity was auto filing. A big part of our legacy problem was a result of the fact that users could create their own folders using any naming convention that they desired. There was no consistency in structure across therapeutic areas or project teams. Auto Filing helps us to standardize and harmonize all these disparate structures into one.

In GDMS, every business artifact (document type) has an auto filing rule associated with it. Users are not allowed to create their own folders. Folders are automatically generated by the system based on a pre-configured set of rules that are executed during document creation.

The placement of the documents in the system is completely driven by metadata (attributes), some of which is automatically populated by the system. Other metadata is supplied via enterprise reference entities or controlled data lists.

This "correct by construction" approach to document filing helps to preserve the significant investment Pfizer made in business alignment achieved during requirements gathering by making certain the repository won't degrade over time.

The Pfizer team implemented a business change management methodology called AIM (Accelerating Implementation Management) to prepare the organization for the substantial change that GDMS would bring. This began by developing a program-level business case for change which we customized for each particular business line and region. Throughout the implementation we communicated constantly and kept our key sponsors apprised of all schedule changes and any events that might impact their business line or site.

As of this writing, GDMS is being used by 17,000 users in over 100 countries worldwide. There are approximately 4.7 million active, authoritative documents under management in the repository. We have well over 100 vendors and partners working securely in the system.

GDMS has been an enabler for global simultaneous regulatory submissions as well as helping us to implement new sourcing strategies for submissions and report level publishing. We are working to harmonize our key business processes around the new single repository. It's important to note that all of our innovation is now occurring around a single repository supported with standard processes as opposed to the 50+ systems and processes that GDMS replaced.