|
|
||
|
Root Cause Analysis By: Lee Helwig, Software Engineer, ATS Some years ago, after an RBOC that had been running SimCall for over a decade, we were asked if we could start gathering data on the corrections so as to determine the root cause. In the beginning, the SimCall error number was used. This was valuable data, but could only be analyzed by an individual that knew and understood the ins and outs of the SimCall engine and it’s, switch specific, error codes. It was later determined that more specific definitions were required so as to be able to hand off data to a technical manager who could analyze said data and make a determination as to an appropriate action. It was determined that for the DMS, relevant “TABLE NAMES” would be used. For the 5ES, different “VIEWS” were identified and used, and in the 1AE “FORM NUMBERS” were utilized. These were dubbed CAUSE CODES and would be added up at the end of each image being processed. An action was added as to show whether the item was added, changed, deleted or N/A if none of these applied. This particular RBOC, already had an external SQL database which tallied overall SimCall completion data in an annualized fashion so it was determined to gather this new CAUSE CODE information there as well. This database is managed by an administration group. When an office image has been completed by a communications technician, that technician notifies his administrator. That administrator physically looks over the image and if satisfied populates the database with a completion date and a series of processes are initiated. A list of completed offices is programmatically ftp’d into the SimCall server on a daily basis. Unix shell scripts on the SimCall server read the incoming ftp files and subsequently gather completion data as well as CAUSE CODE data and put it together in a format ready for reading into an SQL database. Upon completion of that specific days office list, the data is programmatically ftp’d back into the SQL database. Once received at the SQL database, a DTS (Data Transformation Services) job is running which reads the specifically formatted data into the appropriate tables in the SQL database. The SQL database is the final repository for this data and is retained indefinitely so as to analyze the utilization of the SimCall tool as well as the evolution of the technical understanding of the different switch types. Although the data and it’s main functions exist within the SQL database, an additional report is derived from the data. A weekly count of completed offices has been established as well as a monthly total report. This report is specifically for upper management so as too track their projected annual percentages. Questions or Comments? Contact us at info@atso.com. |
||
| Resources | ||
|
|
||
Copyright
2010 (Advanced Technologies & Services, Inc.) All Rights Reserved