Retrofitting the Enterprise

Retrofitting the Enterprise

Tom M. Strickland
IT Futurist, SpatialAge Solutions
Byers Engineering Company
368 Mount Zion Road
Madison, AL 35757
Telephone: 256.430.1718
Email: Tomstrickland@Byers.com

Abstract
Designing the Enterprise is not an option within operating telephone and utility companies with existing large non-spatial, mission critical applications. Automating information flows to add spatial content provides hidden information. Focus is historical AM/FM/GIS engineering flows to telephone assignment; with data merges for planning insights, Accounting, and Customer Service use of geospatial. Examination of alarm monitoring, sales, marketing, and provisioning show how future business cycle integration will support better service at reduced costs.

Introduction
If you could design the enterprise, you would provide information flow such that the appropriate levels of detail were immediately available to anyone who needed it. Information would be collected and input once at the source of its creation; in most cases via electronic scanners and measurement devices. This information would flow and be validated by intelligent feedback of the automated networks and by users of the data. Triggers would be established to focus attention on exceptions and problems. Rather than constantly addressing “held orders”, Engineering would build to long term plans that dealt with realistic demand projections. Capital budgets would be adequate to perform the needed network modifications and customers would experience uninterrupted quality service at steadily improving value levels.

Location would be recognized as a primary key to management and control, as shown below:

Of course, this vision requires more than just a perfect information flow within the company. This also requires advanced information on road moves and paving, new construction, zoning changes, technological advances, and competition. Information flow from and to the company from other agencies, companies, and the public would be similarly perfect. Even weather would behave and not cause network damages.

Reality.
Internal systems exist. Data managed within these internal systems balances between very valuable and highly suspect. Data is redundantly input manually based on paper flows and telephone conversations. Disconnects occur between planning, engineering, provisioning, marketing, and billing. New businesses and residents in new subdivisions request service, at times before facilities to serve them are in place. Storms and unexpected demand force expensive construction and repairs, while excess capacity fails to provide returns on investment. Trucks roll to determine what really exists and installation discovers that material or facilities needed to complete the order are different from what was indicated by the records systems.

Reasons.
Over time, most of these existing systems were created or acquired independently based on expediency of need of a single organization. These systems used the technology available at the time they were defined. Upgrades to better processors, more in-favor operating systems, data screens, and databases, along with changes in the needs of the organization may not have considered improvements to, or even protection of the data. Cases exist where data is input with no clear need for its utilization. Relationships both inside a single system and between systems may depend on human integrity maintenance rather than referential constraints. Customer

Services assets
Geospatial was typically only used for systems where paper map-books or plats needed to be updated frequently. Data generated from these spatial systems were re-entered to non-spatial systems, losing the keys that allowed validation and re-integration. Each department was, and is, accountable for its own budgets and information. Communication across departments and to external organizations is generally less formal and quite often evolves based on social rather than true business requirements.

Conditions:
Isolated systems with questionable data are the current conditions in many companies. However, the luxury to start over does not exist. The problem is one of integrating information, while improving data quality, reducing costs, making information available where needed to improve value to the customer base. We have also reached a time in IT endeavors where ROI (Return on Investments) must be measured in months rather than years.

Fortunately, technology and standards have now advanced to the point where geospatial techniques can be effectively and relatively inexpensively employed to not only validate data, but also to improve data quality during integration. The work of the OpenGIS Consortium (OGC) over the last decade has resulted in accepted International Standards (ISO) as well as proving interfaces in test-bed trials.

Moving Forward:
Client implementations, based on these developments are being deployed. Examination of these efforts, plans, successes, and issues follow.

The first issue to address in today’s environment is ROI. How do you pay for the effort? Can this be done using capital budget? Can reduction in work effort be achieved to offset the costs? If so, how long will this take? Creation of the business case is the first step. In spite of the short term ROI requirement, clients have been able to justify very impressive efforts.

A second issue is leadership of the effort along with staffing, both internal and third party to achieve success. Improvements in business processes can only occur if talent is made available to dedicate their time to make it happen. Failures result from lack of attention to the details or automation of a process that should be eliminated, rather than technical deficiencies.

