Digital business models: From hardware provider to IoT solution provider with licensing model

Hello Frank and hello Fabian, welcome to the IIoT Use Case Podcast. I am very happy that you are with us. Fabian, we did a podcast with you and Device Insight last year, which had over 1,000 listeners – one of our best episodes. It was also about business models, AI and IoT in practice. That’s why it’s cool that you’re here again, and today you’re also here with your customer. I’d say we’ll just start with a quick round of introductions. Fabian, can you say a few points about yourself and your role at Device Insight, and just tells us what exactly your company does?

Fabian

Thank you very much for the invitation and that we can be part of it again. We are always happy to participate in this podcast. All the nicer that we have our customer RAFI with us today. About me: I am Fabian Habermeier. I am a project manager or product owner at Device Insight. From my background, I am an industrial engineer and now in my second year at Device Insight. I have been working with RAFI for a year and a half now, and in my role I am the link between the customer and development, dealing mainly with organizational and technical issues. For those listeners who haven’t met us yet: Device Insight has been around since 2003. Accordingly, we are a pioneer in the field of IoT. We are located in the east of Munich with a view of the mountains. We now have 100 IoT experts in our team and have successfully supported around 150 IoT projects, connecting approximately one million devices. Since 2019, we have been acquired by KUKA, are now a wholly owned subsidiary, and also provide support there in the development of Industry 4.0. Our customers come from a wide range of sectors from automotive to smart vending. Examples of customers that our listeners may know are Kärcher with high-pressure cleaners or Costa Express, where we support the vending machines that are located at train stations, for example, which you may be more familiar with from the UK. Perhaps Krones is still a familiar name, they make filling systems or Feintool, a plant manufacturer for presses and fineblanking machines or Fendt from the agricultural sector with tractors. To explain our business model briefly – what do we actually do? Everything we do is based on system integration, based on the major Hyper Scaler platforms. The well-known platforms are, for example, AWS or Azure from Microsoft. As a Gold Partner of Microsoft, we also work primarily with Azure, but we also use other platforms and combine them with Ready to Use components that we have developed ourselves. We also have our own product as an IoT platform and, of course, on top of that we have very capable developers who also provide us with customized, flexible and, above all, scalable solutions with software development and add them to the existing building blocks. This combination of building blocks allows us to implement initial use cases very quickly and cost-effectively, which is what really sets us apart here. In contrast to software-as-a-service solutions, which are often not as flexible – where you simply buy a finished product and are then stuck with what you’ve bought – we can simply add on top. That is our strength, that we have excellent developers here who make this possible, and also accompany our customers through a 360-degree approach. In other words: end-to-end, from business case analysis and solution design to development, rollout and operation of the solution.

 

To conclude the round of introductions: Frank, you are now here in the customer role. Welcome also once again in your direction. Would you also like to introduce yourself briefly and then we would start directly with the topic of this podcast.

Frank

Hello Madeleine, thank you for the invitation and that we can also be there. Perhaps first a word or two about RAFI: RAFI specializes in the field of HMI systems. That means we have three product areas. On the one hand, we have a classic components business, where we also sell RAFI components under our own brand. This means mainly pushbuttons and signal lamps. In the second product area, we are on the move in the field of customer-specific developments. That means we develop and produce customer-specific HMI systems from mechanics, electronics, software development to production – everything that goes with it. And in the last area we are active in the field of EMS. That is, as a service provider for electronics assembly. The industries in which we are active are quite broad. We actually do everything except automotive. This means that we are in the industrial sector, mechanical engineering, medical technology and also have commercial vehicles on the road with which we offer a wide variety of HMI solutions. About me: My name is Frank Fleischer. I have been with RAFI for over 15 years. I originally studied electrical engineering and then worked in development for a few years. Today I’m responsible for technology and innovation. This means that the entire technology management, innovation management, but also pre-development is part of it. And we are also one of the drivers for IoT and digitization in our company.

 

Now, of course, I’m also primarily interested in the topic of digitization in the podcast. You have just mentioned that you have three areas and one area is also that of the components – be it emergency stop switches, pushbuttons, signal lamps, HMIs, i.e. the touch panels that you find in production. After all, this is a classic hardware business. I would be interested to know what exactly you do in terms of digital transformation. Why IoT? And what market developments do you see there, now specifically for your core business?

Frank

As you rightly said, we have actually been in the human-machine interface area for over 120 years already. Until now, it has been a classic hardware business, i.e. the sale of components or even systems. In principle, what prompted us to move in the direction of IoT and digital transformation is that we realized that we actually already have all of the competencies at RAFI, we just have to combine them in the right way. This means that there are different competencies in the individual business units, as I said earlier – from electronics development, software development, mechanics or connectivity. We just had to combine them in the right way, and we already had the perfect combo for the digitization and IoT solutions. Of course, our goal is to move from being a component provider to a solution provider. The ambition was to add value through data from our simple hardware components. Despite IoT, Industry 4.0 or even automation, many people are still active. Today, not only machines and robots are involved in production, but also a great many people. And the difficulty for many was or is to digitize and optimize precisely these manual processes. And there are only a few solutions on the market. And that’s exactly where we saw that there was a need and that we actually already have the right components for it.

 

Many who are now active in production are familiar with components such as pushbuttons, lights, emergency stops from everyday use. To give listeners who may not know these components a virtual picture: Can you pick tell us a bit about where they are still used or where they are generally used and where they are installed? Simply to situate the whole issue a bit.

Frank

Our pushbuttons, signal lamps or even entire operating systems are typically used mainly for the operation, monitoring and control of plants, machines or processes in the various industries in which we operate. The typical customers today are usually plant engineers or machine manufacturers who use our components and install them in their plants and machines. So far, the signals that have provided just such traditional or conventional components. They were very dedicated and used very locally in plants and processes. Our goal now was to make this data globally available and to say, I don’t just use these simple signals centrally in one machine, but I can also use them company-wide or even across companies.
 

A quick question on this: That is, I have to imagine that I have a signal lamp somewhere here that is attached to a cutting machine, for example? Can you give us an example there?

Frank

Yes exactly, that would be a typical application, a cutting machine in production. In principle, almost every machine installation today needs a signal lamp that simply represents the machine status, usually via coloring. I have to turn the machine on and off somehow, of course. For this I need simple buttons or I need an emergency stop. And all these are components that we traditionally supply for different plant machines.

 

Now, in the podcast, I always talk about concrete projects from practice, i.e. the use cases. I would like to delve a little deeper into the classic problems and challenges that your customers face in practice. Can you tell us a little bit about the customer requirements you guys are facing there and maybe give an example or two from the field?

Frank

As mentioned earlier, customer requirements are increasing to the effect that this data, which is generated on the machines, is not only available locally, but can also be accessed globally in order to bring more intelligence or more transparency into the plant, machine and production processes. And today, IoT solutions are often very complex. In our experience, many customers are reluctant to invest in a large-scale IoT solution when it may only be a matter of obtaining very simple, basic status data for the time being. The challenge for us was to create an integration as simple as possible, so that a customer can optimize existing processes without programming effort and IT knowledge and with as little intervention as possible. That was the challenge we set ourselves, and ultimately KIS.ME emerged from that. KIS.ME stands for Keep it simple – manage everything. In principle, this is our guiding principle. This means that we first want to achieve a high level of benefit with very simple products and thus actually manage almost everything that is possible in our manufacturing or logistics processes. That was exactly our big goal. Perhaps a few practical examples of what we have already implemented there. For example, there is a use case from intralogistics. We often call it Logistics on Demand, which means quite often a transport call is required at the push of a button. That means, we have networked our push buttons. We have networked pushbutton boxes and can use them to trigger certain logistics processes as needed, making it easy to optimize and shorten such milkrun routes. That is, we don’t want to replace Milkrun routes for now, but they are good as they are. Only we would like to optimize the throughput times and the cycle times by taking the routes that have to be taken only very rarely or that are very remote, that the route is really only taken when it is really necessary. In this way, we create a faster material supply and material removal. We can save unnecessary ways, up to better personnel planning in the end. A good customer example is topics such as waste removal, where a customer actually places a KIS.BOX on each floor at the waste disposal points and thus controls the waste removal, through to complete control systems for transporters, where large monitors and dashboards are used to signal very centrally where there is currently a demand.

 

Here’s a quick question: You mentioned a pushbutton box, what exactly is that? And KIS-Box is probably a product name from you guys, right?

Frank

Exactly, the KIS.BOX is a product from the KIS.ME series and is basically a simple box containing two pushbuttons that is very easy to install. It can be mounted on slippery mounting or aluminum profile mounting on site and brings a WLAN interface, with which I can then use these signals digitally. This is a product from the KIS.ME series and the KIS.LIGHT is the associated signal light, which can also be easily used via WLAN.

 

Now you had just spoken of several examples. Do you maybe have one from another area if someone is not from logistics? How might that work on the shop floor?

Frank

Yes, so especially the signal lamp can be used very easily for retrofitting. As I said earlier, almost every machine today has a signal light already mounted. And we can simply detect these machine conditions with our signal light and thus also detect downtimes, for example, and then also reduce them. You can use it to make key figures transparent, measure up and down times, and even enable me to rectify faults quickly and thus increase production availability. And that’s just by swapping an existing signal light with a digital light that makes it very easy to use. And if you then think one step further, that you not only record the conditions from the machine, but also read in external sensor signals, such as a light barrier or similar, you can thus also very easily make a first pass yield determination or determine a line cycle of a machine and thus measure the actual output of machine systems, up to OEE key figures and then display these again on other boards. This makes it very easy for me to bring transparency and efficiency into production.

 

If I imagine such a signal lamp, it first provides simple data. So I’m not saying huge data of a process or anything like that. What data is of interest to your customers here in the process now? Perhaps we can make some more reference to the use cases. What data is the customer primarily interested in here, is it simple data or how does it work?

Frank

I say, you can generate a lot of value with this very simple data. That is, as you said, it’s actually just simple data, like: A button was pressed or the signal light now has the color state green or red. Or I have a simple condition by an external sensor like a photoelectric sensor or other proximity sensor. But even through these simple signals I can generate a very high benefit already with the customer. On the one hand, I make a minimally invasive intervention in the existing processes: I don’t have to rebuild an insane amount, I don’t have to invest an insane amount, I don’t need large software installations, no IT support, I don’t have to bring along any programming efforts and I can simply use the conditions and the simple information that are there in a very simple way. We then took the path of saying: Okay, our components are more of a kind of gateway that can already provide or tap into this simple data. And we then deliver that data to the cloud, so to speak. We ultimately moved the intelligence to the cloud and that’s where all the control of the components is done, all the functionalities up to the display, everything that goes with it.

 

Cloud is of course the fitting keyword now. Fabian, I’m looking in your direction again. Now a button is pressed in the process or a photoelectric sensor supplies status data – what happens to this device data in the cloud?

Fabian

So as Frank already said, this is in principle very simple condition data. The device has two buttons, the button is pressed and basically this pressed button ensures that the condition data is sent from the device to the cloud. The real intelligence is now emerging in the cloud, in the KIS.MANAGER. This is RAFI’s product, the heart of the IoT solution. And here the user can interpret and further process the data as required by his individual use case. There he can make use of various functional features that we have provided to the platform. When you press a button – which, by the way, you can also stick a label on, it now says on it, for example “Report malfunction”, and then the user on site knows, if I press the button, a malfunction is reported – the condition data is sent to the cloud. This generates a data point in the platform, which is then called “Button Press”. And the KPI, which could then be called “disruptions” for example, similar to an Excel formula, quite simple, then accesses this data point and counts the number of button breakers and that then corresponds to the number of malfunctions over a certain period of time. The user can compile these KPIs himself. And so now, at the push of a button, you can transparently display how many malfunctions we had, for example, in a certain shift or in a certain month, and then also already go into areas such as process optimization. Simply because you have this transparency. In the same way, you could also use the KPI in the same example to map the duration of a disruption. There is also a timestamp there. We’ve heard that we can get the condition data flow in. These buttons can also display different colors via an LED. We can set this so that the LED turns red when “fault” is pressed. Of course, this should also signal to the user that the red color is a warning signal here. How long this lamp was red, we can of course measure in time. We also have a rule engine, which I will explain in a moment. This could then be set in such a way, that when the button is pressed again, the LED light turns green. Accordingly, you can then measure the duration, how long it was red, and also how long it was green, and can then also map via the KPI how many malfunctions you had in a certain period and how high the productive share was. Of course, you can then jump into process improvement very quickly. The rule engine I just mentioned, that’s basically an if-then logic. We have a trigger here, which could be the Press button, and we have a condition, for example, an action that causes this light to turn green and no longer be red. Entire process chains can then be mapped digitally. An example of what we have already heard is garbage removal. This could now look like this, that the button is pressed, there is for example a label on it, for example waste removal. That way the user knows if I press that, a message will be sent via email and then the carrier knows they need to pick something up in that area. But it could also be an alarm signal that we control via the rule engine in such a way that when the button at this signal light is pressed, a red light comes on in the control room, for example, and then he can look directly into the platform. We also have dashboards to visually represent the KPIs and data points, and here we can visualize which processes are in which state, in production, in logistics. This gives us maximum transparency in the platform, too, and we can see where something is happening and perhaps already know why. On top of that, we also have a Digital Twin of the physical devices. These can also be planned on a shop floor, which the customer can import himself in order to map his factory. And you can also position the devices there so that you know where they are at the moment. If, of course, these devices, the digital twins, map the physical devices there, you can see at a glance where something is red, where something is green and also intervene there, and thus also have a digital factory in the final effect.

 

How deep do you go into the individual processes together with the customer? After all, every customer probably has a different use case or application. Do you guys take a collaborative approach there and look at: Hey, what does the process look like at the customer’s site – is that now waste removal, is that another case? And then you look at what data you can collect there and how, or how does that work in practice?

Frank

Usually, process owners know very well where the pain is, where they have a benefit. That is, our experience shows that we don’t actually have to support or help much at all. The only thing to do is to stimulate the imagination: What are actually “only” by the button and the signal light, which are networkable, and with an intelligent cloud solution the possibilities there. And that’s more what we need to do a little bit. And the rest is usually done by the customers themselves. They usually come up with even more ideas because they simply know their processes and the pain points much better. The rest then happens directly on site at the customer. That’s the beauty of the product: that they can do the installation and setup completely on their own and don’t even need this advice and service, which is often time-consuming and expensive.

 

Fabian, if I now think a little deeper into this architecture – how exactly does the solution work now in detail? Now you had talked about your rule engine, also about the interpretation of the data. Can you maybe tell us a bit about it from the bottom to the top across the layers? How does this overall solution work and with which building blocks?

Fabian

At Device Insight, we have a flexible IoT solution stack that we use as a foundation. It already consists of ready-made IoT components that are part of our product. Accordingly, these can already be used for data or device management, for example. We combine this additionally with Azure cloud services, in RAFI’s case, for example, with an IoT Hub, which regulates the central data input, and an Event Hub, which acts as a message broker. On top of that, we have custom services developed specifically for RAFI, such as the Rule Engine you just mentioned. And with these Azure cloud services, we can achieve a very fast time to market and, above all, maximum scalability of the IoT solution. The modular principle allows us to implement initial use cases very quickly and cost-effectively, because we can draw on what is already available. This means that we can simply move forward very quickly in line with the motto “Start small, think big”, and by looking ahead in the direction of “Big”, we have maximum flexibility in further development thanks to our custom modules, which we can also develop. RAFI naturally supplies the hardware and the matching firmware for the devices. Again, we have built a feature here that allows firmware updates over the air, so that these solutions can also be updated in the long term and no intervention is required directly on the devices on site.

 

So, I have to ask another small, critical question. If I look at our users now, they have various heterogeneous system landscapes – from perhaps their own cloud services, which are used, to a wide variety of hardware, sensor technology, etc. How does such an integration work with an existing customer landscape? Many may have already something in place. Do you then also integrate this data, depending on the case, or how does that work there?

Fabian

It is, after all, a software-as-a-service solution. This means that the customer does not even have to integrate it directly into his environment, but uses a web portal here. And that was also RAFI’s goal, not to intervene in existing complex architectures, but to implement this system like a satellite next to the existing architecture. And with as little effort as possible from the customer, without IT knowledge and accordingly has a platform that can be used practically from now on.

 

I now come to the point of integration for the end customer on site. Frank, the question for you: What does it really look like on site at the end customer now? What connectivity do you bring along besides the hardware? How does this integration work there on site at this solution?

Frank

After all, our devices are WLAN-enabled. This means that both the KIS.BOX and the KIS.LIGHT have their own WLAN interface integrated. That means, of course, that we need a WLAN infrastructure on site that we can tap into, so to speak. The experience from our side shows that this is actually already very widespread. Most companies today already have a very well spread WLAN infrastructure and where it is not present, it is usually also a very minimal effort to set up WLAN somewhere. We also deliberately keep it separate from the company network because, from a security point of view, many people are afraid of connecting the company infrastructure, the entire production infrastructure, to the Internet. Our intervention is simple in the sense that we basically dial into a kind of guest network. That is, most companies have separate networks, which are then intended for guests and we integrate the devices there as well. This means that we are completely separated from the company network and production network with the Internet solution and don’t really have any major problems there. We use TLS encryption and also certificate-based communication, so we are actually already using state of the art technologies as far as security is concerned. For the end customer, this means that ultimately only the WLAN key or the SSID, the password of the in-house WLAN network, has to be on the devices. In our case, it’s relatively easy via USB. This means that I have to connect the devices via USB to a PC, computer or laptop during the initial installation and from there I can copy the WLAN access data to the devices, similar to a USB stick in the end, and the rest happens fully automatically. That means all the onboarding in the cloud happens autonomously. This means that after a few seconds or minutes, the devices are available online and the customer only sees the devices that he has on-boarded for himself in his environment and can actually get started immediately.

 

I would now like to go into more detail about the business model and the business case behind it. As a customer, I now have certain potential cost savings or even the opportunity to build this as my own business model if I now come from a similar role, for example if I am a hardware manufacturer. What does the business case look like for you in practice? How does it work?

Frank

It was clear to us that if we invest in a cloud solution, there will of course also be ongoing costs – be it for hosting, for maintenance, support, etc.. We turned the whole thing into a licensing model, so to speak. That is, we simply license per number of devices and the number of users is completely open. The customer can onboard as many users as he needs. And he pays based on the number of devices in use. This simply means for the customer: He can derive great benefit from it even with minimal investment. Often, one or two products are enough to optimize a production part or a process and to achieve a considerable increase in productivity and cost savings. This licensing pays for itself very, very quickly and I don’t have to purchase an all-encompassing expensive big solution, but I can also do something with very simple and small costs here already. And for us, of course, from a business point of view, this means that we are moving away from selling hardware to becoming a solution provider and licensor with permanent licensing income.

 

The topic of return on investment is of course very important for many customers. It’s nice that you’ve now elaborated on that as well. Fabian, do you have any additions from the Device Insight side, especially regarding the business case from your side?

Fabian

Yes, of course we first had to make this software-as-a-service model, which is ultimately based on a subscription model, possible. For this, we have delivered features that practically allow the business model to be mapped for commercial use. And what we have implemented there, on the one hand, is the licensing model, which activates or deactivates features depending on the respective customer license or also only makes certain functionalities available in a slimmed-down scope. At the same time, we have also mapped a role model that provides various groups of people with different rights and functionalities, but of course also allows RAFI’s customers to administer and manage these roles independently via simple user administration, without having to resort to RAFI here – which is of course also very important for the onboarding process mentioned, including the devices, so that there is simply no additional effort for RAFI here and the customers are also able to operate the system independently of RAFI. Accordingly, company updates over the air are also possible so that customers do not have to return their devices. The customer has here a scheduling that allows him to decide when this update should run, so that the production is not disturbed and depending on the shifts or the rhythm this update can also run through.

 

If I’m now slowly coming towards the end, perhaps a brief question about collaboration: How did that work? Fabian, I’ll look again in your direction here.

Fabian

RAFI, of course, had the idea of what they wanted to do, and Device Insight had the solution of how to make it happen. In terms of the process, we first had an initial step, which was a proof of concept, where we first showed RAFI what options were available and then, of course, convinced them of the solution or of us as a partner. And accordingly, it then went through a solution design workshop, where we again sharpened it with the feedback from the POC, agreed on what we wanted to implement in the first step, and what the crucial features were. We take an agile approach to the implementation itself. The entire Device Insight company is organized in an agile manner, and what we have had very good experience with here are so-called refinements that we have twice a week with RAFI, in which we discuss the requirements together in detail in order to also have a common understanding before we then develop the topics. And that’s where we have very good discussions with RAFI at eye level. It is a very cooperative partnership. We’re perceived as a trusted IoT advisor, but we’re also very happy with RAFI, how they’re involved. You can tell they’re real tinkerers, they put their heart and soul into it, and they also come up with very good ideas. And it’s just fun to work out clever concepts together, too. We then implement this in so-called sprints, which last about two to three weeks. There we have user stories that we prioritize together, where we say it has the greatest value that we then start with these topics, slowly build up the product and quickly get initial feedback. We then present these topics, which we have implemented, in so-called reviews at the end of the sprint. We then also incorporate customer feedback back into the backlog or into the other topics. Or completely new topics emerge that we hadn’t even thought of yet. And that, of course, allows us to move pretty fast. We have a lot of speed here, I would say. We arrived at the finished business model in about a year. We had about three months for the MVP, which RAFI also presented with the first basic functionalities at the SPS trade fair in 2019. And here, too, we have of course received feedback from the first customers, which we then incorporate into the development. The pure development time until the official launch was about six months. Overall, the time was tight, because of course we also had clarification issues and transition issues, but the pure development was about six months. One major reason for this speed is, of course, that we were and still are able to draw on ready-made IoT building blocks. What should also be emphasized, of course, is that as Device Insight we have a very large partner network. One can also speak of an ecosystem. This means that the added value is now no longer limited to development for RAFI, but we are also finding that we are also presenting the solutions to our partners, who are very interested in them and can also indirectly support sales to some extent here. We simply also see that we create a win-win situation for both sides.

 

