AltText
☰

IMPLEMENTATION GUIDELINES


The implementation of the SOTS process is straightforward and can be accomplished with a minimal amount of effort. The key to successful implementation lies in the Customer (Service Provider) and the Organization (Supplier) coming to agreement on the data exchange details prior to formal adoption of the process.

Note: Since the SOTS process utilizes a standard outage template for reporting outages, the data fields in the template cannot be customized or modified for a particular Customer or Organization. If it is determined that a change is needed, then a change request can be submitted to the QuEST Forum - IGQ - SOTS sub-team for consideration.

Initial Implementation Checklist

This checklist is offered as a way to ensure the most important tasks are addressed. The typical set-up time for SOTS, based on prior implementations, is 4 to 8 weeks.

SOTS Implementation Design Document

The generic SOTS Implementation Design Document contains guidance and additional detailed information for both a CSV and XML implementation of the SOTS process. It is based on a design document created by one company (which is very active in the SOTS sub-team) as part of their SOTS implementation. It should be emphasized that the implementation design document is simply useful information based on one SOTS implementation and not in any way a mandatory implementation.

Key Implementation Details

SOTS Technical point of contact – The person who will own the SOTS process implementation and support from an IT perspective. This person may have little, if any, knowledge of the content being exchanged, but this person should be skilled in the area of database table setup and web services, especially if XML is to be used. They will be responsible for working through the technical specifications with their partner company.

SOTS Operational point of contact – The owner of the content of the SOTS data being exchanged. This person will have a deep understanding of the content and will be authorized to modify records to resolve differences between the Customer and Organization databases. Reconciliation of differences lies in this organization, so it will be necessary to identify operational contacts up to the Director level, which is the highest level of escalation for the SOTS process.

Communication format – Email is the most common vehicle used to accommodate the data exchange; however, other forms of communication can be used if the partners agree.

An email may contain a SOTS records in attachments in some agreed format, e.g. CSV or XML. Each data file attachment should be parsed, processed, validated and inserted into a database. The records received via SOTS are extracted and imported into the database as part of the process for generating TL 9000 measurements.

A robust SOTS process should accommodate the ability to parse multiple attachments received from a submitter. The appropriate extension, .csv or .xml, must be used to assure automatic parsing of the record without without delay or manual intervention.

Encryption, if used, should be negotiated between the Technical contacts.

Frequency and Schedule of processing for Data Records – The Customer organization should strive to transmit Data Records within 24 hours of occurrence. Although it is up to the recipient of the SOTS data, typically the information should be processed as soon as possible. This allows for verification and correction of the data in a timely manner. It is recommended that the transmittal process be automated and that it be executed at least daily.

Batch versus Individual data record transmittal – Customers can send data records either individually or in a "batch" file. The organization must be able to accommodate either type. A batch file may contain multiple data records, potentially with multiple product categories, but all data records will be intended for the same organization. Once SOTS data records are received by the Supplier organization, the appropriate product managers and customer service engineers should be made aware of the field outage data as soon as possible.

Allow for the Retransmission and Receipt of (duplicate) Data Records – Data records must be uniquely identified by a combined key (Outage ID Number - Company Name), however a data record can be transmitted many times. Whenever a SOTS related field is changed in the Customer database, that data record must be retransmitted to the Supplier organization in order to maintain SOTS related database synchronization between the Customer and Supplier. Therefore, both the Customer and Supplier implementation must allow for the multiple transmittal and receipt of a data record. The Supplier must overwrite the existing data record when a newer (Record Status = REVISED) data record is received, or remove from all select action for a deleted (Record Status = DELETED) data record.

The Customer must transmit a revised data record when a SOTS related field is changed. The Customer must have provisions within their database to manage the transmittal and changes of SOTS data records. For example, the Customer data base must be capable of retransmitting any data record that has had a key SOTS field changed, or when a SOTS data record has been deleted. One way to manage this is through the use of a supplemental (i.e. not in the SOTS specification) Boolean field that notes whether a record has been transmitted to the Supplier. That field can be used to automate the detection and transmittal of records to the Supplier, and also used to detect records that have been changed or deleted and need to be retransmitted to the Supplier.

Frequency and schedule of reconciling outage data –The Reconciliation process focuses on the outage data itself to verify it accurately describes the outages that occurred. This can be done as part of the outage data record acceptance process or can be performed on a periodic basis, reviewing and reconciling all outages that occurred during the period (for example, monthly).

The SOTS Administrative Report is an example of a TL 9000 product category-based report that can be used to reconcile the outage data between the customer and the supplier. The report provides information on the population data for a given Product Category and summarizes the outage activity for the report period. This information ensures that the Customer and Organization databases are synchronized for the reporting period and in agreement with calculated TL 9000 measurements. SOTS Administrative Reports are specific to a given product category (and supplier organization) and contain information for all outage data records sent during the month. It is strongly recommended that the SOTS Administrative Report be created and transmitted within 10 days of the end of the reporting period. The SOTS Administrative Report should ideally be developed to allow it to be pushed or pulled at any time throughout the month, if using Web Service. The customer and supplier would agree on which organization would be responsible for generating the report.

Template review – The biggest challenges in SOTS implementation have been related to inconsistencies in the populating of the fields in the SOTS record. A field-by-field review in order to establish expectations, for both mandatory and optional fields, and coming to agreement on formatting conventions will save considerable time and effort later. It is critical to the SOTS process that the integrity of the data record be maintained. There are certain fields that are described as "Optional" in the SOTS Data Record Template. Optional in this case refers to the need to populate the field, not whether or not the field is part of the SOTS Data Record. Optional fields are ones which may or may not be populated, but ALL fields must be included in the SOTS Data Record.

Special Email Mailboxes – Two dedicated email accounts must be established to support SOTS. There is a recommended naming convention for the email accounts:

NOTE THAT THERE IS A DASH IN THE NAME, NOT AN UNDERSCORE, AND NOT A SPACE. The special naming convention has multiple purposes. It is intended to stop the churn which occurred in the past as SOTS administrators would change or people would leave for new jobs. The naming convention also helps the SOTS administrators who deal with many companies remember the e-mail addresses. Additionally, under the old system there were many requests to "add xxxx to the distribution list", or "remove yyyy from the distribution list" and it became an administrative burden. This is now handled completely at the receiving company, which will be in complete control of the routing for SOTS messages.

The sots-data account should be dedicated to receiving data records. By having an account dedicated to the SOTS data records, automation scripts can be written that only process and redirect data records, and no provisions will be needed for administrative communications. All other SOTS communications should be directed to sots-admin@company.com, which can in turn be set to redirect to the appropriate SOTS administrator(s).

Note that all Customer organizations (Service Providers) should establish the sots-admin@company.com email account. While the normal communication process is from Customer to the Organization, there is value in having a common virtual e-mail address for SOTS administrators. This will allow anyone involved in SOTS to quickly contact their counterpart. The sots-data@company.com email address is not needed on the Customer side as they will not be receiving data records, only sending them.