- Apollo
- Technology and the world
- Esso Business Systems
- Exxon to Oglethorpe
- Software development
- Management trends
- Era observations
This chapter is from the book
This chapter is from the book
This chapter is from the book
Esso Business Systems
In 1970, fresh out of graduate business school, I moved to Baytown, Texas, just east of Houston, to work in the Esso6 refinery as a business systems analyst. But the job wasn’t just analysis: It also included design, programming, testing, documentation, and—at crunch times—mainframe computer operator.
One leading-edge project I worked on would in the future be called a management information system (MIS). A study team consisting of young gung-ho, mostly MBA types did the analytical work to identify management’s needs. John Fahlberg,7 a colleague from that period, was on the team and reminded me of details in a 2022 call. John’s first recollection was our regular Friday night retreat to the top-floor bar in the then-new Galleria Hotel, where we commiserated about long work hours and management, of course. When our report was presented and approved, I was a team of one who wrote the software system, which consisted of COBOL8 and Mark IV (a high-level reporting language) code that extracted data from various operational systems and generated the new reports. The system was a big kluge, but it worked, and the executives benefited from the data. The information included barrels of refinery products produced, staff levels, maintenance activities, costs, and other financial analyses. It was the first time, at least in the Baytown location, data was extracted from multiple operating systems and consolidated for management. Previously, managers received transaction data from operating systems, but no cross-system data in a consolidated manner.
I was still new to programming, with no formal training, and I’m sure my COBOL programs were a maintenance nightmare. We did have a few pattern-like models, such as updating a primary file with transaction files—all of which contained serial data stored on magnetic tape. This was an era in which the last record in files had to contain all 9s as an end-of-file indicator.9 The only interaction tools at the time were punch card input and printed reports. Turnaround for running and testing programs was usually overnight. It often took several iterations to get a clean compile, at 12 hours per try. In addition to programs, linking a series of programs together with needed data files and tape drives required knowing IBM’s arcane Job Control Language (JCL).
Testing in those days was a trip. Testing tools were nonexistent. Once you had a clean compile, test data was developed and key-punched into cards, JCL was modified, and the test was run. Of course, if the file was greater than 80 characters, first you ran a program to combine multiple cards into an extended file format. Not surprisingly, many transaction files were 80 characters in length. If you were lucky, the test results were printed and analyzed. If you were unlucky—which was most of the time in the beginning—execution terminated, resulting in a core dump. This 144 characters per line printout of the entire computer memory in hexadecimal10 looked like “01 A9 34 5A D2 88 88” and went on for page after page. Figuring out where your program started and then tracing the execution path was loads of fun!
In those days we had a vision of what management wanted, but the technology was severely limiting.
I managed the implementation of a new accounting system scheduled to replace both the software application and the entire account coding system (another team developed the software). Because of the new coding system, the operational systems, such as payroll, would begin using new codes during the month. As a result, when we turned the old month-end system off, and switched the new one on, there was no going back. The project involved modifying and integrating many subsystems, which pushed the implementation to a nine-month project.
My innovation as the project manager was to build a test program that compared the outputs of the existing subsystems (payroll, accounts payable, cost allocation) with the outputs of the new or modified ones. My comparison program was complex, since it involved mappings for all the data in the operational systems feeding data to the accounting application. As different subsystems (for example, the maintenance cost system) became ready and started generating new codes, the testing program would map the new codes back to the old, and compare them with the correct mapping—and we would find tons of errors. It was my first insight into how critical, and hard, testing was.
As we neared our dreaded conversion date, working nights and weekends, we often helped the operators in the computer center, mounting tape drives, making card deck corrections on the fly, and rerunning the system. In subsequent years, developers were banned from operations due to audit “separation of duties” controls.
One evening toward the end of the project, the team returned from dinner, and I parked my car in a director’s reserved spot. I worked all night and completely forgot about the parking. The next morning, one of my colleagues informed me I was in big trouble and needed to go see the director post haste. He was a gruff, traditional executive, so I was nervous as I entered his office, apologized, and told him my story of working all night. He surprised me by being gracious: “Anyone who works 24 hours straight gets to park anywhere they damn well please. Just leave your car where it is.” He also thanked me and the team for our hard work.
Closing the accounting books for the month, even with the new system, took three nights.11 The morning after the first day, things weren’t looking good: The dreaded, and complex, cost accounting system, named BUPS (Burden, Utilities, and Plant Services),12 wasn’t working correctly. There were only two or three people who knew this system well enough to troubleshoot it, so we took a small conference room to hash out solutions. My manager at the time was an old-school micromanager, and he walked into the room and started trying to “fix” things. Having worked two days with almost no sleep, I had little tolerance for his interference, but I did have enough sense not to confront him directly. I went to my friend, John Fahlberg, who was on my manager’s level. “Get him out of there before I lose it,” I tried to say somewhat civilly. John, being the suave guy he was, guided my manager out of the room and convinced him to let the team fix the problem—which we did shortly thereafter.
The project was a huge success, and everyone was relieved after nine months of 60- to 80-hour workweeks. My friend John planned a party for the team and their significant others. Ignoring his boss’s suggestion to keep the cost of the party down, he put on a first-class event, replete with surf-and-turf entrees. Considering the enormous number of overtime hours put in by the project team, this was a minor concession.
While my title on this effort was Project Manager, I knew nothing about project management, except perhaps what a Gantt chart looked like. As with programming, I’d had no formal education and there was little material on the topic available. But I knew other team members had programming experience, knew their systems, and didn’t need me micromanaging. We had a deadline, lots to do; the team just needed an overall game plan. It was the Wild West of project management, but I was starting to develop an inkling of management style.
During this period, most systems users were clueless, and most of us computer pioneers were marginally less clueless. A project with the refinery maintenance department provided a couple of clues. Managers there wanted a rudimentary system to keep track of maintenance tickets. Like a good analyst, I talked to several maintenance people who currently performed the task manually, wrote down a few specifications, and then developed and tested a system in Mark IV in about three months. I showed the various reports to the managers, which they liked, and then showed them the input forms they would need to fill out and get keypunched. “Cease” was the response. “You mean we have to fill out these forms?” I tried to explain that producing reports required input data. They were not happy and ended up abandoning the effort. The knowledge on both sides about computers and how to make them effective was in its infancy.
The successful accounting system implementation led to my first management job—promotion to supervisor of an accounting group responsible for payroll, accounts payable, and materials accounting, among other areas. I was 28 years old, and the next youngest person in the group was 45, and they were all unionized. In this role, I learned the difference between being in IT and being on the business side of the IT–user interface. In IT, we were always asking for business users’ time to learn about what they did, so we could build systems to support their efforts. Due to the long IT project timelines, there wasn’t always daily stress—until the end, of course. On the business user side, there were daily stresses of making deadlines for payroll, accounting closes, and invoice payments. I’ve never forgotten the different dynamics of these interactions.
Once, when a staff member complained about a rude, disrespectful vendor demanding immediate payment (it wasn’t overdue), I called the vendor vice president. I said if his staff were ever rude again, they would never do business with Exxon in the future! Of course, I had no such authority, but he didn’t know that, and my staff loved it. This episode added another bit to my nascent management style—you treat everyone with equal respect.
In the early 1970s, there were seven Exxon refineries: four large and three smaller ones. The business systems group in the large ones had developed systems independently and the accounting system mentioned earlier was an initial step in instituting commonality. This reconciliation of differences wasn’t easy, as each location had its own way of doing business and was reluctant to change.
To assist in rationalizing IT systems throughout the refining department, the position of business systems coordinator was established in the Refining Controller’s office in Houston.13 As in many companies at that time, IT reported to the controller. Later, as IT became an integral part of businesses, IT organizations would report to a chief information officer (CIO), who then reported to the chief executive officer (CEO). Accepting the coordinator’s job, I worked to consolidate business systems, of which the accounting system was an excellent start. Consolidation of the software systems eventually led to consolidation of the refinery’s computer facilities—a major accomplishment in those days.
Since we were in the controller’s organization, one of my infrequent tasks was consolidating quarterly refinery financial reports. One day, I received a call from my counterpart at the corporate level who consolidated reports from all the divisions—refining, exploration, production: “Congratulations, your numbers are off by only a billion dollars.” “Well,” I said, “it was only one digit.”
This was an influence job, not a managerial job, as the business systems supervisors in each refinery didn’t work for me. Even so, I needed their help in planning how to bring the refinery IT systems into a modicum of commonality.