From machine to digital services: Equipment as a service

David: Welcome to MFT 104 and to our session called From Machine to Digital Services. I'm David. I'm part of the AWS Solutions Architecture team for manufacturing back in Germany. And today I'm pretty excited to share the stage with one of our customers from Germany, which is Heidelberger Druckmaschinen.

I'm joined by Matthias who is a Product Owner at Heidelberg and Jörg, who is a Cloud Architect. Thank you. Thanks.

Now, if you don't know what Heidelberg is doing, if you might have never heard their name, well, it's pretty likely that each and every one of you here in the audience has um in the last few days been in contact with the product that was at least partly produced by one of Heidelberg's machines. It might have been the box of your favorite sports shoes that might have been uh packaging of the cosmetics you used this morning in your bathroom or it might have been the label on the bottle of your favorite drink you had last night before coming to re:Invent.

So, Heidelberg is a German precision engineering company and they build industrial printing presses among a few other products and you could probably say that Heidelberg is a poster child for the typical German engineering or made in Germany brand. They look back at the history of over 100 and 70 years and they've building industrial equipment, industrial machines for a long time and probably long before uh Las Vegas was actually founded. So that's, that's pretty fun.

Well, today we're gonna share a story from Heidelberg and, and how they use cloud and how they used AWS to transform the print media industry and to drive a new business model in in their market, which they call Heidelberg Subscription or more generically Equipment as a Service. And we are also going to learn how they build a technical scalable foundation on AWS to facilitate that.

Now at AWS, our goal is to enable our industrial customers and um any manufacturer basically to use cloud and the valuable data in their companies across their entire product life cycle or their entire value chain, right? That means we typically divide this into different solution areas and you will find the solution areas sprinkled around the different re:Invent sessions and workshops and and demos. We have available here to re:Invent starting with engineering and design, for example, right? We, we help customers on that end to leverage data or leverage leverage cloud to build their products faster and more efficiently um reduce time to market on that end. For example, we're working together with automotive OEMs like Celant to build things like the Virtual Engineering Workbench that allows engineers to build and test and validate automotive software faster. And there's also a workshop uh this week if you want to check that out in more detail, of course, supply chain is also a ever important topic. And we of course also work with a lot of customers on that end. And we also tap into Amazon's vast experience in that area of arguably running 11 of the uh the most complex and uh biggest logistics operations on the planet.

As you go ahead and start manufacturing, um the product you in the industry you're in. uh we talk about smart manufacturing, right? and, and that really means bringing the data from the shop floor into the cloud leveraging modern analytics tools to be able to make fast uh insights, uh get fast insights and make data driven decisions on top of that data. And we also work, for example, with companies like Northvolt who are a Swedish battery manufacturer in automotive electrification. And they, for example, build something they call the Shop uh Software Defined Factory, which allows them to roll out new connectivity, blueprints to new factories as they keep expanding their factory blueprint. uh the factory footprint.

And the last area is what we call Smart Products and Machines or Smart Products and Services, right? And this is really everything around equipping the product you build with smart technology or with connected features that can really reshape the way your customer experiences, that product and the reason i like this a lot is because it can have a quite significant impact in the relationship you as a manufacturer have with your customer and also on your business model.

So what does this change in business model mean for a manufacturer like Heidelberg is small now on a historic look onto the industry, right? Many manufacturers, you could say come from a very asset centric or equipment centric background specifically when it comes to what they offer to their customers. So typically, um a manufacturer like Heidelberg would offer a machine as a large capital expenditure to their customers and they buy it, um put it in their factories and advertise it over a bunch of years. Of course, the full truth is that within the last 10 to 15 years, we've also seen a strong trend towards more contract oriented models, right? That means for example, um offering additional machine service contracts on top of the pure equipment or giving customers access to spare parts and consumer bills from you as a 1st, 1st party, basically as a manufacturer and slow and steady. Many manufacturers have been building out this landscape of contract of contracts with their customers, right? And there are many reasons for that. um And it's of course, no secret that already today, many of those contracts and subscription offerings drive a significant part of the margin for many manufacturers and industrial companies realize that they need to build out a persistent custom relationship to be able to make that work. And they also realize that just the pure equipment offering by itself is in many markets with a high competition, not necessarily a key differentiator anymore.

