Airbus connected factory to shorten Time To Market, Remy’s Martin connected bottle to avoid counterfeit, Schlindler’s elevator smart sensors to improve security, Cisco-IBM connected port in Colombia to enable predictive maintenance, these are some successful examples of B2B IoT creating value and business, and there are many more to come. MACKINSEY ASSESS THAT 70% OF POTENTIAL VALUE ENABLED BY IOT SHOULD COME FROM B2B! McKinsey Global Institute – “The internet of Things: mapping the value beyond the hype” – June 2015 A growing number of companies understand the potential of IoT for B2B markets and its trillions dollars’ revenue expected in 2020 (from 3 to 20 depending on sources and studies). That said, you don’t develop a bluetooth key ring the same way as a sensor designed to monitor temperature in a hot caustic reactor lost in the middle of nowhere and requiring 99,9% availability. While B2C IoT main challenges will remain business application and datamining, B2B brings an additional complexity to the device and its direct environment (gateway, other IoT devices, IT, etc). That is why we make a distinction between the “sexy” IoT focused on B2C and its challenges (marketing, business model, retention, etc.) and what we call the “serious IoT” which is more related to industrial and B2B stakes. This article is the first of a series where I aim to describe the whole process of IoT project development, from a business point of view as well as a technical point of view I will start with this first article by giving what I believe is the best methodology to start a BtoB or Industrial IoT project. What are the challenges of serious IoT? What are the key success factors to launch a product? What to begin with and which steps to follow? THE FOUR PILARS TO SUCCEED IN AN IoT PROJECT Before I dig into the process to follow, let’s share some key success factors that I’ve identified in all the IoT projects I’ve seen and run: Design thinking As IoT is “hype”, many companies want IoT to launch a project and forget that simple saying: “no pain, no gain”. If there is no pain to be addressed with the project, it will certainly end up in the archive box of the data room. Design thinking allows to have a consumer-centric approach at each stage of the development and ensures your project/product relieves pain, brings a benefit for the customer (even if customer is internal). Master a wide range of technologies MacKinsey assess that system interoperability represent 40% of the potential value of IoT revenue. The “inter” of interoperability means that companies would need partners mastering many different technologies to have all layers/devices work together. In the embedded/IoT world, this can easily exceed 50 technologies (HW architectures, OS, radio & network protocols, frameworks, applications, etc.). So the success of an IoT project, and more widely of an embedded project, is moving from a technical “silo” expertise to a system approach coupled with technical expertise. Designing the device itself also requires a wide range of expertise and a system approach to optimize the whole system based on business application requirements. Reliable partners (either for technologies or distribution channel) This is often called ‘open innovation’, a term that can freak out CEOs or CTOs. It is simply the fact that you build your project involving partners at each stage to create more value. As IoT impacts every single bloc of the business model (distribution channel, revenue mode, communication, key activities, key resources, etc.), not a single company can have every related asset internally. So finding the right partners, and sharing value with them, is key to manage and roll-out the project Agile approach This is another “buzz” word. But it is not so obvious for companies not coming from the software industry or coming with a pure embedded software mindset and its 'waterfall approach'. IoT sees many new comers discovering the software challenges, and trying to apply their regular development processes (V cycle for example) to the IoT project. That is the best way to burn it in endless discussions on product scope, spend a lot of money on redeveloping things, and delaying your project launch forever. WHERE AND HOW TO START YOUR IoT PROJECT? Now you’re thinking: “Hmm, interesting, thanks Mr Consultant for this completely un-operational advice. But that doesn’t help me to start”. Don’t you leave now, here is the practical part! These are the first steps to follow when you want to manage an IoT project: 1. START WITH ''WHY'' As Simon Sinek would say, you’d better start with the “why” before launching any useless project. So, why do I want to launch an IoT project? Do I want to launch something that makes my company look trendy and innovative? Do I want to save cost by optimizing my business processes (maintenance, operation, production, etc.)? Do I want to enable new business models into my company offer, thanks to the IoT opportunities (renting vs selling, data value, new services, service vs product, etc.)? Do I want incremental innovation to refresh some of my products? Do I want to use the project as a Trojan horse to digitalize my company? Over the past few years, I have seen all of these motivations among management teams, and all of them are fine. But, you cannot pursue all those goals at the same time, and you certainly won’t design the same project depending on the choice you make. As we say in French “choisir, c’est renoncer” which would translate into something like “Choosing is giving up”. So take time to clearly state your motivations and then select one that needs to guide your focus in the coming months. 2. DESIGN USE CASES AND MAKE ASSUMPTIONS Easier said than done, but first forget about technology/product, and just think about what IoT could allow in your environment and to which customer this could be most valuable. Draw several customer “journeys” and see where innovation could be used as painkiller or gain creator. Let’s take the example of a maintenance scenario. The idea is the allow remote action for on field devices. For instance, coffee machines installed into gas stations all over Europe. In that case, ask yourself how IoT could make maintenance more efficient? Try to assess time gain, money gain, and security gain and quantify it. Let’s say you identified that among 1000 machines installed, you have a high chance of having 5 customer claims per week and therefore 5 diagnosis to be done per week. Can IoT help you run the diagnosis remotely? Can IoT help you solve the problem remotely? In that case, will that save all on site trips? How much money would that save for the company operating the machines? Knowing that, you can start building a first draft of business models making assumptions: how much of that value can you take? What is the business model you can build around that? How much will it affect your customer process? Have you got the right distribution channel to sell this new offer? Which key assets and activities would you need to bridge the gap between current status and this innovation? 3. GET OUT THE BUILDING Use cases and key assumptions in your pocket, you will now need to go and meet potential customers and partners. The more you share, the more your project will evolve to a credible scenario. Who in your existing base can be your early adopters? Who are your customer having the pain you ease at the highest level (and it is even better if they try to solve it themselves with a workaround). In our example of remote maintenance, they would have some artisanal webcam system on each site to see the machine state and detect some issues without any on-site intervention. Once you’ve identified 5 to 10 contacts, go out and meet them, and try to understand several things : the high level stakes, the problem they have on the field, the way they have tried to solve it, the change process and stakeholder, and then (and only then) you can present your innovation and collect feedbacks. A few slides are enough to present. There is no need for a prototype or any bigger investment. You will be amazed on the quantity of information you can collect that way. And remember something: don’t listen to what people say, look at (or try to understand) what they actually do. 4. BUSINESS MODEL AND FUNCTIONAL SPECIFICATIONS You had your first iteration, congratulations! You wrote down assumptions, you went on the ground to test them, and you collected valuable insights from your targeted customers. Maybe your assumptions proved fully wrong, then go back to stage 2! Otherwise, lucky you, you can write down a v1 of the business model and define your product functional specifications better. This is where you can start defining features, functionalities, prices, offers, channels, technical constraints, cost, financial figures, etc. At the end of this stage you will have some kind of a business plan, a sales pitch, functional specifications, and maybe even technical specifications for your IoT project. 5. POC, POC, POC That is one of the hardest part of any innovative project: build a Proof Of Concept and test it. Questions are: what are the key features/attributes that I need to test to prove that my concept makes sense for customers? How can I do that as cheap as possible in order to keep my budget for the real product? You’ll need to be very smart, or pay some smart provider, to be able to degrade your end vision so much to just keep the key attributes you want to test. If we go back to the remote maintenance example, can you build some basic software on a Raspberry Pie Board connected to the machine, coupled with a basic web interface that give critical information on the machine, for instance power consumption, run time, temperature, etc. Even if the final product won’t be using raspberry, if you want the web interface to be embedded into an app, and if you want to have twice as much indicators, just focus on the key elements. And test. Doing so, you’ll allow your customer to see real progress, to feel involved in the development process, and to influence the final outcome. And on your side you will collect key information that would take months or even years to collect if you had done it on the real product. A Proof Of Concept can be a functional prototype, or a design prototype, or both. That is pretty much depending on the project and again on the key attributes/functionalities you want to test. 6. ANOTHER LOOP TO COME Congratulation, you’ve made another loop. You are about to become expert in so called “iterative development”! If you don’t feel so, don’t worry as you’ll have many other loops following the same process: make assumptions, test, measure, learn, adjust and make new assumptions, test, measure … Each loop will allow you to adjust the business model, the functional specifications, the customer engagement and go further into your product development. The complete ''Lean startup process'' The key is to keep in mind that your goal here is not to have the perfect product. It is just to be able to learn as much as possible in each loop while spending as less as possible. Make as many loops as you can until you reach a satisfying v1 product brief. But that is for chapter 2… Originally Written on WITEKIO Technical Blog by Samir Bounab, Chief Sales Officer, WITEKIO 15 September 2017
記事全体を表示
