I'm going to introduce Gregor in a second but, just to give you an idea of what we plan to do, I thought we'd spend the first 10-15 minutes with Gregor talking us through their  journey, the situation they faced, how they went through this pilot project or planning clinic, as they refer to it, and what they've learned so far. We can get into the open discussion about the implications and some of the questions that many of you kindly submitted on the pre session input. Let me start with you Gregor: you are Senior Demand and Inventory Manager at BIOTRONIK. You've been one of the key team that has been leading this pilot project so please introduce yourself and if you could tell us to start with what the background was in terms of the project, where you were, why you started looking at this, what challenges were you facing? 

Yes, thank you. Yes, my name is Gregor Kirshner, I am responsible for the demand planning of the CRM business at BIOTRONIK. CRM in our case means cardiac rhythm management. I would like to share a few slides for you just to visualise some things that we had the pleasure to work together with Frank and Matthew from Flowlity and make a pilot project regarding the usage of the Flowlity solution for our demand planning process. Maybe first a couple of words regarding BIOTRONIK: this is our 60th year now as the first German pacemaker company. It was a startup from the University in Berlin and grew to an international company selling our products in the whole world making more than €1 billion revenues per year. 

You can see a summary of our product portfolio so we are producing and selling implantable pacemakers and everything around the heart that you need for that also: ablation catheters, stents and balloon catheters and last but not least our newest business unit is the neuro modulation. Regarding our pilot project with Flowlity we had the challenge or maybe the background that we do a monthly rolling demand planning process which is characterised by a huge workload especially in our sales force but also here at our headquarters. We have more than 500 materials that have to be forecasted for the next 18 months. Why 18 months? Because we have quite a long supply chain, long lead times. That's why it's important to have this large forecast horizon to be able to produce and deliver on time. 

What we use for demand planning and finance planning is the XXX one tool at the moment. As already stated, the challenge is that we have a huge workload due to the decentralised manual planning. Every country does its own forecast and we aggregate the numbers then at each month at the headquarters and create the global demand plan which we then hand over to our production. Of course another challenge is always forecast accuracy. Although we still have quite good forecast accuracy I would say there's always room for improvement especially in the mid and long term horizon. The goal with our cooperation with Flowlity was to find ways to reduce the manual workload significantly, to optimise forecasting to a certain degree, of course, to keep or even increase our forecast accuracy in midterm horizon. Last but not least, to visualise the impact on possible stock optimizations. 

Therefore, we chose Flowlity as our partner for this pilot project, with Frank and Mathieu supporting us. Here are the results that we found out after the planning clinic: we were able to reduce or potentially reduce the forecast error by 28.5%. I will give some more details on the next slide around that. We analysed a selected number of SKUs from our portfolio. From every major product group that we are selling we picked a few materials that we analysed so high runner products and a couple of countries that we analysed based on that. We also took a look into our process, our monthly S&OP - sales and operations planning - process especially the demand planning process and evaluated how far we could optimise this process. The outcome was something between nine and 36% depending on which modules you use. 

This is calculated based on the data we provided that there could be a potential inventory saving improvement by around 15% to 30%, which we did not analyse deeper in this project yet due to the lack of time. We only had three to four months for that. We didn't deep dive into that part because then we would have needed more time but maybe Frank can add a few words about that. The average forecast error was 43.8% looking over a time span of twelve months and with a different lags of forecast and the Flowlity solution was able to reduce that to 31.3% so that's the 28.5% reduction in the forecast error. There's also potential for 9% to 36% workload reduction, depending on the approach. 

Thank you very much for that Gregor, I'll open it up to the group in a moment and also invite Frank to add his thoughts but first I wanted to ask you, Gregor, a couple of questions. I think one of the most interesting aspects of this case study is how you've gone about the business case development for this. You mentioned at the beginning that you have a decentralised planning structure and that was one of the reasons that you began to look at this. What I'm interested in is that we often talk about the need for a compelling story, the feeling that something isn't working or there's something that could be made a lot better. My question is, before you embarked on this journey, what were the pain points that you might have had? Was there a generally recognized understanding that something wasn't as good as it could be? Was that within the planning team in supply chain more broadly or across different functions? 

