ERP Best Practice Example 1

8/11/2019 ERP Best Practice Example 1

1/137

NYCDMS/1183869.19

6/10/11

By and Between

nd

Project

Effective

June

10

2 11


2/137

TABLE OF CONTENTS

1 BACKGROUND AND PURPOSE

4

1 1

Undertaking ....... ..... ..... ................ . ............. ..... ................ .... ................................ 4

1 2 Definitions ................ ................. . ................... ...................... ................. ................ 4

1 3

Objectives ... ................... ... ......................... . ............. ............. ... ....... ......... ............... 10

1 4

Phases ........................ ............................................. ......................... ......... ..... ....... ..... 12

2 SERVICES ...... .....................

....................

................. ..... .................. ..

................... . ............

13

2 2 Planning and Initiation Phase ......... ................... . ...... ................ ..................................

15

2 3

Global Design Phase ................. . .................................. ......... ......... ........ ....... .... . .... ...

18

2 4

Global Build Phase ... ................ .... ...................... ................. ....................................... 35

2 5 Testing Phase .............. .................... ................... ..................... ..... ............ ................... 43

2 6

Deploy and Support ..... .. .......... ........................ .. ...... ..... . .... ...... .............. ...... ......... 46

3 ORGANIZATIONAL CHANGE MANAGEMENT

51

3 1

General. ............................................ ...................... .................... ..................... ..... ........... 51

3 2

The Organizational Change Management OCM) Team ............ ................ .... ..... ......

51

3.3 Organizational Change Management Strategy ... ... .... ........... ............. ...... ................... 51

3 4

Training .................. ...................... ...................... .... ................... ..................................... 54

3 5

Organizational Change Management Components . ................. ...................... ....... . 55

4 TOOLS AND METHODOLOGY

59

4 1 Project Methodologies ..... ........................................... ............................. ........ 59

4 2 Deliverab1es ......... ..................... ....... ...................... .. .............. . .................. ............... 60

4 3 Tools ..

....... ...

..........

.

........ ..... .

..........

....... .................. ...... ................... .....

....

.

60

4 4 Six Sigma and Lean .. ................... ...

... ...............

................ .... .................... ............ 60

4 5 Cost/Benefit Analysis ................. . ..................... .............................................. .

. ........ 60

5 PROJECT STAFFING

61

5 1 Personnel On-Boarding ............ .......... ........................................ ... ................

.

... . ...... 61

5 2 Key Personnel. ......... .................... .................. .............................................. ................ 61

5 3

Staffing Plan ........................... ............................... .

........ ......... ..... .. ........ ... . ......

61

5 4

Program Manager ...............

............ ......... .......... ..... ...... .............................. 61

5 5 Responsibilities ......................................... ..........................................................

61

6 MILESTONES AND DELIVERABLES ......................... .................... ................... ...............

62

7 ACCEPTANCE

OF

DELIVERABLES

62

7 1 Acceptance ofDeliverables ............. ..................... ................. ......................... .......... 62

7 2

Acceptance Criteria .. . ......... ........ ..................................... ....... .................................. 62

NYCDMS/1

18

3869.19

6/10/1 1

2


3/137

8. GOVERNANCE ........................................................................................................................ 63

8.1 General. ................ ................. ................ ................ ................ ................ ................ .......... 63

8.2 Governance Structure ........... ............. ............. ............. ............ ............. ............. ............. 63

9

ASSUMPTIONS ....... .................................................................................................................

66

9.1 General Assumptions ................. ................. ................. ................. ................. ................ . 66

9.2 Staffing Assumptions ..................................................................................................... 66

9.3 Other Assumptions ......... ................................................................................................ 67

9.4 Adjustment Events ................. ................. ................. ................. ................. ................. .... 68

10. FEES AND FEE SCHEDULE .................................................................................................. 69

10.1 General. ........................................................................................................................... 69

10.2

Subsequent Project Phases .............................................................................................

69

10.3 Adjustment Event Dispute Termination Right. ............................................................... 70

11. DATA PRIVACY AND SECURITY ....................................................................................... 70

SIGNATURE PAGE ............................................................ ............................................. ........................ 71

EXHffiiT 1 FEE SCHEDlJLE) ................ ................. ................ ................. ................ ................. ............ 72

1. STAGE 1 OF THE PROJECT ..................................................................................................... 72

2. STAGE 2 OF THE PROJECT ..................................................................................................... 73

3.

TRAVEL OUT OF POCKET EXPENSES .............................................................................. 73

4. ............. .............. ............. ............. .............. ............. .............. ............. ........... 73

EXHffiiT 2 STAFFING PLAN) .............................................................................................................. 75

ART I:

STAGE * ................... ................... ................... ................... ................. 75

ART

II: STAGE * .................. .................... ................... ................... ...... 76

ART

III: STAGE 2 * ................................................................ 77

_ _

PART

IV: STAGE * ............................... ............ 78

EXHffiiT

3 KEY PERSONNEL) ....... ... ....... ........................ ....................... ......

.....

......................... 79

EXHffiiT 4 DELIVERABLE MATERIALS

AND

ACCEPTANCE CRITERIA) ........ . ...................... 80

EXHffiiT

4 INDEX

OF

DELIVERABLES ............................................................................................ 123

EXHIDIT 5 DATA PRIVACY AND SECURIT) ............................................................................... 124

EXHffiiT 6 NINE LEVERS OF SCOPE) ............................................................................................. 130

EXHffiiT

7 ) ....................................................................... 136

EXHffiiT 8 PRELIMINARY HIGH-LEVEL PROJECT PLAN ........................................................ 137

NYCDMS/1183869.19

6/l

0/11

3


4/137

1. Background and Purpose.

1.1 Undertaking .

1.1.1 is undertaking a project to increase its performance and efficiency y standardiz

ing Industry Leading Practices on a single technology platform ( Project or Project

1.1.2 will define standard global business processes and implement them on a

single global instance ofthe eBusiness Suite ( ERP version along with

certain other software that has licensed or will license.

1.1.3 As

of

the Effective Date

of

this SOW, includes the following high-level

business process areas (all as more specifically described in Exhibit 6):

a)

Product Lifecycle Management;

b)

Procure-to-Pay;

c)

Plan-to-Manufacture;

d) Order-to-Cash;

e)

Market-to-Customer;

f)

Record-to-Report; and

g)

Hire-to-Retire.

1.1.4 will be implemented world-wide at all Sites, including those in

the United States, Latin America, Europe and Asia (as more fully described in Exhibit

6).

1.2 Definitions.

In addition to any definitions provided in the Agreement, defined terms in this Attachment shall

have the following meanings:

1.2.1 Adjustment Event shall have the meaning ascribed to it in Section 9 4.1.

1.2.2 Application Architecture shall have the meaning ascribed to it in Section 2.3.7(a)l.

1.2.3

Benchmarking Study shall have the meaning ascribed to it in Section 2.3.2(a).

1.2.4 BI means Business Intelligence, as that term is generally understood in the industry.

1.2.5 Bolt-On means a software application (whether third party or custom written) that can

e

attached or linked to the System and made a part thereof in an fashion

without the need for a Modification.

NYCDMS/1183869.19

6/10/11

4


5/137

1 2 6

Business Process Design means written documentation describing the various work

steps and rules required to accomplish a task

or

tasks in satisfaction

of

a Business Re

quirement. Business Process Designs can be High Level Business Process Designs or

Detailed Business Process Designs .

1 2 7 Business Requirements or User Requirements Specifications means those opera

tional requirements necessary to operate its business, comply with all appli

cable Laws and to achieve the Project Objectives.

1 2 8

Business Scenario means description of the ways in which work processes are carried

out in a business activity.

1 2 9

COE or Center ofExcellence shall have the meaning ascribed to it in Section

2.6.4(a).

1 2 10 Compliance and Validation Strategy shall have the meaning ascribed to it in Section

2.3.10(c).

1 2 11 Configuration or to Configure means Software setup or establishing parameters

within the Software in order to make the Software function

