The long transaction and work management integration

The long transaction and work management integration

Kevin W. Miller
FristEnergy Corp, 253 White Pond Drive
Akron, Ohio 44230

The Long Transaction

PaperBackground
In this paper I will discuss the Long Transaction (LT) and its role in the Geographical Information System (GIS) -Work Management System (wMS) integration. I will explain at a high level what a Long Transaction is, why they are important in the GIS realm, and how they are applied. I will explain how the LT is affected by WMS / GIS integration. Finally, I will provide a high level view of the FirstEnergy Corp WMS / GIS integration with GIS long transactions.

Definition
A LT is an update to a database that takes longer than time required by hardware or software constraints. Business processes determine the time required for the transaction. The duration of a LT can range from a few minutes to a few years. The business need is based on the importance of storing information about a change in the system being modeled until the change actually occurs in the system. The goal is to capture future updates to a database during some process like planning or design.

Because the changes being captured have not occurred in the system being modeled, it is important that the changes do not affect the production view of the data presented to the user. It is beneficial if the user can identify areas where these changes are occurring and view them when needed. For example, if a planned or designed change to the modeled system includes the installation of a piece of equipment, system users might design changes using current production data for context. The change would be captured in a LT and could be displayed within the data as a change and not as the production data which would remain unchanged. When design changes were completed in the field and the equipment installed, the LT could be completed updating the production view of the database. This process could take years and the LT functionality must support this possibility.

To support business functions related to their normal life cycle, LTs are often designed to support a progression of stages. The LT must pass through these stages before being posted to production. The way the LTs data is presented or the functions that may preformed on the LT can be altered as the LT progresses through these stages. For instance, a LT may be created in an initiation stage. Then it may be moved to a design stage where changes required by the design are recorded and the data edited. The next stage could be a construction stage where the LT may be write protected. Finally, the LT could be moved to an as-built or closeout stage where post construction updates were recorded and the design is reconciled with the field construction. Business functions like material reconciliation can also be captured in this process. The stages are not required by the LT process but are driven by business requirements. This compliance with normal business functions adds value to LT functionality.

Several different schemes have been developed to achieve this goal. Most GIS products provide for the implementation of one or more of these schemes. It is not within the scope of this paper to discuss these schemes or their relative merit. I will discuss the scheme employed at FirstEnergy and some of the reasons it was chosen.

The long transaction in production GIS

Business Drivers
The business drivers for LT implementation fall into two categories. First is the maintenance of data. The care and maintenance of a production GM database is an expensive necessity facing GIS managers even before conversion is complete. If a process is not put into place that will maintain the data model, a very large investment can quickly evaporate. After the conversion of model data, the need exists to show return on the investment and the continued maintenance of the data model after conversion detracts from this return.

The LT offers managers the chance to capture data updates in the process of other normal and necessary business functions. Instead of the pure expense of drafters recording data updates to the database after the changes are completed in the field, designers can create their designs on the GIS in a LT. This process adds value to the necessary task of updating the data model while assuring that the data will be maintained. The LT also supports this change in another way. Because the task of maintaining the data is being shifted to users whose primary job function is not drafting or data updating, a review process is necessary to assure data quality. The LT can support this review by allowing for quality assurance fimctions. Once the changes in the LT are completed in the field, the data can be reviewed for cartographic and schematic integrity before being posted into the production view of the database.

A relatively small number of users charged with enforcing the business rules of the database can review each LT change before posting it. These users can make changes as necessary, and assist the client community in understanding the importance of following guidelines established for the system.

LTs also provide the opportunity for recording as-built changes before the data is posted. Changes captured in the LT can be updated to reflect changes made to the design in construction. If in the example above the equipment change was not implemented as designed, the changes made can be incorporated in the LT before it is posted to production. This necessary function can also be accomplished in the process of completing normal business functions such as job closing or reconciliation.

