NCOAUG Training Day March 3, 2003 Effectively Using Offshore Services Presented by Karen S' Janssen

1
NCOAUG Training DayMarch 3, 2003 Effectively
Using Offshore ServicesPresented by Karen S.
JanssenSenior Project ManagerUniversity of
Chicago Hospitals
2
Objective

• Provide and understanding of the offshore model
• Provide an understanding of the lessons learned
• Provide recommendations to organizations
  interested in engaging with the offshore service
  providers.

3
Approach

• Look at an Actual case study that used offshore
  services as part of the solution team
  implementing Oracle Applications at the
  University of Chicago Hospitals
• Share what we learned through our experience

4
Agenda

• Background Information
• Offshore Model Used at UCH
• Lessons Learned

5
Background
6
BackgroundUCH Profile

• More than just a hospital...
• Bernard A. Mitchell Hospital, primary adult
  patient care facility
• University of Chicago Children's Hospital,
  devoted to the medical needs of children
• Chicago Lying-in Hospital, a maternity and
  women's hospital
• Duchossois Center for Advanced Medicine, a
  state-of-the-art outpatient care facility
• The University of Chicago Physicians Group, a
  network of more than 600 University of Chicago
  physicians
• CareMed Chicago, a home healthcare organization
• Affiliated physicians offices located throughout
  the Chicago area

7
Background UCH Initiative

• Supply Chain Improvements Project
• Significant Cost savings within 3 years will come
  from enabling improvement in five areas
• Better contracting
• Product changes and standardization
• Better management of inventory
• Better tracking for proof of delivery
• Better evaluation of repair vs. replacement costs
• Achieve better efficiencies
• Improved ability to turn requisitions into
  purchase order.
• Integration between Accounts Payable and
  Purchasing
• Forced documentation through the use of required
  fields.

8
Background Implementation Scope

• Implement 8 Oracle R11.5.8 Application Modules
  Supporting Supply Chain
• GL Foundation
• HR Foundation
• Payables
• OM for Internal Orders
• Integrate with Supporting Applications
• Time and Attendance Integration
• Purchasing Cards Integration
• Optime Integration
• EDI Gateway

• Purchasing
• Internet Expense
• Inventory
• Internet Procurement

9
BackgroundDevelopment Scope

• This included 64 Development Solutions

10
BackgroundOur Challenges

• Limited Experience - Entry level Training and
  limited applicable implementation experience on
  Pivotal Applications key to Hospitals Operations
• Limited Resources - Limited number of trained
  technical resources who still had production
  support responsibilities
• Limited Time line - dictated by scheduling
  disruptions, busy season constraints and
  scheduling with external project dependencies
• Limited Budget - maximum project funds were
  established, committed and capped

11
BackgroundOur Solution

• Engaged with Oracle Consulting to address our
  limited experience and functional knowledge on
  mission critical applications
• Engaged with Oracles North American Offshore
  Resourcing Program to address our limited
  resources, that ultimately facilitated our
  limited time line and limited budget.

12
Offshore Model at UCH
13
OffShore Model at UCHCommunication Model
14
OffShore Model at UCHTeam Organization
15
OffShore Model at UCHDevelopment Process
16
Lessons Learned
17
Lesson 1

• Pick the right kind of work to send offshore
• Dont delegate critical path or solutions highly
  dependent on user feedback
• Do look for large volume work that can disappear
  off the radar screen for a couple of days,
  without major impact.

18
Lesson 1Continued

• Examples of Good Choices
• Modifications and Extensions of Oracle
  Applications creation or modification of forms,
  reports or programs (shell scripts, triggers or
  stored procedures (SQL, PL/SQL)) to cover a
  functionality gap.
• Interfaces - programs developed to move data
  between applications or systems. These are
  inbound and/or outbound online interfaces.
• Conversions/Data Migration - programs developed
  to perform a one-time upload of data into an
  application from a legacy system.
• Custom Development creation of new systems or
  subsystems with functionality not native to or
  based on current Oracle applications.

19
Lesson 2

• Assign a Technical Lead with strong technical and
  management skills as a dedicated project team
  member.
• Dont assume that activity of the offshore team
  is always apparent.
• Do drive and track both the progress of the
  onsite team and communicate well with the off
  shore team.

20
Lesson 3

• Due diligence to the definition and planing
  process is crucial.
• Dont assume that the project plan is an adequate
  format for communicating deadlines and
  dependencies identified in the project plan.
• Do create an isolated detailed development-only
  task plan and track against the detail.

21
Lesson 4

• Supporting both Onsite and Offshore System
  Availability impacts your backup window.
• Dont plan for normal backup schedules
• Do consider system availability requirements for
  both teams and proactively communicate exceptions.

22
Lesson 5

• Plan for and schedule frequent code drops and
  manage to the dates.
• Dont accept code in a big bang, all-or-nothing
  package.
• Do plan the code drops based on priorities and
  dependencies.

23
Lesson 6

• Establish Well-defined Coding Standards and
  Measurable Acceptance Criteria
• Dont just assume code matches specifications
  simply because it runs
• Do add both a QA Test and a Code Walk-thru Step
  into your plan once the code has been returned
  in-house and before you accept deliverable.

24
Lesson 7

• Ensure that offshore methodology is a fit for
  your organizations culture
• Dont just assume all the methodology mechanisms
  exist
• Do have the offshore provider give examples of
  their process mechanisms before you agree to
  engage

25
Lesson 8

• Plan for the potential of additional costs
  required to support the offshore model
• Dont assume that offshore resources are the only
  significant cost factors
• Do consider potential costs of telephony, network
  communications, travel expenses, resource
  facilities, cell phones.

26
Lesson 9

• Appropriately balance costs savings between
  onsite and offshore resources across development
  stages
• Dont assume that man-effort has been averaged
  across the development time line
• Do consider a shift in resource usage during
  appropriate stages.

27
Lesson 9Continued

• Example

Onsite 25 _at_ 100 25 of Cost Offshore 75
_at_ 25 75 Total Cost Savings 40-50
28
Lesson 10

• Have a contingency plan for your onsite
  coordinator
• Dont assume that in case of an emergency the
  individual can be replaced in a minutes notice
• Do proactively identify a replacement and ensure
  that the appropriate paper work is in order
  before the engagement begins

29
Lesson 11

• Communication is a critical success factor
• Dont rely simply on email and telephone
• Do setup a chat room and expect it to be visited
  twice a day, and setup and test network
  communications and telecommunications prior to
  the arrival of the first resource.

30
Lesson 12

• Negotiate a fixed price contract
• Dont assume that there is reliable time tracking
  to audit and control TE contract.
• Do have a good preliminary projection of your
  man-hour estimates so that you can effectively
  assess the the bid that is proposed.

31
Lesson 13

• Have well-defined procedures for issue tracking
  and resolution that includes offshore
  considerations
• Dont rely on template, spreadsheets and word
  documents as trackers.
• Do provide a tool with automation and write
  procedures that can be implemented, if possible

32
Lesson 14

• Select a vendor that has high Quality
  Certifications
• Dont assume that quality ratings are the same
  between providers
• Do look for providers that have reached highest
  Certification levels

ISO 90002000
33
Lesson 15

• Other Critical Success Factors
• Functional Specs - All requirements must be
  defined up front and documented clear and should
  be relatively stable.
• Connectivity - You must agree to some level of
  remote connectivity.
• Volume of Work -. Small deliverables require too
  many one-time setups (connectivity,
  communications, etc.) and the additional days
  offset the lower daily rate savings.