Cambridge Igcse Mathematics Extended Practice Book Example Practice Papers
ERP Best Practice Example 1
Transcript of 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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
10/137
-
8/11/2019 ERP Best Practice Example 1
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;
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
15/137
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
17/137
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
21/137
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
40/137
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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
-
8/11/2019 ERP Best Practice Example 1
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