EJ Tavella 0:00:09.9: 

This is a real-world story, working with a great customer to talk about implementing applications, but also getting the details of hey, look, how do you implement applications in a case where you've already got a custom-built solution? What's that look like? What does that mean? What's different? How does it all work? How are we driving value, etc., through that cycle? So very excited. EJ Tavella, I run our supply chain business globally, have had the pleasure of actually being an Anaplan partner also for the last eight years before that, implementing little companies like Nvidia and Bacardi and lululemon and others. So appreciate the experience, having gone through this a lot with our customers and understanding really what the platform does, but also understanding the reality of implementations, what that looks like, the effort from a data perspective and a change management, etc., as we go through it also. Again, super excited to be able to present with you, and Kyle, why don't you do a quick introduction and we'll jump in?  

 

Kyle Friedrichs 0:01:05.3: 

Sure, Kyle Friedrichs, head of OpEx at Maesa. So basically, I've been here for about two and a half years, and I've done implementations with a couple of other companies for a variety of different systems. So I've got to see ERP and MRP implementations at four other companies and about six different implementations of two different countries. 

 

EJ Tavella 0:01:23.3: 

Yes, love it, I love it. The growth that you guys are having is amazing. So interesting to dig into that. So let's jump in. I think we can skip this when we've done it. I think if you guys haven't all heard of Maesa, I don't use a lot of it, but I have three daughters that are in their 20's and they're like, 'Oh, yes, dad, come on, this is cool stuff.' So it's a very impressive company. Why don't you share a little bit about Maesa and its growth that you guys are seeing? 

 

Kyle Friedrichs 0:01:48.0: 

Sure, so Maesa, we develop and incubate brands. We've had a fairly large number of different brands that we incubate, mostly in the hair and fragrance space selling at mass. So Target, Walmart, Amazon. We launch a couple of new brands every single year. So the rate of change is very high, and it's a pretty heavy rate of expansion in terms of items and customers over the years. 

 

EJ Tavella 0:02:10.8: 

Yes, and that kind of growth drives the need to automate these processes. We were talking about as you guys scale and continue to grow in size, how do you manage and maintain that. The fashion industry is also a picky industry. So launching new products, trying to understand what that launch is going to look like and how that's going to support demand and supply, I'm sure is one of those challenges you guys have to… 

 

Kyle Friedrichs 0:02:33.4: 

Yes, we've had quite a lot of change. It changes very quickly because you have things like an influencer, for an example of Miley Cyrus [unclear word 0:02:39.1] posted online, and that item demand quadrupled overnight, and this source of change creates a lot of volatility and we need to be able to react very quickly on all the different components and push everything through our supply chain pretty easily. 

 

EJ Tavella 0:02:51.4: 

Yes, love it. Great. Well, we'll dig in, maybe give a little bit of the background. How did you get into this journey? Where did you start? 

 

Kyle Friedrichs 0:02:57.9: 

Sure. About two years ago, we launched Anaplan with statistical modelling. We did a demand planning solution. We did it mostly in-house. We did have a consultant help us with some of the implementation. We basically went online, downloaded the stat models and then built a custom solution based upon that, and as something we tend to do, we did it really quickly. We did it from start to finish in about six weeks, which was quicker than probably we should have, but it did actually work and we've been making improvements as we go. The advantage we found with Anaplan is we could launch with a minimum viable product and then expand from there as we went. So we were able to know things we wanted to do in the future and know we didn't have time right away, and build upon that. So even though we launched the demand planning, we knew eventually we would want to get supply planning. So we actually even built all the tables and the exports for that, that we would need, even when we were building demand planning, because we had it in mind, and we have to do that and leave it there. 

 

EJ Tavella 0:03:47.4: 

Yes. So as you got demand planning in place and started to understand that signal better, and when you decided that now we're ready to get into supply planning, because we have nothing else going on in the business. It's going to be easy. When you looked at applications, what was the decision-making making around applications? What were some of your key requirements? You've got them listed up here, but what were some of the key requirements that you saw as a fit, and why did you decide to use applications versus build it again yourself? 

 

Kyle Friedrichs 0:04:14.0: 