Requirements
Production GIS is a strenuous environment for LTs. It is normal for a large volume of LTs to exists at any given time. These LTs are constantly moving through the GIS following business processes. They will be manipulated, progress forward and backward through stages, deleted, and eventually posted to production. They must be readily available for review by users and management. The production data underlying the LTs is subject to review and manipulation. These LTs must be managed over periods ranging from a few minutes to years. It is important that GIS users be aware of, and able to review changes pending, in areas subject to LTs without affecting the production (or current) state of the data.

Robust
This is the most important requirement. In our company we process approximately 2500 LTs per month. The design within each LT can represent anywhere from a half-hour to a month of designer work. LTs contain all of the facilities information of pending designs. Any problems that develop in this process immediately affect our ability to do business.

LTs must tolerate faults from software, hardware, communications, and users. The basic LT design must be simple enough to allow recovery from unavoidable problems that will occur. When processing 30,000 LTs per year, affecting millions of rows of data and tens of thousands of man-hours, the system must be very robust to avoid losses.

Manageable
Users could loose control of he LT process if it is not well designed and business process driven. It should not be necessary to divert users from normal business functions to manage the LT process. As described earlier, users while performing their normal Iimctions should move the LTs through the process. Tools need to be developed to review the progress of LTs in the system and identi~ LTs that may need attention. These tools must watch for LTs that have deviated from the business process path or have developed data or schema related problems. Considering the volume and value the LTs represents, management must be as simple as possible and business driven.

Flexible enough to Conform to Business Processes
It is important that LTs are not allowed to drive business processes, but that business processes drive LTs. The normal work performed by system users must be allowed to cause LT to progress through their required stages. A designer navigating to an area on the GIS where work is to be designed and beginning to prepare a work print should drive the creation of a LT. A LT should capture his work as the designer creates a design. When that designer has completed the design, the act of notifying a supervisor should move the LT from one stage to another. The act of completing the reconciliation process should move the LT to a final review stage. This should indicate to the person responsible for posting the job to production that it is ready for final review and posting. Support C)A/QCProcesses

Maintaining data integrity is an ongoing problem with any GIS. GISS implemented in the current environment of competition and changing business conditions are even more susceptible to the pressure of limited time and attention. The GIS investment in data tends to be very large and keeping this investment healthy is critical. All process in a GISS LTs must support Quality Assurance and Quality Control.

The LT lends itself to this because the quality of the production data is not affected until the LT is completed. Because of this the LT can be reviewed at any stage. These QA events can and should be driven by the normal business process. The first QA opportunity can happen in the design approval process and opportunities continue to occur as the LT moves through its stages. There are also opportunities for software based audits of the LT data and it schema integrity.

User Friendlv
The LT functionality should be user friendly to the point of the user being unaware that he is using it. This is possible when the LT is a integral part of the production database and the fi.mctionsof the LT are business driven not LT process or technology driven. The business needs must drive the LT process. If the LT functionality introduces more work or complicates work, it risks being ignored or circumvented.

Business Drivers for GIS work management (wMS) integration
There are many business drivers that make GIS / WMS integration very attractive. These systems have several relationship points that blur the line between them. A close integration exploits this. After all, maintenance of the GIS data is work that must be managed. This work also represents the operations work that is the focus of WMS. For example; the addition of a new customer requires work which must be managed. This work includes at least the following:

Assuming that there is strong WMS / GIS integration the flow might look something like this diagram.

It can be seen by the large number of common interaction points that the WMS is often involved in the same tasks as GIS. Providing a close integration adds value to data in both systems. It also allows for a reduction in duplicative data entry. A strong integration also provides for a less fragmented workflow. Users need to move from one system to another less frequently as work progress through the system. Users and management can follow a work packages through the business process as one system updates the status of a job in the other through the integration.

GIS Data Model Maintenance
From the GIS prospective the easiest advantage to understand of GIS / WMS integration is data maintenance. Design work can be performed on the GIS. Updates to the data model are captured within a LT. This allows model changes to be captured at the very front end of the business process. A closely integrated WMS then produces a work package with material list and estimate as the user completes the design in the GIS. This allows the design, construction drawing, work estimate, and material list to be developed in one integrated process. The LT is the component that makes this a possibility. Without the LT, the data would need to be updated at the end of the process after the work was completed in the field in order to preserve the production data. With the LT, model changes can be captured at any time during the business process that makes business sense.