Now, we also see a key trend of many players and particularly the ones of germany pushing this trend even further. That means they really go towards um centering the entire value proposition of their offering around the end to end experience and around the outcome that machine generates not only more around the physical hardware they offer, right? So they add additional components to the mix, like for example, performance consulting, which means that their customer success agents, for example, work on a monthly cadence with their customers to uncover machine inefficiencies and try to troubleshoot these these issues to raise the machine efficiency overall. And of course, digital digital products play a big role in that. And that's certainly a topic that we're gonna dive a lot more, a lot deeper into today.

But what we would now call a full Equipment as a Service offering really is going away from selling this uh machine as a capital expenditure, right? And adding a bunch of contracts on top. But really consolidating this entire landscape into one subscription offering where you would even charge your customer by the outcome or by the in Heidelberg's case, by the sheet you print or by the bottle, you produce right, whatever machine you're building and that's really, um, not so different than the pay as you go pricing. We, i guess all know and love from AWS. Right.

Well, why am i telling you this on an AWS conference? Right. You might ask, um, well, we believe that reliable and real time data from these machines are key to make that work. We think you cannot do it without it. And this becomes quite apparent if you look at the different components of our sales package individually to understand why if we take for example, machine services, right, using things like scalable remote service solutions or um automated decision making based on the machine data that allows you to scale your service uh from the machine and your maintenance efforts across thousands of machines that are deployed on customer sites. Because in such a subscription offering you as a OEM you as a manufacturer are now responsible for keeping the efficiency as high as possible because you're also, of course, financially incentivized when you do really this, this pays good pricing.

One similar things go for performance consulting, right? You wanna give your um your customer success agents access to latest and greatest analytics tools based on that machine data to quickly uncover those machine inefficiencies and work together with a customer to raise this uh to raise these KPIs.

Now I could go on and on here. um But I think it becomes pretty clear that we, we really need a technical foundation that is able to scale across all of those different components of our subscription offering. And um, well, we of course also realize that for many manufacturers, the reality is that this, of course doesn't happen overnight and working with um a few of the key players like Heidelberg, but also other ones, we've observed a few challenges that manufacturers are typically faced with and there are quite a few more than four. I just want to highlight four of those here and one of the most important ones, but maybe also one of the most complex ones comes back to organizational transformation. And that really means how you do software development, how well you adopt DevOps practices, right? How you do product management, how, how close your engineering teams are really to the requirements of the customer and understand that to reflect that in their road map. And what we we've also seen is that things like breaking up data silos for many manufacturers, they have been growing various solutions over the years that have, that might have siloed data in different departments and to be able to make such a such a subscription offering work properly, you might need to be able to tap into those different data pools and and unify all of your teams under one. vision, data sharing is an interesting one as well, right i mentioned previously it doesn't really work with all the data from those machines, but you might have customers that say, i don't want to share my data. There might be reasons for that. Some might be more valid than others, right? What we've observed is that it really comes back to the value proposition you're putting on the table and to really convince your customers why they should care about that and what do they get out of it? And as we will hear later from Heidelberg, there are some very convincing numbers as to why they should really care about it.

On the more technical end. Of course, we also discuss things like scale. That means um how do you scale your connectivity to tens of thousands of assets and machines deployed on the customer sites in their networks? How are you able from a technical perspective to operate those to push down configurations to those devices? um And, and also operations of of the digital platform in the cloud, right? Many manufacturers um might have very great experience in building embedded software or um desktop software. But as you now go ahead and operate solutions for your customers in the cloud, you kind of become a s a provider and that has some particular challenges to it as well.

Now, as you go ahead and rebuild all those capabilities, right? um this might look very much different depending on the industry you're in the product you're building and also your decision, whether you build all of this yourself or whether you integrate some existing solutions here and there. We've observed a few patterns that i want to share with you here. But we're also going to flesh this out in a more architectural detail in the later part of the session.

