Digitization vs Digital Transformation

Digitization vs. digital transformation: Why digitization might not be enough

In certain times, some terms are used almost inflationary. Nowadays "corona" certainly crosses one’s mind immediately. Another contemporary word that is used often is “digitalization”. You almost get the impression that digitization is the reason for everything: When something goes particularly well and (positive) economic figures skyrocket, digitization has obviously worked or was responsible.

In the case of bad news, the guilty parties can be found just as quickly: Of course, digitization is either non-existent in the specific area or has simply been ignored.

However, I seriously doubt that writers and readers understand the meaning of "digitization" when they refer to it. The reason is that there are some important differences between "digitization" and "digital transformation". In fact, I, too, plead guilty to primarily using the term "digitization" on my website and blog posts, when I actually mean "digital transformation". "Digitization" is simply faster to say and doesn't sound as clumsy as "digital transformation". Also, as a verb, "digitize" sounds snappier than "digitally transform". Nevertheless, the difference is eminently important. So, it's time to take a closer look at the terminology and work out the differences. In the future, you might also use these two terms more consciously, just as I promise to improve the wording of future blog posts and articles. Let's get started!

My discussion of the two terms was triggered by a blog post by my colleague Prof. Dr.-Ing. Evi Hartmann from the Friedrich Alexander University of Erlangen-Nuremberg. In her article entitled "Estonia, of all places!", she points out the lead Estonia has gained in an international comparison in the field of digital transformation. At the same time, a few words are enough to clarify the difference between "digitization" and "digital transformation". I will therefore quote here from the introduction to the article, which is well worth reading, in which Prof. Hartmann addresses the question of why Estonia should be called a digitalization pioneer. Her answer:

"The reason is that in Estonia, for example, 99 percent of government services are digitized; that's around 3,000 applications. For example, if you do your tax return, you do it online - just like we do when we use Elster. In Estonia, a digital tax return like that takes time - what would you think?

Eight minutes in average. That's the difference between digitization and digital transformation. Digitization is when you digitally write inefficient analog processes on code. Digital transformation, on the other hand, is when you not only code the tax return, but at the same time make it so agile that it can be done in eight minutes, without first having qualified as a tax consultant."

So far, so good? In fact, Prof. Hartmann hits the nail on the head in just a few words and you, my readers, probably now understand much better why the difference is so important! After all, digitizing individual steps in already existing processes using IT can only be a start. Compared to the digital transformation that really matters in the future of companies, it is only a small step and not really worth mentioning. The ultimate discipline for any company on its way to a digital future is in fact digital transformation! Anyone who has once understood this difference will hardly be able to speak of "digitization" in the future, as it only brings marginal improvements for companies. It will not be able to make a grand impact. Instead, companies must take a holistic approach to their processes. This is what’s hidden behind the unspectacular phrase "agilize" that Prof. Hartmann mentions in the quote above. She makes it clear how enormously important processes are in the digital transformation.

Coming to the same result, Thorsten Dirks points out the misunderstandings surrounding digitization in his now legendary quote. He stated in 2015 at the business summit of the "Süddeutsche Zeitung":

„If you digitize a crappy process, you have a crappy digital process."

As harsh as his words sound, this man speaks from the bottom of my heart! It's also important to remember the context in which his words were uttered: As you can read here, Thorsten Dirks was simply frustrated by the lousy digitization projects that companies thought were taking digital transformation forward. In reality, they were "only" digitizing. Do you see how fundamentally important this difference is?

It is exactly how Mr. Dirks has described it: A paper-driven process, for example, will not improve one bit in its complexity if you use Excel spreadsheets instead of paper. Today, we see a similar trend using Robotic Process Automation (RPA). Again, it’s a fallacy that they are digitally transforming. It's just digitization! Mr. Dirks also refers unequivocally to the holistic process view as the key to "real" digitization, which we want to call "digital transformation" from now on.

The difference is also important since the requirements for a company that intends to transform digitally are completely different from the requirements that a company has to fulfill in the case of pure digitization. It is precisely these differences that I would like to address in the remainder of my article. The management can only make well-informed decisions when  recognizing the requirements and consequences that have to be considered in a digital transformation  as to the desired direction.

The following comparison originates from a brainstorming session. I have neither done research nor does the list demands to be complete. It is and remains a brainstorming. I am looking forward to your feedback to extend the list if necessary.

