• No results found

Stakeholders identification: key success factor for the implementation of Electronic Document Management Systems

N/A
N/A
Protected

Academic year: 2021

Share "Stakeholders identification: key success factor for the implementation of Electronic Document Management Systems"

Copied!
13
0
0

Loading.... (view fulltext now)

Full text

(1)

factor for the implementation of Electronic

Document Management Systems

Isabel Saez-Pujol

Director, Informatics & Knowledge Management Daiichi Sankyo Development, Ltd.

The views and opinions expressed in the following PowerPoint slides are those of the individual presenter and should not be attributed to Drug

Disclaimer

those of the individual presenter and should not be attributed to Drug Information Association, Inc. (“DIA”), its directors, officers, employees, volunteers, members, chapters, councils, Special Interest Area Communities or affiliates, or any organization with which the presenter is employed or affiliated.

These PowerPoint slides are the intellectual property of the individual presenter and are protected under the copyright laws of the United States of presenter and are protected under the copyright laws of the United States of America and other countries. Used by permission. All rights reserved. Drug Information Association, DIA and DIA logo are registered trademarks or trademarks of Drug Information Association Inc. All other trademarks are the property of their respective owners.

(2)

Presentation outline

• Factors influencing Electronic Document

• Factors influencing Electronic Document

Management Systems (EDMS)

implementations

• Case Study 1 – Project “A” • Case Study 2 – Project “B”

www.diahome.org

Factors influencing implementations

• Before system go-live:

Stakeholder Identification and Participation

– Commitment and Leadership – Scope management

• After system go-live:

User perception of system need – User perception of system need – Time, rewards and incentives – Technology / people / processes – Training and end-user support

(3)

Stakeholder identification & participation

• Users must become

"

k h ld

"stakeholders“

• Give them the opportunity to participate in decisions concerning the system • When individuals "buy-in“,

they possess "ownership"

www.diahome.org

t ey possess o e s p

of the idea and become facilitators in making the implementation successful

Commitment and Leadership

• Commitment must be displayed by

p y

y

individuals involved in the

implementation at all levels

Should be identified

as Stakeholders

• Leadership support is

key

to successful

(4)

• "scope creep“ - can be

minimised b

Scope management

minimised by:

– Stakeholder identification – Clear scope changes

escalation procedures • changes prioritisation

(G P/N G P)

www.diahome.org

(GxP/Non-GxP)

• Steering Committee approval

User perception of system need

• Technology should not be adopted for

its o n sake a gen ine need m st

its own sake - a genuine need must

exist

• Users will use technology once they

understand how it can make them more

productive

p

• Users are stakeholders. A communication plan

to stakeholders needs to be established.

• User representatives (per function) should also be part of the project team

(5)

Time, rewards and incentives

• Mastering technology requires time

• Users have very little time (and patience) for experimenting with new technologies

• Creative ways to provide time for users to play with new technology:

– Encouraged through the use of rewards and

www.diahome.org

incentives

– Formal recognition of their technology endeavours

Technology / people / processes

People / Resources

Methodology / Processes Technology

(6)

Training and end user support

• Users must feel confident in the operation of the technology and their own ability to

integrate it into daily processes • Train, train and re-train

• User support can be divided into layers:

Q ti www.diahome.org Question Business question Super-user (Functional Liaisons) Business Owner Technical question

IT HelpDesk System OwnerInformation AdministratorSystem

Case Study 1 – Project “A”

• Project Specifications

(7)

Project Specifications (1)

System EDMS implementation

Goal Deliver a local database for Regulatory Affairs to create, store and archive documents and interface with an electronic Publishing tool.

Use Use:

–Regulatory Affairs, Clinical Development – approximately 20 users www.diahome.org approximately 20 users Location: – 1 US location

Project Specifications (2)

Time 4 months (in 2002)

Time ( )

Budget Fixed budget

Constraints Validation required:

21 CFR Part 11

ICH guidelines

Project j 5 team members:

Team –Validation Lead – from vendor

Quality Assurance – from vendor

Sponsor – from Regulatory Affairs

Project Manager – from Document Management

(8)

Factors influencing implementations

• Before system go-live:

Stakeholder Identification and Participation

– Commitment and Leadership – Scope management

• After system go-live:

User perception of system need

www.diahome.org

– User perception of system need – Time, rewards and incentives – Technology / people / processes – Training and end-user support

Case Study 2 – Project “B”

• Project Specifications • Project Team

(9)

Project Specifications (1)

System EDMS Configuration

Goal Deliver a single regional (US/EU) database for all key documents (intended for Regulatory Submissions)

Use Multi-functional use:

–Regulatory Affairs, Quality Assurance, Project Management, Clinical Development, Development

www.diahome.org

g p p

Research, Biostatistics & Data Operations, Translational Medicine & Clinical Pharmacology, Medical and Technical Writing, etc.

International locations:

–Europe 2 locations, USA 2 locations

Project Specifications (2)

Time 9 months (2007-2008) Time

Time ( )

Budget Fixed budget

Constraints Validation required:

21 CFR Part 11

ICH guidelines

Project Remote Project Management:

Time Quality Cost Project Team j g

Project Manager in the UK

Project Team in the US (same US location)

Multi-cultural implementation team from:

(10)

Project Team

Steering Committee

Role Defined in company procedures Role mentioned but not defined in

company procedures 4 Committee (Senior Management) Business Owner (Business Function) Information Systems Project Manager (I f ti ) Computeris d S t company procedures

Role not mentioned or defined in company procedures 0.5 0.5 2 2 11 2 5 www.diahome.org

Project Team Validation Team

Owner (Informatics) (Informatics) ed System Owner (Business Function) IT Application & Services

(IT Appl. & Services) Validation Lead (Consultant) Technical Lead (Consultant) Quality Assurance (Regulatory Affairs & Risk Mangment.)

Functional Liaisons

(Business Function)

3 2

1

Factors influencing the implementation

Before system go-live (1):

• Stakeholders’ identification and participation:

– Identification:

• Departments involved identified by Business Owner(s) • Departmental representation identified by Management

– Communication plan in Project Charter:

• Weekly (+ad hoc) Validation Team meetings • Monthly meetings with Functional Liaisons

• Functional Liaisons responsible for departmental communication • Monthly Status report sent to Steering Committee

(11)

Factors influencing the implementation

Before system go-live (2):

y

g

( )

• Commitment and Leadership

– Steering Committee approach

• Scope management

• Scope changes rejected – some would be

implemented as Change Controls after system “go

www.diahome.org

implemented as Change Controls after system go-live”.

Factors influencing the implementation

After system go-live:

• User perception of system need • Time, rewards and incentives

• Part of employees objectives

• Technology / people / processes

• Updated company proceduresp p y p

• Training and end-user support

• Content Management training

• Functional Liaisons / Content Management support • IT Help Desk / System Administrator

(12)

Projects Comparison

Case Study 1 – Project “A” Case Study 2 – Project “B”

Si l d t t P d fi d d t t Single document type

• Difficult to search

• No document specific attributes • Unlimited scope for document type

Pre-defined document types • Search capability improved per

document type and attributes • Attributes specific to document type Freedom of classification

• Users unable to find documentation

Pre-defined classification based on document type

• Facilitates User familiarity with folder structure and navigation

www.diahome.org

20 users 200 users

Electronic signatures

~100,000 documents in repositories >250,000 documents in repository

Lessons Learned

• Stakeholders involvement can make the difference between success and failure: difference between success and failure:

– Identify Stakeholders

– Prepare a Stakeholders’ communication plan based on level of prioritisation

– Involve Stakeholders’ to participate in the project before go-live and after go-live

(13)

References

Related documents