www.rmoug.orgFebruary 20-22, 2018 | Westin Westminster Hotel | Westminster, CO

Join me at the RMOUG Training Days where I’ll be presenting

Cloud--Real Life experiences covering the Good, Bad, and Ugly

Bob Sachs, Solution ArchitectDavid Fuston, Technology Manager

Grant Thornton, LLP

GRANT THORNTONTECHNOLOGY SOLUTIONS

© Grant Thornton LLP. All rights reserved.

GRANT THORNTON, LLP

SPEAKERS

Bob Sachs is a certified HCM Implementation Specialist for both EBS R12 and Taleo with Grant

Thornton, Technology Solutions Group based out of Arlington, VA. He has specialized in HCM

implementations and business process changes for Oracle EBS R12 and Taleo since 1999, along with

integrations/interfaces of third party systems. He has been a technical author and speaker at Quest

RECONNECT13, OHUG, and other user group events.

David Fuston is an certified PM and Engagement Manager with Grant Thornton, Technology Solutions

Group based in Overland Park, KS, concentrating on strategic assessments, global process engineering,

governance controls, applications design and development, and portfolio management. His expertise is

in program oversight of Oracle Fusion Applications R10/11/12, EBS 11i/R12, and Hyperion

HFM/Planning 7/9. He has been a technical author and speaker at Oracle OpenWorld, ODTUG, IOUG,

OAUG, HEUG, and multiple Collaborate user group conferences.

© Grant Thornton LLP. All rights reserved.

Real Life Experiences across multiple HCM implementations/upgrades

Session Objectives

• Objective #1: Discuss the root causes of obstacles/problems encountered in multiple implementations, share common themes across all/multiple teams, how each issue was addressed/resolved, and what the lessons learned are about what can be done to prevent/minimize impact on future projects.

• Objective #2: Discuss the assessment of executive or business sponsor’s readiness to start the project, what we actually found during implementation, and accuracy of the assessment from a business sponsor/stakeholder viewpoint

• Objective #3: Discuss the Program Management Office and Steering Committee governance structure, along with what worked, what did not and where the PMO underestimated magnitude of the change necessary.

• Objective #4: Discuss the definitions and measurements for project success.

5

STAKEHOLDER PARTICIPATION

STAKEHOLDER PARTICIPATION

• Stakeholder Responsibilities– Strategic oversight, including risks and mitigation **– Scorecard Accountability for schedule, results, costs, and data

quality– Back filling team members on day-to-day operations to

maintain schedule, costs, quality, and process improvements **

– Final decision maker for escalated topics– Maintain organizational alignment for project benefit – Measurement logistics and accuracy **

• Change management– Consistency and repetition in message and content **– Scope Change Management ** – Vision and Thought Leadership – Support and deliver commitment for people, process, and

technology changes– Project/program repository **

** lessons learned apply here

Stakeholder responsibilities

• SITUATIONS:

– VP of HR added to project sponsors when fellow executives realized that they were missing structural/architectural design integration considerations

– HR tribal knowledge not documented in "AS IS" process diagrams, and now being processed as change orders

– HR-BEN testing scripts not tied to business requirements

– Data translations, derived data calculations, massaged data, and inserted missing data makes for a confusing data quality discussion for reporting

Stakeholder responsibilities (continued)

• LESSONS:

– Standardized measurements across teams/groups/locations enables progress reporting using same definitions, same testing methods, and allows accurate progress comparisons over time

– Identification of critical reports early in discovery process drives data field verifications, data scrubbing requirements, aligns configurations, and dramatically reduces risk

– Business sponsor/stakeholder recognition overcomes multiple contentious issues if he/she continues to reward appropriate behavior in public

– Stakeholders must be active and visible

9

STRATEGIC OBJECTIVES AND PROJECT MANAGEMENT TOOLS

STRATEGIC OBJECTIVES

• Executive consensus re: business justification

– GT Project Readiness Assessment**

• Internal Appropriation Request

• Project Charter Document

– Absolute, nice to have, wish list requirements

– Measurements of Success**

– Progress Tracking tools**

• To Be Process Definitions

– Data Needs Analysis

– Reporting Needs Analysis**

** lessons learned apply here