um But nonetheless, i think it's also pretty clear that you will need a secure way of ingesting data from tens of thousands of assets deployed in the field. You will need capabilities for managing that fleet, for pushing down configurations and updates for managing the security of those devices and many customers of course use AWS IoT as a managed service to quickly get them to where they want to be. And on the other side, right? You also want to secure the access to those tools and platforms and solutions you're building and funnel any insights downstream to your systems like a customer portal where your customer can see their key KPIs and make decisions already on their own, but also to your own enterprise systems, integrating with the ERP for example, to do things like the paper use billing, right? If you want to charge a customer on the use, then you need obviously the data to do that same as AWS in some sense.

Red, we also find typically capabilities like multi tenancy because that you operate potentially sensitive data from thousands of customers. You need to be able to scope the permissions to this data accordingly. um Which means you need to build out multi tenancy capabilities. And as you bring in all of this data into your platform, right? It also gives you unique opportunities to build out new digital products on top that can step by step, build out your entire digital ecosystem, which means using all of this data to build new more advanced predictive maintenance solutions, for example, or or any other use cases. And there i would say very creative ways our customers can come up with. And we're going to hear some very concrete examples from Heidelberg.

Well, i mentioned we're going to flesh this out in more detail. um But at this point, i'd like to hand it over to Matthias to tell us more about the great products Heidelberg built and their journey over the last few years.

Matthias: Thanks for the introduction, David. Good morning. I'm Matthias. I originally started with Heidelberg as a software developer and moved over the years into a position to have a product owner. And now I'm responsible for several of our digital offerings. Working for Heidelberg is always exciting and offers as well opportunities to explore new horizons. We will share with you in this talk.

David told us about some print products that might have been printed using a Heidelberg machine. These prints are part of the global commercial print market which even in today's digitized world sizes around €400 billion a year. This is a huge market and we believe this market offers lots of opportunities for the print media industry.

There is a long history for our company. Heidelberg is active on market for more than 170 years. Heidelberg's core business is oriented to the whole value chain at our main target markets which are commercial and packaging, printing and we deliver solutions to make our customers successful in its markets.

Heidelberg achieves a yearly revenue of €2 billion realized by approximately 9500 employees. And Heidelberg is active in around 170 countries across the globe. Heidelberg is also active in new markets like e mobility, but the main market is the print media industry for this.

We are delivering several kinds of equipment as well as software solutions for process automation. But manufacturing of sheet fed office press is the core DNA of Heidelberg. Hedberg is the market leader for sheet fed office press with a market share of more than 40% sheet for office process.

As you can see one on on this slide there, i think it's a perfect sample for german precision engineering. Once i was told there might be more parts in such a Heidelberg machine than in the Boeing 747. Anyway, if this is true or if this is wrong, a Heidelberg machine is a swiss clockwork in x xl.

Well, we are proud on the quality Heidelberg finally stands for and we are also proud on the printing quality. You can get out of such machines. It's really incredible which position is required to get high class prints.

We take pride in the performance these machines delivers which is enough to cover more than two soccer fields with printed sheets in an hour. And we are as well proud on the reliability of the machines which results in a machine life cycle of 15 years and more.

Well as a conclusion, if you would have the chance to watch the Heidelberg machine during production, you shouldn't miss it. I promise. It's really fascinating.

Well, what about the challenge we sell machines, why we've been thinking about new business models? Heidelberg delivers machines with the increased productivity machine generation by machine generation. Plus, Hedberg delivers as well as software solutions to optimize production processes in print shops and both in combination results to a productivity increase at our customers of 5 to 10% per year and increase productivity on the one hand side and assuming a constant global print production volume. On the other hand side leads to lower demand for new machines in the market and hence causes a massive impact to the Heidelberg coal business. And this motivates to think about new sustainable business models by increasing the scope to customer success.

We already started in 2017 by introducing a new business model, we call equipment as a service and reduced its essential core. This business model works quite simple. Heidelberg is shipping the machines and the consumables and the customer pays by outcome. So it's a kind of a pay per use model. There is a basic monthly fee that includes a certain amount of sheets for printing. And if additional sheets are printed, additional fee is required for Heidelberg.