or

behave in a certain way.

Such parameters include setup parameters or switches , defining or altering Descrip

tive Flex-Fields (DFFs), modifying existing Workflows,

or

modifying screen layouts

or

provided reports, all as supported by the intrinsic functionality of the Software.

1 2 12

Conversion and Interfaces Programs Document shall have the meaning ascribed to it

in Section 2.4.3(c)l.

1 2 13

Customization means any enhancement to the System resulting from methods that do

not require changes to the core Software source code or underlying data structures - and

which are supported through the normal

upgrade path.

1 2 14

CRP

or

Conference Room Pilot shall have the meaning ascribed to it in Section

2.3.ll(a).

1 2 15

Cutover Checklist shall have the meaning ascribed to it in Section 2.5.7(d).

1 2 16

Cutover Plan shall have the meaning ascribed to it in Section 2.5.7(a).

1 2 17 Data Archiving Strategy shall have the meaning ascribed to it in Section 2.3.12(e)2.

1 2 18

Data Conversion Strategy shall have the meaning ascribed to it in Section 2.3.12(e)l.

1 2 19

Data Conversion Strategy Plan shall have the meaning ascribed to it in Section

2.3.12(a)3.

1 2 20

Data Governance Strategy shall have the meaning ascribed to it in Section 2.3.12(d)l .

1 2 21 Data Management Plan shall have the meaning ascribed to it in Section 2.3.12(c)l .

1 2 22 Data

Readiness Assessment shall have the meaning ascribed to it in Section

2.3.12(a)l.

NYCDMS/1183869.19

6/10/11

5


6/137

1 2 23 Database & Instance Strategy shall have the meaning ascribed to it in Section 2.3.8.

1 2 24 Deploy and Support means the phase of the Project in which the Parties will deploy

the System to all Sites and during which IDM will provide Post Production Sup

port Services pursuant to Section 2.6 of this Attachment.

1 2 25

Deployment Strategy shall have the meaning ascribed to it in Section 2.3.17(a)2.

1 2 26 Detailed Business Process Design means those Business Processes that are docu

mented to at least Level-5 (as that term is normally understood in the industry).

1 2 27 OW means Data Warehousing, as that term is generally understood in the industry.

1 2 28

Enterprise Architecture has the meaning ascribed to it in Section 2.3.7.

1 2 29

Enterprise Architecture Diagram means a diagram that documents the Enterprise Ar

chitecture.

1 2 30 Extensions means those custom developed objects which can be classified as either

Modifications

or

Customizations (i.e., the E in

1 2 31 Fit/Gap Analysis shall have the meaning ascribed to it in Section 2.3.4(c).

1 2 32 Functional Specifications shall have the meaning ascribed to it in Section 2.3.9.

1 2 33 Gap or

Gaps means those areas where the standard functionality

of

the Software

does not meet the Business Requirements.

1 2 34 Global Build Phase means that phase of the Project in which the Parties will build the

necessary elements to deploy the

System, including development of the objects

needed for the implementation of the System, pursuant to Section 2.3.18 of this Attach

ment.

1 2 35 Global Design means the design of the System that includes all System-enabled Busi

ness Processes, data structures, objects and all functionality that is common to

all Sites, or that is in the core System (including local requirements that are im

plemented in the core System).

1 2 36 Global Design Phase means that phase of the Project in which the Project Team will,

among other things, create the Global Design for the implementation

of

all

as more fully described in Section 2.3

of

this Attachment.

1 2 37

Global Process Review Board shall have the meaning ascribed to it in Section

8.2.1(c).

1 2 38 High Level Business Process Design means those Business Process Designs that are

documented to

Level-l,

Level-2

or

Level-3 (as those terms are normally understood in

the industry).

1 2 39 Methodology shall have the meaning ascribed to it in Section 4.1.

NYCDMS/1183869.19

6/10/

6


7/137

1 2 40 Program Manager means the individual assigned

by

to carry out the

duties and responsibilities outlined in Section 5.4.

1 2 41 Implementation Plan and Estimate shall have the meaning ascribed to it in Section

2.3.19(a).

1 2 42 Industry Leading Practices means those proven practices, techniques and methods that

are commonly accepted and utilized by other top-tier system implementation service

providers or otherwise derived from ffiM's experience and expertise in other successful

system implementations.

1 2 43 IQ/OQ means installation qualification and operational qualification.

1 2 44 KPI''

or

Key Performance Indicator means a measurement intended to monitor the

performance of a particular business

or

system function.

1 2 45 Localizations means Configurations, Business Processes or objects that are

not part of the Global Design but required for a specific Site or set of

Sites.

1 2 46 Master Validation Plan or Validation Master Plan means a document that will state

what is to be done, the scope, the approach, the schedule ofValidation activities and

tasks to be performed. The Master Validation Plan will also state who is responsible for

performing each activity and must be approved by management.

1 2 47 Milestone means

an

event that the Parties have designated as such, which mark key

events or accomplishments throughout the Project.

1 2 48 Modification means a change to the core Software source code or underlying data

structures that are outside the bounds ofnormal Configuration, Bolt-on, Customization

or

object-

and not part

of

the normal upgrade path.

1 2 49 Needs Assessment shall have the meaning ascribed to it in Section 2.3.20(b)3.

1 2 50 Objectives shall have the meaning ascribed to it in Section 1.3.

1 2 51 Ongoing Production Support Plan shall have the meaning ascribed to it in Section

2.6.4(c)l.

1 2 52 OCM

or

Organizational Change Management means a structured approach to tran

sitioning individuals, teams and organizations from a current state to a desired future

state, in this case, from current state to the full implementation, including Ac

ceptance and beneficial use of the System.

1 2 53 OCM Strategy shall have the meaning ascribed to it in Section 3.3.1.

1 2 54 Organizational Change Management Team or OCM Team shall have the meaning

ascribed to t in Section 3.2.

1 2 55 Organizational Transformation Plan shall have the meaning ascribed to it in Section

3.3.4.

NYCDMS/1183869.19

6110/11

7


8/137

1.2.56 Pilot Location means the Site at which the System will be deployed first, and

used to initially test the adequacy

of

the System's functionality and performance, prior

to it being deployed in the remaining Sites.

1.2.57 Planning and Initiation Phase means that phase

of

the Project in which the Parties will

prepare and plan for the implementation of the System, pursuant to Section 2.2 of this

Attachment.

1.2.58 PMO shall have the meaning ascribed to it in Section 2.2.l(a).

1.2.59 Post Production Plan shall have the meaning ascribed to it in Section 2.6.3(f).

1.2.60 Post Production Services shall have the meaning ascribed to it in Section 2.6.4(b).

1.2.61 Production System means the System once it has passed all required testing and is

ready to be deployed or has been deployed and is able to process live transactions and

provide information in the manner in which it was designed.

1.2.62 Project shall have the meaning ascribed to it in Section 1.1.1.

1.2.63 Project - see Project .

1.2.64 Project Methodology shall have the meaning ascribed to it in Section 4.1.2(a).

1.2.65 Project Objectives

-see

Objectives.

1.2.66 Project Plan shall have the meaning ascribed to it in Section 2.2.4(a)1

1.2.67 Reporting and BI Strategy or Reporting and Business Intelligence Strategy shall

have the meaning ascribed to it in Section 2.3.14.

1.2.68 means reports, interfaces, conversions, Extensions, and workflows.

1.2.69 Development Strategy shall have the meaning ascribed to it in Section

2.3.15(a).

1.2.70 Listing shall have the meaning ascribed to it in Section 2.3.15(b).

1.2.71 Risk Assessment means the assessment of both regulatory risks and Project risks per

formed per Section 2.3.10(d).

1.2. 72 Risk Mitigation Plan shall have the meaning ascribed to it in Section 2.3 10(d)1

1.2. 73 Roles and Authorization Specification shall have the meaning ascribed to it in Section

2.4.4.

1.2.74 Security Matrix shall have the meaning ascribed to it in Section 2.3.10(b).

1.2.75 Site Readiness Evaluation Document shall have the meaning ascribed to it in Section

2.5.8.

NYCDMS/1183869.19

6/10/1 1

8


9/137

1 2 76 SME means subject matter expert who is an individual with in-depth knowledge of a

specific area

or

subject.

1 2 77 SOA'' means Services Oriented Architecture, as generally understood in the industry.

1 2 78 Solution Workbench or Solution Workbench means a proprietary tool

used to assist the Project Team with the tasks associated with implementing ap

plications.

1 2 79 Stage 1 means, collectively, the Planning and Initiation Phase and the Global Design

Phase

of

the Project, including any applicable OCM activities.

1 2 80 Stage 2 means, collectively, the Global Build Phase, Testing Phase, and the Deploy

and Support Phase of the Project, including any applicable OCM activities.

1 2 81 Staffing Plan means the staffing tables included in Exhibit 2.

1 2 82

Steering Committee shall have the meaning ascribed to it in Section 8.2.1(a)l.

1 2 83 System means, collectively, all hardware, software (including Business Suite

( ERP version Rl2), Business Processes, objects, Localizations

andre-

lated technology elements, that will enable the fulfillment of the Project Objectives.

1 2 84

System Operations Support Plan shall have the meaning ascribed to it in Section

2.6.4(a).

1 2 85

System Testing

or

SIT means the tests used to confirm that the System

or

portions thereof function( s) in accordance with applicable Functional Specification(s)

and that each developed component functions in an manner with the rest of

the System and individual modules, add-ons, or other separate parts, when combined to

gether, operate as designed.

1 2 86 Team or The Team or Project Team means the joint team (under supervi

sion) comprising resources and resources.

1 2 87 Technical Specifications shall have the meaning ascribed to it in Section 2.4.3(a).

1 2 88

Technology Architecture means the elements of the System described in the Technol

ogy Architecture Strategy which includes hardware, servers, workstations, power back

up

systems, operating systems, networks (LANs and W ANs), connectivity, communica

tions, databases, and technology tools & utilities.

1 2 89 Technology Architecture Strategy shall have the meaning ascribed to it in Section

2.3.6.

1 2 90

Test Plans shall have the meaning ascribed to it in Section 2.4.7(a)l.

1 2 91

Test Scripts shall have the meaning ascribed to it in Section 2.4.7(a)l.

1 2 92 Testing Phase Checklist shall have the meaning ascribed to it in Section 2.5.3(a).

NYCDMS/1183869.19

6/10/11

9


10/137


11/137

1.3.7 The System must be validated in such a way that it enable compliance with applicable

Laws, and is able to satisfy audit requirements.

1.3.8 Identify and incorporate appropriate KPI s that enable effective measurement of the

Project s success and effectiveness

of

new business processes.

1.3.9 The Project should be completed in the shortest amount of time necessary to accomplish

these Objectives and the Project investment should yield a positive return on in

vestment (ROI) over the time-frames to be defined during the Global Design Phase.

1.3.10

IDM understands that Project has been created in support of the following addi

tional business drivers and will work with in support of these goals:

NYCDMS/1183869. 9

6/10/ll

a) The Project will eliminate redundant ERP systems.

b)