Common Oracle PROJECT CHARTER Scenario

• SITUATIONS:

– Multiple executive project sponsors/stakeholders are required since projects cross departments, functions, groups, and locations

– Project funding has a built-in assumption regarding both risk and spending tolerance

– Project sponsors all agree on top 5 objectives ("What"), but have not discussed the "How" details

– Reality is that project management tools focus on process and data flows, not tribal knowledge, information silos, nor people management

– Reality is that putting in an ERP system requires new thinking on data relationships, logical business requirements, who does what in revised process flows, and sharing information.

Common Oracle PROJECT CHARTER Scenario (continued)

• LESSONS:

– Change Management is about all three pillars together--people, processes and technology

– Change Management needs its own funding budget inside appropriation request

– Re-engineering several core business processes objective is not necessarily consistent with controlled spending caps nor reducing risk

– Sponsor/stakeholder inconsistencies are costly in both time, money, and rework.

– Workloads and functions will shift between departments!!

Common Oracle Cloud Reporting Scenario

• SITUATIONS:

– ERP/HCM team has belief that basic reporting will be provided by out-of-the-box standard reports, XML/BI Publisher, or OTBI dashboard

– ERP/HCM team believes that Cognos, OBIA, Hyperion, etc. could be installed later for more complex reporting

– Reality is that neither assumption is correct

– Reality is that putting in ERP/HCM system without planning for reporting is like building a house without considering plumbing or electrical connections

Common Oracle Cloud Reporting Scenario (continued)

• LESSONS:

– If you do not take the time up front to gather and plan for the reporting requirements, you may not have the information available when you need to access it

– Planning ahead means performing a "reporting needs analysis"

– Incorporation of reporting requirements into ERP/HCM applications design and configuration

15

TEAM STRUCTURES & TIME MANAGEMENT

TEAM STRUCTURES

• Team Design– Representative balance across the process flow on each

team**– Enterprise wide Process flow thought patterns– Data analysis and processing logic capabilities**– Team player attitude versus individual contributor– Soft people skills/communications– Roles and responsibilities**

• Inter-team Coordination– Progress tracking tools (time, schedule, resources, updates)

**– Shared pool resource constraints– Data quality– Governance and oversight reporting**

** lessons learned apply here

Team Design

• SITUATIONS:

– Process flow knowledge is limited across departments to very few personnel

– Data usage knowledge is limited, and same data fields have different meanings to different groups/different reports

– Team lead was picked due to current supervisor role, not process flow knowledge nor people skills

– Team has not yet completed "AS IS" process flow diagrams and/or lacks functional documentation when project starts

Team Design (continued)

• LESSONS:

– Team lead needs process thought patterns above all else to make solution design complete and comprehensive

– Data Quality, relationships, values, usage and reporting is every team member's responsibility

– Basic Oracle Education of modules features and functionality for key team members is required before, not after, discovery begins in an implementation

Inter-team coordination

• SITUATIONS:

– Multiple teams have belief that shared IT pool technical resources are always available their services are needed.

– Program Management Office (PMO) and/or steering committee is perceived as asking too many questions, too demanding for weekly updates on schedule/scope, and requiring too much for business justification in written scope change docs

– Reality is that each team needs both functional SMEs, process BPAs, technical developers, IT support, and reportwriters from kickoff phase thru transition to PROD phase to ensure design balance, data quality, and business effectiveness

– Reality is that most team process decisions are based on who is the loudest, not what is the best process for the company

Inter-team coordination (continued)

• LESSONS:

– "Culture eats strategy for lunch" regarding inter-team cooperation

– Recommend that all client team members interview and accept the outside consultant (works both ways) before arrival onsite

Change management• SITUATIONS:

– Separate non-integrated repositories for functional, technical and process documentation

– MS office (Excel, Word, Access) documentation natively does not contain version control capabilities. Without version control, each iteration can produce some level of surprises, and sometimes new functionality

– "TO BE" process flows require considerable discipline and thought process, taking anywhere from 3-7 reviews before becoming stable, especially if re-engineering is involved

– The world is full of auditory, visual, and kinesthetic personnel, all with varying degrees of absorption of new concepts/materials in training/knowledge transfer

