JP
Good, guys, look, we'll get started. The way I thought we'd take this is really just kind of start getting into the challenges that you're currently facing around visibility, and particularly with supply visibility and collaboration with LSPs in terms of getting a better handle on that before we then kind of look into some of the potential ideas and ways that we might be able to tackle that. 

JP
D, for no other reason that you are first on my list on my screen, may I start with you and invite you just to tell us more about the visibility challenges and what's causing them from XXX’s perspective? 

D
Sure, yeah. We have quite a lot of purchased components that are included in that bit of materials and we have factory constraints and we can see those ourselves. We understand our own factory constraints, but when it comes to the delivery of components then that can obviously have an impact on your ability to make complex systems and things. We're trying to introduce a vendor portal that would allow us to get information from vendors to say when they are going to deliver components. When you've got hundreds of vendors and some of them are quite small, getting those people to adopt using a portal and constantly updating delivery dates is quite hard. What you're tending to rely on is just the information that's in SAP to say when a component is going to get delivered. 

You're relying on your own internal information. I think what we've found over the last few years is that lead times have become much more variable than they were previously. It was okay to rely on your fixed lead times in SAP, but now they're much more variable. It's much more of a challenge and we seem to be struggling more with external vendors than our internal constraints compared to previous years. You've got the external material visibility, you've also got the internal. We ship products between locations, which is obviously dependent on freight. Again, freight used to be relatively predictable, but now again we're seeing things where we have an expected lead time between two locations. If you look at the history, it's quite variable that lead time. Obviously there are lots of portals and things that you can use to bring information in. There's quite a lot of integration work involved in that and the business case to create all of that infrastructure is not that solid. 

When it gives you a bit more information, it doesn't change what's going to happen, it just gives you a bit more visibility on the arrival dates of things.

JP
Thanks D. What's the scale of the issue for you? I mean is it just an inconvenience, is it causing serious headaches? What are the implications? 

D
Certainly over the last year or so it created some major implications. I mean one of the things was we were getting very long lead times from suppliers, which meant you then were ordering materials based on those long lead times and that meant that potentially demand didn't come in at the levels you expected. You then ended up with lots of excess inventory. That has been quite a major problem to us in the tens of, if not hundreds of millions of dollars of inventory that is now excess and slow moving. 

JP
Thank you, D. B, if I could come to you next, I saw you nodding quite a bit of what D was sharing there. Perhaps you can reciprocate, just illustrate your situation for us. 

B
I was agreeing pretty much with everything that D said. That's why I was nodding away actively. Certainly yes, the uncertainty of the delivery dates for inbound materials is a fairly major factor. Also the variability in transit times between our different operations. Particularly in and out of China at the moment, where it can be a week, it can be five weeks and that can be a real pain. Even if we've got a finished goods and we're trying to get to a customer, moving it around within our network can be very problematic. The big impact for us and the difficulty of building a business case to do anything about it, as D pointed out, it's far more about communication with customers. That's the real hole that we're getting ourselves into is we're telling customers, yeah, you should have the product on such and such a date and it is just so unreliable. 

We're either being unduly pessimistic and then we lose the order because they go somewhere else and then it comes in three weeks ahead of what we expect and we think we could have caught that order or the opposite is true. We're continually going back to them saying it's going to be later. That really annoys the customers because we're feeding into their supply chains. We come from a culture where we used to supply everything out of stock or have very reliable lead times to make to order. Suddenly if we're not reliable, we charge a premium based on that service and we're not giving them that service anymore. Building a business case around customer service being better is a tough one because it is hard to establish that you are really going to get those extra orders or are you going to avoid losing those orders just because you make a step improvement, but not necessarily get it back to where it was? 

JP
B, I remember from previous conversations that you had been focusing quite a bit on pulling together data. I think you had a Microsoft Azure project going on to integrate that data. Was that intended to alleviate or address this problem in part or in whole, or is that a separate issue? 