Introducing this business model was as well as the starting point from a transaction of business to recurring revenue. And in moving from a transactional business to subscription, this means as well that the customer relationship is changed significantly from a one time transaction to an intense partnership where both parties are interested on the success of the other. For example, both parties are interested to increase the productivity and the strut the customer can count on. The Heidelberg gives the best support to optimize the machine operation. And this support enables our customers to realize additional output and hands to achieve additional revenue and profit.

And there's another immediate benefit resulting out of the business model. Our customers can decrease, they are capital expenses significantly and can replace it by more predictable monthly costs. This is how we started and our customers were demanding for more subscription offerings addressing the whole value chain. So we extended equipment as a service to Heidelberg subscription by adding more offerings related to software service and training and consulting and making each of these elements successful requires a complete new view on the availability of data.

But making this model altogether successful means the ability to integrate all these elements seamless and talking about seamless integration. I mean for example, it's about to integrate equipment, software and consumables to know about material consumption at the customer side to be able to deliver new materials right in time or seamless integration means for example, to integrate equipment software and service to make offerings like predictive monitoring, that means to know about machine problems right in advance and to fix them before they would occur to guarantee the machine availability and well seamless integration means for example, as well to integrate equipment, software and training and consulting, to notify customers about issues seen related to productivity or machine operation in real time and to enrich these notifications by solution suggestions or consultancy offerings.

Well, for us, subscription is a complete and optimized system of offerings we deliver to our customers and any of the elements is tuned towards productivity and quality to meet our customer demands and all this is driven by data. So we see in practice what david already mentioned in the in the introduction, reliable and real time machine data is at the core of business oriented subscription models, subscription oriented business model, sorry. And with other words, data is the key to redeem the value proposition of such business models, the more complex a subscription contract model, the higher demands are placed on digitalization.

We design different sets of subscription contract models for our customer offerings by keeping in mind the subscription contracts for a sustainable business and it's not only about to offer a new sales model. It's about the digitalization of all the relevant processes to run such models successfully. And it's as well about the digitalization of all that process to scale this model successfully.

Maybe just to say it a bit over it. It's no longer about to have a day by day call to the customer to learn about the material consumption or to handle customer invoices manually by excel or to scale by hiring additional staff to the to the back office process. Digitalization is the key success factor for subscription based business models and as well for sure for scaling that models, if you want to scale it, let's say horizontally by adding more machines or vertically by adding more or more complex contract models.

All this we discussed already several years ago and at this time, we already ran several software solution that contributes to this idea. And so we've been delivering successfully a tool set of software solutions. We call connect explicitly made for process automation and print shops. It is already insult at several thousands of customers. Connect is built based on his retail architecture and made for on prem installation at the customer side. But connect is as well an important pillar for the software development at Heidelberg and also a major experience in our know how of software engineering.

For example, we've been doing iot since 2005 back then. Nobody was even talking about this as i and we've been doing io based on data ingestion of machine log files. So we already got a large amount of machines connected and we gathered lots of data plus, we ran already a solution that enables our technical experts to support our customers in case of problem remotely.

But based on the history of that services, we were faced by a number of learnings of these existing solutions that may be known to other companies as well. We've seen issues related to data silos. So the data had been managed in different solutions and the data were neither linked to each other nor available for a general usage.

We were faced by some issues related to maintenance efforts and maintenance costs. So all these solutions had been built, what i would call problem oriented. It means from scratch by a mix of own solution and board products. And it made it really hard to maintain and to innovate these services, we found issues related to data consistency because based on the data we had available, we created figures out of it and the figures finally did not match to each other. And this results in a lack of trust at the customer side to the figures shown we missed the flexibility for the integration of all the elements. I was already talking about how important it is to have a seamless integration of of all the elements of a business model.

And finally, we missed near real time capability because based of the technology for data ingestion, we used data had been available for further processing hours or days after the data had been created by the data producer. So we learned that we can't map building new sustainable business models on the existing software structure. And we had to think about a complete new approach and about a new data platform, we decided to step further and to build a cloud based data platform based on aws. And the purpose of the platform is to combine all these relevant all the relevant data and to build data driven applications based on this platform.