Sure. So part of what made it more complex for us is our old systems are ERP and are MRP. So when we were going to replace one, we had to replace the others. We had to do both the ERP and the MRP implementation at the same time. What we liked with Anaplan is a couple of things. One, we already had it for demand planning, so there was some company familiarity with it already. We also understood the modularity of it. We could add to it as we go, and we had seen that functionality before. The reason we ended up going with an app is the app gave us about 70 per cent of what we needed right out of the box. So instead of having to custom build everything on our own, we could download that, set it up and start building on top of that. So it saved a lot of the work on developing the best practices that already existed. 

 

EJ Tavella 0:04:51.7: 

Yes, I think that's pretty representative of what we're saying. I think when we look at the market, we've got some customers that are saying, great, I'm going to use it out of the box. But honestly, probably the vast majority of them are seeing somewhere in that, I'll say 70 or 80 per cent use case out of the box, and then configuring from there. It is like any other Anaplan application, or any other Anaplan build for that matter. It is probably an ongoing process as well. I think this is the case for you guys as well, you're alive, you're using it but you're also still adding new bells and whistles as you go. So that doesn't go away. You don't lose that option. You're not locked in like some of the, I'll say, more traditional applications, the ones that start with a B and a Y, and others where once you're done implementing it, that's basically all you're going to have for the next three years or five years, because you can't change it. 

 

Kyle Friedrichs 0:05:39.1: 

Yes, even though I've been doing the supply planning implementation for the last couple months, our demand planning head has come with different things that they wanted added. They've been tweaking and making changes to their reports, and most of the requests are quick, some are longer, but we are able to make those tweaks and make those improvements as we go. 

 

EJ Tavella 0:05:52.6: 

Yes, cool. Well, let's maybe talk a little bit more about the journey. I mean, this is a crazy journey that you went on, and I think the audience will appreciate and maybe reflect and understand the challenges around the data, but share where you were and how that bumpy journey went. 

 

Kyle Friedrichs 0:06:08.7: 

Sure. So the old system we were using was over a decade old, wasn't supported anymore, wasn't updatable, it wasn't really fit anymore. Since our ERP and MRP linked together, we had to make that change at the same time. So it was last February, we actually got approval to even look into some system to go out and do that. So then by about April, we decided upon using NetSuite for our ERP and then Anaplan for MRP. 

 

EJ Tavella 0:06:32.9: 

You realised NetSuite doesn't have a supply plan. [Laughs] 

 

Kyle Friedrichs 0:06:35.1: 

So we ended up going and deciding to partner with Bluecrux, and they basically helped us come on and design what we were going to do. What made it a bit more complicated is we were still designing and building out our ERP, which is the major feed for MRP data. So it was a very back-and-forth type of process as we were going, building it out, trying to understand how everything was going to link together there. 

 

EJ Tavella 0:06:57.1: 

Yes. How closely with IT did you work on that process? 

 

Kyle Friedrichs 0:07:00.8: 

I think the IT team knew us better than they would like to at that point. 

 

Audience 0:07:04.2: 

[Laughter] 

 

EJ Tavella 0:07:06.3 

[Laughs] Yes, I mean I think it's interesting because I think Anaplan often is business-led, and I think that's great, but I think when you get to supply chain, you get to the data integration that you need to do MRP, right, you've got to have that master data. You've got to maintain it, manage it, control it. IT always has their fingers in it to really help make sure it can scale. What does your integration look like? How frequently are you guys pushing information back and forth? Things like that. 

 

Kyle Friedrichs 0:07:30.9: 

So every single day we feed new inventory information, new in-transit information and sales orders, and then at the end of every day, we take those, any purchase orders the planners decide to buy, and push that back. So it's a once-a-day feed in either direction.  

 

EJ Tavella 0:07:44.7: 

Great. So you're actually not only pulling in the transactions and the actuals, but you're actually pushing - you're creating the purchase order requisitions and pushing that into the ERP to execute on. 

 

Kyle Friedrichs 0:07:52.9: 

