An Old Twist to a Current Buzz Phrase: Digital Transformation

As a consumer I have a high level of expectation on services, driven by the likes of Costa Coffee, British Airways and the Intercontinental Hotels Group.  Most of us will have similar experiences and service expectations.  I perhaps don't notice every aspect of the service every time but can be noticeably caught by surprise when it doesn't happen where, through necessity, I’m using a competitor.

In these businesses, service is a routine: they know we can quickly take our loyalty and spending power elsewhere.  I’m apt to do just that.  At work however we’re a captive audience.  The level of interdepartmental service is perhaps related to seniority, or how much fuss might be made.  Individuals may also be content to have an unautomated or paper-based process: they take longer, so are a source of greater income and apparent job security.

The first interdepartmental software I wrote tracked manufacturing Reject Reports in a simple workflow, with email alerts.  This enabled the General Manager to see at a glance what production work was rejected by Quality Assurance, plus who might be holding up rework and rectification.  Senior production staff were no longer walking the length of the factory to get urgent approvals.  My second project was ‘Maintenance Requests’: the maintenance manager loved this because it would no longer be their responsibility if they forgot a ‘lapel grab’, or a paper request got mislaid.  What is important here is that I wasn't part of the IT team: I reported solely and directly to the factory’s Production Director.

The factory manufactured widgets with a standard certificate of compliance.  As an additional service, a two-factor characterization could be reported: these were its weight and actual minimum effectiveness rating.  The manual process was to write down the serial number, weigh the widget and write down the weight, perform an integrity test and record the performance characteristic.  These data points were then typed into a computer. The automated process by comparison was to type the serial number into the computer while weighing the widget, and the cable from the weighing machine captured the weight.  The record sheet was then printed, with widgets listed in serial number order. When it came to recording the integrity test value, this was quicker because the serial numbers were now in numerical order, rather than random, and printed with a large font. Initially this there was some reluctance to adopt this faster working practice.  One day, however, the RS232 interface on the weighing machine stopped working. The biggest moaner about the ‘new’ automated system then became the biggest moaner about the breakdown. I discovered much later they were embarrassed about their handwriting, and the computer doing the printing was a very personal bonus.

Later as a departmental manager, and due to circumstances, I was training a new graduate joiner on a routine task. As I was doing so, I said “Oh, we can have this automated”. The third time I said this the newbie retorted “you’re have me automated out of a job!”  A month later this graduate came to me about another routine task they were carrying out.  To my surprise they asked: “can you have this automated for me?”

The moral of these four stories is twofold: 1) people are keen to automate routine tasks once they have a moment of realisation, and 2) the IT team doesn't need to be the driving force or even involved in the initial stages.  There’s probably a good chance however that the code I wrote 25 years ago for an RS232 cable has long since been updated for a USB connection, or even Bluetooth.

A recent project involved pulling information from 6 databases, producing a chart and amalgamating into a unified document. This allowed the business relationship team to have a single reference document, laid out in a standardised format. Using expert system methodology, the report highlighted opportunities to enhance services to the customer. When I left the project after three iterations, it was still not static - there was a road map for the next year, but each quarter the road map was being reviewed.  As a routine, new items were added, and priorities shuffled. The new programme for code changes over the following three months would be charted, with ‘ruthless’, ‘nice to do’ and ‘if convenient’ priorities.  Again, this was not an IT department driven project, but could not have been achieved without automated processing of the raw data.

View comments on this article on LinkedIn: