<INSERT CLIENT LOGO>

CoE Solution Design Guideline

Oracle Field Service

Client <Client>
Product Oracle Field Service (OFS) <version>
Created By <name>
Date Created <date>
Table of Contents
1 Introduction.........................................................................................................................3
1.1 Solution Design Document Purpose...................................................................................................................... 3
1.2 Glossary............................................................................................................................................................................. 3
2 Objectives............................................................................................................................4
2.1 Project and Customer Overview.............................................................................................................................. 4
2.2 Business Challenges..................................................................................................................................................... 4
2.3 Business Goals................................................................................................................................................................ 4
2.4 Current Operating Metrics/KPIs............................................................................................................................. 4
2.5 Current Operations (High Level)............................................................................................................................ 4
2.6 Expected ROI................................................................................................................................................................... 4
3 Proposed Systems Architecture............................................................................................5
3.1 Systems Architecture................................................................................................................................................... 5
3.2 Integration Architecture............................................................................................................................................. 5
3.3 Network & Security Architecture............................................................................................................................ 5
4 Proposed Business Processes (Use Cases).............................................................................6
4.1 Future Business Operations...................................................................................................................................... 6
4.2 Use Cases.......................................................................................................................................................................... 6
4.3 Expected System configuration (Major Functional areas only)..................................................................7
5 Project Timing, Assumptions & Risks..................................................................................10
5.1 Project Timing.............................................................................................................................................................. 10
5.2 Project Assumptions.................................................................................................................................................. 10
5.3 Project Risks & Mitigation....................................................................................................................................... 10
1 Introduction
In general, a Solution Design Document is supposed to provide the details of the proposed business solution for
<Client>’s implementation of Oracle Field Service (OFS). The SDD document should define “How” Oracle Field
Service is to be utilized to meet <Client>’s business needs.

This document is NOT intended to be a complete list of everything that should be in a solutions design document for
an implementation but rather a guideline on areas that are important to consider for a successful OFS
implementation. Most implementers will have their own style or variance in producing a solution design document and
often there are more granular details that will not be covered here. However, this document should provide a good
guideline of the areas to consider and the type of information needing to be captured in order to help insure a
successful implementation. These topics below are what the Oracle Center of Excellence will be looking for in a
solution design document to help insure a successful implementation.

The Oracle Center of Excellence will perform an expert review of the documentation and provide feedback and
guidance on best practices and optimal solution options that should be considered prior to actually performing actual
implementation.

1.1 Solution Design Document Purpose

The purpose of a SDD document is to describe <Client>’s business processes and “How” Oracle Field Service will be
utilized to meet the business objectives. The document does so by capturing requirements information in the
following areas: (this is not a complete list as each implementation will vary by customer)
 <Client’s> business objectives
 <Client’s> business overview – lines of business, number of technicians, Avg. number of activities,
geographical area, seasonality, etc.
 Business Processes (with flows) – via uses cases for both current and future
 Modules to be deployed
 System Architecture and Interfaces
 Solution Measurements, Assumptions, and Constraints
 OFS System functionality utilized
 Customer KPI’s and expected ROI

1.2 Glossary
Provide unique terminology (OFS or Client’s) description (if any) related to the project.
2 Objectives

2.1 Project and Customer Overview

Briefly describe the customer industry and the project, what will be delivered and the main benefits expected from the
customer with the OFS’s deployment. Please list the various OFS modules purchased.

2.2 Business Challenges

Provide an overview of the business challenges faced by the client that the OFS deployment is expected to address /
improve. Please provide challenges for each line of business (if multiple)

2.3 Business Goals

List the client’s business goals for this project as well as the critical success factors they will use to evaluate project
success or failure.
Example Business goals (not a complete list):
 Improve customer satisfaction by providing timely, relevant communication; shorter appointment windows;
increased on-time arrivals, and a consistent customer experience.
 Simplify and standardize business operations by reducing the number of systems, tools, reports, and touch-
points necessary to perform routing, dispatching, and capacity management.
 Increase visibility into third party (subcontractor, retailer) capacity and performance.
 Provide a comprehensive, up-to-date view of current Field Service operations.
 Improve operational efficiency through routing automation and optimization
 Assign more jobs to less technicians
 Reduce the number of no-show’s/cancellations, go-backs, etc
 Functional and Performance Measurements – List the functional and performance measurements the client
is hoping to achieve. These measurements should be mapped back to the business goals.

2.4 Current Operating Metrics/KPIs