B
No, I was far more focused on our master data. I think we're not really doing anything in terms of actively pulling in live data from our internal transfers or from supply from external parties. It's being done, but it's being done by people on a manual intervention, case by case basis, which when you've got 100,000 plus products, just doesn't work. It only touches the very top products, the very top customers. Something that could add the depth to that further down the product portfolio is something we just can't do with people. So how else do you do it? 

JP
Yeah. Thank you, B. M, if I could come to you next because in our last discussion, you, I think if I remember correctly, highlighted that it's really the customer collaboration or customer service element that's driving the initiatives that you're working on. Can you also just tell us a bit how the visibility is impacting on that aspect of customer service or any other aspect in terms of inventory optimization that D mentioned? 

M
What D said in terms of experiencing longer lead times over the last couple of months and our lead times going back to normal, we also had within our industry lead times up to six months. Customers and, I think, also the organization got nervous then about not being able to supply and with that, building stocks, and now those stocks are certainly hitting the roof. For a few months, there is an activity in place to regularly review and to make sure actions are in place to get this down to a standard level. Questioning what is the standard level nowadays? Because there are contractual obligations which we need to keep, but at least to get this under control in terms of visibility, I think our customers as such, are able to provide fairly good demand data in the horizon of three minimum four months. 

Even here there are a lot of changes as soon as a purchase order is placed from a transactional point of view. What we are trying to do is, together with the customer, as well as within our customer service and supply planning organization, to try to also get back to reasonable lead times, which means in combination with a deep dive into the demand data from the customers. Rather than ‘I need 100 million per month’ we need to understand, do you need those 100 million as 25 million in week one, or 30 million in week two, 15 million in week three, et cetera, to have those demand data then coming into our system, not as a purchase order or definitive order, rather than still a kind of forecast, but be able to plan around that? Which means we could manage together with the customer peaks and troughs more frequently and we have better visibility at least of those short term horizon, the current plus three. 

It comes all to process adherence and data accuracy because also here looking into the team's work, managing the raw material and also the supplier collaboration, they get an email with a confirmation, they type in data into our system. If that's not being maintained regularly, daily, based on the updates we get from the suppliers, then the system calculates as it stands in our system because that's how an MRP works, that's how SAP works. If you want to reschedule, it's dependent on such data coming from the teams. We have not integrated suppliers yet with EDI but that's in the pipeline, to my knowledge. Even though there are supplier portals available, again, it's about connecting to the portal, checking the detail, how often do you want to check the detail, et cetera. 

There's still a lot to do on that end. If I look into customer collaboration, we are well advancing for one of our biggest customers for an integrated and online capacity versus demand view, where we then use the customers data, discussing regularly and also finding actions, mitigating risk, et cetera. 

JP
Thank you very much, M, S, I could bring you in at this point. Hopefully there's a few points there that resonate with you. Perhaps you could just tell us a bit more from XXX’s perspective the challenges or issues on how you're approaching the supply visibility piece. 

S
Yeah, so those of you don't know, XXX specialize in distribution of consumables. In particular in my division, we're supplying into the retail sector. Our main customers are the likes of Morrisons, Tesco, Asda and such. We deal with 16,000 plus products with over 600 suppliers and similar to what some of the other points that the guys have made is we are seeing the supply chain calm down. Lead times are improving, but we're still spending an inordinate amount of time chasing down suppliers for updates rather than doing the kind of value add activity that includes excess reduction supply performance management, inventory optimization, catalog management, forecasting and sales analysis. The one question we're always trying to answer for the team and our customers is around when is stock turning up, how accurate is it? I think D touched on the vendor portal piece and trying to go down that route. 

That is very much where we're going. We always talked about trying to develop something in-house but we were approached by a company called XXX at the start of last year who specialize in this kind of supplier portal. We're currently just in the throes of test scripts and UAT and about to go live with it. The way it all links, it links into the MRP, the ERP it recognizes where we raise purchase orders, it sends out an email to the supplier and they can literally get there's a button that they acknowledge it and they can feed back any detail into us around when it's going to come in. What if there's any change to price or if there's any change to the kind of order, quantity, MOQ or anything else that we need to know. All that information then gets filtered back into kind of a single dashboard that anyone in my planning team can access. 

Anything that doesn't match the order we've raised gets highlighted as an exception. Depending on what that exception is, we can automatically accept that, in which case it'll feed back into the MRP and update it all. So it's all present and correct. If there's an issue with, let's say, the price, we can then work internally to resolve that. It has regular things within it that set out cadences to request updates from the supplier. Three weeks out, can we expect a delivery date? It'll send us an email out to the supplier to say, is everything still on track with this order? With one click of the button, the supply can say yes or not, or if it's not, they can log in again and provide some further feedback on what's happening with it. We've also got it linked into our kind of doc scheduler, so if a delivery is booked in, it will then update the MRP with the date that it's booked in. 

We're presenting our order books and estimated dates back to our customers, it should provide a fully up to date and accurate order book. Like I said, we're in the midst of testing prior to potentially going live next week, so I can't provide too much feedback on it. From what I've seen so far, it's really intuitive, really impressive. It's doing exactly what it says on the tin. 

JP
That sounds good. It's essentially automating a lot of the manual processes that you would have been doing, kind of checking up on what's going on with orders. Often a weakness in those kinds of things has been just the supplier’s bandwidth or willingness to be able to work within those kinds of systems because obviously they're probably facing requests from multiple customers using different types of portals and different kinds of systems and it can be quite overhead for them. Even though it's still early stages, do you have any sense in terms of the kind of supplier adherence or compliance to using the system? 

S
The main question we've had back is what cost is it going to be to me, to which there isn't. We pay a license fee. We could have as many users as we want here at XXX and we could onboard another 600 suppliers and there's no additional cost. Actually they're already receiving purchase orders via email now they just get kind of an email with a PDF attachment. This is just a button that they can go through and acknowledge it. It actually makes their life easier, I would argue. 

JP
Yeah, okay, thanks for that. Fraser, I invite you to just briefly introduce yourself and reflect on what you've heard so far and the extent to which that's common in terms of the people that you work with.

Fraser
Yeah, it's super helpful. Thank you. And thank you for having me today. My name is Fraser, I'm the founder of Beacon, which is a supply chain data and visibility platform. What I find so interesting listening to all the commentary is this probably comes as no surprise to anyone on this call, it's very consistent and I hear this feedback repeatedly. What's interesting is that what I hear when I try and distill down many of the points that I'm hearing, these are things that we already know, is that lead times are so core to this and it's really broken 

down into two pieces, isn't it? It's sort of that ordering lead time:’how long does it take for my
manufacturers to make stuff?’ and then there's the lead time in the transportation bit, which is ‘how long does it take for my stuff once it's ready to get to me?’ 

There’s that lack of reliability that's causing peaks and troughs in my warehousing and my inventory. I think that what I always come back to is there are two such interesting and distinct use cases of both of quite different value when it comes to lead time. One is that real time use case, which is ‘where's my stuff now and when's it arriving in my warehouse which is full or isn't full. It's a very real time use case. There's that planning use case, which I think is the more interesting one, where I want to get into the data conversation.

I'm curious about people's views on data. I almost feel like it's about having enough data that's accurate and mapped correctly, that then gives you the information you need to solve challenges. I think what I'm hearing, which is the more valuable problem, which is ‘help me to decide when I should order more stuff based on when I need that stuff to be available and in the following quantities’. That's really a planning exercise, isn't it?

That's not what's happening now. I think that goes back to M's point about you've got pretty good demand forecasting, you've got people who are saying this is what we need. I think the harder question is where do those things need to be and in what quantities, and when should we order them and ship them in order to land everything in the perfect place at the perfect time. That's basically impossible to do if you don't have all this quite structured, neat and tidy data in order to make that decision. I don't know if this is a good thing or a bad thing, but these are very consistent problems.

It’s interesting to hear how lead time, I think ultimately coming down to that lack of reliability, which can let down customers or let down your CFO because you’ve got too much inventory. Not to take this down too technical a route, but I think everyone understands that the root of all the problems being described is really having good data and where are you getting it from and are you able to access it? And I think that's a challenge that so many businesses have. 

