Tag Archives: GIS

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.


Was Perfect Once

From Ben Hammersley’s book “Now for Then – How to face the digital future without fear, Part 60. Failing Gracefully, or Why Everything is Beta Now”

“On-line everything is beta because the state of perfection is permanently receding on endless waves of innovation. And an app that is adaptable, or that can deliver a soft landing even when it fails, is far more valuable than the perfect-for-a-moment app that either lacks the flexibility to cope with whatever is coming down the line next, or is too late. Good-Enough Right Now beats Very-Good Later, and completely defeats Was Perfect Once.”

In my innocence the above description was far closer to the type of development cycle I was using when doing my IT stuff than the official line at Process Control or GIS. Both (but especially the latter) were so glacially slow that by the time a solution was ready, quite often the problem had changed substantially. Also, their approach seemed to assume that the developer had all the information available to build the finished article, which from personal experience I found was hardly ever the case. Especially since only a selected few users were consulted when compiling the needs analysis.

In the end, what you receive from such an approach is something that may look snazzy and may have a wow factor on day one, but soon the user starts to feel the limitation of usability when it becomes clear that getting new requirements added means a complete new turn of the development cycle – which most users feel (in my view quite rightly so) should have been an automatic extension of the initial development cycle.

What I’ve found from personal experience is that, even if the user has a full say over the initial requirements list, initial use of the system will either show up gaps in the initial understanding of the customer’s needs, or create further requirements based on an extension of the initial design. And that is just assuming that all relevant stakeholders have been able to have their input, which is not always the case.

The answer: build a continually developing system where interaction of the user and the system grows asymptotically to something that approaches stability – that is, until outside factors induce the next step change.

IT Security

IT Security is the health & safety of the IT world. Not that people die of it if something goes wrong, or have to visit the occupational health nurse, but in the sense that it stops all discussions because “surely, no-one can be opposed to better health & safety regulation?” Likewise, IT security can be used to squash any dissenting views because “surely, no-one can be opposed to better IT Security?”

Except when the proclaimed added security is a cover to meet no opposition for whatever IT feature you want to introduce. You don’t like people using Dropbox to keep documents on the cloud ? Declare it a security risk and ban the use of a Dropbox. You don’t like people accessing their personal emails during work ? Declare GMail unsafe (which by the way takes some chutzpah) and ban its use.

But even when the issue is real security, sometimes the medicine is worse than the disease. Take for instance the scanning of your hard drive which is scheduled to start at 10am every Tuesday : for people with a standard XP machine (in short, most people) the limited amount of CPU means that for the rest of the working day your machine will be slow as hell.

And when there’s a breach, did it happen through these well-advertised security failures ? No. The latest one I encountered came from someone plugging in an infected USB stick, and McAfee hadn’t been set up to vet such devices for anything dodgy. I half expected that from then on USB ports would be disabled, but presumably even the security experts thought that was a measure too far.

Still, whenever a new measure was announced, my cynical self could help search for ulterior motives. Not that it would help you to complain anyway. Not when you receive a snotty email identifying you as one of a select group of people who had the audacity of using Dropbox for the simple reason that it was useful.