After getting this understanding, we had some intense discussions about make or buy and to be honest, there had been different opinions in the company about that issue. Finally, we decided to build the platform by our own. Why did we opt to make and not to buy? Primarily, we decided to build the platform by our own because of the strategic importance of this platform to our business models, we have to keep the data in our own hands and we have as well to guarantee the accessibility to the data. At any time, we decided to build the platform as well by our own simply due to the matter of speed and to to the ability to act because we know how important this is, it is to react on new demands and on feedback quickly and flexibly and last but not least we decided to build a platform by our own simply to have the best option for a flexible integration of all the services.

Well, i have to admit that the decision to build a platform by our own was a challenging decision for a manufacturing company and it was as well a challenging decision for a team of software engineers used to build on prem applications for a long time. And well, this decision as well gave us definitely some sleepless nights. And with that, i will hand over to you and you will tell us more about our technical journey where we started from and how our technical solution supports our business vision.

Thanks Matias, I'm cloud architect and i spend most of my time in the engineering room about three years ago. It was winter cold and dark outside Matthias. And we sat together and talked about the cornerstones of how to implement the solutions that were solved and to make the business vision available.

The challenges Matty told already about the equipment as a contract, the equipment as a service says, we really growing quickly, this increased the high, this increased the pressure on the service teams and they were really struggling to catch up with the sales. We were not able to grow the workforce at the same speed. So the goal was clear, we had to improve the productivity of our service teams for the cornerstones. We we decided that whatever we are going to build has to support near real time data processing. And uh it has to support um large amounts of historical data and make it available for further analysis and machine learning and similar tasks.

And we want to set up uh independent product teams that can solve the business goals by themselves and don't depend on others and don't have to wait for others. So, uh basically, we are talking about uh def fins teams and Matthias told you already that we are coming from on premise development. So we expected to learn a lot and that's why we wanted to iterate really quickly learn fast, fail fast and adjust accordingly.

For our first step. we wanted to take care of the connectivity of the machines. um so this is what um our first solution looked like going from left to right. uh we integrated the iot client in the printing machine in the print shops which is talking via mq tt to the aws iot core, the iot core forwards the data to k's data streams. and um and aws lambda function is filtering the data for relevant parts. um with the connectivity available, we wanted to show the data in a real time dashboard. and um the, the lambda function filter the data for exactly the information that we were looking for and stored it in the dynamo db. we attached a web application to it um that will show the data from the dynamo db.

After six months we had three fi test customers connected to the system and we were working with three developers and came up with our first dashboard in this dashboard, you see five tires and each of these ties represents one of the machines of a customer. and you can see the progress of the currently running print job. you can see the speed at which the machine is currently running and you can see the print job by the name of the print job that's currently running there as well.

It felt like a really blazing fast development time with a small team of three developers and we were having the data in the real time. so from um the data or the state of the machine changing in the print shop until it was available on this dashboard was around two seconds or even less with this success. we now thought about how can we transfer these learnings to our next business cases.

um we went back and had to look at our backlog and searched for the business cases or the user to that would make really the most impact and we came up with two different use cases. um the first use case we were handing was um doing file transfers from the machine and make the fight files available to the service technicians. um when, when our sales technicians handle issues at customer sites, one of the first steps that they do is collecting the latest log files from the machines. and in the previous solution that matthias mentioned, it took hours or even days until this data was available. so the time until the service technicians can really start working on, the problem was already in a scale of days, we thought that we can improve on here. and this was our first use case that we wanted to take care of.

um you see the iot platform is there is the start of this journey with the iot client and the iot core. um and we started a web application that that is available to our service technicians in this web application. the service technicians can see a list of files that are available on the machine and they can request these files. the file request is sent via lambda function and kine data stream to the iot core. the iot core forwards the request to the machine and the io client on the machine uploads a file into an sv bucket after the upload is complete and handled, it's available to the service technicians and they can start their analysis of the problem.

yes. after launching this, the service technicians are really happy. they were a lot faster in handling the cases. they came up with a couple of ideas and features. you can imagine, for example, they wanted to request the data while the machines are still offline. a couple of customers turn off the machines when there is no shift active and the service technicians just wanted to queue the transfers. we added the dynamo b to handle these cues and they were really happy with this with these learnings