When people ask me, ‘how do you solve that? We've got data everywhere but how do I get it? It all looks different: Maersk has got some, suppliers have got some, K+N have got some…what do I do?’

It is a huge problem and I think that's where this live tracking data is so key. It’s important for me to understand how people in the room value what we call live tracking, which is this use case about when's it arriving: is it next week or the week after? Because I often hear, yeah, that's kind of a problem. It's useful to know and it's exception management. But I think the hidden benefit of it is that by tracking goods in a very central way and managing that data in a live fashion, I always remind people that the minute goods have arrived, you're no longer tracking them.

But if you've been storing every milestone along the shipment or the movement of those goods, then suddenly you are starting to build your own mineable database of information on which you can then use to build your predictive analytics and your tools and so on. I think you can take the approach of ‘do we try and take everything we've got so far and tidy it up and somehow map it?’ which is very hard, or do you start tracking and actually building that highly structured data now on which you can then build more predictive analytics? I'm just curious to hear from the group how everyone feels about the quality of their historical data and how confident people are that it actually is usable in the way that you really want it to?

D
Can I just chip in there? I think one of the challenges that I see is that, it's fairly predictable that if you raise a purchase order that the supplier will deliver it, and if you make a shipment, 99.99% of the time it will arrive, so you will get the revenue from that business. How does tracking actually generate either a reduction in inventory or higher revenues? Because when you're trying to put a business case together, it's really hard when you say, oh well, customers will be more satisfied because things arrived when we said they were going to arrive. It doesn't fly very… it's very hard to get that alone as a business case unless you can somehow demonstrate lost sales as a result of the delay and well, does a one day delay or one day disappointment cause a lost sale? It's a really hard, as I say, a really hard business case to put together. 

All of these things require integration of your SAP systems or whatever into external systems and that thing, which will cost money and it's just another system, but it's not a transactional system. It's like you say, it's a thing that helps with the data inside your transactional system. How do you solve that?

Fraser
Yeah, I think within visibility there are a few vectors that you can unpack. I mean there are some much more
basic vectors of value which are easier to describe, which some businesses are good at and some aren't.

I mean visibility certainly in the transportation bit where there's a ton of waste and cost. A lot of businesses we talk to have absolutely no idea how or why their D&D costs are what they are. They have zero way to challenge what the forwarder or the carrier is saying. From a visibility perspective, you can be very granular and actually
on a per container basis, see precisely how many days every single container you have has spent where. Okay, so it's quite an isolated use case, but for many businesses, D and D runs into the hundreds of thousands, if not millions of pounds per year. So it's quite a narrow example but it’s a very tangible, hard cost, I think that's associated with not understanding the duration of your containers resting in various places.

We had a customer the other day who said ‘well, hang on a minute, I don't have a D&D problem, so I don't have that cost. And of course, as it turns out they were paying for too many free days in their contracts. Actually by knowing how many days they actually need, they can then negotiate a better contract with their carrier.

The harder point, to your point D, is how do you make a business case around more intangible things like making sure your inventory levels are what they need to be and that you aren't overstocked. And that's a tougher thing. Is that actually hard dollars? Hard to say. Is it happiness? Can you measure that?

I think when it comes to the bigger picture, I think that businesses do at some point need to make a fundamental decision that you either have to believe that automation technology ultimately reduces costs or you don't. Because a lot of the things that automation does is a harder business case to make. It just is. If I could use the example of having your data and starting to build that data in a cheap and structured way is a pretty meaningful investment in your business. I don't think that a business can aspire to automation of their supply chain without having their data stored and mapped in a very structured way.

First of all, a business has to make the decision that they believe that there is inefficiency in their supply chain and that automation can reduce cost? If the answer to that is yes, then you must start storing your data. You should view tracking as giving you low cost, short term visibility. What you're really investing in is building your database of centralized, mapped, structured supply chain data. That is just an investment you need to make in exactly the same way that people that businesses that use Salesforce are investing in understanding their customer. 

With a CRM, the entire system is designed around the customer and optimizing for that. When we’re talking about centralizing all this supply chain data, what we're actually doing is building what we call a SKU RM, where the SKU is the central component of data as opposed to the customer. You build an entire database around every SKU in your business. How many have you ordered? When are they ordered, how long do they take to be made? How are they transported? Who's buying them, how much should they cost and how much revenue you're making from each individual SKU?