I would say it's a general issue in our company that we require the sales guys to hand in a forecast each month or to update their forecast each month, which consumes a lot of workload from them. It's not their core competency to do a forecast, but to sell products. We need this information to steer our company in the right direction and they know best what's happening in the market. We of course could do a central forecast based on actuals and maybe intelligence from the market. Especially when it comes to phase in and phase out of products, which regularly happens every one or two years at BIOTRONIKs, depending of course on the product group that would be too complex for us to foresee. How quick will they introduce new products, phase out, old products? Every product has its own new features and it's different from the predecessor. 

Even before the Coronavirus, our supply chain was very long. The lead times are sometimes more than twelve or even 15 months or longer. That's why we need this information so far in advance to also reduce the scrapping here on our end. Because if sales are switching too fast to a new product platform, then we have too many of the old components which we have to throw away and would create millions worth of scrap per year. The other way around, if we are too late, then we cannot ramp up as fast and we lose revenue. That's the background and of course everyone is complaining about the workload that they have to put into this. We call it a rough rolling order forecast. We are always trying to find ways to make it easier for the sales to give us a good forecast and AI obviously seems to be one of the current top tools to do that. 

Did everybody see it the same way? Were all the stakeholders involved, particular senior management who are probably the key guys to make sure that they're on board and bought into the idea that you can't just keep on doing the same thing, particularly with the prospect of investing in a new planning platform

Yes, especially our management board is often throwing up this AI discussion because here you can do everything with AI. You just have to press on the button and then you have a very nice forecast for everything. That's the background, it always comes up once in a while and now we said, okay, let's do another. We have already made a couple of attempts using statistics and so on forecasting and now we had this opportunity to do the planning clinic with Flowlity, with a very advanced tool. The other attempts were more internally with our own tools. We had the opportunity to use a professional tool and analyse if that's an approach that would make sense to go forward. 

Thank you, Gregor. Before I open it up to the group, Frank, would you like to add to what Gregor has shared?

Yes, thanks Gregor. First of all, I thought it was a really good collaboration with the BIOTRONIK team so it's been very active. We worked together for a couple of months. I see the output is pretty satisfying. One of the questions you raised Gregor was why was there a difference if we're using the forecast module or the planning module? The reason is that obviously there is the automation. The level of automation you can get by using just a forecast module tends to be obviously lower than if you accumulate it with also the planning and replenishment modules because the background idea is that the system works by exceptions, which means that it will automate 80-90% of the tasks of a planner and help the planner to focus only on the exceptions, the disruptions that need to be looked into. 

Thanks, Frank. Questions on what we've covered so far? 

Hi, thanks for that…sounded very interesting. Could you talk to me a bit about the implementation and how you engaged with it? How did it go, how long, how many people were involved, all that stuff?

We are not currently not at the stage of implementing this tool so we have just finalised the pilot project. The planning clinic is a pre analysis and further steps would have to come so unfortunately I cannot tell you about the duration of the implementation and the challenge but maybe Frank can do that from his experience with previous customers. 

So, the implementation phases for our projects usually last three or four months. The platform, which is a SaaS platform, it's its actually an off the shelf platform that embeds AI natively. What we do is that we install the system at our customers and, once installed, we work on the specifications of the business case and fine tune or slightly adapt each solution for the customer. On average, it's around three months. If it's a more complex project it will be four months. The planning clinic that Gregor mentioned is actually an analysis of the performance. We can bring on a selected number of SKUs which are going to provide KPIs in a short period of time to prove that Flowlity can or cannot do the job and project the performance, providing the expected forecast improvements, but also any relevant KPIs, such as waste so we can see how can the waste be reduced. 