Jorg: We, we had to look at our next use case. It was a more complicated one, more challenging one, but we felt ready for this. Um so a lot of the software, a lot of the issues and especially the software related and human related issues on the machines can be solved by the user interface or by using the user interface of the machine. Um and um making this user interface available in a remote desktop uh session helps our service technicians to remotely handle a lot of these issues as well.

We had to look at a couple of third party services that would enable a remote desktop solution from the service technicians desk to the to the machines. But a lot of these third party tools require larger installation of software on the machine. They require installation of client software on the service technician computers, which both involve a lot of maintenance for, for these parts on our side. Um larger updates on the machines, we have to handle the client on the computer. So it didn't really fit to our expectations and plans.

Um but we knew that there is already a vnc server on the machine. The vnc server was used already on premises to remotely connect to the machines and handle and control them and handle issues. On them, we found a web based b and c client that we could integrate into um into our web application for the service technicians. Um but now we had to find a solution how to connect these two parts.

Luckily aws launched the secure tunneling gateway a couple of months before and it looked like a perfect fit for, for our task. It talks and web socket as protocols which works for from the io client side on the machine. Um it helped to reduce the amount of protocols and ports that the customer has to adjust on the firewalls. And the even better part was that our web application can talk directly to the tunneling gateway.

We extended the web application that it's uh that the b and c client can connect to the tunneling gateway and the tunneling gateway um connect the tunnel client from the machine. This enabled our service technicians to after analyzing the files to directly connect the machine from the same web application. Our service technicians were really happy with this and really um yeah, could handle the problems on machines a lot faster.

Here you see an example, screenshot. On the left hand side, you see the list of files that are available on the machine for download. And on the right hand side, you see a vnc session that is currently showing the interface of the machine. So after less than two years, all our technicians were working with this new tool. We added some features. But these two use cases really made the difference for them and help them to keep up with increasing workload.

And to be honest, the pressure forced us to really think about the right priorities. But we were lucky as well. We had the right team working on the right features at the right time. And today there are around 3000 remote sessions handled per month and um we transfer about half a million of files elsewhere per month. I think a service technician can handle significantly more machines than before. And the it team consists of four developers that handle everything that's related for the development operation and security of this application.

After helping the service team to, to scale and handle the efforts and workload, we thought now about how can we scale our development teams and take our learnings to build the the additional or the next and upcoming digital products that heidelberg was planning. And uh it turned out that having the iot platform as a as a basis and the foundation for our digital ecosystem really made sense. So it handles the basic connectivity, the authentication, um data validation and all related tasks and makes the data available for for other products.

Um the small and independent product teams was really something that helped on the success and using serverless technologies and services helped them to focus on the business logic instead of infrastructure or other related tasks. And um the remote service was the first product that we launched. Um i told you just before the next product was the insights product. The insights product is a tool that's available to our customers. The customers can um look at um at the historical performance of the machines and they can compare, for example, the impact of different supplies on their productivity. And the third product that we launched that fits into this pattern as the maintenance manager and the maintenance manager helps the customers to organize and keep an overview about the maintenance work that is related to the machines. The service technicians can use this tool as well to have a look at what's completed or what maintenance has to be done.

During this journey, we found that many products will require a lock in of our customers and a sign up and this was the reason why we launched the heidelberg customer portal as well here, our customers can sign up once and get access to all our different products. Yeah. Um and with this, matthias will tell you more about our um our achievements.

Matthias: Thanks Jorg. Well, what have we achieved? And first, let's have a look for the technical achievements in general. York reported how we made our data platform and the first digital products and all had been done from scratch to production within 14 months and taking into account our starting point and as well, taking into account the complexity we've seen we think it's a good example in putting ideas into practice in quite a short time.

Our data platform provides what we call nerea capability from its beginning. That means there is a processing time and maximum of two seconds between the data and just from the machine and the availability of that information in the customer's dashboard. This is a processing time. We finally aim for and to build our use cases and to to implement solutions on it.

