[Guest Blogger] 40 Years in the Field (Part 7)


Graham Jones (Surrey, British Columbia, IT Pro)

Before I launch into part 7 in earnest I would like to relate a recent conversation that I had with a good friend of mine. We both worked for ICI in the UK but didn’t become colleagues (and eventually friends) until we met in Canada. I was telling him about this series of blogs and how it was a great trip down “memory lane” for me. He proceeded to tell me about his first “experience with computers” in 1958. He left for vacation and returned to find that his office had “joined” the one next door and sitting in the space was an Elliot 802 valve based mainframe. He worked as a Project Planner and the machine was to be used for that purpose. This gentleman has a very interesting history and we have many erudite conversations. For example, he had a major part in the implementation and extension of Critical Path Planning and developed a safety study technique called HAZOP (this will emerge again later). I should point out that he is now 85 and his mind is still as “sharp as a tack”.

From my successes described in part 6, I was now viewed as the “process optimization ‘king’ using computers”. Such plaudits are nice to have but now you have a reputation to live up to; no pressure! Success is ALWAYS dependent upon opportunity and circumstances, and help from others as much as one’s own efforts. It is always vital to remember this and to give credit to others where it is due.

I was moved to the ADN (adiponitrile) plant. The ADN process used a catalyst which was packed into vertical tubes (a “cartridge” type of assembly). This ADN process was batch based, which was totally new to me. There were 5 parallel batch reaction units. The operating problem was that the reaction by-products would “gum up” the catalyst eventually resulting in the need to replace it. The overall problem was that this step had become the bottleneck in the Nylon Salt production. My task was to figure out how to overcome that problem. Computers came into this in 2 different areas. One was the introduction of a Process Control computer to maximize the “run time” for each “cartridge” by controlling the process operating variables more closely. The other was to study the “process” of removing, refurbishing and re-installation of cartridges, which is where I came in.

This involved 2 new areas for me; the modeling of “queuing” processes and Monte Carlo simulation. A simple example of “queuing” is deciding how many checkouts to have at a store. They certainly aren’t in the habit of spending money just to make the store “look big”. A “queuing” simulation is built that uses certain “success” criteria, such as the maximum time that you want a customer to have to wait before being served. Where it gets more complex is the “demand” side of the model and the time it takes to “process” each customer. “Demand” is both time of day and “seasonally” influenced (eg. Xmas eve). There are also cost issues in terms of staffing each checkout; having checkout clerks standing around most of the time doing nothing is not very cost effective even if it means that customer waiting time is practically zero. So you have to build a “model” (there are software packages to do this) which allows for the “processing” capability and the “demand”. This is “nondeterministic”, ie. it requires the application of a statistical approach. For example, “how big is the demand per customer?”. This will vary for each customer “payload”, ie. number and nature of items purchased. This is where Monte Carlo (MC) meets “queuing theory”. First comes observation, ie. you have to build up statistical distributions for all of the main “variables” in the process, and then you use “pseudo-random” selection from the distributions (MC) for each variable to use in the “queuing” model.

The model is then “run” as many times as necessary (possibly many thousands) to produce a statistically significant result (ie. not substantially changing). In the case of the process plant, time distributions for such things as productive operation, safe shut down of a unit, cartridge removal, catalyst removal (it had to be drilled out using a special machine – the drill bits would get dull and need to be replaced or might break inside a tube – it was like drilling hard concrete), catalyst charging, cartridge re-installation and startup were needed. A statistical modeling language (the name escapes me – I want to say SPSS but I am not sure) was used. So we have a model, now what? Well, let’s think about the store example for a moment. We could investigate whether the introduction of another “15 items or less” checkout would make a substantial improvement in profitability allowing for the extra staffing cost versus the chance that people won’t shop at the store if wait times are unacceptable. In the plant example, it was clear that we needed to spend some money to increase production but how much and where? Debottlenecking the plant was essential but the overall profitability of the process complex also had to be considered. The easy option would simply have been to buy more cartridges, which were very expensive, but if the catalyst drilling units were the least reliable that would not be a good investment. So the model permitted us to “experiment” without changing the plant itself.

