Saturday, October 27, 2018

My Work Experience – Part 3



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