All of that universe cannot happen if you don't start ingesting and storing that data about those SKUs, which is what tracking gives you, because an ERP will give you a momentary snapshot in time of your inventory and so on. What it doesn't give you, what it doesn't tell you is the journey that each of those SKUs went on. When was each SKU raised? How many times did that order change volume? How long did it take to make that SKU? When was that SKU collected? How long did it sit on port? How many times did the ETA change and by how much? It's those milestones and that very three dimensional view of each SKU. You must have that. Only with that can you then start to build on top of it and actually optimize and design and build a supply chain that is much more resilient and agile and ultimately automated.

An ERP won't give you that. It doesn't give you that dimension of change over time and duration and why things happened the way they did. It's either from a business perspective and a business case building perspective internally, I think it really depends on which business case you are trying to attack. If it is a business case built around knowing when things are going to arrive in the moment, that is a valuable, but much less valuable proposition. That product is also much cheaper to buy. If the problem you're trying to attack actually is better planning, better visibility, in terms of building a more efficient and cheaper business supply chain, you’ve got to have the data to do that otherwise you remain in the world of hiring supply chain consultants to come in and try and sift through data in various places. Those tend to be static reports that say, here are things I recommend you do in order to improve, but they aren't moving and they aren't fluid.

If it's a much bigger investment in automation, longer term, then I think that's about creating and mining the data that lives there. Tracking is the engine of creating that data because it actually doesn't exist. Maersk doesn't have it, K+N doesn't have it. Nobody in the world has the data that tracks the movement milestone based on every single SKU in your business. It's actually a brand new data set that needs to exist to power automation. So, in a strategic perspective, you should actually think of tracking as also being the thing that creates the database that you need to then build automation. 

By starting to do live tracking, you are then investing in building that database of things. How they move, when they are ordered, how long do things sit there, how many times did that ETA change and by how much and why? Those are the measures of reliability. If an ETA changes five times and each time it changes by a day, it's not a big deal. If an ETA changes three times but each time each change was five days, that's a big deal. 

Measuring and capturing that information is literally, I believe, the gold that lives in everyone's supply chains. 

JP
That was in response to the business case point that you made, D, so did that help your thinking? 

D
I still see a challenge, but it's something to think about building up that database. And actually you made a really important point about tech fear, tech stack terror: it’s like an integration nightmare. This is going to break my It team and it's so painful. 

Fraser

The reality is we've got customers who've come to us and say, oh, we want an API, we've got an IT team and we've got to integrate with the ERP and so on. The funny thing is, our reply to them every time is, okay, here's how this can work. You just upload into the system. Forget an integration…just upload all your container numbers into the system once a week. Just make it five minutes of someone's week. That's literally all you need to do to start building that database. 

We then go away and pull all the data and start doing all the tracking. That's all you need to do. There is no integration. Now if you want to connect to an ERP so that container numbers are automatically going into our system, sure, do that, but a human being can copy and paste 1000 container numbers if you want, once a week and you will be building that database.

D
Without getting too technical, I think our thoughts on that from an integration perspective, we want to know when our stock transport order is going to arrive. It's got data on it that SAP created, but now we want to get the tracking information back and update SAP. There must be some integration to do that?

Fraser
To do that in an automated way in ERP, you do need to pull our API and populate the necessary fields, for sure…there's no escaping that if you want the loop to be dynamic.

But I would say that the sorts of integrations that we've seen done are, in the world of integrations, they're among the most light touch that I've seen. They are very lightweight integrations, but it does remove the need for a human to be involved. In terms of making that investment as a business in building your supply chain data store of value, you don't need the ERP integration to do that, to start making that investment.

Start making it, which gives you optionality to then come back and build on it later. You don't even have to do anything with it right now, but you have to start building because every day that data is not being created is wasted. Data is the oil on which you build your business and I'm amazed at how most businesses I encounter are not prioritizing building a data store of supply chain data in this way. I think they think that it's a lot harder than it is, but it's one of the most strategic decisions I think any business can make.