The final outcome was that we did buy one additional cartridge because the drilling over time damaged the tubes which occasionally needed to be replaced, ie. we could take one cartridge out of commission for repairs and still have 6 to use (5 working and 1 being re-charged with catalyst). The biggest single improvement came from investing in diamond tipped drill bits made of a less brittle metal. They weren’t cheap but the model permitted us to demonstrate the economic benefits when applying for the funding.

And now for something completely different! I mentioned in part 6 a “eureka” moment. It literally took place whilst taking a bath. The complex, and a large part of the company in the UK,  used a “Continental 4 crew shift system” to staff the process plants 24/7 365 days a year. This was based on a 40 hour working week. Over the years the unions had pressed for a reduced work week to nearer non-unionized labour which was 37.5 hours. Every time the company made a concession it added to the cost. You still had to effectively cover the real 40 hours which meant either hire more people (not desirable) or use overtime. Eventually, when the working week had been reduced to 38 hours, it became very costly because it generated a much bigger need for “premium” overtime payments. For example, if someone was required to work a 12 hour nightshift in the middle of a 2 day rest period they could earn the equivalent of one weeks salary for that one shift. Incidentally this was affectionately known as a “golden nougat” and it is easy to see why! These things were so prized that we had to keep records of whose turn it was next for fear there would be a “riot”.

So, what if we could keep essentially the same crew, eventually cut the working week to 35 hours, eliminate most of the premium payments and have a flexible system that could be adapted to different work requirements across the company? The answer was a 5 shift system. It wasn’t that 5 shift systems didn’t already exist but they had problems like time off at Xmas or New Year (Hogmanay) didn’t always work out equitably (huge problem!). My “eureka” was to have balanced short working periods of 8 and 12 hour shifts (modules – a mini spreadsheet with 5 rows x number of days), like 2, 4, 6 and 8 weeks, that could be plugged together end to end to make up a balanced period of choice, like a year. I discovered that it wasn’t actually as difficult as I thought it might be. The main challenge was the transition from one module to the next. For example, you can’t have someone going directly from finishing an 8 hour night shift onto an 8 hour morning shift. So this meant that each module must be capable of having the 5 shift entries sorted to make a working match. Sounds like a job for a computer program to me! I set about building an interactive program in BASIC whereby you could select the modules that you wanted and it would take care of the matching and printing the entire shift pattern for each shift for a year. Even the printout part had never been done before in the company. However, I had a problem. How was I going to get support for spending time on this without a demo of some kind.

I eventually got the attention of the Personnel Department at the company head office and they agreed that I could do a demo. However, I hadn’t completed the “automatic” re-arrangement part. Incidentally, I called the program SMART (Shift Module Automatic Rearrangement and Tabulation). I was going to have to do that manually behind the scenes. I issued a challenge whereby those in attendance could pick any of the modules (limited selection at this point) in any order to make up one year and I would be back in under 1 hour with the printed shift patterns. I must have been mad because everything imaginable went wrong; they picked the toughest combinations possible (unknowingly) and then the computer system went down temporarily. Literally, 59 minutes later I returned with perspiring brow with the result. There was a “stunned” silence which seemed to last forever after which they started pouring over the output to check it. It was like they still couldn’t believe that it could be done. Later I added the A in SMART and handed the program over to the Personnel Department to “play” with together with many more modules. Unfortunately I never did discover its final fate because the whole complex was shutting down permanently (putting 900 people out of work in an area that already had over 30% unemployment) and I was now off to pastures new in Canada. My suspicion is that it never got used because it was too radical a change and would result in “clawing back too much money from the unionized employees” in exchange for a further reduction in the work week. I estimated the full potential savings to the company at $150 million per year in today’s money.

Part 8 sees me start a new job and a new life with a young family (2 boys ages 5 and 3) working for a Process Technology engineering company in Vancouver.


Graham J.

Comments (0)

Skip to main content