Elimination of Data Entry Duplication
Duplication of data entry is a problem that kills efficiency. Often different user groups develop systems with little attention to how they could or should interact. The systems are developed on incompatible platforms and software without understanding the effect this had on productivity. At our company in the past it is not uncommon to print reports from one system and then type the information back into the next. The development of WMSSthat integrated the functionality of many of these incompatible systems into one comprehensive system was a huge step towards the elimination of duplicate data entry. The ease with which these systems can then be interfaced to other related systems like Materials and Plant Accounting continues the process. The integration with a GIS, which may not be as simple, can affect much more data. The data that GIS needs to remain current is the same data that is required by a WMS to estimate and then manage work.

Data Access
Integrated WMS and GIS facilitate data access. Data managed within systems that reside on different platforms and without common keys, are greatly reduced in value due to their inaccessibility. Users can’t find the information and mangers can not easily analyze and understand it. With integrated WMS and GIS it becomes an exercise in report writing to understand the systems being modeled and the work that changes them. Users who need to find the status of work can go to one interface. The accessibility of this large body of data greatly increases its value.

Increased Linearitv in the Work Flow
When all systems that are required to complete work are integrated, work is completed in a much more linear fashion. Users can complete each task in the work process without the need to access different systems on different platforms. It is no longer necessary to do work on one system then report or track the same work on a different system.

The impact of WMS / GIS integration on the long transaction
WMS integration greatly increases demands on the LT within production GIS. With the integration, the robustness of the LT process becomes much more critical. A failure of a LT that is a key to both a design and a WMS work packages could affect several systems. Thus, the time and effort expended to create the changes in the LT must be multiplied by the effort expended on the other systems to understand the total investment in the managed by LT and the expense related to loosing it.

De~endencies on External Systems for LT Stage Management
In order for the integration to be as effective as possible, and avoid duplication of effort, stage management in the GIS must be reflected in the WMS and vice versa. When a stage is completed in one system the completion of that stage should be reflected in the other system. There should not be a need to perform a task in one system then go into the other system and report the task completed.

This means that the LT in the GIS must be robust enough to be advanced and demoted from the WMS with minimal failures. The design stored in the LT must be able to track with the work package in the WMS. At any point in the business process users should be able to find the work package in either system. After finding it they should be able to see the absolute status of the design.

Fault Tolerance and Data InteErity
Because the work packages must track together in both system and due to the increased importance of the changes recorded within the LT, it is critical that the systems interface be fault tolerant. Each system must not only be able to advance and demote the stages of the work within the other, they must also detect failures in the interface and respond appropriately.

When the failure of these attempted changes go undetected, the work packages become out of phase in the two systems and corrective manual intervention is required. Due to the high volume of work packages being processed, a high percentage of failures would quickly lead to severe data corruption.

Increased Investment in LT Data
In addition to holding information about updates to the GIS, the LT now contain key information regarding work packages in the WMS. This makes it more important that the LT be completed successfully. In this new integrated environment a corrupted LT causes much more damage. It also is more important that the LT fimctionality be pushed down into that database in order to take full advantage of the data management features of RDBMS.

FEC GIS / WMS and long transaction implementation

AM/FM Implementation
FirstEnergy is an energy services provider with 2.1 million customers and a 13,000 square mile service territory in Northern and Central Ohio and Western Pennsylvania. FirstEnergy was formed from the 1997 merger of Ohio Edison Company and Centerior Energy. FirstEnergy began the AM/FM project in 1992 (as Ohio Edison Company) with a proof of conceptpilot. Thepilot covered a fifty square mile portion of our service territory. The pilot involved approximately 20,000 customers and 19,000 sites. At the end of the pilot we were given approval and started a project.