Thank you for that. Gregor, you said you were doing 500 SKUs…is that your total number of SKUs that you are currently forecasting in overall terms? And secondly, what were you using before? Was it a purely manual Excel based forecasting system? Did you have another system that was doing some a forecast but it was not AI based? What are you comparing this with? 

Basically we have been using XXX for a couple of years now. Before that we had XXX. Before that, when I started 17 years ago at BIOTRONIK, we still had Excel, but I think 15 or 14 years ago we’d already switched to XXX and then I don't know exactly ten years ago to XXX. Of course our portfolio grew over the last decades. Right now it's more than 500 materials that we forecast each month only for our business unit. 

We represent about 75% of the revenue of BIOTRONIK. Where there are a couple of more SKUs that have to be planned, but that's done by our counterparts in the other business units which use the same tool. We have our own processes internally depending on the business unit. This planning clinic was a selected number of SKUs of high runners from each product group and the most important countries from a volume perspective. 

So, essentially you were using another tool to make system generated baselines, but you found this tool better at doing it. It wasn't as if you were running forecasts purely manually.

I don't know in detail if some of the maybe more advanced countries or better staffed countries maybe use some intelligence on their end, but in this tool, XXX, that we currently use, there are no statistics that we use. It's a pure manual forecast from the countries. 

Okay, so you're essentially going from a purely manual forecasting methodology to a one where the system is looking at history and generating a baseline for you.

I assume that the countries use some kind of elementary statistics, checking the actuals, of course, but no advanced statistics or AI or anything like that. Of course they have some intelligence and know what's going on in the market, but nothing tool-based, so to say. 

First of all, the pilot results look impressive. Good job on the process that you described, from it being purely manual today to moving to this being an AI-generated forecast, that's a big change journey, I guess. What thought have you put in at BIOTRONIK for managing that change journey from sales guys entering forecasts to trusting a central team to be generating a forecast on their behalf? 

Of course, it's a new way of approaching a forecast. We first internally, at the headquarter, spent a lot of time searching for the methods and getting familiar with AI. Also, we have to build trust into these automatically generated numbers so that we are quite focused on that, always challenging whether the AI forecast is better than our internal forecast? Sometimes it is, sometimes not. In general, it seems to be better. Of course, we need to train the sales force or the guys that do the forecast, because for them it's also new. On the one hand, everyone complains about the effort they have to put into the manual forecast. If you come to them with a new system that says, okay, here's the tool that proposes the values for you, then everyone, of course, would say that I don't trust these numbers and I think you have to put in a lot of training and education when implementing such a solution. 

We would do this step by step with pilot countries to convince them and then roll that out internally. I assume that this is a big topic and a big hurdle for most of the people to build that trust in new technologies that we already use in everyday life but no one is aware of. For instance, if you think of an aeroplane, there are 200 computers in it that steer the aeroplane. The pilot is basically for starting and landing. Nobody would trust an aeroplane without a pilot, although the pilot only does 10% of the work. That's how it is, I think, with a lot of things and also the same with forecasting. Of course, you cannot replace the people and the knowledge…there always has to be someone who's looking at the automatically generated forecast and confirmed or reject suggested changes. 

Our approach was to ask ourselves, how can we minimise this effort? As Frank said, the approach would be to have this planning by exception, so that the system shows where are the spots, the focused products that you have to look in and all the other 80% of the portfolio can be forecasted automatically and you do not need to check every product. 

Okay, so the ownership would remain in the regions, but this would be as a support to take a lot of the assets out of that process of forecasting and then you tackle the exceptions in the regions. 

Exactly. 

Just to recap what I understand so far, which is that you are currently using a system to generate a baseline statistical forecast at central level. You are splitting that by region, right? You were touching the element of trust and then a gradual deployment in order to gain the trust on that number. My question is that if there is a forecast enrichment process, how does that look like and if that enrichment process is hosted by an ERP system. I don't know anything about the business that you are ordering in, but for sure your business is driven by quarterly and yearly business targets, right? At some point sales, they will have to actually meet those specific targets and therefore you can use sales history to a certain extent and can be very reliable. You will have an element that you will have to okay, we’re expecting in this region, this product to actually grow exceptionally versus the other. There is a manual element that is the fine tuning of the baseline statistical forecast so what does that process look like? 

