Supply Chain Impact of Industry 4.x #4 - Developing a Simple Framework for Digital Transformation
In this article we will explore a few simple steps towards developing a framework for a digital transformation:
1. Change the mindset the world is not the same place as when you first started
Companies are formed to generate some form of economic gain, usually financial. Traditional companies tend to aim for growth year on year at a steady pace expanding from one region / area of expertise into another, growing locally, regionally then globally gradually.
When you examine these company types, you can see that they have core systems / processes which embed a series of procedural systems and approvals, change happens, but at a pace acceptable to the norms of the business.
New start ups, on the other hand, tend to break this mould, these types of companies think globally from their outset, change, new products and new services arrive at a rapid pace, change is embraced wholeheartedly and is seen as a way of life.
This does not mean do sound like traditional companies will not change, change happens but at a reasonable pace, so it can be embedded correctly with the business ethics, of a traditional company.
However traditional companies must recognise need to adapt and embrace technology or risk competitors overtaking them within a market place.
2. Don't worry be happy (Don't jump in head first, practice lean first then proceed)
In the previous article, the need to practice lean first to improve operational efficiency was stressed ahead of moving head first into a digital transformation programme of activities.
3. Drop customisation adopt configuration
By far the biggest headache systems developers face, is implementing IT systems which contain vast amounts of bespoke customisations, as the client usually states it must be done in this way to meet internal acceptance needs, the client usually insists on specific methods to maintain internal processes.
Thus, entails the dreaded argument, of trying to explain to a client that customisation will lead to a much larger future state pain, as it prevents updating of legacy systems, at the time you feel this information is never fully understood by a client, who just wants system behaviour to occur in a specific manner at the point of initial system implementation.
The client then develops a pain point of not being able to move off an existing IT system, as far too much customisation occurred originally.
Indeed the client then may go out and purchase a new IT system, at a future point in time, which maintains yet another high level of customisation, it may get implemented to work in situ with original IT system as the new system does not perform as well as old in certain circumstances, or worse the old system cannot be upgraded due to high customisation levels.
This creates the nightmare scenario of far too many IT systems with lots of bespoke customisation which most likely replicate vast amounts of data between them.
Now you can use secondary middleware products to do basic communication, you still end up duplicating data needlessly.
But why would you? get the client to understand to go vanilla within a IT system, show them the out of the box functionality and just what can be achieved with standard configuration settings, it may initially seem to a client this is a worse what they have currently, but if they understand the long term functionality they gain with regular software updates with less expense, less painful migrating data issues, then surely the counter argument for not adopting a vanilla system and changing internal work processes to match the IT system functionality will hopefully prevail.
The digital transformation process is the perfect example of getting the client to understand efficiency gains, keep things simple, reduce the number of data silos within a business, streamline processes and implement business task processing that works with IT rather than dictates, thereby implementing reducing the need for customizations.
It should be seen as the perfect opportunity to completely overhaul a system to move forwards.
4. All data since time began or accurate viable data?
Here is an interesting conundrum, transform every data record since the start of time or just relevant accurate data?
A lot of people argue the need to gather every single data fragment since a business started, then run deep learning and algorithms to produce best of breed 'what if' reporting.
Is this really needed?, if you embrace lean in your processes, there should be no need to store vast amounts of unused data. Following lean, processes should be streamlined, redundant data should not really exist.
You can then move forwards with a digital transformation using more accurate data.
5. I must maintain multiple IT systems or do I?
Maintaining Legacy IT systems on top of newer IT systems can be a real pain, the legacy systems should not be seen as the only solution.
This is particularly the case with safety critical data systems where, more often than not, data is maintained on multiple legacy systems, but if the data can be migrated to newer systems with low customisation levels, such that data silos are reduced from several different systems to a more unified system, this should be seen as a better state of affairs.
Engineering design systems also typically exemplify both high levels of customisation and record all product versions. Typically as the engineering design software has progressed from simple CAD, PDM and PLM configurations, multiple engineering systems have persisted within the same business over the past decade or more, simply because the earlier system(s) either had far too much customisation or a data format that was deemed to expensive to convert into a newer system.
Thereby resulting in the organisation maintaining multiple systems, this the case for moving towards common PLM data object models and using industry frameworks working within a single PLM system rather several legacy systems which lead to several disparate data silos.
Regular reviews of IT systems should take place, take the bigger picture view (the examples below are just a few suggestions)
- How much data is being held within each IT system?
- Does it contain business critical data?
- How is the data being stored and backed up? - How long would it take to fully recover from a back-up?
- Is there any system resilience in the current system? - is there a standby system which ensures business continuity?
- Are the disaster recovery plans accurate? - could you even recover the data if needed?
- Are there any data cleansing activities undertaken to reduce the size of the stored data (deletion of older back-ups)?
- Can we migrate the legacy system onto a newer system to save costs? (duplicated server / storage / back-up maintenance costs)
- Can the system be migrated to a cloud based solution?
6. Less is actually more secure
A lot of new data protection regulations focus on the need to maintain accurate data and not store data needlessly. Think about it, the more systems you have then the more data you have stored, then the more data security is needed. As a result of the new data protection regulations, industry now needs to address:
- Why is the data being stored?
- Is the data internal or internet facing?
- Is the data accurate? or is the system just storing from initial record?
- Does the data identify any individuals?
- Is the data adequately protected secure? (firewalls / anti-virus / switches / etc)
- Has permission been sought from the data subject to record data relating to them?
- Do we remove data at the users request?
- Can we apply some anonymity in our data storage to prevent personal data from being identified by an unknown untrusted third party?
Update your systems in line with the new data protection regulations, you will soon see the need to store much less data, or even use or need it in the first instance, as a result of implementing best practice leading to implementing more secure controls on data.
Conclusions
The purpose of this article was not to outline a transformation framework, per se, as there will be quite a lot of variance between different industries. The aim was to step back and suggest a few applicable steps.
Feedback
Please share any experiences you have had with regards to implementing digital transformation.
If any organisation is interested in being interviewed as part of my PhD research project, please feel free to contact me via LinkedIn or via the TICS website.