 |
|||
  |
|||
After getting kicked out of the defense contracting industry, I landed on my feet in the cellular industry. Once again, my military experience helped. As a communications officer in the Air National Guard, I was responsible for putting in microwave and telephone systems: the two major ingredients of cellular telephone. When I joined McCaw, they had hundreds of thousands of subscribers with as many as 30,000 in Seattle! The challenge I was faced with was how to take the hourly reports that were put out as human readable ASCII on read-only-printers (ROP) and make meaningful information out of it. Each of our 30 markets were doing their own thing and nobody was reporting to headquarters. Craig McCaw still wanted a decentralized decision making, but needed centralized data to make overall strategy decisions. I spent my first week at McCaw doing HR stuff and getting to know people. I spent the second week on a road trip from Seattle to Birmingham, to Pittsburgh, to Minneapolis and return to visit "friendly" markets. These were the markets who logged onto our computer and ran our reports. I came back with pounds of sample reports and pages of scribbled notes. Our report system consisted of a couple of AT&T 3B2 computers running Unix shell scripts to parse the ROP data into ASCII delimited files. Then a series of awk scripts manipulated this data into reports. The process took hours to run even the simplest reports. Making new reports was a major programming effort. On my third week, I held a conference with my staff (a Unix systems administrator, and a mathematician C-programmer) and we did a source selection on a database management system. I then went to my boss and asked for $60,000 worth of software. He approved it. The database plugged into the existing system nicely. We still gathered the information using shell scripts (this was later replaced by C programs), but now the database picked up the ASCII delimited files. Running reports now took minutes instead of hours. Reprogramming new reports took hours instead of days. We were able to turn the system around in a couple of weeks and within a couple of months, all the markets were running our reports. Eventually, field engineers were getting processed information within an hour of sending raw data. Another problem we had was with the reports we ran for the senior managers. These reports took up to six weeks to publish. The process went something like this: when the financial reports were published (about two weeks into the month) we would get the subscriber figures and start our process which included running a report for each market. Then we took the results and shipped them to engineering who would enter the data into a lotus spreadsheet and Harvard Graphics to produce spreadsheets and bar graphs. The finished report would then come back to us for validation, reporduction and distribution. The problem was solved by a combination of process and technology. First, I had to convince the person that produced the financial reports to get me a preliminary report with the subscriber figures. I got special dispensation from his boss to give us the report, provided that I shred it when I was done with it since financial data isn't accurate until approved. I got my subscriber figures on the first or second business day. We ran the market reports faster with the new database and then fed these figures to a C program which produced troff code (today we'd use HTML) which produced a final product suitable for printing. Report generation time went from about 6 weeks to less than 6 days. Decisions could be made based on more current data. So much for the low-hanging fruit. The main successes were done through coordination with our markets and our vendors. Initially, we were often taken by surprise when one of our markets would cut over to a new version of the switch software. The data stream to our parser would change, and our programs would fail. We soon got into each market's planning cycle. We worked with the switch vendors (AT&T, Ericsson, and Northern Telecom) to get a definition of future changes so we could program them before they hit the field. One of the vendors even provided us with tapes containing data that they used to test the system themselves! Our main hardware and software vendors were Sun Microsystems and Informix. I spent a lot of time coordinating with them and not only worked good deals on upgrades and license trade-ins, but had them working for us and not merely trying to sell us their wares. I told them what it was we did with their products, and they concentrated on solutions for us. We got a lot of free engineering help from them such as helping us transition from the 3B2s and install upgrades. We had a good working relationship at the engineer-to-engineer level. My main "war story" from my McCaw days was when I was in my office one evening talking to my database manager. The phone rang, and the caller ID said "C. McCaw." I told my coworker, "I better take this one." The question was whether a recent law suit alleging that cellular phones cause brain cancer lead to a drop in the call rate. "How quick do you need the answer?" "30 minutes." I laid out the specificaion and the DBA whipped up some queries and we called back 15 minutes later. There was some uncertainties concerning AT&T buying McCaw Cellular which started me looking at other opportunities "just in case." This looking resulted in an offer with a 50% increase in pay and a 15% reduction in commuting time. So I left McCaw and went to Legent.
|