We also are facing this problem that on the one hand you have the actual, the history. That's what we also do here from the headquarters when we do the sanity checks of the forecast for the countries and so on, and we try to align our forecast. What we do is a sales and shipping forecast. The countries have to forecast what they want to sell and this is also revenues or financially related. Every couple of months we also have a bigger finance forecast round where they have to forecast the sales and the revenues and this is aligned with our shipping forecast…what do they want to order. We also have to have the stock forecast for the countries because there's also a big issue for us to keep the inventories in the countries as low as possible. 

This process has been aligned within our sales and operations planning process and of course they have to reflect the expectations from the management regarding budget and growth rates and so on. Of course, at the beginning of the year or when the budget is set up, we look at the numbers and critically challenge them. How realistic is it to have this and that growth rate for the different products? Of course, at the beginning we have to trust it. With each month and as the actuals are coming in, we are looking at how they perform versus the forecast and then start to challenge the numbers. Even with a management board, which is part of our sales and operations process because we present our new plan, Demand Plan, production Plan each month also to the Management Board and they have to approve it. As I said, we're critically challenging the numbers. 

Of course to a certain degree we have to trust them. If the deviations are too big or too obvious that the expectation and the reality do not match, then we even would have the right to overrule from a shipping perspective, which is the input for the production to overrule the country forecast internally and add or reduce the quantities that the countries are forecasting. If we see that they are over forecasting too much, then we reduce the numbers internally because we don't want the production to run into the wrong direction and waste capacities and materials and create scrap and so on. That is our role internally regarding the shipping forecast. We are not responsible for the sales forecast because this is part of controlling of our sales, but we are responsible for the forecast regarding production. 

Okay, very clear. Thank you. 

Yes. Just to clarify, Gregory, the last point. You're saying that if the sales forecast gets put in and that forecast is higher, you reserve the right for the planning forecast to reduce that number to a number that you think is more suitable regardless of what sales are put in. 

Yes. 

Don't you run the danger then of the feeling that this is their number and this is my number and you have two different sets of numbers running in the system and it's not one single number for planning forecasting? 

Yes, they're doing the sales forecast for the revenue. Sales units which they want to sell to our end customers, to the hospitals and so on. They also have to put in the shipping forecast. What do they want to order from us? We have the right to overrule this quantity and say, okay, we do not believe that they will order that much on the midterm horizon. Maybe not for the next month, but for the midterm and long term horizon. That's the number that what we hand over to production. Of course there are the two numbers. One is the country's forecast and the other one is what we think is realistic because we also put some intelligence with we have certain ratios of products that are related to each other. 

For instance, if you need more pacemakers then you also need more leads because they are connected to that. There are certain ratios that we compare the global forecast against and also if we see that they are under forecasting the products then we also add quantities to make sure that production gets the best numbers that we know. In both directions we can overrule if necessary. 

Thanks. 

Thank you, Gregor, for that. That's given us a really clear view of how that's been working at BIOTRONIK. Frank, obviously you guys work with lots of different clients, different sectors, different sizes. We've heard some of the common challenges that are brought up here in the questions that have been asked. How typical are the issues and challenges in this transition? What have you seen when people are trying to build greater maturity, greater accuracy in their planning processes supported by AI and other technology that I guess shapes the Flowlity philosophy, if I can call it that, about how you feel that should be done most effectively. 

Well, what we usually see with our customers is that there is a growing maturity to, I would say, bridge the gap between the systems they currently have, such as Gregor expressed with XXX, and to be able to improve the demand and inventory side and actually do this trying to get rid of any scepticism because the systems that they've used and put in place over the last years tend to be very costly systems. There is a strong need to indeed check if they can improve the forecast and what's going to be the impact also on the inventory. I'd say that all of our customers are actually in an exploring mode. They're using systems and processes they've had for years. Their first reflex is to say, well, can I actually improve the demand and inventory in a way where they feel very safe about it. 