Yes, right now about 80 to 90 per cent of the POs that we're doing are being done through Anaplan. That was sort of expected. Always something that has to get placed that day or is a bit outside of the normal flow. So it's about where we expect. We maybe have to bump that up a bit in the future. But again, there's still other improvements and enhancements that we're going through. When we went live with a launch, we knew there were certain things we wouldn't be able to get done in time because going back to the timeframe, we wanted to get everything done before Q4. Having no system in Q4 would not have gone over too well. So we had to get everything done a little quicker. So some of the things that were smaller, we ended up pushing out to be able to develop and build out later. 

 

EJ Tavella 0:08:25.2: 

Yes, I love it. That makes sense. Well, I think maybe give a little bit around the scope and some of the - you hit on a few of these pieces already, but a little bit of the overall scope of what you're planning, how many SKUs you've got, customers, warehouses, etc. 

 

Kyle Friedrichs 0:08:39.6: 

So we have about 30 different users, both in the US and in China that are in the system almost every day. We have about 2000 different products spread over 100 different suppliers and vendors, and then about 9 different warehouses. So right now, we might be on the smaller end of what some of the people here are working with, but part of the reason for choosing Anaplan was the scalability. So the idea is to be able to grow and then not - if we double in size, to not double the user base, not to need to have to grow that quickly on users. So we took the system, made the choices with the ability to be able to grow that way. 

 

EJ Tavella 0:09:12.0: 

Yes, I think that's a common theme that we hear all the time. I was on stage with Nvidia a year ago, around this time, and we're talking about their scale. They've, let's call it five X'ed in the last two years, and they were saying they've been able to do the same planning process with increasing only the planning team by ten per cent. So there's a target and goal for you, as you - one goal, quadruple your business in the next two years, okay, that's one goal. Two, only increase the team by ten per cent.  

 

Kyle Friedrichs 0:09:39.0: 

I think our CFO and CEO would like that. 

 

EJ Tavella 0:09:41.7: 

They would like that. Okay, cool. Yes, we can come back and do a check-in on that in a couple of years. Awesome. Perfect. So maybe we dig into the details, right? Maybe walk us through it, right? I mean, I think again, the audience typically in these things really likes to understand what does it look like? What are the steps that you went through? Maybe a little bit also what was different with those steps, with applications versus building it yourself? I know you talked about MVP, but as we get into foundations, like design, right, that design phase, how did that differ? 

 

Kyle Friedrichs 0:10:14.2: 

Sure. So what we had to do here is to really understand what we wanted out of the system, what the requirements were, what the needs were, what the nice-to-haves were, and the things that can be delayed or pushed out. So really, the first couple of weeks were really understanding what we needed to do, digging into it, understanding how things are going to flow and then also, how it would change now that we were going out of one system and into another. So then it was getting the models and getting some of the technical stuff in the background, getting the app, getting all that up to speed. Our original model on demand was using Classic, and we're now using Polaris. So we had to bring up Polaris and get that all set up. Then the other big one is data, which in itself, in a normal environment, extremely important, but when you're also going live with a new ERP at the same time, that's an even bigger data push. So we're changing all the data formats in ERP, and at the same time then being able to push that into the MRP system, and also finding out data that we didn't need in the past world that we do need now. 

 

EJ Tavella 0:11:12.6: 

Yes, one of the things we hear a lot is through that design phase, also being able to not have to just do that totally in a vacuum, be able to see what's in the application, see what it could look like, understand options, etc. Helps to make intelligent decisions on how you take that forward and versus - especially as you're evolving your process, and again, going from kind of maybe a - I'll say, an older process to a new process, helps to drive that overall cycle. When you think about data and data integration, and again, we've [?said 0:11:45.4] this a bit, you also had an existing system. How was the connectivity between the existing system and the application? Was that a hard thing to do? Did that take a long time? Were you able to leverage the data that was already in that solution as part of the supply planning solution, where it was appropriate? 

 

Kyle Friedrichs 0:12:00.7: 

So in our old system, we didn't have things like even locations in the old system. So we had to go get all of our transit information, all the lead times from scratch. We were able to, within our ERP, upload a lot of the master data, but even then there was quite a few holes in there and quite a different bunch of different formats, and whenever you go live with a new system, you find the gaps that existed, that people knew how the old system worked and that they were able to work around. When you're going live with a new system and trying to get everything more regimented, it's sort of forced into place, processes, and then therefore are gaps within that data. 

 