Wherever possible, utilize the inherent functionality of

ERP system without additional Modification (e.g. changes to

and other software base code).

(c) The Project will establish processes and system designs that facilitate a fi

nancial reporting structure that produces accurate reporting

of fi

nancial operations.

d) The data that is produced by is expected to be a consistent, single

source

of

truth about products and business activities.

(e) The system will be designed wherever possible, to facilitate the interopera

tion of business processes whi le minimizing workarounds.

f) The new business processes and System will be designed wherever possible

to enable the optimization and/or consolidation of product devel

opment, manufacturing and distribution operations.

(g) The future state organizational structure and related business processes will

be designed in such a way as to implement an service delivery

model that enables continuous process improvement.

h)

The System and Business Process Designs will incorporate a Business Intel

ligence structure that provides the current information the business decision

makers need to run their business looking forward.

i)

The Project Team will work to create and deliver appropriate training that

prepares the organization to execute the new business processes and System.

j) Enable to transform its processes and environment to allow

to:

1.

2.

scale efficiently to grow organically and through acquisition

within the medical device industry;

meet goals for improved profitability;


12/137

3.

4.

5.

6.

7.

8.

capture value from acquisitions by providing the ability to more

quickly new businesses, reduce their costs and im

prove their efficiency;

reduce administrative and procurement costs e.g., through

spend aggregations, strategic sourcing, better compliance and

tighter controls);

improve supply chain performance;

reduce inventory days on hand;

provide improved insight into true operations and performance;

and

significantly improve management reporting capa

bilities.

1.3.11 Implement in such a way that allows to upgrade, add to or modify

the System in the future.

1.3.12 Accomplish a transformation o business in such a way that Project costs are

reasonably predictable to

1.4 Phases.

Generally Project comprises five 5) major phases, all more fully described below. The

preliminary high-level Project Plan on which the Services in this SOW are based is included as

Exhibit 8.

1.4.1 Planning and Initiation Phase, which includes the following high level project objectives

as further detailed in Section 2.2 below):

NYCDMS/1183869.19

6/10/11

a) Articulate how Project will meet the Objectives and develop a high

level project approach and schedule to meet those Objectives;

b) Complete a staffing plan and assemble the project team;

c) Prepare and educate resources to perform their assigned tasks and exer

cise their roles and responsibilities pursuant to the Project Plan;

d)

Align and on common methodologies that will be used through

out the Project;

e) Establish project governance;

t) Plan for the implementation and optimization o the System; and

g) Conduct workshops, or utilize other such methods in order to efficiently

launch Project

12


13/137

1.4.2 Global Design Phase, which includes the following high level project objectives (as fur

ther detailed in Section 2.3 below):

(a) Design consistent and optimized High Level Business Process Designs in

corporating Industry Leading Practices for the medical device industry where

possible, including leading and/or necessary processes and practices current

ly being utilized by (the High Level Business Process Design ).

b) Design an Enterprise Architecture that includes the necessary technical ele

ments required to accomplish the goals and objectives

of

Project in

cluding, but not limited to supporting data structures, localizations, user re

quirements, objects, and system configurations.

(c) Evaluate the nine levers

of

scope , approach, staffing, costs (internal & ex

ternal), deployment strategy and time-line for Project

d) Benchmark current operating metrics against industry and cross

industry metrics and determine target metrics and KPI' s for Project

and the timing of achieving said metrics.

(e) Create a business case including an ROI calculation for the project.

f) Establish an appropriate strategy, architecture and plan for data management.

1.4.3 Global Build Phase, during which, The Project Team will configure the software and

create the Business Process Designs, and develop the objects required to im

plement the overall global design as further detailed in Section 2.3.18 below.

1.4.4 Testing Phase, during which the Project Team will confirm that the System solution

meets Business Requirements,

as

further detailed in Section 2.4.12 below.

1.4.5 Deploy and Support Phase, will occur as follows (and as further detailed in Section 2.6

below):

2. Services.

(a) Deployment Phase 1 -prepare for and implement the System in the Pilot Lo

cation as determined during the Global Design Phase, and provide Post Pro

duction Services.

b) Deployment Phase

2

prepare for and implement the System in all other

Sites in subsequent waves, as determined during the Global Design

Phase, and provide Post Production Services.

2.1.1 This Statement of Work describes the major services that will provide to

will perform the services in a manner designed to accomplish the Project Objec

tives (the Services ).

2.1.2 and will establish a Project Team comprising resources and

resources.

NYCDMS/1183869.19

6/10/

3


14/137

2.1.3

With respect to the responsibilities

of

the Project Team, in general, will:

a) Provide overall leadership, supervision, guidance, application exper

tise, business process expertise and technical expertise for the Project includ

ing project and program management;

b)

Provide team leads for the following Project teams:

1 Record to Report;

2.

Market to Customer;

3. Procure to Pay;

4. Order to Cash;