The tendency is to actually start with either a business unit or I would say products which are pretty difficult to forecast, or raw materials which are difficult to forecast. The second part to this is obviously, as Gregor was mentioning, is the change management associated with it. I think the idea you mentioned, Gregor, about the pilots doing 10-20 percent of the job is indeed, I would say, what we were trying to explain to our customers, because there is this tendency to think about it as a black box. What we tend to do is provide along the road the necessary information for our customers to understand that the forecast we're providing is actually accurate. Obviously, there's some versioning possibilities to understand: what is the history behind this forecast? It's also a change in the way of working for the people doing the forecast and the planners in terms of focusing only on the areas where there are disruptions and then obviously to trust the result that has been provided by Flowlity. 

You mentioned that issue of trust, and this is a question that comes up quite often with AI related platforms..the black box phenomenon and the extent to which people trust that. How are people able to develop that trust? Can they peek inside the box? Can they edit the algorithm? How do you see it best happening that people build that trust in the number? 

When we work with the supply chain teams, the project teams, what we do is we go through a number of runs when we're in the implementation mode where we compare the results. We set the KPIs with the customers to actually be able to feel confident and do a few runs to actually measure what are the forecast improvements along the line and inventory improvements too. We have a support team member who's actually continuously in touch with our customers to follow month after month what is the outputs of both on the forecast and the demand side. It's a building trust relationship which is backed up by KPIs which have been continuously measured, which means that when we deliver the results and when they implement those results, they're actually checked and validated before going into production. 

Thank you. Thank you so much for the presentation today. It's really insightful and I really appreciate the discussion around change management. I think that it's so important because I hear a lot here around, numbers and we should trust that, this is accurate. That's, that's I think that's completely right. 

That's the right approach. 

When we interact with stakeholders, it's probably only 30% of the change management. The other 70% is emotional, right? I'm not trusting that whatever numbers you give me, it's a big change for me here. I think what would be really interesting is do you have a way or does anyone here have experience of  that kind of change and how did it really work for you and for your company? You can help with the change because I think that 70%, it's where we struggle the most, not the 30% of data backed benefits. 

I can go into that because I've done this very similar exercise in a previous company I used to work for. What we did was we moved 50% of SKUs, which is 3000 SKUs, into an AI algorithm offshore. Those 50% made up less than 10% of our revenue. Essentially your C class SKUs and moved them across. What we found was that 70% of what you're saying is very important, right. No matter how beautiful your black box is and how many good tricks it can do, we found that depending on the maturity of the market you were dealing with, so for example, the EMEA markets, or the Middle Eastern markets, the African markets, they would touch the forecast 85% to 95% of the time. They touched it while adding little value to it. The intervention rate was extremely high and this is the maturity curve because they felt that they had to match the financial forecast at all given times, regardless of what the box was throwing out. 

If it's out by five units, they would put five units in because that's what the financial number needs to be. This is where when you bring in a technology like this in, it's very supply chain oriented with supply chain doing all of these things, whereas your commercial folks are saying, well, I can't bring this down basically. We found that in Europe it was a bit better. We were probably at maybe 50% of the time that were trying touch it because it was more mature and they understood that. Frankly, touching the C class SKUs is not something that's going to give me my financial budgets, right? I need to concentrate on A's and B's, for which we did allow them to change the forecast. It's interesting, there's still this initial element of like I don't trust the system. If I'm not touching the forecast, then it's not my number, right? 

Thanks M. I'd like to take the opportunity to come to you I, if you don't mind, because surely everyone at XXX trusts the number, don't they?!