– Scope changes, data quality, modifications to native functionality, and resource constraints are all deadly threats to a project success

– Resistance to change generally originates with fear of unknown, and can be overcome to a large extent by "what is in it for me" explanations and communications

Change management (continued)

• LESSONS:

– Change is our friend; treat change as if he/she were a friend; be the change

– Team Checkpoint gates are a necessary evil to ensure readiness for the next step

– Single project repository for all project teams (functional and technical) combined with version control and documentation standards enables maximum quality and training efficiency

– Personalizations to hide/mask/display data is a necessary evil in every project for data access control.

– Avoid customizations and/or offline processes at all cost, if possible. Recommendation is that any customization and/or offline process be justified by module lead and approved in writing by the steering committee

23

INFRASTRUCTURE

Control in Data Infrastructure and Testing

• Data Infrastructure– Code and Configuration freezes ahead of each testing cycle enable

repeatable and consistent testing results, and are especially useful in troubleshooting and comparisons

– Oracle environment(s) should contain enough instances to enable testing strategy & patching strategy over life of project

– Integration/interface testing generally requires special attention from IT support staff

– Security, access controls, and sensitive data will generally vary by instance during the life of the project

– Instance migration of objects, configurations, and security is an opportunity to introduce unintended consequences **

– Data loading from scratch for each instance can be burdensome unless some level of cloning or data refresh is used **

– Some functionality requires at least shared access to other modules due to technical data integrations/schemas under the covers—this is normal and generally does not affect licensing

** lessons learned apply here

DATA Infrastructure and testing controls

• SITUATIONS:

– Clone from Prod combined with latest development code freeze and a data refresh produces inconsistent or unexpected results from previous testing

– No comparisons/verifications between instances was completed before instance was approved for use by end users

– Data conversion methods were changed between instances and now data integrity is being questioned

– Regression testing is generating fails in tests which previously had passed

– Restore from backup is a 2-3 week process from Oracle Support and not recommended

– OracleOps will not promote/clone an instance unless patch levels are the same

DATA Infrastructure and testing controls (continued)

• LESSONS:– Internal controls and standardized methods can greatly improve

instance creation and verification reliability

– Documentation created by one professional must be used by separate professional to ensure that the documentation quality is complete and accurate to produce reliable results

– Testing strategies, methods, and test scripts need documentation updates after each testing cycle in the checkpoint gate review

– Service level agreements can help set expectations among diverse groups

27

SKILLSETS AND TRAINING

SKILLSETS AND TRAINING—FUTURE STATE

• Skillsets– Identification of "TO BE" roles post go-live, and mapping of

current team members to these roles **» Identification of current skillsets and skill levels using

standard industry definitions, including any remedial efforts unassociated with project

– Identification of quantity and level of skill gaps ** » Master list of options to close the gaps

• Training– Identification of certification level or knowledge mastery

required for each position/role/job **– Training class matrix with headcount, costs and training

delivery options for each gap for project approval– Schedule and travel logistics plan for all approved training

** lessons learned apply here

Skillsets and training – Future state

• SITUATIONS:

– VP of HR has identified skill gaps outside of the project as a result of a strategic succession planning exercise

– HR has controlled budgets manually regarding training approval requests in the past, and now faces native workflow functionality with CFO approval, including training approval requests

– HR has created new positions with new skill requirements in new system to overcome a backlog of pending updates not yet processed in the legacy system

– CFO has approved new spending approval levels and other changes for certain management positions in supervisory hierarchy

Skillsets and training – future state (continued)

• LESSONS:

– "AS IS" and "TO BE" skill assessments need to be accurately correlated to positions using industry standard definitions

– Training quality must be an active consideration in change management planning

– Training spending and costs should be based on magnitude of process/people/technology changes

QUESTIONS

31

GRANT THORNTONThank you & Contact info:

Bob Sachs

Manager/Solution Architect

Technology Solutions – ERP

Work: (703)-637-4183

Cell: (202)-577-5860

Email: Bob.Sachs@us,gt.com

David Fuston

Technology Manager

Technology Solutions – ERP

Work: (913)-272-2780

Cell: (816)-729-1033

Email: David.Fuston@us.gt.com