EJ Tavella 0:12:32.5: 

Yes, for sure. Was it hard to connect the old demand planning system to the new supply planning system? 

 

Kyle Friedrichs 0:12:37.6: 

That part was pretty easy. So it was just the Classic into the Polaris. I think it was about a [?little than 0:12:41.0] a day's worth of work, that actual part of the connection. So that was… 

 

EJ Tavella 0:12:44.5: 

You said that earlier to me. I wanted you to say that again because… 

 

Kyle Friedrichs 0:12:47.1: 

I got that! 

 

EJ Tavella 0:12:47.9: 

[Laughing] Well, it's something that I get asked all the time. Hey, but we've already got this in the solution. We've already built this out custom. If I use applications that totally change the architecture, am I able to connect those two pieces together? I mean without prompting me, you said a day and a half, I'm like, that's a great story. I mean, it really is impactful. I think that's our intent, right, at the end of the day, it is the same platform. We are still connecting those pieces together. I've been through a similar experience with another customer that was in the process, not of replacing their ERP, but putting together an entire data lake in parallel. They never had a data lake, and so they said, great, we're going to use Anaplan and we're going to have a data lake. For them, I think it was interesting, they ended up - IT would end up saying, hey, we ended up doing a better job of creating that data lake because of the fact that we were doing this planning program with Anaplan, because we had better insight into what kind of data we really needed, what level of detail we needed, how it was all going to be interconnected.  

 

EJ Tavella 0:13:46.2: 

So it ended up actually - yes, it was painful and you lived through it together, but they were happy with the result of it because of the fact that they did it together, and if that was something that's valid for you guys also? 

 

Kyle Friedrichs 0:13:57.8: 

It was, along with the new ERP, MRP, and we also had a new data lake at the same time. So we were doing the same thing where we were understanding what information we needed, and there was definitely a lot of iteration. We'd make a change in NetSuite. We'd then look at Anaplan the next day and go, that didn't quite work. Go back and have that discussion and try to figure out where that gap was. So a lot of flowing back and forth. Even at times, planners seeing something didn't work in the test or even production later and saying, 'Hey, something didn't work.' And just flowing back to us and saying, 'What broke?' 

 

EJ Tavella 0:14:24.5: 

So you actually ended up configuring NetSuite in a way that's going to make it more effective for planning too? 

 

Kyle Friedrichs 0:14:29.5: 

The NetSuite, how we export the data, how we even then look at it within Azure. 

 

EJ Tavella 0:14:33.3: 

Yes, I think that's great. As you got further down the process and did the build etc., what did the transition to the end users look like? How involved were they through the early stages of the process, from a visibility of what was happening and decisions that were made, and how did the training and user ramp-up go? 

 

Kyle Friedrichs 0:14:51.6: 

I think they were involved in the beginning. In hindsight, we probably wish they've had more involvement, but since we did all the systems at the same time, we only had so many people and they were now split between all the different systems. I would say that would probably be one of the bigger takeaways of having more involvement from specific users at the beginning, and then at the same time, we were going live with training for this, we were also getting training for the ERP at the same time. So we had a lot of split time. So that was probably the part that, if we're looking back on it, would be the one that we would want to change the most. 

 

EJ Tavella 0:15:18.7: 

Biggest challenge, yes. Did you do live training for end users? Hands-on? More like recorded types of training? How did you end up conducting the end-user training ramp-up? 

 

Kyle Friedrichs 0:15:27.0: 

Most end-user training was led by either Bluecrux or the super user, and showing them the tool as they go. A lot of that training was recorded just because somebody is often not there [?sending it 0:15:36.7], or also for future reference. But a lot of it was live training, and then we have a daily touch bases, where everyone's going over it, ask questions, see if something's working or not. The nice thing is those meetings are getting shorter and shorter, on average though. 

 

EJ Tavella 0:15:49.2: 