We’ve had a very similar journey as the others here and a lot is around the trust issue. When we implemented, we did a comparison of the numbers with different codes and where we are adding value. This helped us a lot since we started implementing machine learning. We introduced the first part and we realised that once you bring the forecast value add in a more enhanced part of the journey, it's more difficult to change. If they are still using and touching the number and when you are coming with a metric of forecast value add, nobody is really paying attention because it’s complicated. What we did was to put it up front all the way in one of the other markets we did last year and it was completely different. 

First all, we had to do the education: what are the methods we are going to compare, what are the codes we are going to compare, what are the headaches we are going to compare and bring it into the S&OP process. So we said your process is like this, I will produce this number and this is the forecast value add. We ran exactly as Frank was saying, doing the rounds and comparison of different codes and always showing the forecast value add. At the end, it was really good to hear but they are running the business they are steering the business but it was really good to hear what they were saying that they do not do forecast value.

It's telling me like -7% forecast value or -8% so why you guys are touching it? It was like okay, my job is done! They are still now into the rhythm so I think that was a really good change with the approach and now for instance would be more that they identify wherever they are touching it and they are adding value, I say OK, I take the challenge: I need to improve the model. Maybe another demand driver that they are putting that I don't know, media, for instance, or any other thing that they are adding. I would include it into the model, improve the variable. I can give it to you as a part of the demand driver basically, coming from machine learning. Those are the conversations we are having now instead of saying guys, don't touch it. 

Very quickly we moved from last year…it was in October, November when we launched it, literally adoption of ‘no touch’. We started with 8% and now we are looking and in four to eight months, we are looking around 45% - 50%. Our ambition is for those markets 80%. So it's very quick. We are seeing improvements. That's the little change that we did and it was fruitful. 

JP

Thanks, I. 

Maybe also as a first step we are looking forward to the way we use these statistics and AI is to have something that we can match our country forecast against to see where the deviations are the biggest and then have start the discussions maybe on a more database and not just actual versus forecast and so on. Of course then the next step is to roll these automatic generated proposals out to the country so I think you need to do a couple of steps before you have the countries trust the black box. That's also our approach.

I think it's really interesting because we tried a few different things. In Europe, we launched it and we said, okay, you can enrich everything. You have your stat model as a base and then what we found is everyone is enriching back to where they want it to be. 

If they have a thousand then it says 800, I'm just going to add 200. Every month as the stat model just re-updates and you just have more work because we need to redo your forecast to match back to where you didn’t think it would be. I don't know if that was the best option. We did have as well other approaches where we launched in North America. We gave the opportunity to freeze the stat model to set up. On this one, I'm not too sure I'm willing to freeze either the inputs or the outputs or the stat model change or you can as well look at the frequency of the data. I was quite curious to see what was the approach used. Did we actually go all in across like your experience guys, you say okay now everything is stat modeled and we expect, as you go you give the opportunity for the business to freeze and not freeze knowing that then the adoption base is much slower but at least you gain that trust as you build it. 

What we did was that we initially did the SKU segmentation, so we did an ABC segmentation and we said the A class SKUs were the ones which were racehorses, right, which were your new products, which needed a lot more intervention because they needed a lot more market intelligence. Frankly, they're the ones that everybody is concerned about because they need to succeed for your pipeline to work. We allowed more different sets of rules for that and we probably wouldn't run the baseline for them because there was just too much going on there and, even if you did, you were allowed to overwrite it a lot. When it came to your high volatility, low volume SKUs, your C class SKUs and maybe your less volatile ones we were tighter on saying you're not allowed to touch so much. We would measure your amount of market intelligence against the baseline every month to see how much you were adding every month to see if that was actually adding value compared to if you had just left it. You change the behaviour pattern by showing them that, if you just left it, your bias would have been lower and your forecast accuracy higher. You take them through that journey every month basically. 

Completely agree with you. You are showing this and you have a dashboard and on a weekly, monthly basis until you get into the new thinking because literally this is new thinking. 

Thanks guys. Frank, we talked about some numbers here. At the beginning Gregor outlined the improvement in forecast accuracy. There are some tentative numbers in terms of reducing inventory costs from the pilot project but in the full implementations that you've done, how much have you seen that kind of trust and behaviour change as people get more and more familiar with the system and hopefully the trust in those outputs? 