Digitization vs. Digital Transformation - A Comparison
At the top of my list is, of course, the process issue. In the case of digital transformation, the focus is on differentiating innovative processes implemented through individually implemented software. In the case of digitization, standard processes tend to be implemented through the purchase of standard software. Gain competitive advantages through individual development or "just" catch up with the competition by purchasing ready-made solutions? That is the question you have to answer when deciding between digital transformation and digitization. In general, when discussing digitalization, the focus is usually on IT issues such as the state of the IT infrastructure, the quality of data connections, software and hardware equipment for employees to enable home offices, security, data protection, and so on. Digital transformation, on the other hand, is considering innovative processes.


Closely related to the process question is the ever renewed discussion about “build or buy”: Should companies buy software or rather build it themselves? Should companies think for themselves (build) or let the thinking be done by others (buy)? For many years, the answer was clear: buy! This was also my experience with a German medium-sized company in the textile industry. When asked about what they knew about me as a customer, the answer was: Nothing, but we will soon buy a CRM system (Customer Relationship Management). This behavior and thinking is symptomatic and common: Arising Challenges are solved through buying. In standardized processes, this can be the right approach. Instead of "rebuilding" them, it is advisable to buy (and adapt the software to the company's own requirements, so-called "customizing", accompanied by a small amount of programming). The advantage of this approach: Companies do not need to build large IT departments. The existing IT team "only" must concentrate on operating the purchased software and import the required updates. However, important IT know-how is of course missing, especially the knowledge of how to use IT for innovations. But that is precisely what is vital for digital transformation!

So let's keep in mind that buying software is a rather evolutionary way of innovating and is a typical behavior for digitization. With digital transformation, on the other hand, we are talking about disruptive innovations implemented through processes that have yet to be created, since they cannot be purchased in this way (after all, it would then no longer be an innovation, since the process has long been established). Digital transformation is therefore about new digital business models and the holistic use of IT for product and service innovations. Consequently, the only option here is to build it yourself. 

The previous example from the textile industry illustrates another important aspect: In digitization, people think in short-term, solution-oriented ways, whereas digital transformation demands more long-term, strategic thinking. This is accompanied by the distinction between thinking in systems (digitization) in contrast to thinking in processes (digital transformation). In the case of digital transformation, the innovative power is primarily in the processes, whereas in the case of digitization the focus is still on the existing product or service.

Which brings me to the next question, namely the necessary transformation of companies into IT companies. At this point, things are getting really uncomfortable for some companies. In combination with the process focus already discussed above, software development represents a special challenge for companies. Whereas they were previously able to avoid the, they can no longer avoid it in the digital transformation. This is a discouragement! Any non-IT based company will certainly see its competence everywhere but in software development. However, the absence of software development is simply no longer an option in digital transformation.

Let's take the example of the automotive industry one more time. This is a good example of the shift from products to services. Anyone in this industry that has not yet understood that the car is evolving into a smartphone on the move and that the future lies in software-based services will not survive. The outstanding engineering skills of German carmakers will no longer play a practical role in the future automotive market! This is frightening but unavoidable. That's why it's better for companies to rise to the challenge right away and not wait for the inevitable to sweep them into the abyss. IT will be everywhere in future business models (IT everywhere) and requires companies to have holistic product, process, and IT knowledge. This is quite typical for digital transformation, whereas local IT deployment and product knowledge and leadership are (still) sufficient for survival in the case of digitization.

Another factor complicating the situation: digital transformation generally requires several IT innovations (e.g., artificial intelligence, big data, the Internet of Things, etc.) to be orchestrated simultaneously to form new processes holistically, whereas digitization is always about punctual deployment. Obviously, selective deployment is easier for companies to cope with than the parallel combination of a wide variety of technologies and solutions.

This is accompanied by a massive change in the role of IT in companies. Currently, IT plays a rather passive, "command-receiving" role, especially when it comes to developing new business models. Innovative business models still originate primarily from the business side when it comes to digitization. IT subsequently receives information in the form of specifications on how these business models are to be supported on the IT side. The IT departments review feasibility, intervene if necessary to correct the situation, and finally deliver what is required. In terms of effort and workload, IT is primarily concerned with keeping things running ("keeping the lights on") and only secondarily with new business models.

This attitude is changing fundamentally in digital transformation! The triggers are, of course, the new digital business models, which can only be implemented using IT and thus only with IT. Here, companies now require an IT that becomes an active partner. Consequently, IT actively contributes to the design of new business models and is probably even the driver of innovative ideas. A change in thinking must occur here, something that is relatively difficult for companies with inflexible structures.

To enable the IT department to play its new active role, companies must take measures to give the IT department the freedom it requires to come up with new ideas. After all, as we have discussed above, at present the IT is mainly focused on routine tasks to maintain operations. Consequently, IT must be freed from these tasks to give the department the time necessary to develop its own ideas and fulfill its new role appropriately.

As a final consequence, the last-mentioned demand for more freedom for the IT departments requires another important change on the IT side: the reduction of technical debt. According to Wikipedia, technical debt is defined as follows:

"Technical debt is the additional effort that must be budgeted for changes and enhancements to improperly coded in comparison to well-coded software."

The maintenance share of software and thus the needed time for IT support therefore increases with the share of inadequately written software. Consequently, poorly written software should be avoided at all costs. How can this be achieved? By once again changing the way we think. Software development must be conducted as if a software product is being created. This must be differentiated from the type of software development that merely aims to complete a project successfully. When software development is approached with a project mindset, the primary goal is to complete the project in a given time and within a given budget. Software quality mostly falls to the wayside in the process. This is completely different with product thinking: Here, the developer must also suffer the consequences of poor software quality and be on standby in the event of problems. This way of thinking is certainly familiar to some readers under the term “DevOps”. DevOps, consisting of "development" and "operations", gets to the heart of the matter: the developer (development) of software is also responsible for its operation (operations). Simply put: "You build it, you run it". Every future decision must consider the impact on IT and its support effort! Conversely, decisions that restrict the IT's ability to act by incurring additional technical debt must be reconsidered or avoided altogether! To put it in a nutshell:

The ability of a company to act in the digital transformation depends directly on the ability of its IT to operate!

The performance of IT is therefore critical to the future development of a company. From the company's point of view, everything must therefore be made to increase performance and maintain it on a high level. This can only be achieved by reducing technical debt. All decisions that hinder this goal must be avoided. For example, current IT trends that companies believe will help them on their way to a secure, digital future are often counterproductive. RPA, for example, is exactly the inappropriate technology for a company on its way to digital transformation, as RPA increases technical debt. The same is true for microservices connected via eventing or BPMN-based process models that interact directly with the system landscape. All these possibilities may still be considered as acceptable for a digitalization. For a digital transformation, they are harmful on account of the increase in technical debt and the associated restriction of the IT's freedom! 

We are therefore dealing with several important paradigm shifts (making IT powerful and capable of action, product instead of project thinking, reducing technical debt) that will accompany companies on their way to digital transformation!

If we take a closer look at the approach (methodology) used in software development projects in digitization and digital transformation, the differences are the following: In digitization, the approach is bottom-up. At the start of the project, the project team analyzes the current status and tries to achieve selective improvements through IT. The procedure for digital transformation, on the other hand, is completely different: Without taking the current situation into account, the intended target state is designed and implemented top-down.

This saves the time-consuming, costly and difficult task of determining the current status, which is in any case unnecessary in the case of disruptive innovations that are intended to bring something new to the market. Conversely, an as-is analysis for innovation projects is harmful since the project participants' thoughts are narrowed by the recorded as-is status. Their thinking is no longer free and is influenced in such a way that the recognition of new paths is clouded by the actual state in mind. Furthermore, the start of a project without the inclusion of the actual status is quite unusual for a lot of project participants. Operating in a "vacuum" causes uncertainty. Like so many things in the digital transformation, this is something that must first be learned.

Serious changes also accompany the company's management on the path to digital transformation. It is no longer enough to "only" manage a company and its business and to lead into the future with gradual adjustments. As nice as the title MBA (Master of Business Administration) may sound for executives in this context, these individuals are incorrectly positioned when it comes to leading a company into digital transformation. Digital transformation requires significantly more entrepreneurship than digitization, efforts that are mainly focused on keeping the status quo. With digital transformation, the change must come from the top! The CEO personally must stand behind the digital strategy of his company and also set an example. Without a personal role model for the cultural change and  mindset change within the company, any digital transformation, no matter how well-intentioned, is condemned to fail!

But more entrepreneurship also involves more trial and error. The future is uncertain, and it cannot be determined which digital measure will ultimately be successful in advance. Therefore, companies have no other choice than to experiment. Here, an IT environment that allows fast “build - measure - learn" cycles is beneficial. Since digital transformation is about software-based experimentation, a software landscape with little technical liabilities is precisely the desirable initial point for implementing flexible cycles effectively.  You can clearly understand how closely interlinked the relevant discussion aspects are. Somehow, everything is connected. Consequently, a convincing IT strategy is becoming increasingly important for the survival of companies! Besides, trial and error is only effective if those responsible can also visually detect optimization potential. For this reason, more transparency must be introduced into IT departments. For example, this can be achieved in the context of process by using BPMN-based process models that are executed at runtime by process engines in precisely that way.

Last but not least, companies need to think about new partnerships and  networks in the digital transformation. Whereas digitalization still more or less focused on fighting alone, digital transformation is characterized by new alliances. At this point, I would like to remind you of Apple. Apple succeeded in revolutionizing an entire industry by collaborating with the music industry. Apple, a hardware manufacturer, shook up the music industry with the iPod. Instead of selling records and CDs, music is now available for download or streaming. A completely new business model for distributing audio content was created. This is where the inventiveness of entrepreneurs is required to launch the next innovation in new collaborations for other industries as well.

I would like to end my discussion of the differences between digitization and digital transformation at this point. The following table clearly summarizes the key aspects of the comparison:


  • Buy (+ customizing + build): Let others think

  • Standardized processes

  • Standardized software

  • Focus on IT issues (security, data protection, data management, IT infrastructure, employee equipment)

  • Evolutionary/sustainable innovation

  • Systematic thinking

  • analog business models largely remain in place

  • Selective use of digital solutions

  • Short-term solution-oriented thinking

  • Bottom-up approach

  • Product focus

  • Innovations primarily based on products

  • Product knowledge and product leadership are sufficient for a company's survival

  • Scope of IT deployment: local limitation

  • Selective use of IT innovations

  • Project thinking in IT projects

  • Development of business models: IT is a passive partner; IT is primarily concerned with day-to-day operations

  • Build-up of new technical debt

  • Company is a pure product and/or service company: IT plays a subordinate role

  • one-man crusade

  • Managing the business is enough (MBA)

  • Retains the status quo

  • Is made by technology*

Digital Transformation

  • Build: Think for yourself and take the initiative

  • Differentiates innovative processes

  • Tailor-made software

  • Focus on process innovation

  • Disruptive innovation

  • Process thinking

  • Emergence of new digital business models to solve customer problems

  • Holistic digital process approach

  • Long-term strategic thinking

  • Top-down approach

  • Service focus, implemented through processes

  • Innovative strength lies in the processes, product-accompanying through services

  • Holistic product/process/IT knowledge are a requirement for survival

  • IT everywhere

  • Orchestration of various IT innovations

  • Product thinking in IT projects

  • IT as an active partner: harmonious cooperation between business and IT

  • IT also has freedom to generate/drive innovation

  • Requires a healthy IT base to eliminate technical debt

  • Transformation to IT enterprise: IT drives future business

  • Networks and new collaborations

  • Demands entrepreneurship (with role model character)

  • Requires mindset/culture change - change from the top - CEO as the role model

  • Is made by people*

If you take a moment to consider this chart, the digital transformation are truly formidable! We really don't want to sugar-coat anything at this point. However, the following is also clear without any doubt: Digitization alone is not nearly enough for the turbulent times of digital transformation ahead. For this reason, it is important to me to differentiate between the terms “digitalization” and “digital transformation”, to clarify the completely different implications that need to be considered when deciding on one path or the other. Only digital transformation enables companies to survive. Those who refuse to embrace it will be able to survive for a few more years, even if the figures are favorable. However, this is deceptive – in the long run, all companies will have to deal with digital transformation. The sooner you start, the better it is.

Obviously, I wouldn't be writing this article if I didn't have a message of conciliation for you at the end: The process-driven approach is the only approach I know of that effectively and efficiently accompanies you on the IT journey to digital transformation! It is the only approach that provides you with positive support for all the elements discussed above.

 It is therefore worthwhile to take a closer look at the process-driven approach, and my website would like to help you with that. In any case, I wish you all the success on your journey to digital transformation!

*Following the publication of this article, I have received a nice complement from Mr. Georg Kästle. He wrote in response to my announcement of this article on Xing: "Digitalization is made by technology. Digital transformation is made by people." I liked this feedback so much that I immediately included this difference, so accurately formulated by Mr. Kästle. This description demonstrates one thing very clearly: people and their creativity are now becoming more important in the digital transformation process. This aspect alone should motivate us to take people along on the journey to digital transformation! I would therefore like to thank Mr. Kästle for his contribution.