This podcast episode shows manufacturers how to make their devices IoT-enabled and manufacturing companies how to optimize their parts management using an IoT scale. In episode 63 of the IoT Use Case Podcast, HK.SYSTEMS GmbH, partner for digital business models and fast, effective entry into digitization, has brought along two subsidiaries – HELICOM and ROBIOTIC – to present the solutions for this.
Podcast episode summary
Many manufacturers of devices, industrial automation or components are nowadays taking the path of making the data from the hardware usable for customers and developing new services! Why? Up to now, traditional hardware sales have sold these in large quantities – according to the core business – but today end customers want to use the data from the devices and components more and more and integrate them into their processes – this calls for new competencies and digital solutions.
It is precisely these new business models and services that are presented in this episode using the example of three realized use cases: including a use case with the company WÜRTH – the specialist for assembly and fastening materials – with the company Würth Industrie Service GmbH & Co. KG and a use case from the area of “hazardous materials” (DENIOS).
It shows what is important for customers here, what business models arise, and how to get to the first IoT product in six weeks.
The topics and competencies at a glance:
– Speed of implementation: from idea to functional sample in 6 weeks
– Development expertise from the hardware to the operation of the solution
– Self-sufficient and flexible solution through mobile radio transmission WITHOUT involvement of local IT (e.g. WLAN)
– Long runtime by using NB-IoT radio standard and intelligent algorithm of transmission
Madeleine Mickeleit’s podcast guests in episode 63:
- Sven Ehrmann (CEO & Head of Digital Business, HK. SYSTEMS)
- Thomas Krekeler (CEO, ROBIOTIC GmbH)
- Viktor Giesbrecht (Company Management, HELICOM)
Podcast interview
Sven, I think many IoT projects are still in the very early stages. There are the proofs of concepts that have been launched, but many projects still fail – or at least there are challenges, shall we say. In your view, what are the top 3 reasons why digitization projects fail today?
Sven
Thanks for the really good question, Madeleine. The exciting thing is that it hasn’t changed that much over the last few years. I have been involved with digital business models and M2M and IoT topics myself for almost 20 years. And the biggest challenge that still exists is – and this will be familiar to very, very many customers, especially from the German SME sector: Know-how and resources.
Do I really have enough know-how in my own company? Employees who understand digital issues in depth, both on the hardware and software side? And do I have enough resources to actually pull off such projects? This is something we talk about a lot with our customers, and of course we are a good partner to be able to support them in these matters.
The second point is the whole issue of interface coordination. We have a very, very wide range of different issues to be realized in an IoT project. This starts with the IoT devices, i.e. the hardware. It’s all about data transmission, i.e. connectivity. We have the whole issue of data handling in the cloud – how do I handle that data? How do I put it out again? … I have interfaces to my own systems or maybe even to my own applications, and I have to run that. I need service for it. And not to be forgotten at the end of the day: of course, IT security, which is immensely important to provide safety.
And even if I have specialists in individual areas – coordinating these interfaces is a major challenge and often eats up an incredible amount of time in the projects. This also leads me to the third reason: the fear of failure. What we notice again and again is that as soon as things get difficult, especially in the form of it taking longer than originally assumed, projects in the digitization environment are often already viewed critically, sometimes even discontinued. Not at all because they were on the wrong track. But because there are simply hurdles in between that become difficult at that point. Which indicate that it will take significantly longer. And that’s where it’s important to simply realize from the very beginning, how can I coordinate these interfaces perfectly, or coordinate them in the best possible way, so as not to waste time unnecessarily? But also to have the courage, when things get difficult, to go over that hurdle and then successfully tackle the next steps.
Having the courage to go down this path – of course, it requires new skillsets and corresponding know-how. But I think these learning curves can also be taken together, tackled together. That’s why we in the IoT community are super keen to learn from existing projects – use cases, as we call them. Just to know, how do others do it? What experience can I use there? How do others deal with these challenges? What use cases did you bring from the field? I would also like to dive into one of them in detail to understand the project.
Sven
On the one hand, we have brought a project with us today that we have successfully implemented over the last few months with Würth Industrie Service – this is a company from the Würth Group. Now we are in the series and support Würth Industrie Service where they can optimize their service at the customer’s industrial plant and thus be even more successful on the market.
Thomas, Viktor, you deal with a wide variety of customers – do you have an example to get you started, so you understand where you are also heading?
Thomas
One of our most exciting customers is DENIOS SE. DENIOS is the world market leader as an equipment supplier for the storage of hazardous and noxious substances. This means that there will be DENIOS products in every industrial plant. They have 16,000 catalog products, but they also supply large room systems – really forged chambers that are then driven on semi-trucks to industrial customers where hazardous materials are stored. They have been on the market there for many years and are active worldwide. What is exciting about this customer is that they are focusing on their core business and have brought us on board as an extended workbench for the digital business. DENIOS is very innovative and also innovation-driven. So they want to reorganize the business. We don’t just supply hardware here that we develop together with them, so where Viktor’s and his team’s competence plays into it – that delivers data from A to B. Instead, we supply the complete cloud system, but also the application at the back, which triggers the processes relating to the handling of hazardous substances. That is, until now DENIOS sold pure hardware – now they sell the good feeling of security. Because the processes around hardware are now digitized.
So quasi a new business model for DENIOS at that point
Thomas
That’s right, completely new business model. It’s a very customer loyalty-intensive application that they’re delivering there. So in addition to the leakage sensor, now the automated processes.
So then we have a project that you have in logistics, together with Würth. Then now the hazardous substances part with DENIOS. Viktor, do you have a third project that we can use to understand where you guys are still going?
Viktor
Yes, we still have one very special use case, and that is our alert pager. First of all, this is a classic fire department pager, as you know it, which is used to alert the emergency services. The special feature of this pager is, we use redundant, permanent, bidirectional, economical, encrypted data connections – over the public mobile networks. That is, we are constantly establishing a data connection, to each of these GSM technology-based pagers. Thus, we have the possibility to use different mobile technologies as well or to roam via several providers. And because of this constant connection, the system knows before or during the start of the alarm which of these emergency forces are available or reachable at all. This pager is used with mountain fire departments, for example, or squadrons or fire departments that operate across state or federal borders.
After all, the topic of fire safety is still one of the most relevant. I think there’s a lot of potential there in terms of IoT and new logics that can be brought in. I would link the projects in the show notes. Let’s jump into the first project Sven presented, with the Würth company. You’ve already shared a little bit, but maybe we’ll just dive into the day-to-day job of your end customer. What are Würth’s tasks here? Can you tell us more about the project?
Sven
I think everyone in the audience will have heard, seen or perhaps even worked with Würth in some way – as the world’s largest C-parts supplier there is. Our customer here is specifically Würth Industrie Service, which is the arm of the Würth Group that actually supplies industrial companies with C-parts and with the management and logistics of C-parts. To classify this a bit: C-parts always sounds a bit like small parts and not so important. The first part is still true – small-scale is certainly not wrong. But they are enormously important for the production and the security so that the production can also continue. Because if C-parts are missing, i.e. screws, other small parts, then this can actually lead to a loss of production. This means that availability and also the accuracy of fit of availability – i.e. delivery capability – is an enormously important issue. And Würth is taking the step here of taking over this complete service for customers, and ensuring and guaranteeing that there are always enough parts in production – in the right quantity, in the right quality, and also delivered at the right time. That in particular is a great challenge, because of course there is not always someone from Würth standing next to it looking to see when the kanban container in which the C-parts are filled will be empty again next time. That means I have a logistical burden to make sure there’s always something there. And with Würth, with IoT technology, we have actually simplified this entire process significantly and, along the way, also significantly saved space in the production facilities and thus made it available again.
Does this mean that Würth has also established a kind of new business model here? Up to now, you have been supplying C-parts – and now you suddenly establish contact with the end customer and know how my C-parts are doing … do you have to deliver something later and so on?
Sven
It’s partly a new business model. But to be fair: Würth has already offered this service in the past. Certainly not always; but that is part of the Würth business model. But with a high logistical effort – and we were able to simplify this process significantly. Ultimately, this Kanban system, which is located at the customer’s production, at the assembly station, does not belong to the end customer either – he doesn’t buy it. Instead, he receives this service from Würth, which has designed its business model accordingly.
A smarter service, so to speak, which is now being further expanded at this point?
Sven
Correct.
Challenges, potentials and status quo - This is what the use case looks like in practice
Thomas, if we go back to the beginning: Many people may not even be where Würth is today. Nevertheless, I would like to highlight Würth’s challenge in starting such a project. What are the potentials they have seen? What did they start with at the beginning?
Thomas
Sven has already hinted at it: A high logistical effort and a high personnel effort for Würth, which has already offered this service in principle in the past. The challenge to digitize this process was to find a hardware that once takes care of the weighing issue, is compatible with already existing Kanban containers. That is, perfectly adapted to the system they have rolled out on site. And ensuring that the systems that are then rolled out are plug-and-play. That means they really have to be set up and switched on at the customer’s site and work. They must also always be available in terms of data connection – because the system can only work if you can rely on the hardware.
This has also been part of Viktor’s task, to create a radio link that is data-efficient, but also easily accessible in environments that may not be reachable with regular mobile communication. That’s where we use narrow-band IoT technology.
That was the challenge at Würth and we were able to support them very well.
So first of all, it’s more of a technological challenge, but definitely with a business case behind it – that there are savings potentials and personnel costs. There is a large procurement effort that they have tried to digitize or simplify here to save money in the end and highlight the business impact on both sides. On the subject of weighing, Sven, can you tell us more: many are already technically inclined and like to talk about the practice. What data is particularly exciting here? Not focused on bits and bytes, but the types of data. The weight? Or what data do I need here?
Sven
That’s a super exciting question, and the answer sounds quite mundane at first: The most important thing is actually weight. That is, we weigh the Kanban box, including the contents, and thus know how much content still is in this box. Now you need to know that of course – everyone can certainly imagine – each individual part has its own weight. There are different size screws, different fasteners weigh slightly different. The challenge we have faced is that we can not only receive data – that is, the Kanban container, the IoT scale not only sends data, but can actually play back configuration data from Würth’s ERP system. This means that, depending on what goes into this Kanban container, the system knows via the weight measurement how quickly it empties and when I have to make additional deliveries. – For the optimal time, I only need this one container, which is equipped with the scale, and can thus map the complete service.
Sounds relatively trivial to weigh at first, but there’s probably a whole lot of analytics behind it. Viktor, a technical question in your direction: The customer always has different requirements. What was important to DENIOS for the design of the hardware? There are probably a lot of things to consider, right?
Viktor
Right. First of all, the harsh industrial environment that the customer has in such C-parts delivery and such places of use. This also challenges the housings and electronics. Then there was also a very specific plug-and-play technique at the customer’s site – that is, only the power supply should be connected, and then everything should run. Furthermore, the self-sufficient power supply. That is, here had to be a battery operation – there should be no power supply installed anywhere, for example. Then the downstream process, the subsequent delivery, should run independently. That is, it should not be a manual intervention. All these processes should run automatically. No local WLAN or other networks were to be used either – they wanted to be very network-INdependent. The next point was to enable global deployment. After all, they deliver these Kanban boxes worldwide and so they also wanted to use the scales worldwide. And finally, that they also wanted the whole thing encrypted in any case, to have the data secured in the system.
It also has great security relevance if I know how much is weighed there and how much is delivered where – it’s a strategic business secret that must be well secured in any case. Thomas, you mentioned DENIOS at the beginning – there are quite a few other challenges in the hazardous materials environment, aren’t there? There you have other standardizations, maybe also other legal requirements that go along with it – what was important to your customers there?
Thomas
That’s right, Madeleine. The products we developed there, the hardware should be ATEX Zone 0 certified – that is, a device must be able to be operated intrinsically safe. ATEX Zone 0 means 90 minutes exposure to any form of gas – including defects – without explosion. This is a great challenge for the design of the hardware. A wide variety of things are stored in hazardous materials warehouses, and therefore this challenge to certify the hardware according to ATEX Zone 0. You can imagine: Making an application that is operated with a modem, a power supply, intrinsically safe according to ATEX Zone 0, that is a real challenge for the engineers who design this hardware.
ATEX Zone 0 is a requirement of your customer?
Thomas
This is a safety requirement, in principle a global standard.
Solutions, offerings and services - A look at the technologies used
Sven, you’ve already teased a bit: you’ve now created a smarter system somewhere with an ERP integration, where you also record this data via a scale. Can you tell us more about how your solution, from hardware to the cloud – works? What exactly did you build?
Sven
We have developed a scale system; the product name is iSCALE. This is what Würth actually sells on the market and is now in series production and being used by the first customer. This is a fully automated Kanban system. This means that in production at the customer’s site, at the assembly station at the customer’s site, the Kanban containers are placed on a shelf like this. This has been the case in the past. To date, however, two Kanban containers have always been stored one behind the other. As soon as the first one is empty, it is placed on top of the system, the second one slides to the front – and when the Würth employee, hopefully, comes by on time, the empty container is refilled and sorted to the back again.
That is, on the one hand, a purely manual process and two containers one behind another, which has brought a certain depth to the system.
We have now developed a scale on which each individual Kanban container stands. That is, each one has its own scale, has its own battery-powered power supply and its own radio module. So it’s not the whole system that sends once via a module, but each individual scale sends its data to Würth’s ERP via our cloud. This gives us optimum redundancy, but also maximum independence from the situation at Würth’s end customer. That means we don’t need a power connection, we don’t need a connection to the WLAN, for example – which in our experience is often the most important reason why things don’t work well: I have to talk to IT at the customer’s site, I need access data; what happens when configurations change at the customer’s site?
This means that it really does work completely autonomously, and Würth has great security in always having access to the data and thus knowing – via the weighing function and the transmission of the data to the ERP – at what rate the parts are decreasing and when new parts have to be provided on site again for this container. We have simplified this process.
And the second advantage, which has also proved relevant in practice, is: I now have only ONE container per part. That means I don’t need that depth anymore – the system is only about half the size, half the depth of the original. This is a relevant competitive advantage for this system when space is at a premium.
If we try to understand this a bit from the bottom up, i.e. from the hardware via the data processing to the cloud – Thomas, how does this work exactly with these weighing sensors? How do you have to imagine it, from data acquisition to processing; what does this path look like?
Thomas
This is quite little complicated in this context. After all, we don’t have to weigh at the gram level here. But all we really need to know is, is the container full? Is it half full or close to a defined limit? – This means that we have a relatively coarse data structure and do not have to weigh at the gram level. Further processing of the data is also simple in this project in that, once we have pre-processed it – i.e. we know which device sends what from where – we deliver it to Würth’s Kanban system via an API. In other words, unlike DENIOS, Würth processes the data itself in its Kanban system. So we don’t have to supply Würth with a software application here – they already have that. They only get the raw data from us, and know how to deal with this data.
And API is simply the standardized interface that you use to route the data from A to B?
Thomas
That’s right, that’s how it is. The interface quasi between two different data systems.
The next step is device management. You had said these are a wide variety of containers that are tracked there – how does the management of the devices work
Viktor
Device management is a very important part of the IoT chain. As Sven said earlier: Every single device is equipped with this wireless technology and the whole thing has to be managed. That is, we need to know from whom and when these devices deliver these things. There are different approaches to solving this problem. For example, in these two use cases, there is a keep-alive or a heartbeat. This means that depending on the use case – for example, once a week in the case of DENIOS, but also up to every hour in the case of the scales – these devices issue a keep-alive: A sign of life that they are there at all. And they are thus also accessible, from within the system. Next in the device management: Very important is the firmware update function. All these devices include this feature to keep up with changes in the operating system on the devices as well as in the technology. This means that if standards in radio technology change worldwide, we can still update the devices accordingly via software. And importantly, the bidirectional connection during the keep-alive also gives us the ability to configure the devices – to adjust the different levels of weight changes, for example. Small screw – small weight change; large screw – big weight change. This varies depending on the material, and that is then also an important aspect – the traceability of the configuration.
All of Würth’s orders and the C-parts are tracked in the ERP – how exactly does this integration work? You just deliver a data package into the ERP system where that gets fed back?
Viktor
Yes, in essence, that is exactly right. We first prepare the data in our system, that is, in the device. We put them together in a way that they transfer well, with little data. Then they are prepared in the middleware for the customer’s system. In Würth’s case, it is passed directly to the customer via the API, and the customer then takes care of the traceability, reordering of parts and so on. For other customers, such as DENIOS, alarm systems must then go off from our system. Then the chain starts with US.
Middleware basically means that you are accessing a server structure or data power, computing power that is running at the customer’s site to do the data pre-processing and pass the data on?
Viktor
That is partially correct. We run the middleware – that’s a very important aspect, because it supplies and also includes the device management, and we take care of the data connection itself, which happens over-the-air. And the customer simply has nothing to do with it for the time being. This middleware then prepares the data for the customer as far as he wants to use it.
Thomas, you also mentioned rules earlier – that means you guys are doing the algorithm part as well. Earlier, the keyword machine learning and so on came up. These are, after all, algorithms that run to define rules. You talked about limits – so now you’re going so far as to put that intelligence into these systems as well?
Thomas
Yes, absolutely right. As I said, in the case of Würth, the essential intelligence is in the Kanban system of the Würth company itself. – We offer most of our midmarket customers this intelligence in our cloud. This means that the defined rules are stored there and the data is analyzed there in principle, with the algorithms, in order to then make recommendations for action. The simplest case is, let’s take a temperature: There we say, attention, seven degrees is the limit below, fifteen degrees is the limit above. Then our system actually does nothing as long as work is done within these limits – and only when a limit is exceeded or not reached is there a reaction. But we can also measure how common are limit violations? Is there anything that can be derived from this to recommend a course of action? For most of the customers we serve, we supply the entire process chain. But we are also, as you can see at Würth, able to deploy at any part of the chain – depending on what the customer’s need is, we would adjust the service.
If I as a customer have specific requirements for hardware: You also produce this yourself with the parent company, via HK.SYSTEMS, don’t you?
Thomas
That is absolutely correct. Hoffmann + Krippner has been on the market for 50 years, family run. Today, the CEO is Ralf Krippner. He got to grips with the issues of digitization at a very early stage, because the company comes from the field of input systems – such as membrane keyboards and touchscreens – and he asked the right questions about data transmission early on: How can I use values even more intelligently and purposefully in order to use new business models? Today, we manufacture the iSCALE, the Würth scale in Buchen in the Odenwald at our parent company Hoffmann + Krippner. But we also do this with the SpillGuard, which is the DENIOS product. So we can actually say that, in principle, we are the point of contact for our customers, from the development of the hardware through all process steps to services and operations, and we also deliver the piece of hardware to the customer or to our customers’ end customers.
I believe that many interested parties also have quite different projects ahead of them. That might not be about weighing or hazardous materials or fire safety. But possibly another use case where I also need the hardware and the comprehensive competence. Would you also take on the hardware development, so to speak, or bring the expertise to the table?
Thomas
Both hardware development and – very importantly – hardware production.
You claim that you’ll develop your IoT product in six weeks – that’s very daring at first. How do I do that? Can you solve the mystery: How do I develop my own IoT product with you in six weeks?
Thomas
The statement also seemed daring to us at the beginning when we made it. But fortunately, we have now frequently proven that this is indeed possible. The projects we have discussed here today are all such projects. And the first step we always take is to kick off together with our customer. That sounds totally banal now … but we attach great importance to the fact that the concentrated competence from both areas is really sitting at the table: So both from our side, across all process steps that are important for this project at the customer. As well as – and we also try to convince our customers of this – all relevant personnel with know-how in the customer’s company.
Yes, keyword interface, you had said at the beginning.
Thomas
Keyword interface, exactly. You were right to bring this up again just now: It’s not always about weighing, and of course it’s not always about hazardous substance detection. Rather, it is about recording something via sensors, transmitting the data, processing it and evaluating or enriching it in a meaningful way. And THIS complete process chain we set up on hardware foundations. Our experience is that, in some cases, we almost don’t have to change anything on the hardware because it has reached a certain standard that we can use in this way. Seventy percent, we can almost guarantee, we already have in the portfolio there. That means we are already setting up at a very, very high level. The same applies to the cloud solution, where we have already mapped the various processes today. For other application scenarios, we may make adjustments and additions. But in principle, the customer doesn’t start with us at zero, but rather, I’ll say now, maybe 70-75 percent on average. This, of course, speeds up the entire process; but most importantly, it speeds up the journey from launch to proof of concept. And that is the first most important milestone. Among the top three reasons we discussed earlier was the fear of failure – it’s also important to set concrete milestones and say that this is a sense of achievement, and then we’ll take the next step. This is exactly what we work out together with the customer in this kick-off and then record in the form of specifications.
That means I get to my IoT product in six weeks, you do a kick-off, you bring all the people to the table who can work on it and bring knowledge to it. Then I build on your know-how – that saves time. Seventy percent, you said, is already there in hardware expertise, portfolio. And, of course, the software application expertise you bring to the table. Plus, you guys take care of it completely from purchasing to production.
Thomas
I would like to add to that: In the best case, the customer comes to us with his idea of a business case. Then it is exactly the way we have just described. But there are also customers who have an idea, and we have to validate it first. Because at the end of the day, what matters is that there is a business model. We are not introducing the technology for the sake of the technology, but because we want to generate something profitable with it. Then it is very important that we perhaps work again with the customer on a business model. We can do that in the workshops that we offer.
Results, Business Models and Best Practices - How Success is Measured
It always stands and falls with the business case – at the end of the day, we really want to save costs or increase sales with it. Set up a new business model or simply optimize a service as described. In summary, Sven, what is the business case for Würth, very compactly?
Sven
The business case for Würth is actually process optimization and the attractiveness of the system to a customer – which of course allows new customers and new systems to be placed with the customer. To perhaps make the turn to DENIOS here once again: DENIOS was previously a pure hardware supplier. That is, the detection of hazardous substances was sold as a piece of hardware. With the DIGITAL product, DENIOS is now in a position not to sell it to the customer at all, but – similar to what you know from the smartphone industry, for example, the smartphone is subsidized – the piece of hardware is placed with the customer at a favorable price. And a long customer relationship and corresponding revenues can be realized via the term and service fees.
I think that’s the important point: to look at the business case. Many are on the way or bring the first ideas for business potential. And if they don’t have the strategy ready, they then need to be packaged.
Transferability, Scaling, and Next Steps - Here's how you can use this use case.
I always find it exciting to talk about the transferability of use cases. Do you have any other customers or ideas where you say, in the course of these conversations, suddenly such and such things came up, or the customer said, “Man, that’s so similar, we can use that with us too!” Do you guys have some best practices on how to transfer these use cases that you’ve presented to business?
Thomas
Let’s take a look at DENIOS, where we had just started with the leakage sensor, which was supposed to do nothing more than ensure that the hazardous substances did not leak. In the meantime, we have many different projects. We are now networking their room systems, offering complete service for this. Is the door of the hazardous materials storage facility closed? Is the air conditioner running? All the information that takes place around the issue of hazardous substances in the room system. From this, of course, you can take a look the issue of building management, for example. This is the same use case – are all the lamps intact? Is the light on or off? So you can actually derive more ideas from any IoT project with a little imagination.
Last but not least, we developed an intelligent beer mat for the company Rastal that communicates with a beer glass – I mean, that’s a long way away from any IoT use cases when you think about it. What is important, and I emphasize this again here, is a consideration of the business model. Otherwise, every IoT project is doomed to fail from the start. Because in the end, every company has to pay the bill; the effort has to be reflected somewhere – either through improved services or acceleration or whatever. That is the essential issue in the context.
Totally, otherwise we have a bunch of technical use cases – but someone has to pay for it in the end. You want to have the return on that. I think that in summary we can say that the lack of know-how is not a problem – there is the corresponding expertise, for example through you and the partner constellation that you bring with you. The issue of interface coordination is something – well, you have to get the right people around the table; you need input and experts to develop the whole thing and approach it together. And then also put aside the fear of failure a little bit and just start. There are enough exciting examples, not only in our community, but elsewhere as well. Where you can simply look: What are others already doing? Observing what potential the technology, but also the market, simply brings with it. Incorporate new customer requirements. Enable and tackle! You guys are also available for advice and support when it comes to discussion, right?
Sven
Absolutely. Anyone who has questions and would like to discuss them with us is welcome. You can find the contact details in the community.
