EMC Documentum Compliance Manager Migration Revisited � What a Difference Two Years Makes

Allergan: EMC Documentum Compliance Manager Migration Revisited — What a Difference Two Years Makes David Mc Donagh Project Manager, EDMS Allergan, Inc. Jes Wills Migrations Practice Manager Blue Fish Development Group

Agenda
Overview of Allergan
Allergan & Documentum (a long history)
The DCM 5 Project (Project Snow Goose/CORAL)
Blue Fish Overview
Project Snow Goose Migration

Allergan, Inc. – Overview
Global specialty pharmaceutical & medical device company, headquartered in Irvine, CA
Neuro Science (BOTOX ® & BOTOX ® Cosmetic)
Eye Care ( Treatments for glaucoma, ocular allergy and infections, retinal disease and dry eyes )
Dermatology ( Treatments for various skin diseases including Acne and Psoriasis )
Allergan - Inamed (Facial Asthetics, Breast Augmentation & Reconstruction, Obesity Products)

Allergan, Inc. – Overview
$2.3B annual sales (2005)
5,000+ employees globally
Manufacturing: USA (Texas), Ireland, Brazil
R&D: USA (California) & UK

Allergan, Inc. – Centralized I.S.
Global operations supported from I.S. based in Irvine, CA
Centralized I.S., little infrastructure outside of Irvine
Single Documentum server for manufacturing applications
Advantages / Disadvantages

Allergan’s History with Documentum
Documentum purchased initially in 1996.
Start: WorkSpace-based (pre-EDMS98) apps
R&D applications:
DCM 4.3 (March 2003)
Publishing (Core Dossier)
Web applications
Web Publisher (Inter & Intranet)
Manufacturing applications
3 Different Workspace applications

DCM 5 – Beta Program
December 2003 – March 2004
Tier 1 participant
What We Said at Momentum 2004 :
Great to get experience with the software early
Software was not as ‘buggy’ as we expected
Beta program was short (2 months – not enough time to really work with the software)
Significant time commitment was required
DCM software was refreshed in the middle
PDFAqua not available until 2 nd month
Learning curve was steep & Little documentation available

Project Snow Goose
Project Snow Goose: “A North American bird that undergoes a long, difficult migration”
Aim:
Convert 4 separate apps, organizations and processes into a single DCM application.
End Users: Global Manufacturing & Global I.S.
Progress:
Prior to 2005:
Wait for R&D to complete DCM 4.3 project
Merge document types in EDMS 98 apps (Merge over 50 different types  7 document types)
Define Requirements based on streamlined business processes & DCM 4.3 knowledge

CORAL
CO ntrolled R epository for AL lergan Documents
Project Snow Goose Core Team
6 full-time Allergan staff members on project
Focused consulting assistance
Extremely committed user organization
Use consultants only to complement existing staff
Defined ownership/ maintains internal control
Knowledge transfer at end of project CRITICAL
Especially technical expertise
Target completion July & August 2005 (2 distinct go-lives)
Migration critical to success

CORAL – Design/Development
Timeline restrictions => Rollout DCM 5.2.5. sp1 (build 132c) July 2005
Issues:
Java Method Server lockup (if more than a few (4-5) people were promoting). Installed Media Server as part of the SP1 "C" build to process the promotion and notification events. HP/UX required additional time to get fix.
Serial workflow functionality was only 25% developed. Modified Quickflow to get required functionality.
17 reviewer/approver limit - Never fixed in 5.2.5 sp1
dcmCheckin method used for custom check ins did not work
dcm_change_cd_properties audit event was not logged. Fixed in SP1 "FCS" build.
Could not demote a document. Fixed in SP1 "FCS" build.
Could only assign the document owner as the periodic review owner and all class coordinators would receive the notification. We customized periodic review.
Search did not work as expected. Customized simple and advanced search.
Future Implementations:
Implement a STABLE “.x” product.

Migration - Requirements
1) Migrate ALL REQUIRED data
2) Migration from a Network Filestore (Global I.S. documentation)
3) Migrate from 3 different docbases (Manufacturing documentation)
4) New standardised cabinet/folder structure in CORAL
5) Property mappings
6) Docbase migration: Complete migration within a “frozen” window of 5 days – NO docbase activity guaranteed
7) Validatable
8) Reusable

Migration – The REALITY (1)
How “clean” is the data you own?
Clean/consistent data required for migration tools
Do you really understand the scope of the data cleanup
Mapping of data from varying locations to consistent CORAL location
Focussed team reviewing and managing data
Inconsistent data = Initial docbase migration Failure!
I.S. Network filestore migration – Target July 2005 – Achieved
Manufacturing Docbase Migration – Target August 2005 – Not Achieved

Migration – The REALITY (2)
New docbase Migration plan:
Timelines agreed with business
Focus on data cleanup
Maintenance of data in clean state
Validate
Dress Rehearsals
Manufacturing Docbase Migration – New Target January 2006 – Achieved

Project Snow Goose Blue Fish Pedigree
What Blue Fish brought to the engagement …

Project Snow Goose What we said at Momentum 2005 …
Organization Challenges Addressed by:
Forming a global migration delivery team
Assigning team leads on local level
Give each decision authority
All team leads had a good command of English
Executing each migration at least three times
Business users auditing the results of each migration
Adopting an approach based on the Blue Fish Migration Methodology and product suite