5. Plan to Manufacture;

6. Hire to Retire;

7. Regulatory Compliance and Validation;

8.

Master Data Management;

9. Product Lifecycle Management if necessary);

10.

Organizational Change Management; and

11.

Business Intelligence.

c) Develop and unit-test the objects;

d) Lead the effort to perform the benchmarking study and create the business

case and ROI calculation;

e) Use proprietary methodology and tools for the Project;

f)

Provide guidance and thought leadership around Organizational Change

Management;

g) Design and implement industry and cross-industry Industry Leading Practic

es and business processes, where practicable.

2.1.4

With respect to the responsibilities of the Project Team, in general, will, under

the supervision, guidance and leadership

of

:

NYCDMS

/1 183869.19

6/10/1 I

a)

Provide an experienced Program Manager the Program Manager);

b) Provide personnel with experience in system administration, database admin

istration, creation of detailed documentation, hands-on configuration and

functional design;

4


15/137


16/137

b)

Budgeting

The Project Team will establish a budget for the timely comple

tion ofProject and establish appropriate mechanisms for IDM and

to track the progress against such budget.

(c) Staffin The Project Team will define roles and responsibilities of all re

sources and complete a Project Staffing Plan for approval.

d) Project Planning and Tracking - The Project Team will build an

Project Plan, as provided in this Section 2.2. will track the overall

progress ofProject according to the Project Plan, as well as provide to

regular weekly written status updates from the team leads and

monthly overall Project progress reports from the PMO.

(e) Project Communication Governance. The Project Team will undertake the

following, as further detailed in Sections 3 (OCM) and 8 (Governance) be

low:

1.

2

3.

4.

5.

6

7.

8.

Establish a governance structure that requires ongoing commu

nications across the Project Teams, as well as to the System s

user community;

Initiate required communications between the Project Team and

the System s user community (as approved

n

writing

n

ad

vance by

Ensure that procedures and processes are n place to generate

high quality Deliverables;

Establish procedures and processes to capture, escalate, and re

solve issues that arise during Project

Conduct regular analyses

of

Project risks and establish

ing processes and procedures to prevent and/or manage such

risks; providing written copy of such analyses to for its

review and comment;

Include tasks and Deliverables in the Project Plans so that the

Project Team can adequately address compliance with applica

ble Regulatory Requirements during the conduct of the

Project;

Include tasks and Deliverables

n

the Project Plans so that the

Project Team can adequately address System Validation and

documentation throughout the the Project; and

Establish (subject to review and approval) written

Change Procedures for use throughout Project

2.2.3

Project Initiation. During Project initiation, the Parties will:

NYCDMS/1183869 19

6110/11

16


17/137


18/137

5

the Project, then will notify Program

Manager.

ii) will work with to correct any issue re

ported pursuant to subsection (i) immediately above,

by:

A At expense, accommodating

requests for to provide resources to back

fill for resources that may not be per

forming at the level required, or

B.

Modifying the Project Plan to take into account

actual performance against the Project

Plan, as the Parties agree.

iii) f any tasks are dependent upon perfor

mance, then performance requirements will be

relieved, but only to the extent impacted by

provided that:

A. has complied with this subsection (4), and

B has used commercially reasonable efforts

to perform notwithstanding non

performance.

Project Tracking and Reporting. will track and report on

the progress of Project in order to achieve the Project

goals using the Project Methodology.

2.2.5

Organizational Change Management ( OCM ). During the Planning and Initiation

Phase, the OCM Team will:

a)

Begin to prepare the initial OCM Strategy.

b) Begin to prepare the initial Organizational Transformation Plan and incorpo

rate such plan into the Project Plan.

2.3 Global Design Phase.

2.3.1 The key inputs that the Project Team will utilize during the Global Design Phase in

clude:

NYCDMS/1183869.19

6/10/11

(a) APQC process definitions;

b)

business processes targeted for the medical device industry;

(c) Business processes that are inherent in the in-scope applications;

d) Applicable global governing and Regulatory Requirements;

18


19/137

(e) Business Requirements and user input;

f) the Project Objectives; and

(g) the Business Case.

2.3.2 Benchmarking Study and Business Case.

NY DMS/1183869.19

6/10/11

(a) will conduct a benchmarking study, using current financial

and operating performance data (to be provided by to in a timely

manner at or near the beginning

of

the Project) (the Benchmarking Study ).

1.

2.

3.

4

will recommend up to twenty (20) KPis that may

use in order to measure value realization for Project and

monitor process improvements.

Using current financial and operating performance da

ta the Project Team will take baseline measurements for the

KPis (selected in the previous step) and will provide ben

chmarking analysis comparing such baseline measurements to

relevant comparable industry data.

will present such baseline data and resulting benchmarking

analysis to to facilitate analysis and discussion between

the Parties with respect to maximizing futegra' s return on its

Project investment.

The targeted improvements for any KPI will be reviewed for

approval by the appropriate futegra stakeholders who will be

impacted by any such KPis. Organizational Change Manage

ment methods will

be

utilized

by

the Team to gain buy-in

by

stakeholders.

b) Business Case.

1. will analyze the Business Requirements and the results of

the Benchmarking Study, and will identify those business

process areas that offer the best potential for value creation.

Based on the above, will provide to a Business

Case report identifying:

i) key areas

of

cost savings;

ii) key benefit opportunities; and

iii)

key value realization targets.

c) Financial impact and benefit tracking.

1. Upon receiving Acceptance

of

the Benchmarking Study and the

Business Case will utilize up to twenty (20) KPI's to track

19


20/137

the realization of benefits within its proprietary Solution Work

bench tool during the course of the Project.

2.3.3 Business Requirements. will use methods which may include one-on-one inter

views and/or workshops with business process SMEs) to gather Business Re

quirements.

NYCDMS/1183869.19

6/10/11

a)

he

Project Team will identify the Business Requirements for the System.

1.

2

3.

The Project Team will gather and document the Business Re

quirements for each process area in scope, clearly and consis

tently, including structured reviews with stakeholders to

confirm such Business Requirements.

The Business Requirements will be the basis for the Business

Process Designs and the Configuration of the System.

The Business Requirements will also be used as input to the

Functional Specifications, which in tum will serve as the predi

cate for the Technical Specifications, which will be used to de

velop objects.

b) Design Guidelines. In gathering and/or documenting the Business Require

ments, the Functional Specifications or the Business Process Designs, the

Project Team will use the following guidelines to achieve the Project Objec

tives, including:

1

2

3.

4

5

6

Minimizing the number objects;

A voiding Modifications;

Simplifying and eliminating unnecessary steps in busi

ness processes;

Requiring solid business justification for deviating from stan

dard APQC

or

provided processes;

Considering Localizations and Regulatory Compliance

Requirements as necessary; and

Maximizing automation in business processes wherever possi

ble.

c) Teams. personnel will be prepared for gathering Business Require

ments by:

1

2

Understanding the parts

of

business applicable to the

processes under consideration; and

Understanding the Project Objectives.

20


21/137


22/137

2.3.6 Technology Architecture Strategy. The Project Team will prepare an initial technology

architecture strategy (that will be updated from time to time as required during the con

duct of the Project) that will:

a) Accomplish the following objectives:

1.

2.

support processes and applications as designed, in

support

of

the Project Objectives and Business Requirements,

and include appropriate growth plans as communicated

y

to the Project Team; and

support the ability

of

the System to incorporate updates, en

hancements and future releases.

b) Include descriptions

of

the following components:

1.

2.

3.

4.

5.

6.

7

servers, including the required numbers and sizing (processors,

memory, and data storage);

workstation requirements;

operating systems

network, connectivity and communication requirements (includ

ingVPNs);

database requirements;

technology tools utilities; and

backup and hot-site failover procedures.

(c) Establish governance policies and administration procedures for the on-going

management

of

the Technology Architecture, including back-up procedures,

data transport procedures, authorization and profile maintenance, and per

formance monitoring.

d)

(a), (b) and (c) above, shall be known collectively, as the Technology Archi

