WIXLIB

Allergan: EMC DocumentumCompliance Manager MigrationRevisited — What a DifferenceTwo Years MakesDavid Mc DonaghProject Manager, EDMSAllergan, Inc.Jes WillsMigrations Practice ManagerBlue Fish Development Group

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

Allergan, Inc. – Overview Global specialty pharmaceutical & medical devicecompany, headquartered in Irvine, CA Neuro Science (BOTOX ) Eye Care (Treatments for glaucoma, ocular allergy andinfections, retinal disease and dry eyes) Dermatology (Treatments for various skin diseasesincluding Acne and Psoriasis) Allergan - Inamed (Facial Asthetics, Breast Aesthetics,Obesity Intervention Products)

Allergan, Inc. – Overview 2.3B annual sales (2005)5,000 employees globallyManufacturing: USA, Ireland, BrazilR&D: USA & UK

Allergan, Inc. – Centralized I.S. Global operations supported from I.S. based in Irvine, CACentralized I.S., little infrastructure outside of IrvineSingle Documentum server for manufacturing applicationsAdvantages / 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 toreally work with the software)– Significant time commitment was required– DCM software was refreshed in the middle– PDFAqua not available until 2nd month– Learning curve was steep & Little documentation available

Project Snow Goose Project Snow Goose: “A North American bird thatundergoes a long, difficult migration” Aim:– Convert 4 separate apps, organizations and processes into asingle 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 50different types è 7 document types) Define Requirements based on streamlined businessprocesses & DCM 4.3 knowledge

CORALCOntrolled Repository for ALlergan 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 werepromoting). Installed Media Server as part of the SP1 "C" build to process thepromotion and notification events. HP/UX required additional time to get fix.Serial workflow functionality was only 25% developed. Modified Quickflow to getrequired functionality.17 reviewer/approver limit - Never fixed in 5.2.5 sp1dcmCheckin method used for custom check ins did not workdcm 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 classcoordinators 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 - Requirements1) Migrate ALL REQUIRED data2) Migration from a Network Filestore (Global I.S. documentation)3) Migrate from 3 different docbases (Manufacturing documentation)4) New standardised cabinet/folder structure in CORAL5) Property mappings6) Manufacturing Docbase migration: Complete migration within a“frozen” window of 5 working days – NO docbase activityguaranteed7) Validatable8) 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 CORALlocation– 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 – NotAchieved

Migration – The REALITY(2) New Manufacturing 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 GooseBlue Fish PedigreeWhat Blue Fish brought to the engagement

Project Snow GooseWhat 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 MigrationMethodology and product suite

Project Snow GooseThe Blue Fish Framework– Identify the data to be migrated– Extract the data from its currentrepository/file store– Transport the data from its currentlocation to the new location– Transform the data into the newstructure– Load the data into the new repository– Validate that the data was transformedand loaded correctly

Project Snow GooseThe Blue Fish Approach– Work with business users to define migration rules for each kind ofdocument– 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 eachstep of migration– Introduce an enrichment step to allow users and/or administratorsto perform meta-data enrichment– Automate the process to allow repeatable test migrations

Project Snow GooseTheory and PracticeHow we used the framework and methodology to deliver the ProjectSnow Goose Migration

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

Project Snow GooseMigration Specification MatrixContent LocationDocument GroupSource Docbase

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

Project Snow GooseRe-architectureProject Snow Goose involved not only a migration, but also aninformation re-architecture.This re-architecture involved systematically determining the targetobject-type, attributes, lifecycle, content and location of a migratedobject, based on the object’s previous incarnation. While the sourcerepositories held a significant amount of information, this needed to bevalidated for consistency and then made accessible to the migrationsystem.Many facets of this re-architecture were complex.

Project Snow GooseExamples of complexity – Assembly RulesReleased SOPsSOPsSOP#1, 2.0, CurrentSOP#1, 3.0, CurrentSOP#1, 4.0, CurrentMaster SOPsSOP#1, 4.0, CurrentSOP#1, 3.0, RetiredSOP#1, 2.0, Obsolete SOP#1, 4.0, Current SOP#1, 3.0, Retired SOP#1, 2.0, Obsolete

Project Snow GooseExamples of complexity – Naming ConventionsA naming convention describes how to break apart names into theirmeaningful elements. An example of a naming convention specification is:type – pla state – unit size – batch size – destination – formulaThe elements of the name are used in other components of the migration, forexample to determine the name of the destination folder in the targetrepository. An example target folder specification would be specified as:formula – 0525 – batch sizeAn example of a name that conforms to the convention, and its target folder:ointment – production – 30mg – 600 – waco – F245F245 – 0525 - 600

Project Snow GooseReduce ComplexityTo manage complexity, and to allow the system to develop as itneeded to, we adopted a model where we could developindividual components to handle a single aspect of the migrationprocessing.Each component addressed a single element of the process.We then arranged these components as a ‘pipeline’, where theprocessing steps required for each migration lot could beexecuted or skipped as necessary.

Project Snow GoosePipeline Operations Folder Naming ConventionDetect DuplicatesSelect LifecycleAttribute MappingCascade AttributesSet Owner NameCheck Effective DateStrip Unwanted ContentPost-export SelectionDetect Split TreesProcess Annotations Document Name ConventionSet Lifecycle StatePerform Document AssemblyRemove ‘do not migrate’ objectsSet Paper SizeSet PLA StateSet Retired DateSet Target PathSeparate Multi LotsSet Site

Project Snow GoosePipeline SchematicFailNOStartComponent #nOK?YESComponent #n 1

Project Snow GooseInspection“Allow non-technical business users to validate documents ateach step of migration”“Introduce an enrichment step to allow users and/oradministrators to perform meta-data enrichment“We re-cast the enrichment step into an inspection step – thisallowed users and/or administrators to inspect the migrationinformation before importing it into the target repository.

Project Snow GooseInspection ApplicationSource ObjectInformationMigrated ObjectInformationReviewer Notes

Project Snow GoosePre-import ValidationBefore 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 GooseValidation“Allow non-technical business users to validate documents ateach step of migration”List of MigratedObjectsSource ObjectInformationMigrated ObjectInformation

Project Snow GooseOverall Process Flow“Leverage Blue Fish DIXI (Documentum Import/eXport Interface)”StartDIXI ExportDIXI ImportPipelineDIXI ValidationInspectionValidationEnd

Project Snow GooseScheduler“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 GooseSchedulerPending TasksActive TasksCompleted Tasks

Project Snow GooseDeploymentStaged LocalContentCORALRepository

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

Project Snow GooseResults Migration Dress Rehearsals paid offFocused Team - Teamwork TriumphsAutomation reduces errorValidation reduces anxietyData Cleanup a key to success!

Project Snow GooseThanks! The Project Snow Goose Team!Migration Lead: Mark BridgesValidation Lead: Kathleen FoleyTechnical Lead: Darin Miller Project Snow Goose GTOPs Trainers/Data Verification:Shannon DeMaria – Irvine, CANicola Harcourt, Caroline Moran & Mary McNally – Westport IrelandAna Maia – Guarulhos, BrazilJena Eilers & Cheryl Turner – Waco, Texas The I.S. and EDMS Teams!