Project Snow Goose The Blue Fish Framework
Identify the data to be migrated
Extract the data from its current repository/file store
Transport the data from its current location to the new location
Transform the data into the new structure
Load the data into the new repository
Validate that the data was transformed and loaded correctly

Project Snow Goose The Blue Fish Approach
Work with business users to define migration rules for each kind of document
Automate the conversion of business rules into XML
Leverage Blue Fish DIXI (Documentum Import/eXport Interface)
Allow non-technical business users to validate documents at each step of migration
Introduce an enrichment step to allow users and/or administrators to perform meta-data enrichment
Automate the process to allow repeatable test migrations

Project Snow Goose Theory and Practice
How we used the framework and methodology to deliver the Project Snow Goose Migration …

Project Snow Goose Migration Specification Matrix
“ Work with business users to define migration rules for each kind of document”
The entire migration was broken apart into separate lots of documents, where each lot was a collection of documents that were all handled in the same way.
The behavior of each lot was specified as a single line in a spreadsheet. Other tabs in the spreadsheet defined attribute mappings, lifecycle information and the like.

Project Snow Goose Migration Specification Matrix Document Group Source Docbase Content Location

Project Snow Goose Migration Specification Matrix
“ Automate the conversion of the business rules”
The completed Specification Matrix is automatically transformed into XML and fed directly into the system

Project Snow Goose Re-architecture
Project Snow Goose involved not only a migration, but also an information re-architecture.
This re-architecture involved systematically determining the target object-type, attributes, lifecycle, content and location of a migrated object, based on the object’s previous incarnation. While the source repositories held a significant amount of information, this needed to be validated for consistency and then made accessible to the migration system.
Many facets of this re-architecture were complex.

Project Snow Goose Examples of complexity – Assembly Rules SOP#1, 2.0, Obsolete SOPs Released SOPs SOP#1, 2.0, Current SOP#1, 3.0, Current SOP#1, 4.0, Current Master SOPs SOP#1, 4.0, Current SOP#1, 3.0, Retired SOP#1, 4.0, Current + SOP#1, 3.0, Retired + SOP#1, 2.0, Obsolete +

Project Snow Goose Examples of complexity – Naming Conventions A naming convention describes how to break apart names into their meaningful elements. An example of a naming convention specification is: type – pla_state – unit_size – batch_size – destination – formula The elements of the name are used in other components of the migration, for example to determine the name of the destination folder in the target repository. An example target folder specification would be specified as: formula – 0525 – batch_size An example of a name that conforms to the convention, and its target folder: ointment – production – 30mg – 600 – waco – F245 F245 – 0525 - 600

Project Snow Goose Reduce Complexity
To manage complexity, and to allow the system to develop as it needed to, we adopted a model where we could develop individual components to handle a single aspect of the migration processing.
Each component addressed a single element of the process.
We then arranged these components as a ‘pipeline’, where the processing steps required for each migration lot could be executed or skipped as necessary.

Project Snow Goose Pipeline Operations
Folder Naming Convention
Detect Duplicates
Select Lifecycle
Attribute Mapping
Cascade Attributes
Set Owner Name
Check Effective Date
Strip Unwanted Content
Post-export Selection
Detect Split Trees
Process Annotations
Document Name Convention
Set Lifecycle State
Perform Document Assembly
Remove ‘do not migrate’ objects
Set Paper Size
Set PLA State
Set Retired Date
Set Target Path
Separate Multi Lots
Set Site

Project Snow Goose Pipeline Schematic Start Component #n OK? Component #n+1 YES NO Fail

Project Snow Goose Inspection
“ Allow non-technical business users to validate documents at each step of migration”
“ Introduce an enrichment step to allow users and/or administrators to perform meta-data enrichment“
We re-cast the enrichment step into an inspection step – this allowed users and/or administrators to inspect the migration information before importing it into the target repository.

Project Snow Goose Inspection Application Source Object Information Migrated Object Information Reviewer Notes

Project Snow Goose Pre-import Validation
Before attempting to import the objects, check for errors such as:
Invalid users
Unexpected file formats
Missing target folders
Missing ‘effective’ dates
Unwanted native content

Project Snow Goose Validation
“ Allow non-technical business users to validate documents at each step of migration”
Source Object Information Migrated Object Information List of Migrated Objects

Project Snow Goose Overall Process Flow
“ Leverage Blue Fish DIXI (Documentum Import/eXport Interface)”
Start DIXI Export Inspection Pipeline DIXI Import DIXI Validation Validation End

Project Snow Goose Scheduler
“ Automate the process to allow repeatable test migrations”
Allows the Migration Engineers to control the what/when/where
Allows the use of multiple machines to reduce overall processing time
Simple to use, provides visual status feedback

Project Snow Goose Scheduler Completed Tasks Active Tasks Pending Tasks

Project Snow Goose Deployment Staged Local Content CORAL Repository

Project Snow Goose Data Cleanup Management and Other Tools
In addition to the migration system, we also developed other tools and utilities to help with the migration effort.
Source Data Cleanup tools
Batch Management Spreadsheet
Daily monitoring of data hygiene

Project Snow Goose Results
Migration Dress Rehearsals paid off
Focused Team - Teamwork Triumphs
Automation reduces error
Validation reduces anxiety
Data Cleanup a key to success!

EMC Documentum Compliance Manager Migration Revisited � What a Difference Two Years Makes

by BlueFish

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 21

Statistics