tecture Strategy .

2.3. 7 Enterprise Architecture.

NYCDMS/1183869.19

6/10/11

a)

will review proposed Enterprise Architecture for its ability to

facilitate the Project Objectives and will provide with recommenda

tions for any necessary changes, including:

1.

Application Architecture, representing the proposed future state

of

software applications to be utilized for the Project (the Ap

plication Architecture ), including:

22


23/137

2.

3.

4.

i) application functionality components and relationships;

ii)

application development supporting software languages

and tools, and other required software applications tools

technologies (such as testing tools);

iii)

diagram describing inbound and outbound

interfaces (which is subject to further refinement in sub

sequent phases);

iv)

methods (including SOA tools, where ap

propriate) with other System components including leg

acy systems; and

(v) legacy software including configurations re

quired to interface with the System.

Reporting and I Strategy and architecture required to run it,

including software and data required to support I and reporting

requirements;

Information Architecture, including master data descriptions;

and

Technology Architecture Strategy

b) (a), (2), (3) and (4) above, collectively, shall be known as, the Enterprise

Architecture .

2.3.8 Database & Instance Strategy. The Project Team will determine and establish there-

quired number

of

production and non-production database instances to allow work to

progress from development through testing in a manner that will allow test results and

design decisions to yield results that are indicative of the performance of the System in

production (the Database and Instance Strategy ).

2.3.9

Functional Specifications. The Project Team will create written specifications and do

cumentation that describe the expected operation

of

any and all objects, Mod

ifications or Customizations based on the Business Requirements in sufficient detail in

order to create the Technical Specifications (the Functional Specifications ).

2.3.10

Regulatory Compliance & Validation, Security Matrix, Risk Mitigation, Controls, and

Application Security Requirements Definition and Design.

NYCDMS/1183869.19

6/L0/11

a)

Regulatory Compliance Validation. Regulatory compliance requirements,

including Validation considerations, will be an part of the Project

approach in all phases.

3


24/137

NYCDMS/1183869.19

6/

10

/

11

1.

2

3

The guiding methodology for System Validation will be

Validation policy.

will assist throughout all phases

of

the Project and

will lead the team in designing efficient compliance processes

and procedures, as well as facilitating knowledge transfer.

With respect to regulatory compliance and Validation tasks, the

guiding principles for all phases throughout the Project are to:

(i) Identify regulatory compliance requirements and Vali-

dation considerations including documentation methods

requirements, and testing requirements approach-

es;

(ii) Use (to the extent possible) existing regulatory

compliance documentation and Validation processes,

policies and documentation if any);

(iii)

Design processes and Configure the System in such a

way so that Regulatory Compliance and Validation can

be accomplished effectively;

(iv) Provide detailed tasks in the Project Plans to adequately

address Regulatory Requirements and Valida-

tion considerations;

(v) Identify and recommend tools, methods, software, and

processes to be used in required tasks for Regulatory

Compliance and Validation;

(vi) Identify and create a Compliance and Validation Strate-

gy for regulatory compliance and Validation during the

Global Design Phase; and.

(vii) Create, test and implement detailed processes, systems,

and documentation associated with regulatory com-

pliance and Validation during subsequent phases of the

Project.

(b) Security Matrix. The Project Team will design (with due regard to cost ver-

sus benefit) a security matrix so that the System provides integrity, reliabili-

ty, and availability of Data and information to users (the Security

Matrix )

(c) Compliance and Validation Strategy: During the Global Design Phase, the

Project Team will create a compliance and Validation strategy, which will:

1.

be aligned and in accordance with Validation policy;

24


25/137

NYCDMS/1183869.19

6/10/11

2

3

4

5

6

7

8

include at a minimum, Industry Leading Practices and industry

standard elements for computer systems validation in

regulated industry;

identify scope, work-plans, Deliverables, Acceptance Criteria

and Milestones for how the System will be Validated from de

velopment through retirement o the System;

include a high-level overview

o

methodologies and strategies

for data migration and conversion, solution testing and defect

management, and change management processes;

include a list

o compliance requirements

include a clear definition o roles and responsibilities;

include a high-level overview

o

the System, key functionalities,

architecture, business processes; and

identify the framework and processes necessary so that the Sys

tem remains in a Validated state post go-live.

(the Compliance and Validation Strategy ).

(d) Risk Mitigation Plan. Risk assessment and related risk mitigation planning

falls into two broad areas: Regulatory and compliance related risks, and

Project related risks.

1. The Project Team will create a written risk mitigation plan (and

update such plan as the Project progresses) that will address

regulatory, compliance and Validation risks, reference the

Validation and testing requirements contained in the

Compliance and Validation Strategy and address all other risks

associated with the Project (the Risk Mitigation Plan ),

including:

(i) providing a high level evalution

o

the functions within

the System to determine the criticality and complexity

o

each.

(ii)

providing a justified, documented assessment o

business, technical and regulatory risks associated with

the System.

(iii)

providing an input to planning the Validation and

testing tasks (to be executed during the Global Build

Phase) to support compliance with Regulatory

Requirements.

25


26/137

(iv) enabling a compliance review prior to go

live.identifying and planning means to mitigate Project

related risks as separate tasks and activities.

(e) IQ/OQ. The Project Team will design plans, procedures, completion criteria

and other documentation so that IQ and OQ can be achieved during the ap

propriate subsequent phases of the Project.

2.3.11 Conference Room Pilot.

NYCDMS/1183869. 9

6110/11

a) As processes are identified, categorized and solutioned, the Project Team

will Configure a representative prototype to illustrate for business users the

key processes and scenarios within application environ

ment(s), based upon the Business Requirements (the Conference Room Pi

lot or CRP Instance ).

b) The CRP Instance to be used during the Global Design Phase will include

sample data and high-level business processes (no more detailed than Level-

3) where appropriate and where possible.

(c) Near the end ofthe Global Design Phase, the Project Team will conduct a

two-step Conference Room Pilot, identified as CRP lA and CRP-lB.

1.

2.

CRP lA.

i) For each major process area, the Project Team will con

duct CRP lA in the presence

of

business

process SMEs, business users, and other

stakeholders (the CRP Attendees ). The

CRP Attendees will have knowledge and familiarity

with the process area being addressed and

Business Requirements for their given process areas.

Using the CRP Instance, members of the Project Team

will walk the CRP Attendees through the Confi

gurations and business processes for each process area,

including Gaps already identified and the proposed res

olution of those Gaps. Where Localizations have been

identified, these will also be discussed.

ii) The Project Team and the CRP Attendees to

gether will determine whether the Configuration, busi

ness processes and/or any Gap resolutions

or

Localiza

tions are sufficient to meet the Business Requirements.

iii)

If

they are not, the CRP Attendees will provide

guidance and feedback to the Project Team as to what

would be acceptable.

CRP lB.

26


27/137

i) For those Gaps that remain unresolved after CRP-lA,

the Project Team will re-Configure the applica

tion, re-design the business processes and/or re-design

the proposed Gap resolution or Localization.

ii) The newly modified solution will be demonstrated a

second time to the CRP Attendees. These indi

viduals, together with the Project Team will determine

if the modified solution is acceptable, and if so the

Project Team will update the Fit/Gap Analysis with the

proposed solution. If further re-work is still needed,

this will also be documented in the Fit/Gap Analysis,

escalated as required, and, if approved, addressed dur

ing the Global Build Phase.

d) The Team will generate a report at the end

ofCRP lB

which sets forth the

results

of

the CRP, and update the Fit/Gap Analysis and all

of

the various af

fected design documents including and Localizations.

2.3.12 Data Management.

NYCDMS/1183869.19

6/10/11

a) Data Readiness Assessment.

1.

2.

3.

During the Global Design Phase of the Project, the Project

Team will conduct an assessment of the Data that is

expected to be converted from existing legacy systems into the

new System (the Data Readiness Assessment ).

The Project Team will design such assessment so that it:

i) may reasonably be used by to size the scope and

effort

of