Please provide Current Operating Metrics or/and KPIs values. If there is a significant variation in numbers for different
lines of businesses, activity types, regions, please provide separate numbers. Information to Provide here may
include: (this is not an exact or complete list as each implementation will vary by customer).
 Operating Locations (Countries, Districts, Regions, etc)
 Number of Mobile workers (within each line of business if multiple)
 Number of Dispatchers (provide average # of tech’s per dispatcher)
 Activity Volume (e.g. annual or daily number of activities)
 Jobs per tech (if there is significant variation, please specify high/low seasons values if applicable)
 Current Work Duration Statistics (e.g. average duration per activity type)
 Average travel cost/distance/time per activity (include differences for different transportation type [if exists])
 Percentage of customer no-show’s
 Percentage of go-back’s
 On-Time percentage
2.5 Current Operations (High Level)
Provide a high-level description of their current operations in order to understand how they are managing their field
service now. Please include a flow of the work, inventory, provisioning, exception handling, escalations, etc. Also,
please explain the utilization of contractors and how they are performing their work.

2.6 Expected ROI

Describe how the client will define success in terms of an ROI.
3 Proposed Systems Architecture
List each system utilized in the implementation and describes the roles and responsibilities of each system. Be sure
to specify the Activity master system.

3.1 Systems Architecture

Information to Provide here may include: (this is not a complete list as each implementation will vary by customer)
 Include the composition of the current systems, middleware, or other applications involved (Please Identify
expected Master systems of record [activity, inventory, resources, etc])
 Include all OFS modules being utilized in this implementation.
 Intended platforms for use with OFS: Mobile Devices, Operating systems, dispatcher hardware

3.2 Integration Architecture

Provide here a summary of the integration flow of all systems/middleware interacting with OFS. Please specify the
OFS API’s being utilized (you should also map these in the Use cases section below for each use case so that it is
clear which API is used for each use case). Also clearly document the functionality and responsibility of any
middleware/agent utilized.

Information to Provide here may include: (this is not a complete list as each implementation will vary by customer)
 OFS API Flow Design (associated with use cases below) – please specify method (REST vs SOAP) but
keep in mind that the Oracle recommendation is to always use REST API methods if possible.
Key areas:
- Data Warehouse [Using Events API or Daily extract or DBAAS/BICS/etc…]
- Real Time Reporting [Ex: using Events API, ICS, etc]
- Activity Booking Options [ActivityBookingOptions vs FindMatchingResource, etc…]
 Integration flow dependencies (Ex: Validations required prior to allowing continued work flow)
 Integration response time requirement [describe parallel vs sequential API processing]
 OFS Mobile Plugin Framework utilization

3.3 Network & Security Architecture

Provide here a summary of the network architecture including VPN, Single Sign-on, Network access from field, other
security concerns (Ex: PCI DSS, etc.)
4 Proposed Business Processes (Use Cases)
The following section describes the targeted business processes that are expected to be in place once OFS is
implemented. The contents within this section describe how the implemented solution will work for the client.

The intent of this section is to provide a review of the business process flow (within use cases) for each functionality
expected within OFS. Also make sure to reference OFS API calls utilized for each use case if relevant.

4.1 Future Business Operations

Provide a high-level description of their future operations utilizing OFS in order to understand how they will manage
their field service. Please include work flow, inventory utilization, provisioning, booking, capacity management,
validations, exception handling, escalations, and intended utilization of contractors.

4.2 Use Cases

Example of use cases that should be provided. This is not expected to be the complete set as each implementation
and customer is different. Please specify API calls including Outbound messages notifications within the Use Case
Description.
 Create Activity (via Integration and Manual)
 Update Activity
 Cancel Activity
 Assign (Manual Route) Activity
 Start Activity
 Complete Activity
 Not Done Activity
 Suspend Activity
 Reschedule Activity
 Booking Process
 Managing Quota/Availability
 Equipment (Inventory) Management
 Outbound Notifications/Messages
 Automatic routing (Describe the business goals to achieve and exceptions)
 Parts Catalog
 Collaboration
 Technician Self Assignment
 Travel area definition
 Reporting
 Repeated activities
 Long Cycle/Multi-day activities
 Overnight work
 Activity Linking [if multiple links utilized to create chains please clearly describe the business need and
expected link structures to use]
 Data Warehouse
  Remote area or unique skill job assignment [additional routing constraints]
 How to handle Backlog
 Jeopardy Management (how to track alerts and how to handle exceptions, point the steps to other use
cases. It helps to add context on how to handle the assignments)
 Teaming resources
 Locations
 Managing of non-completed work (End of Day process)

4.3 Expected System configuration (Major Functional areas only)

The intent of this section is NOT to provide details for all system configurations but rather explain expected utilization
of key concepts and functions that can have a larger impact on the implementation. It may be good to provide a brief
description on how you expect the configuration to meet key business objectives. For example: Routing plans are
normally finalized during actual testing and not Solution design; However, you can provide high-level
expectations/intentions such as Activity cost differences, Field Resource cost differences, expected results of
Immediate or Urgent routing [and how to identify these], etc…
 Travel Configuration
o Activity Coordinates – Please specify will customer provide activity coordinates - latitude, longitude,
(Greenwich Geographical Coordinates in Decimal Degrees), or the customer is going to rely on
OFS geocoding. Note: Oracle HIGHLY recommend for the customer to provide coordinates as part
of activity details. This allows customer to properly control accuracy activity location and insure
proper travel time estimation
 Travel Keys (configured on Configuration->Statistics)
 Activity Travel Key
o Properties - Please specify configuration of activity travel key. Please
specify if there are some activity groups that will not have some of these
properties populated upon activity creation. Note: Oracle recommended
to have your travel key area to be similar in size as to what would be
expected average travel in a day [separate by line-of-business if
different]
o Number of combinations – please provide expected number of different
travel key combinations. If different by travel key please specify.
 Resource Travel Key – please specify configuration if any. Note: Resource travel
key should only be used when a customer is utilizing significantly different travel
approaches in the same area (e.g. walking, bicycling, public transportation, car,
heavy tracks, special equipment, etc. small tracks and vans e.g. do not consider
to be different enough).
 Travel Areas. (Configured on Configuration -> Work Zones). Travel areas are used to
group travel keys. Proper configuration of travel areas optimizes system performance and
guide system how to improve travel time estimation accuracy. Normally single travel area
should correspond a capacity/routing bucket (e.g. the customer local branch)
 Work Zones Key – please specify work zones key configuration
  Expected number of Work Zones
 Expected number of Travel Areas
 Straight Line distance travel time estimation method parameters (configured on
Configuration->Statistics). Please specify values that are going to be used for following
parameters. Oracle recommends always start with the default settings and periodically
check system recommendation that will appears as soon as system starts to learn.
 Coordinate Calculation Weight – default setting is 0.5 (Use equally)
 Airline distance Speed – default setting is 66 km/h
 Departure/parking time – default setting is 8 minutes
 Duration Configuration
o Please specify, for each activity type, is learning expected to be used to estimate activity duration
or OFS should always use duration specified upon activity creation (configured on Configuration-
>Activity Types).
 Oracle Highly recommends to use learning for all individual activities unless it’s duration
defined for a specific case (e.g. Meetings) or by a regulation (e.g. Lunch Breaks).
 Oracle highly recommends to specify external duration estimation, if available, even for
activity types that are going to use learned duration.
o Activity Duration Key – (configured on Configuration->Statistics) please list target activity duration
key configuration
 Please list all included properties, length and function. Oracle suggests to use “Case
sensitive” for all digit only and lookup codes properties. It might have sense to use “Case
insensitive” (i.e. lower case) function for manual input properties.
 Please provide number of combinations - please provide expected number of different
Activity duration key combinations.
o Resource learning (configured on Configuration->Resource Types) - please specify approach for
each different group of technicians (Resource Type).
 Personalized Learning - Oracle recommends to use personalized duration estimation
profile for all technicians unless different is required e.g. by a regulation or a contract
 Impact to company profile – Oracle recommends only allow to contribute technicians to
company profile only if the company has a way to contribute their compliance. (e.g.
usually in-house technicians are expected to be included, and contractors are often not
included)
 Skip first days – Oracle recommend to exclude at least first working week (5 days) to let
the Technicians get used to the system. This value may need to be increased if the
company is migrated e.g. from an offline only or a paper-based processes.
 Routing approaches – please describe all various routing approaches that are expected to be needed.
Please provide information including, but not limited to the following:
o Specific Business Goals that routing plan (group of plans) is intended to achieve and metrics that
routing plan is expected to optimize
o Selected routing approach and related items
 Urgent
  Settings of Activity Priority (Configured on Configuration->Business Rules)
 Immediate
 Specify filter settings used for the immediate routing
 Describe how it’s planned to achieve future optimization of immediately routed
activities
 Bulk
 General – please identify activity priority groups, describe specific requirements
for each of these groups if there are, and specify filter settings going to be used
to select each of these groups.
 Please specify if there is a filter that is going to have different settings in different
filter groups (activities form bucket, activities in existent routes, non-scheduled,
non-scheduled preassigned).
 Initial – please specify how far in advance activities are going to be assigned.
 Intraday – please specify % of the same activities and % of the same day
cancelations, how intraday changes are going to be managed – manually, e.g.by
recurrent routing, with which interval, etc...
 Re-optimization – if used, please specify re-optimization filters settings and re-
optimization penalty.
o Sequential Routing Runs – please specify whether sequential routing plans are going to be used or
not. Oracle suggest to combine sequential routing plans into a single one with multiple filters to
handle the needed differences. Usually this results in better overall cost optimization
o Use of Activity links - please describe whether activity links are going to be used, how and what are
the expectations. Please specify are links used to link a single day or multiple days project.
o Resource preferences – please describe whether resource preferences are gouging to be used or
not, what are the expected effect of each of the preferences
o Work skills/Work zones levels – please describe whether different levels are going to be used or
not, what are the expected effects of using different levels
 Provide brief description of hierarchy tree (identify quote/capacity buckets, routing buckets, contractors,
LOB’s)
 Please briefly describe Quota/Capacity/Booking design and which of OFS features are going to be used to
address these needs if any (e.g. Find Matching Resources, Get Activity Booking Options, Quota, etc..)
 Map Service provider (Google vs Baidu(百度) vs Oracle) to be used, if any.
5 Project Timing, Assumptions & Risks

5.1 Project Timing

Provide a high-level schedule for the project time line for the project stages: Engage, Focus, Refine, Enable, Live
Operate. Indicate if and how resources and / or function may have a phased deployment.

5.2 Project Assumptions

List key assumptions on which the project and its schedule are based.
 Functional Assumptions
 Technical Assumptions
 General Assumptions

5.3 Project Risks & Mitigation