Well before I go actually into the numbers, I'd say what really brings in the confidence is that Flowlity combines the forecast and the inventory together which means that, if we're going to provide a forecast value, which we do for each SKU and correlated SKUs, we're going to provide also what is the impact on the inventory side. Take into account that both inventory and forecast use a probabilistic model, which means that on both sides we're taking factors which are going to influence the forecast and also the inventory. On the forecast, obviously we're going to sense the demand. On the inventory side, we'll also take what is the real lead time and not just the SLA lead time which means that you can do a very good forecast but not have the right inventory levels and not be able to compare both as the exercise is decorrelate and this is where also you get a source of misunderstanding from the teams. 

Whereas, if you combine both, you're actually able to say that my forecast value is so much. It's a forecast value which is going to provide different perspectives of what the future is going to look like. So we're not giving just one number. What we're giving is actually a horizon of values of what the forecast could look like on a given day. The forecast is run weekly and the inventory is run daily, which means that when you actually combine both, you give much more confidence to the teams that the values we're proposing are much more trustable. We have customers like XXX for instance, who had a major issue in terms of sourcing components and obviously forecasting products. The way we worked was to take this gradually and in a couple of months - two, three months - to actually show that the forecast values we’re providing and the inventory values we’re providing were actually matching the demand and the supply capabilities also. 

If you provide a good forecast, good inventory, you need also to be able to check if your suppliers are able to deliver. And this is what Flowlity basically does. The output for XXX was nearly a 40% stock reduction and roughly 16% stock outs. There are some very strong KPIs you can measure the performance on and provide trust. I think those are the KPIs you need to set into stone when you start the project because those are the business drivers. Those are the ones you need to be measured week after week, month after month to show that you can put confidence in the solution you're using. You can do a very good forecast, it can be very accurate. If it's not combined with inventory capabilities that match those forecast performance, then you lose the confidence. 

It's a balance between what your forecast is, what your demand is going to look like and what your suppliers are able to deliver.

Thanks Frank. I'm just conscious of the time and I did promise that I would ask this question on behalf of guys who couldn't join but wanted to who are at that stage that Gregor was four or five months ago, where they feel that improvements could be made. They want to establish a business case to build confidence in that. Frank, if you could in about a minute and a half, just paint a picture as to what the next step would be. What would you do with somebody who's currently at that position of considering the next steps of their planning maturity journey and potentially investing in a planning platform? 

I would say the first thing to do is to build trust. It's a strategic decision for any company out there to say I'm going from a manual or semi automated process to something which is more automated. I think the first thing is actually to prove the case and to show evidence that the tool can do the job. There is something that we call a planning clinic which BIOTRONIK has used to actually show evidence. This is selecting SKUs which are the most representative and showing, based on a number of KPIs that you decide, that performance can be there. That's the first step. 

The second step is to go by a segmented approach which means that you don't have to put the whole business at stake if you don't feel that it's the right solution. You can select a class of SKUs or you can select a region to move forward. There's also another way around this is there is a module called ‘Tactical’ that we have launched which is actually we combine with the platform which enables both the demand managers, supply chain managers, or even procurement to actually be able to understand, make scenarios and understand how they want to move forward. 

A simple example is I have an NPI, what's going to be the impact on a region? What's going to be the impact on my suppliers, my forecast? You can do, I would say, a step by step project in which you're going to say I'm going to implement it in a way where I want to limit the risk. It's more a project strategy and it comes down to how each of our customers want to move forward with us basically. There are ways to mitigate the risk and to do things in a safe way. 

Thank you Frank. We've just hit the hour so I'm going to very quickly say thank you to everybody who's joined and for all your contributions, particularly to Gregor. Thank you very much for sharing your experience and your journey with us and also Frank for giving us those extra insights alongside that story. Thank you everybody, look forward to speaking with you again soon.