Yes, I love it. Well, you had said earlier that the user adoption has been pretty good. So that training sounds like it worked. I mean, even though maybe lessons learned, could have done it faster or could have done it stronger. I think that combination of those pieces definitely makes sense. I'll say my experience with the change management, to your point, like getting the planners in earlier on, just to give them visibility of here's the things that we're making, here's what's coming. Get excited about it. Oh, by the way, here's the impact we expect to get from doing this. This is why this is important. We're not just asking you to learn some new tool for no reason. It's actually going to give us better results, helps. Yes, cool. This is a great story. So maybe we get into a little bit of why the adoption was so good. It sounds like you've really thought through what that user process was going to look like. Do you want to talk through a little bit of your mentality around exception-based planning? 

 

Kyle Friedrichs 0:16:40.3: 

So overall, we have dozens of pages, but the reality is the planners only have certain ones they need to focus on. So one of the main ones we have here looks like a little bit of an eyesore, if you're looking at it from there. But each planner can go in and filter down for their items and basically take a look and effectively see something as red, which effectively means we're running out of stock. Then there's other pages they can then go to and see what orders need to get placed. Then we have a couple of different exceptions on that. So if an order is on time, just needs to get placed on the next week, planner can go in and do it. If something's past due, that highlights that system, you should have ordered this three weeks ago. Well, now we can take a look, see how critical of an issue it is, and effectively they look directly through here or made it through as exportable, and then they can sort for the items that are the most past due. Some things are a day past due, they're probably not going to spend as much time on it. Items that are a month or two past due, they can then spend more time on it. 

 

EJ Tavella 0:17:26.5: 

Yes, I love it. I mean I think as we've worked on designing applications, this concept of an exception-based planning process is front and centre in our mind, as we're developing these. Again, we talk a lot about analytics, and I think analytics you can have - one of my old colleagues used to say, you can have big A analytics or you can have little A analytics, exception-based analyt-, it's not big A, no, you're not doing MLR to make it happen, but it's intelligence into the process that helps you focus your time on where it really needs to be helped, right? I think that's the kind of stuff that we're really trying to drive in applications, is making it an exception-based process, because this stuff is hard, and even though you may have only 2000 SKUs, that's still a lot of products to plan. Especially when you think about managing across the end-to-end network.  

 

EJ Tavella 0:18:09.9: 

We were joking earlier too that - those of you that are supply chain people, especially supply planning people, you appreciate this. In supply chain, you can get your forecast right at an aggregate level, and at a detail level, it still be completely wrong. So somebody says, what do you mean we plan the perfect amount of supply. Yes, but you put too much here and too little there. So you were actually wrong on both ends. Nice try. So the devil's in the details, right, and you've got to be able to go down to that level of detail that actually matters for the inventory and planning pieces. Otherwise, again, you're going to get it wrong. So maybe to that end, we'll go to the next one, which is another great example of a view that you guys use all the time. 

 

Kyle Friedrichs 0:18:49.8: 

So this is basically the front-end view that the planners have. This page effectively gives people a view to what their inventory is, all their in-transits, expected demand, actual sales orders and then highlights any positives and negatives. So on this line, if you look at that bottom strip right there, it's all green. So on the side of everything's being planned, stocks coming in on time, everything's nice. If any of those weeks were coming in under, it basically highlights it in a nice little red. It makes it easy for that planner to then look right in. We also tend to have a lot of our master data up top. So we have our safety stock policies, lead times, MOQs and other information. For the most part, those buckets up there with all the information there, we have a planner saying, 'Oh, I want to see this.' Then usually within the next day, the next time we meet, it's there. Most of this has been fairly easy to add, and it usually comes out to a planner who's been asking for it. We try to do it as easy adds, where it's not really rebuilding. We don't try to do anything too formal on it. Just edit if it's larger-scale changes. Then we try to have a little bit more of a rigid process of making sure it makes sense before things are changed. 

 

EJ Tavella 0:19:48.1: 

So flexibility. I mean it's a really good point. So the flexibility for the data is already in the system. Great. We just want to change where it shows or we want to bring it into this view, and that concept of being able to do that kind of change. Look you're not changing the integration, you're not changing any of the core functionality, that can be done in a very dynamic way. I think that's a really impactful piece. I mean that's something that actually even people that aren't model builders, per se, can even do some of that stuff for their individual views, too. One of the things as you talked about, so going from the first view, I've got an exception. How do I go from an exception and then quickly, to your point, drill into a screen like this where you can say, great, I've got an exception, here's all the information that I need to be able to make a decision. We want to have it at your fingertips in one place. Ideally, you don't have to click through 27 screens. I think as I look across our portfolio of customers and a lot of custom-built solutions, I think we sometimes see that, where they've built 75 different screens to go solve something. 

 

