For successful digitalization, focus on your people

« All Blogs

Written by Marcus Bole

Posted on April 30, 2024

First published in Sname MT magazine, in April 2024.

Digitalization was introduced to me, as a word, back in 2017. I really can’t say that it had a direct impact on my use of information technology (IT) or how I engage with customers using technology for ship design and production, except perhaps for my experiences of software sales and marketing. In the UK, my generation was introduced to computers through the Computer Literacy Project of the mid-1980s, supported by the BBC Micro. I learnt programming, and with a love of engineering drawing and yacht design, pioneered my early ideas of 3D CAD and Initial Sizing routines consuming as many books and papers as young teenager could.

My professional career has grown from this and regardless of whether it focused on delivering engineering projects or software solutions, opportunities to improve outcomes using IT technology have been important to me throughout. Incorporating new technology and tools into my work has been a constant evolutionary process and the emergence of terms like digitalization and digital transformation have not changed that. I’ve quietly hid a cynical view of these words, avoiding use for fear that the proposals and solutions I present be polluted the same tropes and cliches everyone else is using. This view of digitalization is not something I have been proud, and I’ve felt that I must be missing something obvious. Joining the Cadmatic Information Management team in 2022 motivated me to investigate further since information management is at the heart of digitalization. I felt I needed change my cynical view before some called me out! 

Diving into digitalization and digital transformation 

Digitalization and the digital transformation terms have been a unifying banner for a lot of high-level software marketing, much like Industry 4.0 and its derivatives before it. The words themselves do little to capture the intent of the concept or the expectation of change. Explanation is needed to access that understanding, and a well-crafted message and skilled sales operative can deliver learning tailored to sell a compelling solution that will appear transformational and visionary. Yet at this point, the current reality of your business process and practices have not been exposed. As the saying goes, no plan survives first contact with the enemy. Successful projects are amplified on social media and those that fail are suppressed, without the key opportunity to expose valuable learning. Digitalization has become so connected to sales and marketing processes that accessing deeper learning to provide an understanding of how to successfully transform your team, department or business has become challenging.

Would you be surprised to learn that industry surveys (McKinsey, Forbes and Grubenmann, referenced in (Eigner, 2021)) find the number of completely successful Digital Transformation projects number in low single digit percentage figures? While partially successful projects number much higher, this lack of success seems quite shocking compared to the magnitude in which Digitalization has been promoted. These surveys quote the reasons for the lack of success as a lack of Digital Skills, General Cultural issues and use of Digitalization to target cost cutting rather than as an investment in improvements. Mik Kersten (Kersten, 2019) provides a good insight into these challenges and highlights how businesses of all sizes are embracing Agile approaches, adopting these from the software development and electronics industries and adapting and build integrations with traditional functions such as business development, customer support, logistics and human resources etc. As a vehicle to sell consultancy, Mik Kersten’s book stops short of providing enough learning to use the proposed tool, Value Stream Mapping. Indeed, research further you find that Value Streams originate in the manufacturing improvement processes of the 1950s. As you will see, best-practices for successful Digitalization are found in the foundations in the last century’s worth of industry and business improvement initiatives.

Software development and ship design

The similarities between software development and ship design projects have always interested me. While software development benefits from having practically zero manufacturing processes, both involve people, often teams, researching challenges and creating unique one-off complex interdependent systems and solutions to be delivered on time and on budget. Organising the team to efficiently deliver remains an art. Agile practice is one of the biggest changes in the software development industry of the last two decades. Agile best-practice has been codified as DevOps (Development-Operations). Like Digitalization, most software developers understand DevOps for its introduction of tools such as those for automatic testing. Yet, go back to the origins of DevOps (Kim, 2022) you find the initial focus is on people and best-practice organisation of teams to produce value efficiently. DevOps builds on LEAN and its equivalent codification, the Toyota Production System (TPS), adapting it to problem solving and software processes. While the TPS mission was stated in cold and hard business terms by Singeo Shingo as The Elimination of any material or resource beyond what the customer requires and is willing to pay for, DevOps reframes this with a people centric focus as Reducing hardship and drudgery in our daily work through continual learning in order to achieve the organisations goal, a mission equally applicable in engineering and many other disciplines. 

In both Digitalization and Industry 4.0, the age of manufacturing and age of software are defined as two distinctly separate technological eras. Yet the foundations of DevOps clearly evolved from Lean and manufacturing best-practice. In shipbuilding, Lean practice can be found in the use of, for example, block building strategies, pre-outfitting, outsourcing of production and the Panel Line. Lean is typically associated with mass-production where costs are minimised through optimisation of repetition, reuse and automation. Yet much of Shipbuilding involves the manufacturing of unique parts which is atypical of Lean processes. It has traditionally delivered optimisation through repeatable and adaptable manufacturing processes. Software development also experiences a lack of repeatable outputs since each development challenge is typically unique. Indeed, DevOps introduces optimisation concepts for small-batch production which may be equally applicable in ship design.

Dark background with a 3D ship.

Lean

What was most surprising to me was to be reading about Lean at all. Although I had read all about Lean and the Toyota Production System after University, never have I worked for an organization that ever considered even a passing interest. It seemed to me to be common sense good practice, yet in small organisations my managers would show little interest, and in the large corporates it was clear that my seniors had just as limited an influence as me. Business transformations I have been part of have always been led from the top and those initiatives, while initially effective, reverted to the “old ways” after 18 months to two years. Given the decades since the introduction of Lean there must be a deeper discussion of the reasons for this. A Google search brought me to an article by Martial Durin, (Durin, 2023), a deshi (disciple) of Singeo Shingo, which discusses why companies fail to implement Lean. The same reasons for failure are given for Lean as for those of Digitization – A lack of vision, time, resources and a lack of adherence from the employees.