Of course, major successes are achieved by addressing the right problems. Where do you start? In most cases, problem areas are not difficult to identify. For one evaluation, you look at paper trails. Historical AM/FM/GIS systems for telecommunications companies who do design (rather than just after-the-fact records drafting) produce work prints, bill-of-materials (BOM), and other reports. Distribution may be digital, in paper, or some of both. Typically more than a dozen copies are provided to support construction, inventory and purchasing, cost accounting, scheduling, fiber and copper assignment, inspection, and management. Additional copies or information may be sent to these and other organizations after the information is built and “final” (constructed, inspected, accounting reconciled, and ready for service).

Integration areas
Users of downstream systems who receive this information in many cases may use this information to manually input data they require. For instance, job costing and scheduling may input the material shown on the BOM and estimate labor costs associated with the job. In many cases, they also evaluate notes, symbols, and text on the work print to identify costs associate with road-bores and other labor related costs, not in the “engineering” permanent records. An obvious first step is to automate the BOM load. A second step is to capture the labor only and non-accountable material from work print data in a form to automate this loading. A third step can be to associate local labor costs units geospatially. These will vary depending on whether the work is urban or rural, digging is to be done in sandy soil, clay, rock, or historically protected brick or stone pavers, along with other factors.

Companies may avoid the automated load of engineering to job costing and tracking, because there remain numerous items that are not automated. If a typical engineer (or support clerk) spends 8 hours a week inputting information for job cost tracking and this effort can be cut by 40% via an automated load, then one out of 25 can be doing something more productive with their time.

Assignment generally needs to utilize terminals being added prior to an entire work orders completion. At the same time assignment does not wish to see facilities before they can be used. This creates some very interesting interface problems. As of now, no company has construction time reporting digitally flag the work order facilities complete along with hours spent on the job. This would help greatly. High Speed Data (HSD) assignment and the baud rates available may be affected by as-built changes. In truth, until lines are tested, engineering calculations should be recognized as only estimates. However, these are typically good enough to support provisioning. The most difficult timing activity between engineering proposals and assignment utilization is transmission of cable throws or ripples when appropriate. This in no way completely eliminates manual input. Assignment personnel still need to throw customers to the new counts or logical circuits as well as the throws to the cables and terminals. However, by providing consistent proposed rearrangements as pending operations, this does ensure that the records match on a goforward basis.

Integration Questions.
In evaluation of these systems and the need for integration, there are many factors to consider. What information from the engineering system is used to provide a consistent long-term match key in the target system? Can it be changed in either system? Are there other network changes that are captured in this system but not sent to the engineering system? Where are changes captured? Are there different flows for different types of changes? Who can approve or cancel a job? How is this communicated? Even more farreaching changes may be identified by asking, “Why are job’s cancelled”?

Integration should also be considered based on dollars. Capital budgets in many companies approach the GNP level of a medium size country. One planner proved a 16% saving in capital budget by making out year plans available as backdrops for normal work orders. Engineers were told to build to the plan, rather than just solve the current problem. This integration requires a circular flow with strong demographic projections or forecasts, which requires good input from businesses, government agencies, and especially construction. This can be visualized as:

Technically, how is this level of integration being achieved? SQL 3 level databases are replacing SQL 92 implementations. At this point there are still very few “merged models” across disciplines. In most cases, it would simplify implementations to create tables for multiple applications, which need strong integration in a single database. There triggers could easily ensure information flowed as needed. Instead external interfaces, increasingly using JAVA remote procedures pass data between applications to update disjointed databases. At times, this is reminiscent of the old IMS screen changes. It either prevents changes or keeps the IT staff growing.

Internally, more and more companies are using their internal AM/FM/GIS data for the high level of completeness of the street networks, with good relative positioning. Commercially purchased GPS corrected land base data is used for control monument purposes. The two sets are conflated to generate control monuments to warp the facility data to greater positional accuracy. The resultant accurate land and facility data is used to provide the base for geo-coding non-geospatial information using addresses or adjacency to positioned facilities. For instance, the inside plant equipment is obviously contained within the manhole or vault with which it is associated. Even if it is still “schematically arranged” within detail drawings, the drill down and locating of these facilities can be accomplished from a geospatial view. These levels of accuracy have finally allowed for tax reporting to be driven by up-to-date geo-political boundaries, for cities, counties, and states. This eliminates the need to associate ‘tax codes’ with facilities as they are placed, which historically required arbitrary breaks in the network linear elements at these boundaries. Software can now prorate percentages of fiber (or gas mains, or electric cables) measured lengths to the correct area with higher accuracy than the stored, but not updated, ‘tax codes’.