JP
Thanks for that, D and Fraser. Please raise your hands or just jump in if you have anything that you want to comment on or ask about on that. B, if I could actually ask you to come back in because you raised a similar point to D at the beginning in terms of how do you quantify the value of being able to improve customer service and be more reliable? Do you see that becoming something that you could quantify in terms of making that a basis of competition for your customers? 

B
Can I quantify? Probably the answer is no. 

I think that's where you really need to talk to your commercial team because they either put a premium on that information being available to their key customers or they don't. If they do, they should be able to put some dollar signs against it. If you could give a 99% delivery on promise, for example, versus a 95% delivery on promise, they ought to be able to put some estimate of cost against that. Also if the lead time improved, they'll be able to put a cost or a value against that. Now, tracking won't improve your lead times, but it will tell you where the stuff is and therefore where you can work, what you need to do, or where there are opportunities for you to attack to go and get it. I think the delivery on promise side is definitely, in our business in particular, where customer service is so important, particularly to the key accounts, there's a cash value attached to that. 

JP
Thanks B. Any other reflections on what we've just been covering? 

B
I'd love to hear some case studies because who is using this and how is it working for them? Because this is very new to all of us. We're all thinking, yeah, we're interested, that's why we're here. We're not quite sure if we can justify it. We're not quite sure if it's going to work for us. It's always great to hear someone and the closer it is to our world and the more likely you are to give it a punt and have a go. 

Fraser

Definitely. I guess I can name customers. I can certainly talk about what they do. Also the other thing I would like to talk about is that I think it might be much less expensive than people realize to start to experiment with this stuff. I know from earlier in my career, when you start talking about ERPs and complex systems etc., you're looking at costs that run into the millions. I think you would all be surprised to hear that for businesses even doing thousands of containers per year, we're talking for tracking, we're talking in the hundreds of pounds per month type costs. So we're in a very different sphere I think. 

The businesses we work with are in food and beverage, we work with XXX as a pretty well known brand. I don't want to name too many but we have businesses in engineering, we have distribution businesses, we have XXX. These are businesses that vary from a couple of hundred containers per year to many thousands of containers per year. The problems that they're trying to solve vary and most of the time it revolves around ‘we don't know what's going on in our supply chain’. We haven't really talked about collaboration much here, but I think that there's having the data point and there's also how you disseminate the information so that everyone who needs to have it has it and can kind of take care of themselves. 

A lot of what these businesses are looking for is not just where things are and when is it arriving but what they're really looking for as well is an easier way to disseminate that information. With XXX, one of
The biggest challenges they have is that upset customers being let down and not knowing what's going on.

I think it was D maybe that made the point about it's hard to make the use case in those sorts of things. I think it's a bit like insurance: businesses that suffered that pain tend to know the value of it, whereas a business that hasn't suffered it is not sure if they need the insurance because it's not a problem. You either buy insurance or you don't.

I think for XXX in particular, which has onward distribution partners in the US and in Canada who were being let down led to losing orders and so on and so forth. And I think that for them, visibility is not just visibility for themselves, but actually empowering their customer and quite frankly, their warehouse manager and their logistics partner to have visibility as well. It has that effect of calming everyone down, reducing churn, reducing email inbox churn. If everyone can see the same thing at the same time, then everyone is informed, everyone is up to date and is collaborating and can ask questions through a platform rather than being by being confused 

Being able to actually track things by PO, by SKU, how many of these particular SKUs do I have arriving in the next eight weeks and where? Being able to view the inbound motion of your goods beyond just a container, but actually how you want to see it.

JP
Fraser, thanks for that. We're pretty much out of time but I will just quickly mention that we are going to repeat this session in about a month's time mostly because I bungled the timing of this. A lot of people that wanted to join weren't able to. I suspect this has probably given a lot of food for thought for people on the call today so that might be an opportunity to post some more questions in the next edition. We are definitely out of time now. Let me just say thank you particularly to Fraser for being our subject matter expert today but also to everybody for joining for the last hour.