| Bookshelf Home | Contents | Index | Search | PDF | |
Siebel Field Service Guide > Scheduling and Dispatch > Scheduling Administration >
Setting Up Service Regions
The geographic area of a service region is defined by ZIP Codes and geocodes. The Optimizer follows these rules for ZIP Codes:
- A service region can include more than one ZIP Code.
- More than one service region can include the same ZIP Code; this means that service regions can have geographic overlap.
CAUTION: If possible, avoid configuring more than one service region per ZIP Code. Field Service assigns a service request to a service region according to the ZIP Code of its account's address. If that ZIP Code is in more than one service region, the service request is not automatically assigned to a service region and a customer service agent must manually select a service region for it.
Geocodes and ZIP Codes
The Optimizer uses geocode data and ZIP Codes (or postal codes for international users) to identify addresses. Geocode data contains longitude and latitude coordinates for physical locations (for example, a customer site), down to minutes and seconds. The Optimizer can use data at any level of detail; for example, ZIP Codes or ZIP + 4 codes.
As a ZIP Code can cover several square miles, it is preferable to use ZIP + 4, which generally brings the accuracy to the level of buildings for businesses or to within a block or two for residential addresses.
The Optimizer, requires, as a minimum, ZIP or postal codes, country, longitude, and latitude. Five-digit ZIP Codes for the United States are shipped with your Siebel application's seed data. ZIP Code information resides in the data model table (S_ZIPCODE). Table 27 shows the six columns in this table.
NOTE: Where longitude and latitude values are the same for two locations, the Optimizer uses the Minimum Travel Time (see Service Regions View).
There are two ways to load data into the S_ZIPCODE table:
- Use the Siebel Enterprise Integration Manager. For more information, see Siebel Enterprise Integration Manager Administration Guide.
- Import data from Application Administration > ZIP Code Administration.
To import geocode data
- Navigate to Application Administration > ZIP Code Administration.
- Click the menu button and select Import from the drop-down list.
The Import wizard appears.
- Specify the filename containing the data to import and click Next.
- Complete the information, including field mapping for the data records.
Specifications for Geocode Data
There are several vendors of geocode information. Make sure to specify the following information in geocode data:
- Latitude format. North of the equator is positive; south of the equator is negative. The data is interpreted to six decimal places.
- Longitude format. East of the prime meridian (Greenwich, UK) is positive; west of the prime meridian is negative. The data is interpreted to six decimal places.
Siebel stores its latitude and longitude in the decimal degrees format, as this is the most widely used format and is easy to use for distance calculations (see the following example).
Most data sets are in decimal degrees; if not, use the following formula to convert it from the degrees, minutes, seconds to decimal degrees:
Decimal degrees = Degrees + (Minutes/60) + (Seconds/3600)
Example:
37 Degrees, 25 Minutes, 40.5 Seconds
= 37. + (25/60) + (40.5/3600)
= 37. +.416666 +.01125
= 37.427916 degrees
Data Cleansing
Address and ZIP Code accuracy are critical for a schedule optimization. Use of a data cleansing application, such as the Siebel Data Quality module, is highly recommended (see Siebel Data Quality Administration Guide).
Universal Time Codes
Siebel Field Service stores all times as Greenwich Mean Time (GMT). For display in the user interface, it converts GMT to the appropriate local time zone.
Scheduling uses the following time zones:
- The customer's time zone. Appointments are booked in the customer's time zone, which is assumed to be the same as the service region's time zone.
- The service center's time zone.
- The service region's time zone. Activities displayed in the Activity Gantt Chart on the Dispatch Board are in the service region's time zone.
- The employee's (field service engineer's) time zone. Scheduling ignores the employee's time zone and uses the service region time zone.
CAUTION: Activity times (for example, Earliest Start and Latest Start)1 must be specified in the service region time zone. If the dispatcher or service administrator is in a different time zone, the conversion to the service region time zone must be done manually.
Service Region Schedules
Each service region is assigned a schedule that the ABS and Optimizer use. This may be different than the schedule associated with each employee. Schedules are defined in Applications Administration screen, Schedules view (see Defining Schedules).
The ABS uses the service region schedule as a base, and then refines its choices of time slots based on the employee schedules (see Employee Availability and Schedules).
The Optimizer uses only the employee schedules.
Loading and Reloading Service Region Data
The Optimizer acts on the schedule for each service region. Booking appointments and optimizing the schedule for activities requires the following data:
- Schedules for service regions and employees
- Existing activities and appointments
- Service activities
- Service regions
- Employees
- Parts available to employees
- Scheduling parameters
- Service region parameters
- System parameters
- Constraints
- Time windows
- A cost function
To carry out scheduling quickly and efficiently, the server copies data from the database into memory caches, one for the ABS and one for the Optimizer. The ABS cache holds the time slots in the future, and the Optimizer cache holds the activities occurring over the next few days.
Since the information is cached, it must be loaded into the caches from the database when the service is started periodically to synchronize updates. Initial loading and reloading of data are automatic processes. The data for a service region is copied automatically to the caches each time the server is restarted, and manually by clicking the Load buttons; see Service Regions View. Repeat requests can also load service region data.
Since there are two caches, every night, information needs to move from the ABS (future) cache into the Optimizer (present) cache. For example, today is July 1st and the Optimizer horizon holds all activities from July 1 to July 7. The ABS horizon is defined as fourteen days, so the ABS cache holds from July 8th to July 15th. Note that both horizons are measured from the beginning of the Glued period. The end of the Optimizer horizon is set to the same calendar day (at midnight) as the start of the ABS horizon.
After it becomes July 2, the old, July 1 data is no longer necessary; it is in the past and is discarded. At the same time, the Optimizer horizon is still looking seven days out, so it needs to load the July 9 data into the Optimizer cache. However, before the data can be loaded into the Optimizer cache, it must be unloaded from the ABS cache. If it is in both caches at the same time, it could be changed in both engines simultaneously. Therefore, the activities and data for July 9 are released from the ABS cache, and then loaded into the Optimizer cache.
The ABS should always be reloaded before the Optimizer, so that there are no conflicts in scheduling between the ABS and the Optimizer. Carry out both reloads in the same day.
When a service region is being loaded, it is not available for requests. The request is returned with a return code.
At the first load of data from a service region, the Optimizer assumes that the data coming from the database was previously optimized. So while generating an initial solution, it tries to keep the assignee as well as the sequence of activities for each field service engineer. It also keeps the time stamp of this load in the cache.
1In the user interface, Earliest Start =No Sooner Than and Latest Start =No Later Than = Due.
| Bookshelf Home | Contents | Index | Search | PDF | |
Siebel Field Service Guide Published: 21 April 2003 |