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 activity 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 28 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. For more information, 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 the Administration - Data screen > ZIP Code Administration view.

To import geocode data

1. Navigate to the Administration - Data screen > ZIP Code Administration view.
2. Click the menu button and select Import from the drop-down list.

   The Import wizard appears.

3. Specify the filename containing the data to import and click Next.
4. 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.

The Siebel application stores its latitude and longitude in the decimal degrees format, because this format is the most widely used and is easy to use for distance calculations, as shown in 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. For more information, 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 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) 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 the Administration - Application screen > Schedules view. For more information, 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. For more information, 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. For more information, see Service Regions View. Repeat requests can also load service region data automatically, using the Appointment Booking System business service. For information about repeating component requests, see the chapter on using the Siebel Server Manager GUI in Siebel System Administration Guide.

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.