Tag Archives: Supply Chain Transformation

Supply Chain Transformation

Supply Chain Transformation, or SCT for short, was a scheme dreamed up to streamline the material flow through the production process so that delivery to the customer could be expedited. Instead of a single order number for a given order, each step in the production process would have its own order number based on the type of processing that was required to transform an input coil into an output coil.

The main benefit would be that the majority of products would be processed from generic stock and only allocated to a customer at the very end of the supply chain. There was, however, one problem: the SCT superstructure would have to be supported through an unchanged Manufacturing Execution System or MES – and the latter consisted of various mainframe systems (known locally by their acronyms OASIS, COMPASS and STACA) that originated from the 1970s and 1980s.

So an interface would have to be built to let the the two systems speak to one another. In order to do this, a team started to investigate the content of various stocks and production mainframe tables. It was then that they found out that the data quality and internal consistency may well be sufficient to control the production at a single production unit (although even then there were major issues with coil identification), but totally inadequate for a through-process control.

If memory serves me right, SCT was launched in 2010 or 2011 with a planned go-live a few years later. However, it soon became apparent that this was wildly optimistic, and the go-live date kept being pushed back. In the end it became a running joke that the go-live would always remain 3 months in the future.

From my point of view, I wanted to be able to test my systems in a special SCT environment that would be made available a few months prior to go-live. And since my test environment was always bring pushed back beyond the latest deadline, so was the actual go-live forever disappearing into the mists of time.

At some point it looked like SCT would finally come into existence before I would retire, but in the end, no such luck. Maybe Stuart Wilkie had heeded the warning signs that if SCT were to be implemented before we were ready and dead sure of our game, then we might well plunge the business into an information black hole, just at the time when we were already close to being on our knees.

I wonder if the people who gave the go-ahead to SCT (that may well have been in the days of Jon Ferriman) realised how unprepared our business was for the upheaval of trying to erect a new system on the shaky ground of an antiquated mainframe. Surely it would have been more prudent of first trying something like this out on a smaller unit like Trostre or Orb ? IJmuiden definitely must have realised what was up, because the first money they asked for in preparation of their instance of SCT was to upgrade their manufacturing systems bit by bit.

I obviously have no idea whether SCT was ditched in all the upheaval following the planned sale of last year, or whether it was put on ice for a possible revisit when the time was ripe. However, since in my opinion the root cause of the failure was the status of our mainframe systems, the answer must be that first the MES systems need to be brought into the 21st century. Anything else would amount to putting the cart in front of the horse.

P.S. Out of necessity, my knowledge of the topic is nearly a year out of date. Maybe things have improved since I left the company, but somehow I doubt it. When survival is the issue, then a potentially toxic cocktail like Supply Chain Transformation would be the least of your priorities.


Updating a Customer List

You could almost see this as an addendum to the “Excel is not a database” and “Why Excel should not be used for business reporting” blogs. It is also a real life example of how updating a customer is automatic and requires no manual intervention when using a database, but is virtually impossible, and definitely very time consuming if done using an Excel spreadsheet.

I used to have a system for recording complaints by extracting data from the CADS mainframe system. In parallel I also made an extraction of the current customer list from a different mainframe system. A daily automated extract was all that was needed to make sure that the customers from the complaints database matched the list of current customers.

In addition we also had a manually maintained customer list SQL table which contained more extensive customer-related data. If necessary this table could be kept up-to-date through a web-based entry screen, or block changes could also be made behind the scenes using customised SQL commands.

Compare this with the system in place for maintaining a customer list in support of Supply Chain Transformation (a separate customer list was deemed necessary since the customer groupings were specific to the needs of this project): you received an email letting you know that a number of unspecified changes had been made to the Excel spreadsheet which resided on a Sharepoint server.

Now how I had handled the initial SCT customer list was to extract the contents of the initial Excel spreadsheet into an equivalent SQL table and used this table in combination with my complaints table to create a listing of complaints with their specific SCT category. However, since the changes to the customer spreadsheet were not specified I had made up my mind that I was not going to waste any time on figuring them out, and let users flag up any gaps that might appear as a result of mismatches between my complaints database and the now outdated SCT customer list.

I could now make the required changes necessary to fill the gap in the customer list. It works, after a fashion, but it can hardly be considered an elegant solution – and besides, it always requires someone to step in and make the manual alteration. Now imagine if the SCT customer list had been held in a database: at worst I would have to perform a daily extract from Oracle to SQL, but since this is an automated process, the SCT customer list would always be up-to-date without the need for any manual intervention apart from the first one needed to alter the records in the Oracle table.

There couldn’t be a better example of how spreadsheets always need to be shepherded along, whereas a database runs automatically once set in motion. Being essentially a lazy person, I prefer the automated option.