architect. collaborate. innovate. oracle openworld oracle otm – a road more traveled
TRANSCRIPT
Architect.Collaborate.Innovate.
Oracle OpenWorld
Oracle OTM – A Road More Traveled
2
Agenda
Greif Background
Presentation Overview
Executive Alignment
SI Partner Selection
Key TMS Program Components
Q & A
3
Presentation Overview - Background
Greif, Inc.
• The world leader in industrial packaging products & services
• Strategically positioned in more than 40 countries to serve global as well as regional customers
• The company provides extensive experience in steel, plastic, fiber, corrugated and multiwall containers and protective packaging for a wide range of industries
• Greif also produces containerboard and manages timber properties in North America
Business Issues Business Solution
• Decentralized transportation planning/procurement
• No current centralized standard TMS system to manage transportation spend
• Transportation spend data available only in aggregate
• Lack of transparency to detailed freight data at the SKU level
• Escalating fuel and freight costs
• High transportation cost had board-room visibility
• Autonomous business culture – resistant to change
• Multiple ERP’s
• Investigated solutions that would provide detailed freight information and allow for long term sustainable freight management, and achieve projected ROI identified in the business case
• Determined best option to control transportation spend was through Oracle OTM after an evaluation of multiple TMS applications
• Engaged Capgemini to assist with OTM design, integration and implementation
4
Presentation Overview
Our OTM implementation experiences and leading practices Where we focused attention Planning and preparation approach Hardware/software acquisition Team organization Understand where the “potholes” are What worked for Greif
What this is:
• Our shared experience of what went right and lessons-learned during our OTM design, integration and implementation
• A true representation of the good, bad, and the ugly
• Discussion of OTM implementation leading practices
What this is not:
• A consulting commercial
• A deep-dive into the project details…time does not permit
5
Gaining Executive Alignment
Clearly define goals and objectives including costs and benefits to obtain strong support at all levels of the organization
Doug
Develop A Business Case Create A Common Vision Gain A Mandate For
Change
• Benchmark what other companies are using to manage freight spend
• Understand needs of plants
• Clearly define the benefits of a TMS solution
– Real time transparency and visibility
– Centralized command and control
– Measurement
– Execution and Planning
– Standardization
• Define a set of cost reduction “buckets” and link to cost/benefit
• Link TMS vision to Greif’s overall vision and strategic plan
• Take the time to perform a detailed business case and clearly articulate benefits
• Obtain buy in and support not only at the senior management level but at the user level as well
• Obtain IT commitment and resources
6
SI Partner Selection – RFP Process
The Request for Proposal (RFP)
– Provide as much information regarding project scope
• Geography
• Business Units
• Integration
• Middleware, Hardware and supporting Software
• Current ERP systems and future vision of ERP’s
• Non-ERP integration points (carriers, vendors, customers, etc.)
• Timeline Provide a reasonable amount of time to respond to the RFP Require an oral presentation by each of the SI’s Require interviews of key team members proposed by the SI
• Cultural fit with Greif
• Experience with the OTM application and industry
The more complete your RFP, the fewer the cycles (and headaches) you will have to go through with your SI candidates
7
SI Partner Selection - Expectations
An experienced SI team and a good fit with your company’s culture are the foundation of success
DougWhat You Should Expect From The SI What You Should Expect To Contribute
• Cultural fit with your organization
• Pick the team, not the consulting company
• A “referenceable” track record with OTM
• Well rounded team (functional, technical and logistical expertise)
• Demonstrated ability to design, build and roll out the solution
• Solid methodology and template
• Full-time team members
• A “respected” set of subject matter specialists
• A flexible mind-set
• Commitment to achieve expectations within budget and timeframe
• Focus
8
SI Partner Selection – Team Structure
Consider changing team structure to coincide with project phases Design/Build/Test
– Peer-to-peer teaming to enhance knowledge transfer
Deployment
– Multiple teams to speed roll-out and maximize knowledge transfer
Assign team members full-time…part-time often equates to little-time
Assign your best staff– do not allow the project to become the “island of misfit toys”
Ensure full time IT resources committed to partner with SI resources on hardware, software, middleware design and installation
Transfer SI integration knowledge to future IT owner Transfer application knowledge to Logistics owners
Align your team to complement skill sets and project demands
Wave Teams for Facility Roll Outs“Home” Team
Engagement Sponsor
Greif
Project ManagersGreif
Capgemini
Engagement Executive
Capgemini
Lead Implementer
Greif
Wave Team 1Tactical Team Lead
(BIS )
Full Time
Integration Support
(BIS )
Part -time
Hardware Support
(BIS )
Part -time
TMS Analyst
Greif
TMS Analyst
Greif
Capgemini
Lead Implementer
Greif
Wave Team 2
Capgemini
Functional
Implementer
Greif
Wave Team 3
TMS Analyst
Capgemini
Lead Implementer
Greif
Wave Team 4
TMS Analyst
Capgemini
Functional
Implementer
Greif
BIS Implementation
Lead
Subject Matter Specialists
Engagement SponsorGreif
Engagement ExecutiveCapgemini
Project ManagersGreif
CapgeminiSubject Matter SpecialistsBIS Implementation Lead
Part -Time
Lead ImplementerCapgemini
BIS Team Lead Lead ImplementerGreif
Application ConsultantG- Log
Integration Support(BIS )
Part -Time
Lead ImplementerCapgemini
Lead ImplementerGreif
Technical ConsultantG- Log
Hardware Support(BIS )
Part -Time
TMS AnalystCapgemini
Functional ImplementerGreif
TMS AnalystCapgemini
Functional ImplementerGreif
9
Project Kick-Off – Our Approach
Plan what can accurately be planned and have post kick-off deadlines as placeholders for the remaining details.
Doug
Brian
Project Planning Project Governance Administrative Issues
• Create a jumpstart plan that coordinates the arrival of project resources
• Conduct interviews with key stakeholders in advance of formalizing plan
• Exercise due diligence when considering hardware and software procurement (e.g. rating engines, middleware, servers, etc.) and installation.
• Begin Change Management preparations – management and users
• Define issues management and escalation processes – keep it simple
• Develop status reporting requirements and documentation/template
• Meeting schedule for status and Steering Committee
• Create document storage/repository – redundancy is preferred
• Outline a version management procedure
• Outline a change control procedure – establish a Change Review Board
• Provide for security clearance and building access on day 1
• Set up a team room, printer and a shared drive
• Ensure appropriate network access throughout enterprise
10
OTM Design
Consider an End-to-End design with a Process Focus OTM design should not be limited to the application only OTM should be as seamlessly integrated into the workflow as possible Be aware of opportunities to leverage strengths from integrated platforms
Future state process design and development Engage the users, not just the “process knowledgeable” (Finance, Customer Service, Sales,
Logistics, etc.) Consider the overall lifecycle of the order in developing the future state Begin with the end in mind, but don’t assume you will get there in one phase Standardize processes as much as possible – target not less than 80%
Use of Automation Agents Agents should be used to enhance processes not become a process Limit the use of Automation Agents to safeguard system performance and minimize
maintenance requirements
The main thing is the Domain thing Solve the domain design on day 1 of design otherwise be ready for a series of compromises
System workflow does not represent the sum total of process design.
11
OTM Build
Data Loading Aggregate and clean the data early in the project (carrier rates, locations, items) Develop standard naming conventions to enhance data “understandability” Document the application set-up thoroughly Load all base data via CSV, even if it will be updated via integration Document the variation in each object type
Exercise due diligence in rates design and loading Rate loading can be a long and complicated part of the data load – plan for it Consider the need for multi-stop in rates design Document the rate design and standardize as much as possible Consider fleet pricing in the rate design (private and dedicated)
Caveats to consider Data must frequently be cleansed manually Standards must frequently be set for data entry and maintenance in the host system There are ALWAYS rates that exist outside of the electronic records or routing guides Contract rates don’t always cover ALL of the traveled lanes
Plan for extra time in the system set-up, data loading, and rates set-up
12
OTM Integration
Integration Strategy Ensure middleware and hardware due diligence performed and solution is chosen in tandem
with TMS solution due to critical linkage Strive for a data-rich integration and standardize naming conventions across systems Utilize user-configurable code conversion and look-up tables to harmonize integrated
systems and model business rules Develop functional maps that are as detailed as possible and allow sufficient time for
integration development. Ideally, co-locate the technical and functional teams.
Purity of Data Understand what system/database is the system of record for base data Don’t blindly trust that the source data is up to date Ensure that data are updated as frequently as changes are likely to take place
Understand the landscape Make sure that the integration developers understand the concept of domain structure and
where OTM data resides before coding
Do not underestimate the time and effort necessary for integration
13
Testing
Unit Test Ensure code conversion and look-up tables work as intended Review results with integration developers to head-off issues prior to E2E testing Double check field values to ensure proper mapping
End-to-End (E2E) testing All hands on deck to test Employ issues management aggressively and review daily (at least) Develop testing scenarios in advance and validate using future state Test process exception scenarios in addition to core process scenarios Ensure adequate time to fully test Develop additional scripts as the testing process results in new ideas and possible scenarios
to explore
Be extremely thorough and allocate sufficient time
14
User Acceptance Testing (UAT)
Understand what the ‘U’ in User stands for Level set expectations – make sure that the users know that the system is still not production
ready yet Strip down the menu and screen sets to the absolute minimum Give the users an opportunity to explore the system, make mistakes and provide input Listen to the users and be willing to spend extra time in explanation
UAT doesn’t mean everything is perfect Have the technical consultants and integration developers on the ready to make adjustments
and fix issues – builds credibility among users Provide real-world scenarios for the tests (day in the life) Make sure that exception management procedures are discussed and explored as part of the
testing Make sure that there is consensus regarding the viability of the process and that users don’t
make decisions because the use of the system is new or strange to them
UAT is about collaboration and feedback…not perfection
15
The Go-Live
Develop a Go-Live Checklist Develop a detailed plan that includes user involvement (and outside parties such as carriers) Ensure that the production environment is tested/certified well in advance Develop a recovery plan if the go-live must be aborted Develop an issues resolution and status review procedure Ensure that user-support procedures are in place and understood Ensure that an on-gong support staff are adequately trained to handle minor issues
Define “Acceptable” Develop and agree to the criteria for an acceptable Go-Live Make sure users agree to the conditions that constitute “stable” Post Go-Live stabilization does not mean on-going perfection in the operation of the
application but rather an acceptable combination of system/process performance and issues resolution
Go-Live is not an end point but rather a transition to another level
16
Summary
Our accomplishments Mobilized the team day 1 and lost no productivity Completed:
– 11 Integration Points
– 19 maps
– Used Generic Framework to facilitate new integration with ease
– Built comprehensive error management with facility to correct and re-process transactions in error
Top-to-bottom alignment of project objectives within Greif Kick-off to successful Go-Live in 21 weeks for 2 BU’s On plan and under budget.
Our lessons learned Technical architecture and hardware/software procurement should have been completed
prior to project start-up IT resource availability led to project risk – but mitigated Due diligence and more due diligence
17
Q & A