The project included the development of an AM/FM application and conversion of the distribution facilities in our service territory. The GIS tool we selected was MCI / Systemhouse’s Vision* product. We started with a solid application development plan that was intended to have critical pieces of functionality in place as required by the progress of data conversion.

In the first releases of our software we did not have LT functionality. This tool was used primarily for data acceptance and gap update and was quickly developed to allow us to view our newly converted data. Users in these first releases edited the data in the production view of the database. This was relatively unimportant because the data was being accepted from the conversion vendor in small deliveries and was not being used for operations.

Long Transaction Implementation
Converted data was placed into production as large portions of service areas were completed. At this time we intended to have controlled update functionality in place. We had originally intended to use an extract merge back process, but as we began to develop functionality to support this extract merge back process several deficiencies appeared which caused us to abandon the process for versioning.

The two aspects of extract merge back the we found unacceptable were the prospect of conflict resolution that would be aggravated by optimistic locking and the difficulty of managing data distributed in extracted areas. We worked for some time to find solutions for these troubling problems before abandoning extract merge back. The LT approach we deployed was based on versioning. We found it best suited to our business model. Versioning is a very simple approach to the LT although its implementation is not. I will attempt to describe its basic properties.

With versioning records that have a version number of zero (0) represent the production view of the data. The GIS software supports and manages this zero version or production view. When a user edits the data in a LT, the software creates a non-zero version of each record edited. We call this editing in a LT Controlled Update. This non-zero version of the record is stored in the same database and table as the zero version record. The software supports the viewing and management of non-zero version in our Controlled Update process. The soflware must also manage the locking of records being edited in a LT. Our locking model is designed to avoid conflicts by allowing them to be resolved at as edits occur in the design. This avoids the problem associated with extract merge back of resolving editing conflicts after the design work complete. Our locking model is also intended to lock the fewest records necessary while avoiding conflicts and data corruption.

Each LT has one or more associated non-zero version numbers. In our implementation the version number is also associated with a stage of the LT. As the design progresses through the business process and has its stages advanced, new versions are associated with the changes made in the LT.

At the completion of the Controlled Update process the data in the LT is ‘posted’back into the production or zero version of the data. We have in place procedures for this posting that corresponds to the business process of closeout. In the process features and notes associated with the work print are purged by the software. A person generally responsible for the GIS data model integrity performs some programmatic and manual QA process and then instructs the software to complete the LT.

WMS - GIS Integration Implementation
Our company was in the process of an initiatives study at the time our original plan called for the development of estimating and design functionality. The group studying distribution work management decided that the company needed a more comprehensive tool than the simple estimating tool we were designing. It was decided to purchase a tool that could manage all types of work associated with distribution operations. The requirement was also identified that the tool should manage this work from initiation through completion. This was the circumstance under which we purchased the WMIS tool from Logica. The system was named Customer Request Work Scheduling (C~WS).

Our GIS - WMS implementation was completed after we had been using LT fimctionality for almost two years. This was a significant advantage because the functionality had a chance to be refined and the users were familiar with it. We had a developed controlled update process that the CREWS implementation could fit into and enhance. From the GIS prospective the implementation had several interface points in the life cycle of a LT. These interface points were driven by business requirements and designed to occur at points where normal business functions took place. The following diagram is a high level view of these interface points by business process.

As work processes through the above the stages the LT in GIS is promoted. Each stage in the work process can also be demoted if functions completed in previous stages need to be changed or if the work is canceled. A work request can be deleted in either system with some limitations due to interfaces to other systems. This requirement places large demands on the LT. The requirement makes it necessary that the LT can be managed by an external system without users interacting with the GIS.

Summary
The tools now exist to allow comprehensive GIS - WMS integration. A manageable LT is one of the tools that make it possible. It is essential that technologies not drive the deployment of the tools, but that business process determines how they are used. The technologies deployed must flexible enough to conform to business process. The LT and GIS - WMS integration can provide great gains when deployed in conformance with business process.