the data cleansing and preparation activities;

and

ii) will provide a recommended approach to meet

data Transformation objectives.

The Data Readiness Assessment will profile the current sources

of Data, so that the Project Team can identify and

understand the characteristics

of

the Data that may

impact how the source Data can be mapped to the

System. The Data Readiness Assessment will determine:

i)

Data sources and volumes;

ii)

Data quality;

iii)

Data security requirements; and

iv) Data cleansing requirements.

27


28/137

NYCDMS/1183869.19

6110/11

b)

Data Design. The Project Team will conduct a data design effort that will

define the planned usage, definition, and values of data attributes within the

master file targets, which will include chart of accounts, employee master

file, product master file, supplier (vendor) master file, and customer master).

c) Data Management Plan.

1. The Project Team will develop a plan that will address any iden-

tified quality issues with Data prior to conversion (the

Data Management Plan ), including:

i) Identification of appropriate master and transactional

data to be transferred to the System (as defined and ap-

proved y

ii) Identification of the requirements for cleansing the

Data prior to loading it into the System;

iii) Identificationof tools necessary to facilitate the migra-

tion, cleansing and governance

of

Data;

iv) Identification of issues relating to data privacy and data

protection;

(v) Development of practices and procedures to guide the

required data cleansing effort;

vi)

Staffing requirements; and

vii)

Milestones related to the Data Management Plan.

d)

Data Governance Strategy.

1.

2.

3.

The Project Team will create a written plan for developing and

administering the policies for managing Data during and

after the System implementation (the Data Governance Strate-

gy ).

The Project Team will design the Data Governance Strategy in

an effort to meet both (A) enterprise Business Re-

quirements; and (B) business unit Business Require-

ments.

The key elements of the Data Governance Strategy are:

i) Data management policies, procedures and

standards that govern data quality; and

ii) roles and responsibilities for carrying out the

approved policies, procedures, and standards.

8


29/137

NYCDMS/1183869.19

6110 /11

4.

The Project Team will develop a plan to describe the means by

which ata originating from and used

by

different sys

tems running concurrently as the result

of

a phased rollout will

be managed to provide for on-going business operations after

ata is loaded into the System.

(e)

ata

Conversion Strategy.

1.

2

3.

The project Team will develop a strategy to successfully com

plete data conversion required for the implementation with re

spect to all data including new and legacy data conversion re

quirements ( Data Conversion Strategy ). The key elements of

the Data Conversion Strategy are:

i) Identification ofmaster and transactional data to be

converted into the System;

ii)

Conversion approach (manual vs. programmatic);

iii)

Identification

of

tools to

be

used

by

the Project team to

convert and manage Data;

(iv) Convers ion process activities and the steps required to

allow the Data to be converted

and

loaded into

the System test instance;

(v) Business rules;

(vi) ata mappings;

(vii) Transformation rules; and

viii)

ata

Validation strategy to confirm that the

ata is appropriately converted into the applicable

Software (per Section 2.3.10) .

The Project Team will develop a strategy for retirement of

ata

from legacy systems, which is not intended to be

converted and transferred into the System (the Data Archiving

Strategy).

The

Data Conversion Strategy will:

i) Distinguish what is master data and what is

transactional data, and establish processes

to

manage

each;

ii) Minimize the need for costly rework and repeated set

up and Configuration

of

instances

associated with conversion errors;

29


30/137

iii)

Identify and resolve) the majority of potential

conversion issues prior to the actual mock conversion

execution;

iv) Provide for backup of existing data prior to conversion;

and

v)

e

based on the Functional Specifications.

2.3.13

Legacy Systems and Running

Old

and New Systems Concurrently.

a)

The Project Team will develop a detailed plan for supporting multiple

technical landscapes e.g., some facilities on legacy systems vs. new System)

including business process implications and an strategy, which

include roles and responsibilities, contingency plans, help desk hours and

staffing.

b)

The Project Team will develop a detailed data management plan describing

the means by which Data originating from and used by different

systems running concurrently as the result

of

a phased System deployment

will be managed to provide for on-going business operations

including plans for supporting customers, suppliers and employees using old

and new systems concurrently.

c) Legacy System Retirement Planning.

1.

During this Phase of the Project, the Project Team will make

recommendations regarding how legacy systems whose functio

nality will be replaced by the System, will be retired, including:

i) How

Data contained in such legacy systems will

be

cleansed, converted and transferred;

ii) How

the legacy systems will be prioritized for shut

down, as conversion occurs;

iii) How

the legacy systems will be retired and taken out

of

operation;

iv) Consideration ofwhether a parallel run strategy is ap

propriate; and

v) How Data not converted will be archived and

made available to for on-going use.

2.3.14

Reporting and Business Intelligence BI) Strategy.

NYCDMS/1183869.19

. 6110/11

a)

will develop and submit to for its review and approval, a written

Business Intelligence strategy and architecture that is designed to deliver im

proved management reporting and facilitates evidence-based decision-

30


31/137

making (the Reporting and Business Intelligence Strategy or Reporting

and BI Strategy

.

b)

As part

of

this effort will:

1.

2.

3.

review current approach to Business Intelligence;

evaluate existing

I

tools and applications; and

identify Business Requirements that relate to Business Intelli

gence.

(c) Based on the Business Requirements, will recommend, and upon

approval, design a Reporting and Business Intelligence Strategy, archi

tecture, and approach, which will include:

1.

2.

3.

4

Collecting the desired analytics and reporting requirements for

each business process;

Defining which reporting and BI tools will be used within the

System;

Recommending the proper balance between standard reports

and self-service analytics; and

Assessing the adequacy

of

prepackaged reports and BIIDW ap

plications within the applications.

d) will also recommend any necessary Software tools and work

that may be necessary to accomplish the approved Reporting and

Business Intelligence Strategy.

2.3.15 Reports, Interfaces, Conversions, Extensions and Workflows (

NYCDMS/1183869.19

6/10/11

(a) Development Strategy. During the Global Design Phase, the Project

Team will design and document a strategy for the development

objects (the Development Strategy). The guiding principles for

the Development Strategy will provide for:

1

2.

3.

4.

the design objects that will utilize supported

tools and technologies;

objects that will

e

capable of being reused (with rea

sonably appropriate retrofitting)

n

later upgrades of the System;

the design objects will utilize the latest appropriate

technology, as agreed to by for extending applications;

the design of conversion programs (including those for master

data) which can be leveraged for future Acquisitions;

31


32/137

5

6.

the creation of templates for technical design documents for

SO related extensions; and

the establishment of rules for development which will:

i)

attempt to minimize the number

ii)

take into account current technologies such as Service

Oriented Architecture (SOA), XML Gateway, Business

Events, BI Publisher, Applications Framework

(OAF), Applications Development framework (ADF),

Approval Management Engine (AME) etc.; and

iii) comply with current applicable standards in-

tended to facilitate upgrading to future ver-

sions of

b) The Project Team will prepare a list required for the System to

meet the Business Requirements, together with Functional Specifications for

each identified object ( Listing ).

2.3.16 Standard Operating Procedures (SOPs) and Templates.

a) The Project Team will develop a list of documents which will allow individ-

ual Sites to prepare for and perform the implementation of the Sys-

tem, including:

1.

2.

Identification of global SOPs to be developed during the Global

Build Phase; and

templates to detail how the System will be deployed to each

Site.

2.3.17

Deployment Strategy.

NYCDMS/1183869.19

6110

/11

a) Definition.

1.

2.

The Project Team will use methods which may include conduct-

ing workshops for the

joint

Project Team, to determine the ap-

propriate way to implement and deploy the System throughout

the Sites, including how legacy systems will

be

incorpo-

rated or retired.

Based

on

the outcome

of

the work performed pursuant to sub-

section (1) above, The Project Team will develop and submit to

for its review and approval, a deployment strategy doc-

ument for the global System implementation that is cost-

effective and takes into consideration the Project Objectives

(Deployment Strategy ).

32


33/137

b)

Minimum Requirements. The Deployment Strategy will, at a minimum in