EJ Tavella 0:20:47.5: 

So if you know where everything is, it's great, you can do it, but it's not really consolidated. It's something that we as a product are spending a ton of time on thinking about how do you really think through what is the day-to-day user-based profile? If the planner comes in and they come in the morning, what do they want to see? What are the biggest exceptions? How do I then make it really easy for you to then take an action, to your point, get to a single screen or two where you see everything. You can tweak something, you can make a decision, get it to green and then move on. So I think it's great to just see it in action. As we were going through prep for this and you pulled those two out, it's like that's perfect. I love the story. As you roll this up, and I know we don't have screenshots for this stuff, but how are you rolling this stuff out? You're connecting this with the downstream BI tool, and then you're also sharing some of these kinds of screens with management as you go through reviews and that kind of stuff as well? 

 

Kyle Friedrichs 0:21:39.2: 

Yes, the data coming out of here basically goes to two places. One is NetSuite, where we're basically sending all of our orders saying, go place the order, and from NetSuite it goes out to a few other systems, out to the vendors directly, and then to a couple of other sources, finance teams. We store that data. The other place we send it is a Power BI. So some of the reporting functionalities we still do in there, and we also take some information from here, mix it with information from NetSuite and a couple of other systems to make more intricate reporting. So that data comes from here into Power BI. Some pages update every day, some update once a month, some update once a week. So a variety of pages depending upon what we want. 

 

EJ Tavella 0:22:14.9: 

Yes, I love it. That's pretty common. It's a pretty common use case. Well, maybe we can talk a little bit about some of the current status, some of the current results, and then talk about some of the stuff that you're tracking also. 

 

Kyle Friedrichs 0:22:28.0: 

Sure, in the top line, it's running, it's working. So we don't have the old system. So we don't have a choice but to make sure that this was running. About 50 POs a week are sent into the system to go [?by it 0:22:37.1]. So about 80 to 90 per cent of our total PO portfolio, which is about what we expected. We're also still making improvements. Again, there are certain things that we knew when we went live that we wouldn't have time to do right away because of the compressed timeframe, and we're still building those out. There's a nice, also, long list of things we want as future improvements, and we worked about 60 different items on this list of future improvements between all the different systems that are there. It's basically going to be rolled out over time as we prioritise that and see what makes sense, what works and difficulty of each thing. 

 

EJ Tavella 0:23:08.0: 

Yes. Any, other key metrics that you're tracking? You mentioned a few earlier, but key metrics that you track actively in the application, just to constantly monitor your performance against? Again, for the exam next year when we come back and have it, to be able to tell you what the results were. 

 

Kyle Friedrichs 0:23:23.4: 

I think what we track is pretty standard. We're tracking a forecast activity from the demand side. We're tracking our service rate. We're tracking our total inventory levels and our ENO. Nothing too crazy at this point. As we get more sophisticated, we might add more, but right now it's the basics. Get those under control. Get those to improve, and then fine-tune it.  

 

EJ Tavella 0:23:40.7: 

Yes, those are tight. I think these are the core metrics that we see all the time. Again, I think building them into your process, you actually can see them as you go through it, is really a great way to do it. That way the business understands, hey, we see this trend, it's improving, or we don't, what do we have to do about it? What's going to change? How do we shift it around, all that kind of stuff? So I think we'll maybe talk about conclusion, a little bit of a summary here. We talked a lot about times to value. So applications driving that change. I think in your case it's interesting, because you did do a quick win. You set MVP for demand planning very quickly - love it - and then evolved that over time, and then went to applications and got a, I would say, maybe a bigger, more robust solution, but really in still a pretty tight amount of time as part of that process. 

 

Kyle Friedrichs 0:24:26.7: 

