When I decided to leave Olin, I chose an executive search
firm, Robert Half out of Chicago, to help me find a new suitable position. The position they found me, at Air Products
and Chemicals (APCI) in Allentown, PA was one that I was told had been
advertised in the Wall Street Journal, although I never saw it since I have
never been a subscriber. They were
looking for an individual with very particular skills, and ones that I matched
closely. They wanted someone who had
both the skills to do an RPG conversion [just like the one I had finished in
Statesville], as well as one who could work with an online system [such as I
had installed at Olin]. I had never
heard of Air Products, and did not even know where Allentown, PA was – I had to
look it up on a map before I could decide how to get there for the
interview. The interview was a full-day
process, starting with the person who had called me (and who would become my
supervisor), working through several other managers, and concluding with the
Director of MID (it was then known as the Management Information
Department). As I later found out, this
was their standard routine. All the
interviewers called the director’s secretary with their input after they had
conducted their interview – if there were negative votes, then the director
would be “unavailable” at the end of the day to meet with you so he only saw
the candidates that had “passed.” I
passed and started at APCI in June of 1975.
I immediately got to work and had my first business trip
down to Pensacola, FL, even before my wife had finished working with the movers
and had come to PA to join me. The
conversion was quite similar to what I had done at Olin – moving all the
applications at the former Escambia Chemical Company to the corporate computer
in Allentown and transitioning from 360-20 RPG to OS-RPG. The project budget was $100K. After making my own estimates, I informed my
supervisor that the budget was too high and should be only $90K. I got a very shocked response!
A little history is needed here to explain this
response. MID had only attempted a few
projects of this magnitude in the past.
The General Ledger project had been budgeted at $80K but the actual cost
came in at $320K. The Project Cost
Reporting System (PCRS) had also been budgeted at $80K but they spent
$240K. And one other system had been
budgeted at $100K and was soon to be completed at $350K. So they had gotten used to being off by a
factor of 3-4 times. (Remember that this
was the mid-70’s when salary for even an experienced, multi-degreed person like
myself was only $20K/year, so $100K is five man-years.) Thus, when I asked for a budget decrease they
looked at me like I had four heads! I
agreed to keep the budget as estimated but privately I planned on $90K or less.
At any rate, I jumped right in to the project and started
the conversion. I was doing so many
source code updates that I was overrunning the shared source code library and
they needed to give me my own library for the project. I was also preparing all the JCL (Job Control
Language) for running all these systems and keeping the operations staff busy
with all the production turnovers. I
finished the project a few months later with total expenditures of only $85K,
$15K under the original budget. That
cemented my role as the “big project specialist” since I was the first person
to ever meet the budget for such a large project – and it established the path
down which I would travel the next couple of decades.
I also established my reputation in another way. There were times when copying in the old JCL
from Pensacola that one of the job initiators on the mainframe would freeze –
eventually requiring a reboot of the machine to free it. I looked at the symptoms, correctly diagnosed
it as some improper coding, in assembler, of a company extension to the
operating system, and sent a note with the corrected code to the head of our
systems programming group explaining how to fix the problem – all without
actually seeing the code. That equally
impressed that entire group and they became trusted friends for many years.
I should explain at this point that the company was used to
hiring only new college grads into MID.
They would then train them in “the Air Products way”. I was one of only a few people at that point
who had been hired with experience – and only because of the specific projects
that they needed help on. So I was
already two labor grades above all the other new people coming on and one of
only a few who knew what it was like “on the outside”. That gave me a perspective that others did
not have and that also helped me as the years went by.
Over the next couple of decades I remained in the technical
area of IT. The department changed names
from MID to MIS then to IT. There were a
number of reorganizations – from functionally aligned to business unit aligned
and back again. The mainframe platform
continually expanded; we added mini-computers, then PC’s, and even hand-held
computers. I worked for a number of
different managers. On a couple of
occasions I had the opportunity to make the move into management, but I knew
that my strengths did not lay there so I turned down those offers. By the time I moved on from writing code, I
had written more lines of code for more programs in more languages than anyone
in the company’s history – FORTRAN, COBOL (on several different platforms),
assembler, PL/1, RPG, Basic, SAS, ASIST, FOCUS, Pascal and a few others. I had worked on systems in HR, receivables,
payables, purchasing, inventory, maintenance, cylinder tracking, order entry,
sales, truck scheduling, asset management, and others. Any time there was a new technology or a
large “risky” project, I was likely to be involved. I recall one instance where we were having a
celebration get-together for a project that had just successfully
completed. My supervisor was in
attendance as was I since I had helped on some of the more technical aspects of
the system. My supervisor said to me, “I
don’t know what it is you do, Al, but every time we have one of these
celebrations I notice that you’re invited.”
That pretty much summarized my contribution – not often running the
projects, but always helping them to be successful.
I could write several pages here about all the various
systems I worked on, but I’ll limit myself to a couple of interesting ones.
Cylinder Tracking – In the cylinder gas business, not only
is there income from the sale of the gases, but from the rental of the metal
cylinders that the gas is delivered in.
(Officially this is called demurrage as there is a “free” period when
the cylinder is delivered and charges only begin if the cylinder is kept longer
than some negotiated period which would be necessary for using all the gas in
the cylinder.) While the industry had
for many decades just billed demurrage on average balances, there was
increasing pressure to track individual cylinders. Our early pilot project included such things
as figuring out the best shape for the label (since it had to be mounted on a
compound curve of the shoulder of the cylinder), the optimum thickness of the
glue layer, the best type of bar code to use, etc. I got involved shortly after the pilot
project when the IT person on the project was let go and I discovered that he had
booby-trapped the code so it wouldn’t run after he left. This was a real “front line” project as it
involved working directly with the customer.
I wrote the new version of the code over the Christmas break in
Pascal. We ended up licensing it to some
of our larger customers so they could further track the cylinders within their
facilities. The actual input devices
were handheld devices. They were
programmed by me using an e-prom (erasable programmable read-only memory)
burner that produced the chip with the code on it. I had the only such burner in our IT
department. Once one of our customers
made a number of mistakes and wiped out the database on their PC. As a result they ended up paying APCI for me
to fly to their location (a government nuclear facility), got me through
security, and gave me access to their PC to do my “magic” and recover the
database from the erased area of the hard drive.
Vehicle Scheduling – An area where the company gained some
national recognition by the Operations Research Society of America (ORSA) was
our vehicle scheduling system. This
solved what was considered to be a very tough problem in the trucking industry,
especially with trucks that delivered liquid products such as APCI did. We needed to account for: different road
weight limits in different states; days and times that our customers were open
(some required that we deliver when the office was open so they could process
the paperwork, other while the office was closed so we could turn around in the
parking lot when it was not being used); and accounting for the amount of
product to be delivered (since the onsite tanks were being drawn down even
while the trucks were on their way).
Part of the system needed to be online and running under our TP Monitor,
CICS – a product of IBM. Because of this
the OR group would not be able to use their primary language, Fortran, as
Fortran interrupts would disrupt the online environment and affect all other
users when they occurred. The OR group
was not willing to use COBOL, but reluctantly agreed to use PL/1 as it was
closer to FORTRAN. Unfortunately, no one
in the OR group had ever used PL/1 before, so while they did write the first
version of the needed modules, I had to do an almost total rewrite to make them
useable. I was one of the few people who
not only knew both FORTRAN and COBOL well, but could pick up a new computer
language quite easily.
EIS – In the early days of PC’s not everyone had one on
their desk like they do now. One of the
uses of PC’s was for what were known as Executive Information Systems (EIS for
short). The first one developed at APCI
was for the VP of sales. Prior to the
EIS there were bunches of reports produced by sales analysts. If the VP had a question about how things
were going in a particular area, then he’d ask the analysts who would do
further analysis and produce yet another report. The EIS was designed to shortcut all of that
by preparing all the various “cuts” of sales/profit data by product, by
geography, by major customer, etc. and make them available so the VP could just
click on an area of interest and get further details. To make it easy to use, we used the metaphor
of the stoplight – green light for trending up, yellow light for stable, red
light for trending down. We were able to
get access to the VP’s PC over a lunch hour to install the software. Only a few hours later we were called into
his office to answer the question, “How do I know if things are going ok or
not?” It turned out he was one of the
small percentage of men who were red-green color blind so he couldn’t tell
which areas were ok and which were not.
By the next day we delivered the revised system – with different shapes
as well as colors – green up arrows, yellow circles, and red down arrows. Sometimes you have to learn by your mistakes!
SPOC – In the early 90’s the divisional VP brought in a
consultant to examine the business. The
consultants made a proposal to eliminate our mainframe-based systems and
replace them with modern “client-server” systems. The consultants said that they could do so in
one year with a three-year payback. But
that would also mean that they would eliminate all the internal IT staff who
supported that division (including myself) in the process. We weren’t going to take this lying down, so
we (IT) made a counter proposal to management that we could do it ourselves in
only six months and with a one-year payback.
Essentially, we were betting our jobs that we could do this. Fortunately management agreed to give us the
six months. We quickly assembled a team,
partnered with an outside firm that had the expertise in client-server software
that we did not, and began the project at the beginning of April. We had a three-man project leadership team. One was the non-technical project lead, one
handled all the new hardware for this new model, and I managed the software end
of things. Each of us had to have
complete trust in the other two for this to work. The programming was going to take place in
Cambridge, MA at our partner’s location.
We sent three of our IT folks up there to work with them and learn how
to support it. I spent a lot of time on
the phone and made trips to Boston every other week or so (a total of 13 trips
in the six months) – fortunately one of the airlines had a commuter flight from
Allentown to Boston every day, so I only stayed overnight a couple of those
trips. On the last day of October (a
little more than the six calendar months, but less than seven) we turned on the
new system (called SPOC for Single Point Of Contact) and took the first order. This system enabled us to consolidate all our
district order taking, etc. around the country into a single customer service
center and was truly world-class. But
even more importantly, we preserved our jobs!
No comments:
Post a Comment