clude the proposed location and timing o implementing the System on a di

visional, regional, process, modular or other basis, as required by

identify the location o the Pilot; and describe the sequence and the detailed

plan for physically implementing the System at applicable Sites.

(c) Additional Requirements. The Deployment Strategy will also include:

1.

2

3.

4.

5

6

A statement describing System deployment objectives,

including, without limitation, minimizing disruption to

businesses, risk mitigation, and contingency planning;

A plan for staging and sequencing System functionality across

the Sites;

List o viable staging and sequencing scenarios;

The location and timing

o

the Pilot Site deployment;

Documentation

o

the rationale for the inclusion or exclusion

o

scenarios; and

A high level time-line and staffing plan for deployment across

all Sites and facilities.

2.3.18 Localizations.

(a) During the Global Design Phase, the Project Team will identify and list the

required Localizations for North America and identify additional Localiza

tions that are known for the remainder

o

Sites.

b) The Project Team will summarize the Localizations by Site. During

this Phase, the Project Team will write Functional Specifications for all

North American Localizations.

(c) Functional designs will also be written for any Localizations outside o North

America that were identified during the Global Design Phase.

t

is expected

that additional Localizations may be discovered for Sites outside

o

North America in the future and they will be addressed and designed in sub

sequent deployment phases o the Project.

2.3.19

Implementation Plan and Estimate.

NYCDMS/1183869.19

6/10/11

(a) At the end o the Global Design will use its methodologies and

estimating tools to refine its previous estimates and deliver to for its

review and approval a plan for implementing (from Global Build through the

Deploy and Support Phases) the System (Implementation Plan and

Estimate ), including:

1.

Schedule;

33


34/137

2.

Resource estimates;

3. Milestones;

4. Deliverables; and

5

Cost estimate, in accordance with Section 10.2.1.

b)

will submit the revised Implementation Plan and Estimate to

upon completion of activities in the Global Design Phase (but in such a

manner as to avoid unnecessary delays in transitioning to the Global Build

Phase).

(c) The revised Implementation Plan and Estimate must be written in such a

manner that a reasonable service provider would be able to understand and

could use the plan as a basis for implementation.

2.3.20 Organizational Change Management (OCM)

NYCDMS

/1

183869.19

6/10/11

(a) During the Global Design Phase, The OCM Team will finalize the OCM

Strategy and the Organizational Transformation Plan and execute the tasks

and prepare the Deliverables called for during this phase pursuant to Section

3.

b)

Training Strategy and Planning.

1.

2.

3.

4.

During the Global Design Phase, The OCM Team and the

Project Team will develop a Training Strategy that addresses the

learning needs of each impacted stakeholder group, including

super users (as designated by trainers, end users and

support staff (the Training Strategy ).

The Training Strategy may include consideration for conducting

a training simulation, including pre-configured laptops, desk

tops, pre-loaded data, role based demo scripts, demo portal

access for users and pre-defined roles.

Needs Assessment. The Project Team will assess the various

training audiences impacted by the Project and use this data to

appropriately define learning needs, understand business

unit and geographical differences and deliver a document

detailing the results of such assessment (the Needs

Assessment).

Initial Training Plan.

he

Project Team will provide a high

level approach for delivering end user training, which includes

the Training Strategy, Needs Assessment, plans for design and

development of training documentation and curriculum, and

requirements for training related to deployment and Post

Production Support activities (the initial Training Plan ). The

34


35/137

Training Plan will be updated with more detail during the

Global Build Phase.

2.3.21 Planning for Production Support.

a) During the Global Design Phase, the Project Team will:

1.

2.

3.

document the initial high-level Ongoing Production Support

Plan pursuant to Section 2.6.4 c)l,

document the requirements for the Center of

Excellence;

plan for ongoing production support mechanisms; and develop

processes and rules for approving, designing, testing and dep

loying changes to the Production System.

2.4 Global Build Phase.

2.4.1 Overview: During the Global Build Phase, the Project Team will perform the Services

required to Configure and build the System to satisfy the Business Requirements in ac

cordance with the Project Plan.

2.4.2 he Services that the Project Team will perform during this phase as further outlined in

more detail in the remainder of this Section below) include:

NYCDMS/1183869.19

6110/ll

a) Deploying and qualifying the Technology Architecture as designed in the

Technology Architecture Strategy;

b) Installing the required Software applications both and non-

applications) in accordance with the Application Architecture;

c)

Deploying and qualifying the required database instances as set forth in the

Database Instance Strategy;

d)

Designing and developing objects identified during the Global De

sign Phase in accordance with the Development Strategy;

e) Designing and developing Localizations identified during the Global Design

Phase;

t) Designing and documenting all Detailed Business Processes that are neces

sary to satisfy the Business Requirements;

g) Configuring the System and confirming that the System Configurations are

in accordance with the applicable specifications and Business Requirements;

h) Performing defect resolution, as appropriate to resolve any issues related to

errors or faulty code development;

i) Cleansing and preparing data to be converted and migrated to the new Sys

tem;

5


36/137

G Performing unit testing on objects, Modifications, Customizations

and Localizations;

k)

Executing the required Organizational Change Management activities as

called for

in

the Project Plan for the Global Build Phase;

(I) Executing the planned regulatory compliance and Validation tasks required

to be performed during the Global Build Phase;

m) Executing the Compliance and Validation Strategy and completing the tasks

and Deliverables indentified in the Master Validation Plan as required during

the Global Build Phase;

n) Updating and implementing the Risk Mitigation Plan(s) for both regulatory

risks and project risks separately;

o)

Updating the Reporting and

I

Strategy Document as required and perform-

ing tasks called for during the Global Build Phase relating to reporting and

I

activities;

p) Designing and documenting Test Plans and Test Cases required to be used in

the Testing Phase;

(q) Updating the Deployment Strategy as required and perform tasks called for

during the Global Build Phase;

r) Updating the Training Plan and Training Strategy as required, developing

Training Documentation and performing all other tasks called for during the

Global Build Phase in the Project Plan;

(s) Planning for legacy system retirement, running the System and the legacy

systems (legacy and new) in accordance with the Deployment Strategy;

t) Preparing the initial draft of the Cutover Plans for each Site which in-

cludes the Cutover Checklist for each Site in accordance with the

Deployment Strategy; and

u) Conducting one or more Conference Room Pilots (CRPs).

2.4.3

Design Development (including North America Localizations).

NYCDMS/1183869.19

6/

1 1

1

a)

Technical Specifications. will create detailed Technical Specifications

for each of the objects, sufficient to allow a reasonably competent

developer to develop the object so that it will meet its expected op-

eration (as defined by the Functional Specifications) in accordance with the

Business Requirements, including:

1 Technical Specification Templates;

2.

Guidelines specifying when languages other than American

English must be accommodated; and

36


37/137

3. Conventions and guidelines for code design, including those re

lated to object oriented standards, Service Oriented Architecture

(SOA) principles, and code reuse.

b) Develop and unit-test and identified Localizations.

1.

2.

3.

During this Phase, will develop and unit-test all required

objects and identified Localizations;

will develop and identified Localizations using

both onsite and offshore teams and resources;

will be complete when they have passed User Ac

ceptance Testing (which is scheduled to occur in the next Phase

o

the Project).

(c) Conversion and Interface Programs Documentation.

1.

2.

The Project Team will develop and document a detailed listing

and description

o

the data objects, conversion programs, and

interfaces required to be built to support the System ( Conver

sion and Interfaces Programs Document ). The Conversion and

Interfaces Programs Document will include:

i) Data synchronization requirements;

ii) Sources o all data elements;

iii) Specification

o

the programs that will extract data from

legacy systems; and

(iv) Details

o

the interface programs that are to be devel

oped, which will include the type o interface, messag

ing rules, messaging frequency, and field mapping.

will update the Listing so that it remains current.

d)

Unit Testing. will test the newly developed objects at their

smallest functional point to verify that the code meets its Technical Specifi

cations ( Unit Testing ).

