The language of digitalisation

From big data analytics to agile working – digitalisation has its own language. In order to promote digital transformation, a common understanding of this language is necessary. In the blog, CDO Mark Klein introduces two key terms: agile working and the minimum viable product.

Agile working, minimum viable product, artificial intelligence, big data analytics, machine learning – these terms represent the language of digitalisation. I have noticed that more and more people are using these terms, but they understand them in different ways. Often, people do not question them, as they do not want to come across as uninformed or unaware. The problem is: if we do not speak a common language, open discussion becomes difficult. And that is necessary to make progress in digital transformation!

Questions are welcome

In a previous exchange with ERGO colleagues, I was impressed by those who were curious and dared to be honest – for example, those who asked me to explain certain terms. I hope that more colleagues find the courage to be honest about what they know and ask the questions that are on their mind.

That is why I am writing today about the language of digitalisation. I obviously cannot explain all the terms of digitalisation in just one blog post. As a first step, however, I am focusing today on two key terms that I feel are the basis for digitalisation: agile working and the minimum viable product.

Agile working

Agile working originally comes from software development, but has now entered into other areas of the company – for example, when it comes to launching products. Agile working is increasingly replacing the so-called waterfall method, whereby a rough and a detailed concept are generated one after the other. They are then programmed, tested and subsequently implemented for the product. It can sometimes take 18 months before it is actually put into place.

Agile working, on the other hand, relies on interdisciplinary teams, with colleagues from the business line department and from IT working closely together. They develop solutions over a short period of time (often 1–2 weeks) – these are called sprints. For colleagues from the department, this approach means that the overall, generally complex end product is not the aim of the development process, but rather simpler solutions. This solution is designed to meet the most important needs of the customer, but does not have to satisfy all possible requirements. If the customer wants to get from A to B, for example, then the focus of agile working is on developing a scooter rather than a Bentley.

The advantage of agile working is that we are quicker in reaching a tangible result, which we can use to gain experience by discussing it with the customer. Agile working often leads to the minimum viable product – the second term that I would like to outline here.

Minimum viable product

What is the first step when creating a smartphone app that offers ERGO Self Service? We assume that customers wish to use such an app – but we have to make sure that we are correct in this assumption. It takes almost no effort to develop an app that has the same content as the ‘Meine Versicherungen’ (‘My Insurance’) website. It can easily be uploaded to the AppStore and Google Play, featuring a very appealing description. This way we can already find out whether we are correct with our hypothesis that customers want a Self Service App.

No hypothetical ‘would you download an app like this?’, but instead a real-life test – only the actual number of downloads is counted. We will only continue trying to achieve our original aim and further develop the app step by step if a large number of customers download the app. This ‘basic app’ that we produce is a minimum viable product (MVP). This product therefore makes it possible to test a hypothesis in practice with great efficiency – using minimal resources.

An alternative would be to develop the entire app first, and then possibly realise that our customers did not actually want an app for this purpose in the first place! An MVP therefore helps ideas that seem good on the surface to fail early on – by trying out a ‘basic product’ with the real target group. And finally, learning from it and making it better as we progress.

I hope that this blog has shed a little light on the topic of digitalisation. Are there any other topics regarding digitalisation that are of particular interest to you? Let me know! I will be happy to look at them in a future blog post.

I await your comments, questions and suggestions with eagerness.
Mark Klein