Managing updates to protect your data investment
Requirement Four—Process Control
The Work Request is controlled through a workflow process to help ensure the quality of
the data. The workflow process is defined as a set of stages. Currently, only one process
definition (Work Request Type) is being used—Map Maintenance (Table 1). The stages
in use are
- Creation
- Completion of Data Changes
- Verification Sign-off
- Permanent Commit
The Work Request moves through these stages when users perform certain tasks. Once a
task is complete, the user promotes the Work Request to the next stage.
Security privileges control what type of user can promote a Work Request. A user has the
option of rolling back a stage to a previous stage.
Table 1- WorMow for Map Maintenance
| Stage |
Task |
Owner |
Description |
| |
Data creation / maintenance |
Drafter |
|
| Ready form Approval |
|
Drafter |
Drafter promotes Wrok Request |
| |
Validation |
Suppervisor |
Often involves trace testing to ensure proper connectivity either the Supervisor or Drafter will fix the problem |
| Commit Changes |
|
Supervisor |
Promotes the data into a permanent status; the Work Request is completed |
Within a task, the user cart define check-points. These allow the grouping of sub-tasks
that can then be rolled back to a previous check-point. This capability is typically used in
the Data Creation and Maintenance task. Often, the user adds some structures, completes
a logical group (e.g., pole and associated transformers and switches), and then moves to
the next logical group.
Requirement Five-Enterrmise Database
This requirement can be met only if there is a single database that contains the actual
energized network infrastructure and any on-going modifications and additions. The
system must allow for different versions of the data to be held, viewed, and manipulated
within a single database by multiple users.
With all data (reposed, underway, and current) contained in a single database, the
system must support multiple views. In this way, depending on task and/or privilege, a
user may only want to see the ‘energized’ database. A supervisor may want to see all the
Work Requests underway.
The converse approach would be a database of record and a set of project databases
(extracting data, making changes, and then committing) for handling individual Work
Requests. This approach would negate the enterprise benefits. It would also make the
performance of tracing tasks that require data beyond the Work Request area problematic.
"The Drafter would have access privileges only for this type of Work Request. For other types, the Supervisor would likely roll-back
the stage and advise the user to fix the problem and then re-promote.
Solution Implementation
The solution was implemented using the versioning and locking capabilities of
VISION**. Together, these provide the foundation ofrepresenting, accessing, and
manipulating multiple views ofthe same database. VISION* ‘s display caching capability
isusedto minimize traffic tothe database server. This enhances scalability and
performance.
These base capabilities were used in a layered product called the Version Update Control
System** (VUCS). Written in VISION*’s fourth generation language, VUCS enabled the
creation of specific Work Request types as well as the tools for managing the workflow
process. Ohio Edison then customized VUCS to meet its specific needs. For simplicity of
implementation, Work Requests are defined by a geographic area. All features in the area
are locked as part of the Work Request, regardless of whether they will be changed.
Future Plans
The workflow currently being used is quite simple and reflects basic map-maintenance
tasks. Ohio Edison will be adding engineering design tasks that will require a more
complex set of stages. In addition, these stages are being integrated with a Work
Management System that will enable the engineer to take a holistic view of the design
challenge. Tradeoffs on material usage, crew scheduling, and loading will be able to be
collectively analyzed and then committed to. The integration with Work Management is
facilitated by the use of art open, commercial database (ORACLE***) in the AM/FM
solution.
Although a minority, long-term Work Requests will need to be handled. These tend to
focus on large-scale proposed changes to the electrical network and may take up to a year
to complete. This will require two major enhancements:
- Only those features that have changed during the life of the Work Request will be
locked (as opposed to the area-based locking where all features are locked). This
minimizes potential conflicts.
- Incremental commits will be allowed. This enables the owner of the Work Request to
commit data that has been completed.
From the experience of the simple Map Maintenance task, it is clear that up-front
investment in controlling how changes are made to data pays large dividends in terms of
quality and efficiency. Any fiture applications will need to be analyzed and designed
with this change management challenge in mind.
* VISION*, a spatial information management product from MCI Systemhouse, is used by Ohio Edison as the AM/FM solution.
**VUCS is a product of Geographic Information Technologies (GIT).
***ORACLE is a database management product from Oracle Corporation.
Conclusions
As a provider in a de-regulated industry where there is a need to be more competitive in
both cost and service, Ohio Edison is investing heavily in improving their network
facility. Because of its critical nature, the data must be managed in a predictable manner
through its life cycle of change. For this to happen, a workflow system was designed that
addresses conflict resolution, process control, performance, and communication while
preserving the benefits of a true enterprise database. This was made possible by an
underlying technology that supports concurrent update, versioning of data as well as
providing tools for ensuring scalability.