2.4.4 The Project Team will Configure or design and develop Localizations required for the

North American deployment waves during the Global Build Phase and incorporate them

into the Production System. The Project Team will also Configure or design and devel

op known Localizations for regions outside o North America during the Global Build

Phase.

2.4.5 Roles and Authorization Specification. The Project Team will prepare a document that

describes (a) the procedures, policies and methods for creating user roles within the

Production System, and (b) detailed specifications

o

user roles and the privileges and

restrictions associated with each user profile such that role based security standards are

NYCDMS/1183869.

9

6110/

37


38/137

maintained (the Roles and Authorization Specification ), which will include the fol

lowing key activities:

(a) Establish administrative procedures for managing user roles and associated

authorizations for the System;

b) Define new user roles and authorizations for new and changed business

processes implemented in the System;

(c) Modify existing user roles and authorizations for new and changed business

processes implemented in the System;

d)

Define Acceptance Criteria o all user roles and authorizations for

Testing and User Acceptance Testing activities;

(e) Test new and changed user roles and authorizations in the System; and

f) Implement new and changed user roles and authorizations in the System.

2.4.6 Training Documentation and curriculum to be prepared during the Global Build Phase.

NYCDMS/1183869.19

6/10/11

(a) The Project Team and the OCM Team will create a training curriculum that

aligns with the OCM Strategy and details the profiles o the various business

roles in the future environment and provides a roadmap o the activi

ties that will be undertaken to reasonably equip end-users with the skills and

knowledge necessary to perform their jobs and achieve the key performance

indicators desired. The Project Team will update the Training Plan to in

clude:

1.

2.

3.

4.

5.

6

7

8.

Role profiles and descriptions;

Mapping

o

ob and security profiles to applicable business

processes, transactions, tools, and applications within the future

business environment and System;

Role-based training plans based on the above role mapping;

Training plans for each user and trainer;

Training workshop schedule and related logistics requirements;

Confirmation

o

a system to confirm training effectiveness and

maintain accurate training records;

Standards for the development

o

Training Documentation; and

Development

o

training feedback mechanisms and processes.

b)

The Project Team will create the training documentation based on the Train

ing Plan and Training Strategy and will include all materials, whether in writ

ten or electronic form, needed to reasonably equip trainers and end users with

38


39/137

the skills and knowledge necessary to perform their jobs and achieve the de

sired key performance indicators (the Training Documentation ).

(c) The Project Team will:

1.

2.

3.

4.

5

Prepare end-user role-based training courses (the training

curriculum) supported y realistic exercises and simulations;

Finalize the detailed Training Plan for training that will deliver

targeted learning to users based on their specific needs;

Incorporate the following into the Training Plan:

i) Courseware maintenance and change control processes

for process/system changes;

ii)

Ongoing infrastructure/technology requirements;

iii) Potential re-purposing of content for web-based

training; and

(iv) Ongoing training, inclusive of refresher training and

training for new hires and

jo

changes.

Training Documentation will include the following:

i) detailed role-based content that includes copies of

screens and the instructions for navigating both within

that screen and to other screens in order to perform de

fined work tasks, and

ii)

quick reference or pocket guides for the most common

ly used transactions.

Other documentation forms and tools will be utilized as agreed

y

the Parties.

d) The Project Team will develop processes that provide for continuous im

provement

of

training methods, documentation and trainers, and also develop

processes that determine whether users who have been trained are capable of

operating the System on a day to day basis.

2.4.7 Test Plans, Test Scripts and Test Preparation. The Project Team will prepare Test

Plans, Test Scripts and other related Deliverables, which will include industry standard

attributes, location of testing, resources, roles/responsibilities and testing tools. The fol

lowing elements will be included:

NYCDMS/1183869.19

6/10/11

a) Test Plans and Test Scripts.

1. The Project Team will develop a set

of

plans for execution

of

the various tests (including tasks and checklists) that are re-

39


40/137


41/137

NYCDMS/1183869.19

6/10/11

1.

2

3.

System Testing.

he

Project Team will create plans

for System Testing so that each developed compo

nent functions in an manner with the rest

of

the Sys

tem and individual modules, add-ons, or other separate parts,

when combined together, operate as required, and include test

ing for:

i) security/role based access and administration testing, as

well verification

of

any regulatory or compliance re

quirements;

ii)

all functionality as identified in the Business

Process and Localization design documents;

iii) back

up/recovery testing to verify that backup and re

covery procedures execute successfully;

iv) all interfaces to and non- systems e.g.

real-time, batch processing);

v) middleware within the System and all other

relevant to the System; and

vi) electronic exchange

of

information to external partners

e.g. customers, suppliers).

Performance Testing. The Project Team will prepare plans for

Performance Testing so that scalability, reliability and resource

usage ofthe System is able to withstand the estimated load and

include reliability and responsiveness for transactional and/or

reporting functions;

Stress Testing. The Project Team will prepare plans for Stress

Testing of the System using simulated peak system loads and

include plans for:

i) Loading data into the System to validate successful op

eration for extended periods of time and with high vo

lumes of data being accessed across the network;

ii) Simulating peak concurrent user volumes;

iii)

Documenting to show when the System begins to exhi

bit performance degradation;

iv) Assessing System scalability;

v) Implementing performance tuning measures, based on

the results ofPerformance Testing and Stress Testing as

required to meet the Business Requirements; and

41


42/137

4.

vi)

Verifying that System performance meets the Business

Requirements.

Regression Testing.

he

Project Team will prepare plans for

the following regression testing activities, so that any Modifica

tions, Customizations, and/or Configurations as required, do not

adversely impact the System as a whole:

i)

System functionality verification;

ii)

Reasonable assurance that any system bug fixes,

patches, or vendor related updates do not adversely im

pact the functionality; and

iii) Identification and creation of a set

of

test cases scripts

scenarios that are considered the minimum required, in

addition to the functions primarily affected, to execute

for any release moving forward.

2.4.8

Master Validation Plan

and

Regulatory Compliance. During the Global Build Phase,

the Project

eam

will execute the tasks and activities as defined

in

the Compliance and

Validation Strategy.

2.4.9

Entetprise Architecture: he Project eam will update and finalize the Entetprise

-

chitecture, as appropriate and with approval, so that it is complete and accurate

2.4.10

Cutover Plan.

he

Project

eam

will create the first draft

of

the Cutover Plan for each

Site which will include a Cutover Checklist for each Site). The Cutover

Plan and Cutover Checklist will

be

finalized

in

subsequent phases

of

the Project and are

more fully described

in

Section 2.5.7.

2.4.11

IQIOQ.

NYCDMS/1183869.19

6/10/11

a) he Project eam will execute the IQIOQ plans so that the environment s)

are prepared, Software successfully installed, back-outluninstall procedure is

prepared, and necessary interfaces, components, and systems

can be

success

fully init iated and operated for North America and for all other Sites

in later phases

of

the Project), which includes:

1.

2

3.

Creating and completing the IQIOQ documentation for the Sys

tem, which will consist at minimum,

of

a summary

of

the Sys

tem

and step

by

step instructions for IQIOQ execution;

Executing the IQIOQ according to approved procedure, and

providing documented evidence

of

successful Software installa

tion;

Verifying that backup and recovery procedures execute success

fully;

42


43/137

4.

5.

6.

7

Validating that System administration activities execute suc

cessfully;

Verifying that the test and production instances are mirrored and

all exceptions are documented

Successfully resolving any defects; and

Preparing a summary of successful installation, and submitting

same to for review, approval, and acceptance.

2.4.12 Conference Room Pilot s). During the Global Build Phase, the Project Team may elect

to conduct one or more additional Conference Room Pilots CRPs). Each successive

CRP will include more detail as Business Processes are designed and objects

are developed and incorporated into the CRP instance. The CRPs will be conducted in

the same manner as described in Section 2.3.10 e), except that business users will have

the opportunity to execute the processes and software tasks themselves rather than hav

ing such functio

Documents

ERP Best Practice Example 1