Data cleanup:
The ability to geographically overlay information from different systems provides tremendous power in correcting invalid match keys between them. In cases, the data unambiguously matches such that if the customers are served by a specific terminal in the assignment system, then ergo it must be one specific terminal in the engineering system. In other cases, software can determine it is probably one of these two or three. A queued edit scenario for visual inspection can then provide the fastest method for resolution. Data must match at many different levels. Even with a high match between the terminals, the logical circuits may not match between engineering and assignment. Throws, to resolve problems, have been performed inconsistently across the systems. Pairs have been used to add service without engineering record update. Who is right? The answer is neither and both. Heuristics can be defined to assist the cleanup, if the politics allows the changes. In many cases, some percentage mismatch is accepted, as long as the practices and integration are in place to ensure consistency is maintained going forward.

After decades of lax controls on data updates, one hundred percent accuracy on matches is unrealistic. The best approach to data clean up is to have assigned to the problem an individual with experience in the systems being integrated who also has good technical skills with database, spreadsheets, etc. This person should know they have limited budget but be provided with tools for analysis. The person can then draw on their experience to estimate time spent due to invalid or mismatched data versus time saved by correcting the problem. This can be balanced against time to research and fix the problems. Many problems will appear random. Many others will follow a common pattern. Decisions to have special programs or manual effort to correct problems can be made based on the solution ROI.

At times it seems as if people went out of their way to avoid data matching. An example includes where different groups devised separate material codes for identical material. Matching these historical codes and defining a single set of codes for all to use going forward is an obvious first move. Quick programs to reset existing records based on new approved standards is easier to develop than is gaining the permission to change the records. However, these battles must be decided to ensure efficiencies in the future.

In recent years, clients have justified numerous integration projects. When these have involved spatial data or sought to use geospatial procedures to assist the integration, I have tended to be involved in the design and implementation. In the best of worlds, the resultant solution provides temporal and spatial viewing and update of the data. This is not to say that the first approach to solving data integration is to create spatial match keys immediately. In many cases, people did define match keys between systems. These keys can be used to provide 30% to 70% match rates, depending on historical consistency. With any such attempt, and especially with less than 50% match rates, one must be aware of the potential for invalid matches. Geospatial data can very easily determine that these “matches” are wrong by using geocoded information and determining that matched items separated by distances cannot possibly match.

Design
Solving problems and cutting expenses are valid items to address with geospatial integration projects. However, the greavtest potentials come from addressing issues associated with provisioning of new technology. This can also be the most difficult; because existing systems may not provide capabilities to fully support the new requirements. Should existing assignment systems that associate pairs to clients be expanded to associate lambda or frequency assignment on multiplexed pairs and strands? Should existing special circuit provisioning systems be similarly expanded? Should new systems be built or acquired to deal with only the new challenges or also replace well-established implementations? What is the cost of maintaining multiple, somewhat similar systems versus the cost of data migration, retraining, and potential disruption in historical core business processes? In many cases, the risk of disruption is so high, that somewhat parallel systems may be preferred. This can also be the case if major changes are required to an existing system to support the new technology.

When evaluating a new business area, it is seldom a completely new business. An exception is wireless, which is planned, engineered, deployed, maintained, and even marketed very differently than are wired services. New wired services tend to follow very similar processes to existing wired services. Even if certain systems may be created to parallel existing ones, others like engineering may be simply changed by adding new processes and training. Existing interfaces to downstream systems offer a first cut evaluation of how data may flow. However, there are good reasons to examine greater interface capabilities for the new deployments. Why consider duplicating the redundant inputs and resultant errors in a new system? How can geospatial data content help the planning, forecasting, marketing, provisioning, sales, and support across the entire flow?

In many companies, this is the only chance to “design the system” rather than “retrofit the system”. The opportunities are there. The technological tools exist. In many ways, this offers the opportunity to prove the benefits and justify via hard numbers the ROI available in geospatial retrofitting of existing systems. .