Now this one final question about this joint project: Frank, are you happy with the result? And what is the result at the end?

Frank

Yes, we are definitely happy. Of course, we all tried our first steps ourselves. As I said, we also have our own in-house software development department, but we quickly realized that the effort required to launch a complete cloud solution was simply too great and would take too long. That was the reason we said we just need a partner so we can be faster. And with Device Insight we have definitely found a partner to get a quick implementation. In this way, we have actually also achieved that we are simply on the market with the product in the shortest possible time. And we succeeded in doing that, so we’re really happy about the overall solution and we’re happy that we launched the product earlier this year so that it’s also available to the masses. KIS.ME will, of course, be further expanded and provided with new functionalities – both on the cloud side, where we are working strongly together, and on the hardware side, where we are already coming up with new ideas on how we can also offer new solutions here with new devices.

 

I believe that acceptance among many end customers will continue to increase. Digital transformation will advance in general and I believe that more and more projects will emerge and product development in this direction will certainly not stand still, will it?

Frank

Definitely not. For us, KIS.ME is of course a very, very strategic product with a lot of manpower behind it – both for us and for Device Insight in that case. This is definitely a long-term product, where we invest permanently. And of course, cloud solutions are also characterized by the fact that I can make new features and functionalities available to the customer more quickly without having to invest in hardware-related product development.

 

Now, perhaps moving away from this one case to a broader topic. If I’m a listener now, who may have similar challenges, but perhaps in a very different environment: how can this use case, this common project, be transferred now? And what are the success factors here, Fabian?

Fabian

The use case can of course be transferred to a wide variety of applications and subject areas. What needs to be highlighted here is simply that RAFI has shown this courage to develop a true digital business model outside of its core business. And that, of course, is a courage we would also like to see more often. We often see today that the focus is very much on cost savings or process improvements, where customers are simply trying to make what they are already good at even better. But here, too, we can see from the example of RAFI that it’s not rocket science in principle, and that we can develop a completely new business model and a new division within a very short time with the help of digitization, without many years of development and escalating costs.  And that’s simply what we would like to see from many others as well, to go down this path that is simply doable. And, of course, it is always crucial to keep the focus on the customer and try to solve the pain points with the help of digitization. Agile development, which we naturally cultivate here, is a crucial building block for simply being fast with the first use cases, and then quickly implementing this global, digital vision with the customer’s business cases, and doing so in a customer-centric manner. Of course, it is also important that we are flexible and scalable in the long term with these solutions. We take great care to ensure that we don’t block anything, and that even if we start small, we always keep an eye on the big picture and can also scale up again in the long term, rebuild something and don’t run off in a direction somewhere, in which we are then trapped.

 

Those were the perfect closing words, then I would end the session. What is the best way to reach you and how? How do I get in touch with you?

Fabian

The best way is via our website – www.device-insight.com. Here, simply contact the sales department, do not be shy, do not show inhibitions. We also have what we call a Cloud Accelerator team that can deliver POCs very quickly within a very short period of time. And there my request to just get back to us with no obligation and we’ll discuss what the use case is. We can also provide even more information on the website. We also have a case study from RAFI, if you are interested in more detail, I recommend you to visit our website.

 

Frank, what is the best way to reach you?

Frank

For all those who want to optimize their own processes, and do so in a simple way and without a large investment, KIS.ME is actually just the right solution. We have a ready-made starter kit that can be obtained. This means that with a few clicks of the mouse, you are at such a kit and can get started immediately. All the information about this can also be found here via the website kisme.rafi.de.