Hello and welcome to a new blog that will have two key focuses, geospatial IT and how utilities, telecommunications firms, transportation organizations, and others who have to manage network infrastructures have used it to address real-world business problems. I spend a significant part of my time talking about these topics at geospatial and infrastructure conferences in various parts of the world and I am very excited about having a another forum like this to discuss these things with you, so I am looking forward to your feedback.
I spend an even greater portion of my time talking to our largest customers in various parts of the world, and one of things that I find most fascinating is the commonality in the problems that utilities and telecoms and other folks managing network infrastructure are facing in different parts of the world. Equally fascinating is the different approaches that people in different geographies take to solve these problems. 
Let me outline some examples of common problems. If you look at the process that a utility or telco uses to design and manage network infrastructure, you will find more frequently than not that the process is similar to what I've outlined in the illustration to the right. There are some serious problems with this process that inhibits the ability of a utility or telco to improve the quality of service to its customers and to reduce operating costs.
Problem 1: As-built problem
I'll call one of the problems the "as-built problem". This problem is often the result of having different teams responsible for engineering design and maintaining as-builts or records. The engineering design folks typically use a CAD tool to design network infrastructure. The records folks use a traditional GIS application to maintain a record of the network infrastructure after it is constructed. The problem arises because almost invariably the engineering design deliverable is a piece of paper called a construction drawing. (It is actually paradoxical that the engineering design team uses sophisticated digital design tools, but the end result is a very old-fashioned piece of paper. If you are familiar with mechanical design, there is a parallel situation with what are called aperture cards.) The construction drawing is used by the construction contractor to build the network infrastructure. After construction is complete, the construction drawing comes back to the records team as a piece of paper called an as-built, which may have been marked up or red-lined because the contractor may have had to make minor changes to the original design. A member of the records staff digitizes the construction drawing into the records database. At most organizations there is a backlog of as-builts waiting to be entered into the records database, and the backlog can stretch anywhere from 45 days to several years. Just an aside. I visited a large telco a few years back and asked them about their as-built backlog. Their reply was interesting because they said they didn't have a backlog. I expressed my surprise and and asked the question a different way, how long does it take as-builts to get into the records database. Their reply was 45 days, which is really quite remarkable for a telco of their size, but underlines how serious the backlog problem is.
Problem 2: Providing accurate and reliable infrastructure data to field staff
Most utilities and telcos have a lot of people in the field. They are sometimes called install and repair staff, troublemen or linesmen, or field maintenance staff. They are usually customer-facing. In fact in many cases, they may be the only people you meet face to face from your local utility or telco. A large telco in the US or UK serving tens of millions of customers, for example, will have tens of thousands of field staff. A large power company serving millions of customers will have thousands of field staff. The fascinating thing is that the field staff usually know more about the location, detailed properties, and condition of network infrastructure than anyone else in the organization because they work with it daily. Not only that, but the field staff need accurate, reliable data to be productive. When they go out to a site to install or repair equipment, if they know in advance what equipment is up the pole or down the manhole, they can make bring the right equipment and material. An interesting statistic that many utilities and telcos capture is "returns", which is the proportion of work orders that require one or more return visits. At many utilities and tel cos returns amount to between 25 and 30% of all install and repair jobs. This is expensive and it means that instead of a crew completing on average 5 work orders per day, they are only able to complete 4 work orders. Multiply that by the number of field staff and you can see how expensive this is.
Problem 3: Limited support for feedback from the field
In many utilities and telcos there is either no feedback loop from the field to records or if there is, data such as red-lines and markups from the field are treated as low priority and are seriously backlogged. This means that the field staff who need reliable data to do their job productively and know more about the overhead or underground network infrastructure are discouraged from feeding back corrections and updates that would lead to better data quality.
Problem 4: Data quality
A result of the first three problems I described is that the network infrastructure data in the central records is often out of date and inaccurate. This is the result of backlogs, errors introduced during data entry of construction drawings, and the lack of a feedback loop from the field.
The four problems I've described are common to many utility and telcos around the world. What I want to do is tell you how some utilities and telcos are addressing these problems in very innovative ways. I also want to tell you about some transportation customers I met with recently at a conference in Montreal today and at MapIndia two weeks ago.
Also I want to tell you why I think 2005/2006 is a turning point year for geospatial technology and why I think this is the most exciting period since the introduction of the 8080, for those of you who can remember.
One thing I will pass along that was confirmed by Oracle at the conference in Montreal is that Oracle XE, which is the free version of Oracle RDBMS, will include Locator, which is the basic spatial capability that is available in Oracle Standard Edition. This means that everyone can download, try, and use Oracle's spatial capabilities.
Finally, I would encourage anyone who hasn't been to Ottawa, Canada, where I live, to seriously consider a visit. But make sure you do it in January or February. I took this picture of the Rideau canal last Sunday. This is only about 1 km of the canal. You can ice skate more or less in a straight line for 8 km (5 mi), and you usually can do this for 2 and half months of the year, from Boxing Day (Dec 26) through the middle of March. This year Ottawa has been unseasonably warm. Last weekend was the first really good day for the canal. You can see the whole city is out there including all ages from infants to grandmothers/fathers.
Subscribe
Comments