Yes, I think that's a nice advantage for demand planning. What we had been doing originally was all Excel-based. So being able to just get something in a system, something tracked where we can understand what changed was helpful. So we rebuilt a relatively simple demand tool very quickly, just to be able to help, and we actually saw a very quick improvement of forecast accuracy. There's a nice little chart. We have this colour-coded forecast accuracy. Once we went live, we gained about eight to ten points in forecast accuracy pretty quickly, right when we went live. That was a big improvement and since we're getting better, but it's always just slower as [over speaking 0:24:56.8]. 

 

EJ Tavella 0:24:57.1: 

Yes, it's like take the cream off the top first, right? 

 

Kyle Friedrichs 0:24:59.5: 

Yes. It was fixing the easy stuff first, and the biggest issue items. Then the supply planning, supply planning is more complicated than demand planning, a lot more ins and outs. So basically that we had to spend a bit more time on, which was still pretty quick. We did spend more time with that design, getting the app so that we don't have to rebuild everything by scratch. When we first went live with demand, the apps weren't quite out yet, or we hadn't known about them. So yes, we just went with what we could go from that point. 

 

EJ Tavella 0:25:25.9: 

Yes, it's pretty common. We just launched a case study with another customer, Custom Coffee, that the same thing, demand planning themselves, then did supply planning and now they're actually going back and doing demand planning with applications. It's like a second phase to accelerate it all. So it's a pretty common story. I think supply planning is a more complex problem statement, and the out-of-the-box functionality for again, safety of stock, PO purchasing, ABC classifications, that kind of stuff has been a huge advantage. Any keys to success you want to highlight? 

 

Kyle Friedrichs 0:25:54.3: 

People who are doing this from scratch, again, I'd say focus more time early on in the whole data structure, what you're going to get, how it's going to look and really be able to plan that out. Just because I think that that was part of the - probably our biggest pain point. Whereas we're building one system, we see the data is a little different than we expect, we have to go back and make fixes. So it's iterative changes, and we're doing this between a ERP and MRP, and then the data in the middle. It's just not an ideal situation. So I'd probably want to spend more time planning out all that information earlier. 

 

EJ Tavella 0:26:24.4: 

Yes. The business process change was helpful? I mean designing the future state process, you feel like that was helpful, go through that cycle and really not just implement a new tool for your old process, but really get to a future state process that was going to scale as part of that overall cycle, it sounded like. 

 

Kyle Friedrichs 0:26:40.6: 

You have to change the process whenever - if you just change a tool, and then you're going to get the same exact results you did in the past.  

 

EJ Tavella 0:26:47.0: 

I agree. 

 

Kyle Friedrichs: 0:26:47.3: 

Most of the work is changing the process. The tool helps to enable the process, but if you try to - the tool driving a process usually backfires. 

 

EJ Tavella 0:26:54.0: 

Yes. I had a customer back in there, you say if you take your old process and put it in a new tool, all you're going to do is get the same wrong results faster. It isn't going to solve the problem. Next steps, anything that you want to share as far as the journey where you're seeing yourself going, or at least thinking about going in the future? 

 

Kyle Friedrichs 0:27:13.9: 

I think that's why we're still looking at potentially other future models or apps and also making improvements on the ones we have. The reality is, we went live with these systems. We went live very quick. There's some things we knew we would have to add. There's also certain things as you start going through it, you realise where an ideal and you should go back and fix. The nice thing here is you made a reference to another system, which is actually one I had used in the past, once that's there, you can't change it. Here, we are able to make changes on pages, and even if it's something that's as simple as we want to change the order of columns, it becomes a very easy change for people. 

 

EJ Tavella 0:27:44.0: 

We go back to, just briefly to adoption, right. I think that that's a great example of a simple change in Anaplan, not a simple change in other tools, but that little ability to tweak things like that really does help adoption. Frankly, maybe it's not actually changing, but it gives the confidence to the users that, hey, we can have an input in this, it can have my fingerprint, we can really tune the process to fit our needs, and that helps build confidence versus sorry, you've got what you got. Live with it. 

 

Kyle Friedrichs 0:28:15.0: 

Yes, so just a [unclear words] that people feel like they can make a change, even if it's just something just flipping these columns, you want to read in a different order, they know that what they said has an impact.  

 

EJ Tavella 0:28:22.8: 

Yes, absolutely. Great. 

 

Audience 0:28:25.4: 

[Applause]