Singeo Shingo stated that in a successful Lean implementation no more than 30-40% comes from the success of tools, 60-70% must come from the success of the people. In digitalization, where the focus is almost exclusively on digital tooling it perhaps no surprise that there is such limited success. Modern business leaders expect to see returns in the short to medium term, yet Singeo Shingo stated that it requires 5-10 years to achieve the cultural change required to see the full benefits of a Lean transformation. In modern businesses, where employees have become poorly valued in the last decades and the opportunity exists to replace some processes with automation, this suggests that there is potential for painful failures due to naively planned transformation initiatives.

Both Lean and DevOps provide roadmaps to successful adoption. The success of Agile process and DevOps in the software industry highlights that significant improvement is possible. It should be recognised that this was a change that was driven by the development community, it was not imposed by management. There is a lot of tedious drudgery in software engineering. Product testing and maintaining the quality of the code base, despite the use of automation, often requires mind numbingly boring processes. Teams in supportive working environments frequently discuss the opportunity to eliminate dull or error prone task. This is the essence of a positive culture naturally adopting Lean practice through continual learning. With the right conditions this happens in a creative environment whether focused on software development or engineering.

The DevOps Handbook’s suggested roadmap starts with the formation of working groups to learn the potential for transformation and to build consensual understanding to support making change as a positive evolution. Only with the full support of the team will change happen in sustainable way. Like Lean, DevOps transformations are longer term investments with 2-3 years recommended. Changes should be planned incrementally not all at once to allow value streams and systems to be monitored to confirm expected improvement and allow decisions to be reversed if an undesirable outcome is experienced. This mirrors the essence of industry 4.0, applied to people rather than manufacturing automation and builds on the first quality control process devised by Walter Shewhart at Bell Labs in 1924, Plan-Do-Check-Act. Effectively, digitalization, Lean, the Toyota Production System, Agile, DevOps, the Five ‘S’s and Six Sigma are all built upon a foundation of a century of business process good-practice.

Continuous learning process

For the last two decades I’ve been a member of various organisations delivering ship design and production software to customers. Changing this critical toolset is never easy, no different to changing the tooling on a car assembly line. There is never a good time to do it, it’s difficult to judge the depth and scope of initial training to ensure development of foundation skills and the most logical time to change, between projects, frequently brings an urgency that drives the process towards rushing. I’ve been most successful when initially focusing on a select group of key users who can support the transfer of knowledge onto the wider teams, i.e. change happening from within. While the outcome happened more by accident than design, it highlights that giving consideration to how team members affected by the changes should learn and adopt a new software is important. An understanding of Lean or DevOps practice can provide insight to help design engaging implementation programmes. Yet, it should not be treated as a ridged framework. For the continuous learning process to be effective it is essential to start from a position of prior experience and good practice, proceeding with an open-mind by learning from the evolving situation, testing ideas with team members and adapting the approach as more information is revealed.

In the adoption of shipbuilding production CAD/CAM systems, most customers I’ve worked with starting out with a desire to adopt the software with configuration that is close to “out of the box”, i.e. with limited customisation of the software, primarily to avoid unforeseen costs. This approach places undue pressure on the user training and knowledge transfer program with the assumption that, by the end, those trained will understand how to apply the new system to current processes. While much of shipbuilding practice is common, it may be naïve to weight the risk of an unsuccessful implementation on the transfer of technical knowledge alone. Additionally, shipyard teams will need to engage in mini-projects focused on applying the software system capability to current practice and formally propose changes to process. These projects are best when facilitated by domain experts from the software vendor who can bring experience from previous implementations. Furthermore, DevOps practice warns that changing processes and practice can shift bottlenecks in the value-stream. While it is recommended to focus on targeting a change at a time, so that the impact can be closely monitored, changes to critical software systems can rarely be delivered in such a controlled way due to immediate business and project demands. Consequently, there is a much higher need to be attentive to the potential that a bottleneck could move to an unforeseen area that was previously considered mature and robust, the most critical always being production processes.

Summary

While unforeseen issues may impact directly on project delivery, the impact of team members wavering in their support for change has the potential to be far more destructive, as the evidence of the number of unsuccessful of digital transformation projects suggests. Rather than forcing, or even enforcing change, technology adoption strategies that focus on teams embracing digital transformations through learning, adjusting existing practice to the capability of new tools and testing of outcomes are about planning for success. Since the evolution of technology has become far more rapid that the ability of organisations to keep pace, finding strategies to not just cope, but excel will be essential to business sustainability. After more than a half century, Lean practice remains relevant today as it ever was and may provide increasingly important insight for placing people at the forefront of the successful digital transformations regardless of terminology used to brand business change projects today.

References

(Eigner, 2021) System Lifecycle Management: Engineering Digitalization (Engineering 4.0), Martin Eigner, Springer Books, 2021.

(Kersten, 2019) Project to Product: How Value Stream Networks Will Transform IT and Business: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, Mik Kersten, IT Revolution, 2019.

(Kim, 2022) The Devops Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations, Gene Kim, Jez Humble, Patrick Debois, John Willis, Nicole Forsgren, 2nd Edition, IT Revolution, 2022.

(Durin, 2023) Why are most companies failing with Lean implementation?, Martial Durin, Managing Director, Kaizen Institute China. https://kaizen.com/insights/wh..., retrieved Dec 2023.