And seen at the operating cost, we see a decrease on the operating cost of 50% compared to the platform we've been using before. Well, in the meantime, we further developed the platform, we did the global roll out of the platform and as well, we added improvements and other features to the platform.

Today, we are able to manage more than 15,000 assets reliably and these are several kinds of machines, software components and maybe some more data producers and these approximately 50,000 assets are shipping around 30 million of tem records any day. We see as well as an achievement that we are able to manage approximately 5050 deployments per month. Maybe some of you might have expected more but taking into consideration that we previously did two deployments per year for our on prem development. We see this as a remarkable, a remarkable accomplishment for us and well for sure, not yet. The end, having a look for the business achievements.

We've seen that printing machines under subscription performs better than printing machines, not under subscription. This chart shows the increase of several important productivity kpis for sheet fit offset machines under subscription. And this is based on a study of an asian market. And we see that there is a significant increase on productivity for these machines. And it makes it obvious that there is an immediate customer benefit out of this subscription offerings for heidelberg.

The recurrent revenue achieved by our subscription offerings is an important pillar for a sustainable business. Heidelberg managed today more than 15,000 subscription contracts based on different subscription offerings and this results in a 30% share, a recurrent revenue share of the total revenue for the last fiscal year. And this is also the reason why we see ourselves as a trendsetter for the machinery industry with regard to the subscription offerings.

Well, based on the growing business scope to recurrent revenue and to subscription offerings. We extended our development scope from on prem development to cloud technologies and there had been some learnings along the way, we want to share with you and there are mainly some learnings related to the technical challenges. As said, we started our transformation with a team of experienced developers but used to build on prem applications for years. So we started with a very, very little cloud experience.

And originally we believed in that the technical challenge would be the main hurdle on this way but supported by aws and several training and consulting offerings and as well supported by experienced external partners, we made it to inspire the whole team to cloud technologies. And after initial thought, it was a kind of a cell free enforcing process. Well, today, there is still the need for a continuous learning to ask for anybody in the software industry. But the technology know how is no more the limiting factor with regard to the organization.

We've seen that it was very helpful for us that we could manage all the major decisions on this transformation in a single organizational unit of our company. And as well that it was very helpful for us to have the complete backing of the top management and as well as the stakeholders which was totally given for us, we completely changed our organization to manage this transformation.

And we formed approximately 20 teams based on the principle that these teams are able to act vertically and really to carry the responsibility resulting out on digital products or cloud services. And this change in the organization was one of well was, was an important challenge for established organizations because this is quite uh really a a big step to go.

And next to the responsibility in changing the development teams to this or to enable different development teams, the teams must be willing also to take the responsibility to take the responsibility for the decision making to run digital products successfully. And so the teams must be willing to take the responsibility. The organization must also be willing to transfer the responsibility. And this is a learning process both to the teams and as well to the organization and to the management because the management must also be willing to hand over parts of the decision making processes to the teams by keeping the overall responsibility.

And finally, a few words for cultural challenges, which based on our experience is the most important challenge of all. And primarily, i mean about uh that it's really important to keep in mind for the teams. What agility means? You may say this is a common sense, but it's based on our experience necessary to have this day by day in mind. Because finally, time to feedback is one of the most important and time to market beats everything and related to the c challenges as well.

It's about to enable the teams to carry all the responsibilities resulting out of de ops or de se fin ops as we are calling it. This is something we are still working on, but we are in a good way. Well, finally, what's next based on the experiences gained and as well encouraged by the success in building the data platform and the first digital products, we've already been continuing and started to build a heidelberg ecosystem.

And the ecosystem is for us to consolidate all the digital touch points and to provide the ecosystem that could get used both by our customers and as well by by the internal heidelberg experts. And this is still another exciting plan and we are looking forward for the next steps to go. And with that said, i will hand over back to david.

David: Yeah, thanks Matthias and thanks for sharing that very exciting story. And thank you for listening in today. Um I hope you liked it. Um I would ask you to please take one minute to rate us in the aws events app. And I'd also like to invite you to our expo hall where we have a bunch of very exciting demos and put or you can, you can check them out and we also have uh a bunch of experts there. You um can talk to you about those demos. Um it should open today at 4 p.m. and with that, thank you.