Bidvest Waltons: 166% more picks an hour on Manhattan SCALE

Goeiemorgen iedereen. Excuse the notes, I was a last minute sub into this presentation, so bear with me. As the slide suggests, I head up technology for Bidvest Waltons, but in the context of this presentation, I was an accidental project manager a few years ago, which we'll get into. Just for those unfamiliar with our business, I'm sure some of you have. the way our CEO likes to tell it is, if you can imagine a typical office building, and you could pick it up, cut off the roof, and turn it upside down, you'll struggle to find something that we don't supply. Besides for the obvious, such as paper and stationery, you might be surprised to learn that bottled water, milk, and toilet paper are some of our fastest moving items.

Occasionally our sales team gets their way and will even ship you a double door fridge to keep that milk in, or some gardening utensils for your facilities team. Creates some interesting challenges from a warehousing point of view. Anyway, in terms of our footprint, we are 30% retail, 70% commercial. so we have 57 retail stores throughout South Africa, which most of you know, thanks to our strong back to school campaign. but the bulk of our business is commercial sales. So that 70% of our revenue we perform primarily out of three warehouses, Joburg, Durban, and Cape Town. We have three separate furniture warehouses who deal with the bulkier items, desks, chairs, large orders, and orchestrating installations, and everything associated with that. And then lastly, we have four cross stocks, which I will talk to in a bit.

In terms of our WMS journey, we started around 2018 in terms of system procurement and all of that. Back then we used printed picking slips to pick orders. It's effectively a printout of an order, though our ERP did allocate stock from bins. Our pickers really honoured our location, as they knew where to find stock better, and you'd often find the end of hour locations used up for KVIs. Our reach trucks were poorly utilised. The bulk of their time was spent bringing down pallets only for a handful of items to be picked, only to put the pallet back up. So broken pallets galore. Overtime was a weekly occurrence, even in the slower months of the year, and we had little to no insight as to why that was happening. We could tell how many orders went into the system when the orders were invoiced, but we were oblivious to the individual picking performances,.

Replenishment performances, and all of the key metrics that you're all familiar with. We realised at that point that this was not sustainable. Our warehouse operations had become the biggest constraint in our business, limiting our growth. After evaluating several WMS systems, Manhattan SCALE came out on top, for obvious reasons. While I'm mostly going to be focusing on the Joburg implementation from 2020, I thought it' would be worthwhile mentioning that we have subsequently implemented SCALE two more times in Durban and Cape Town, very successfully. This first go live was supposed to happen towards the end of 2019. During slotting, we realised that something had gone severely wrong with our master data. Items that we were expecting to be slow movers ended up in prime pick locations,.

And items that we were expecting MHE to pick ended up in fine pick as an example. It turned out that our poor inventory accuracy and our outsourced approach to capturing master data had resulted in many of our dimensions being captured against the wrong skews We'd also neglected to capture any of the larger units of measure for many of our KVIs which would be picked in cases ideally As a result we' ended up delaying our go live until early 2020 to allow our teams enough time to effectively recapture all of our master data I think at that point it was our third attempt at capturing master data We employed our own team and saw far better success As you can probably tell by the date COVID happened Two weeks before the big day South Africa went into a hard lockdown and everyone was working from home all of a sudden Waltons was fortunate when restrictions started to ease in that many of our customers redeemed essential services the likes of hospitals banks and so on and so forth So we were given an opportunity to reopen We decided to make the best of the situation at that point and scheduled the go live for June 2020 As you can imagine it didn't take very long for the first round of positive tests to bring everything to a halt We'd managed to get a week into the program So out of nowhere with a positive test in hand the IT guy became the most senior person on the project and in the warehouse Needless to say the week that followed was tough We brought in resources from our other regions to stand in for their colleagues in quarantine while I worked Oh sorry what I should have mentioned while everyone was in quarantine one of the key resources was our warehouse manager for the Joburg facility and our project manager She decided to resign at that point So that's how out of nowhere the IT guy became the most senior person on the project and in the warehouse We brought in our resources from other regions to stand in for their fallen colleagues and my objective was to assemble a new project team Our sole focus at that point was to avoid rollback Even though order volumes were down as a result, of COVID the shutdown for sake of getting everyone tested had created a backlog that was seemingly impossible to clear Joys of reporting An area that we neglected to focus on during our implementation phase was reporting specifically around exception management That oversight immediately became evident during those first few days as orders inevitably got stuck in the system excuse the technical term While it was easy for us while it was obvious as to why more than 80 of our orders would get stuck in the pool with allocation failures the best course of action was not clear Just for context around our allocation failures our warehouses are configured to allocate in full So if there's stock within the four walls we've made the commitment to the customer that it's available we need to ship the order So we have two zones fine pick and case pick Fine pick is where we pick loose items into shipping containers and case pick is where we'll pick larger units of measure for transfer orders going into our retail stores or larger customer orders We might have a product in case pick but it'll fail allocation as we don't want to break cases for obvious reasons.

Anyway back to our problem We were fortunate that the SCALE database is incredibly simple and we had the required skills within our team to query it ourselves What you guys see now is one of our main dashboards which ineffectively I think 1 200 allocation failures is not the kind of thing you want to see at the start of the day And at the end of the day seeing that number go up doesn't leave you with much hope either The very first report we built so sorry this is a tool called Grafana that we used throughout this journey just for sake of closing the feedback loop We couldn't wait for SSRS reports to be briefed and written by developers Using this tool we could surface this data. very quickly The very first report that has a very excuse the small screenshot answered a very simple question Of these allocation failures I have which products do we need to make available and which quantity for sake of releasing the most orders We handed this dashboard to a small slotting team who gradually chipped away at our allocation failures over the coming weeks We went on to use this tool for several other exception dashboards to deal with things like bad item master data. misconfigured pick faces as well as providing the project team with a much needed overview into our operations The beauty of Grafana is you can put it up on a TV Whatever it's querying it will refresh in whatever increment you tell it So it can refresh every five minutes or 30 seconds if you so choose.

One of the examples of something we built one of the simpler ones is a dashboard that simply shows us when last our resources in a given facility were last active in the WMS In those early days something like this was handy because it allowed us to identify people who might have gotten stuck They'd stopped somewhere in an aisle they didn't know what to do And in later days this helps us find people taking a nap Oh sorry Let me jump ahead So while this is a tool that worked for us the harsh reality is we should have never been in this situation We should have spent the time ahead of go live to define what our desired state is from a master data slotting picking All of those functions should have been defined ahead of go live And we should have measured against that in our decision to go live We at that point didn't know I mean that's the joys of these things We were optimistic that our slotting would work out And yeah what ensued were fun days As our location failures reduced and volumes gradually increased we ran into the next constraint within our facility Our trolley pickers the guys who work in fine pick were nowhere near the bin hits per hour that our design demanded.

Just for context on how fine pick works it's the zone I highlighted earlier We generally an average order for us is 4 7 lines It's very rare for us to pick a single unit We'll often see well four SKUs going into a stock five box or courier bag or whatever So how we handle it from a system point of view is we'll wave, SCALE will run allocation based off of the zone in which it allocates it'll do container creation and we then just print labels at an area in our facility called the box making station A picker will then come take several random boxes stick that onto their trolley scan scan scan and kick off what SCALE calls group picking The system at that point calculates the pick run and sends them on their merry way The first issue we found in the zone is that our pick path was double the distance it needed to be In the other zone we make use of ride on pallet trucks with long forks to pick larger cases and the likes.

Those machines aren't able to turn around within the aisles The pick path was set up according to that So what we ended up with is you'd go up the one side of an aisle and then back down the other Very very simple oversight which we fixed by doing that Just like that we'd halved the worst case pick path distance and our binnets at that point was sitting on around 30 A simple pick path change pushed that up into the high 50s The second and less obvious issue that we had in the zone just to show you what these trolleys look like was that we deployed too many resources which is a bit of a counterintuitive thought.

Our order volumes weren't where they needed to be but as a result of the backlogs and all of the trauma that we'd endured in the months prior we deployed our full resource model to work in the zone So what ended up happening was guys would build trolleys that are half full Now a half full trolley is for the most part going to cover the same distance in the zone as a full trolley but less containers less opportunity to pick and there goes your productivity So rather counterintuitively we ended up pulling people out of the zone and trusting in the process and the design that we would hit our daily targets That second change saw the binheads jump from the 50 I previously mentioned into the mid to high 70s where we finally reached our design targets at least for that zone.

Slotting A constant throughout the first few months of our go live was slotting As I've alluded to all our location failures were predominantly as a result of slotting so that was the theme for us We had teams working full time I think at one point we had probably six or seven people just moving stock from point A to point B to chug away at these allocation failures We initially had slotted according to a very early calculation in our design which was based off of flawed master data We then made the transition to slotting by exception What we would do with allocation failures now under control is we'd allow a SKU to fail allocation say five or six times Once it reached that threshold we would then assign a PICFACE to it We would then look at our replenishment data to see whether or not our PICFACE assignments were adequate.

In our lives we target weekly replenishments of our KVIs It's as simple as saying has this bin been replenished more than once in that week It's too small Has it been replenished less Maybe it's too big or we could get rid of it altogether.

Having worked closely with our slotting teams over these first few months I developed quite a decent understanding of how in the context of our configuration how the physical locations of stock influenced how SCALE's allocation works and the resulting efficiencies I think we're probably three months in at this point so desperate to get away from the day, to day of the luxurious life of warehouse operations I embarked on a side project to see whether we could introduce machine learning to solve our slotting problems What I was surprised to find was a very early prototype algorithm that we wrote solved many of our problems At its core all this algorithm did was identify products that are likely to be ordered together in quantities that we'd allocate from our find PIC.

Based off of that the algorithm would then attempt to slot them as closely together as possible because if they're on the same order in a quantity being allocated from find PIC they're likely going into the same container which helps us condense our PICing Once we started slotting according to this algorithm we saw this zone emerge in find PIC Sorry big slide again We saw this little zone emerge Just for interest's sake 7 000 locations about a 450 meter worst case PIC run if you move through this zone Once we introduced the algorithm we saw a lot of our PICing activity being condensed into what we dubbed the blue zone About half the distance and a little less than half of the locations We realized that this provided quite a big opportunity for us If we could ensure that a PICer loads their trolley with containers that were allocated from this zone we would again be able to halve the distance of our PIC path which provides a great opportunity for more efficiencies The problem is you can't rely on it happening by chance If you complete say 30 PICs in this little area and you walk all the way to the back to complete a single PIC all of those efficiencies are gone We needed to implement a system driven solution to ensure this outcome The obvious answer might be to say well just introduce a formal zone The problem with introducing a formal zone is that would split container creation between front and back What would have been one stock five box now potentially becomes two stock threes or two career bags You get the idea You'd end up shipping quite a bit of air Another option we explored was handles between these zones.

One team works in the front zone They then hand over to the back They complete the rest but then you've got the problem of how do you get those containers back at the end of it You need to consider automation and the likes something that we weren't nowhere near ready for at that point but something we are looking to in the future The solution turned out to be in collaboration with SCJ actually turned out to be surprisingly simple All we did was implement I think it's an exit point at the time just before labels print and if all of the stock being picked into that container was allocated from this virtual zone we print this little stripe on the side of the label When you're then building your trolleys as a trolley picker if you fill your trolley with those labels congratulations you've got the 240 meter run.

If we don't have enough available you simply take what's there leave these behind so we can ensure we build a full trolley and complete the longer standard run This was our final change into the zone and this was really where our big gains came from We went from averaging 70 bin hits per hour to close to 100 Today we frequently see individual pickers achieving in excess of 120 bin hits per hour in this zone which we think is very close to the upper limits of a resource operating an RF gun pushing a trolley and in all likelihood needing to count further than 10 while picking either pens or rulers or whatever The key takeaway here is not that you should build your own slotting algorithm I mean I'd actually strongly advise against it It's quite a bit of a pain to maintain but what I do recommend you do is ensure that you understand how your WMS allocates stock and ensure that your slotting approach talks to that Every meter that you can shave off of the average pick run is going to add up in the long haul We saw a big jump because we were able to get big gains really quickly.

Around where are we now Also around the three to four months mark after go live things were looking up for us Allocation failures were under control We at one point had a 24 hour shift which no longer existed and I think most importantly our project team was having dinner at home on time every night Fair to say things were going well People were planning to move back to their offices at that point It was exciting to not park at the warehouse anymore One morning I arrived at the warehouse to find that our yard was full of vehicles Upon entering into the warehouse and forgive me this is not our warehouse but those who were there will agree that this is a fair representation We found a dispatch floor that was filled to the brim with stock and our cages looked equally bad yet our drivers couldn't load any orders because seemingly every order had one missing parcel Just to talk to how you end up in a state like this and a bit more about our design We allocate from different zones within the warehouse that I alluded to earlier.

Someone might go pick a stock five box and fine pick and he'll drop it off at QC2 Someone else will pick something else drop it off at QC1 QC2 finishes ahead of QC1 they send it to the cage and so on and so forth We make no effort to consolidate orders in our flow We trust in our data we trust in our process that all of the containers will end up in the correct cage which is great in principle and then this happens So what ended up happening was actually quite simple It just took a few bad days of containers being staged into the wrong containers to land in a situation where the cage became so full that even though I knew that all five boxes were in the cage I couldn't find them all at once Over here you'd find three or four and one is missing Ten minutes later you find the other one and now you're missing another three Really simple thing but it brought our operation to its knees.

We hacked together a solution in an afternoon We call this the Dispatch Helper Effectively this little app runs on our dock workers RF guns excuse the great paint mockup and this allows them to scan any label on any container and very quickly get a bird's eye view of the shipment The numbers next to the things such as containers in picking that's how many containers are stuck in that stage You can then drill down and see what the status of an individual container is and if there's a lost known location such as these PA locations we'll show that to you and if not we'll approximate the location because it might have just been checked by someone.

Little tool helped us to ultimately or to quickly deal with this mess Well quickly is relative I think it took a week before we could see from one side of dispatch to the other side Again I think this is another good example of an area that we neglected Our focus was purely on outbound because that's well it was purely on getting containers through QC Once we get through QC an invoice is generated business is happy everyone thinks it's going great We didn't focus on our dispatch floor and from a system point of view I think what we got really wrong was we didn't clean the system every day Had we kept an eye on containers that weren't being staged or shipments that weren't being confirmed we would have seen this coming a mile away Yeah left it until number 99 so keep your system clean.

The last area I want to touch on is these cross docs I mentioned at the beginning This is now we're now quite far down in this journey probably six months in We were comfortably meeting our daily targets Cut off was being met with relative ease with excess capacity in hand so our project team started looking for ways that we could stress test the system The joys of continuous improvement is you do need a bit of volume to see whether these things are going to work as well as they are so we started looking elsewhere One of the opportunities we identified was our small regional warehouses so Waltons would previously service a customer out in Polokwane from a little warehouse in Polokwane We could easily take over those volumes at our Joburg facility but the cost of shipping something like paper is incredible it doesn't make sense It's just low margin heavy product it's the worst So what we ended up what we came up with was to replace these warehouses with small cross docs that would house a limited set of products Bulky things like bales of toilet paper paper obviously I think there's some box chairs that sort of thing in these cross docs From a system point of view the stock in these cross docs are seen as being in our main warehouse so what that allows us to do is we'll get SCALE to allocate the majority of the order the stationary the small stuff in Joburg and allocate the bulky items out of a bin over in Polokwane We would then take everything we picked in Joburg overnight truck to Polokwane marry it together the next morning and deliver it to the customer So a customer sitting out in I think we go as far as Toi Ando So someone sitting in Toi Ando can place an order at half past three it'll be picked in Joburg overnight truck to Polokwane last mile to Toi Ando the next morning But as you might have guessed it did require a bit of config to enable this behaviour because now you've got to receive and locate into those bins at the facility you've got to be able to count daily because you can't physically see the stocks and now we have this remote bin but it was well worth it It was a great initiative that we worked on with the team from SCJ and I think to date we're on four of these little warehouses that we've closed which just speaks to the efficiencies that something like SCALE can bring.

In terms of the outcomes we achieved in this initial implementation and I think the biggest one was the ROI the system components so licensing consulting all of that wonderful stuff achieved a six month ROI If we factor in the changes to our facilities by introducing new racking and all of the design work and everything else we did our true ROI was somewhere between 24 and 36 months The picking we've spoken about I think pre just to recap pre WMS we were probably hovering around 40 bin heads per hour on average we're now comfortably sitting at 100 and able to achieve 120 during peak with ease Yeah excess capacity it's never a great part of it but yeah excess capacity meant even with our additional cross stock volumes and everything else that had happened sales bounced back we've subsequently grown sales and we're getting away with less than 50 of the staff that we had back then Yeah and then cutoff I briefly mentioned our cutoff used to be 230 we've moved it to 330 for next day delivery and all three of these warehouses that we've brought on to scale have maintained this cutoff streak for multiple years which the teams are incredibly.

Proud of Questions Thank you it's really interesting to kind of hear your story and the issues you faced and I think over the last two days one thing which has come up quite a lot is the importance of master data If it's okay it's a two part question if you can go back and do it all again what would you do differently and what advice would you give to someone that's looking to in the next six months for us to have a successful implementation if I can ask I think on the topic of master data probably the biggest lesson that we learned the hard way and the expensive way is we thought we understood what master data meant but we didn't our idea was poor at that point we had a very limited understanding but what we had no understanding of is how the master data is incorporated into the config.

So something like treat as loose no and yes at the point that we were capturing the master data the criteria that we gave our teams was is it bigger than something and is it a brown box then we don't need to repackage it so that becomes treat as loose no everything else becomes treat as loose yes We later learned that there are certain products that are bigger and are in brown boxes but they're ordered in a quantity where we want them to be treat as loose no sorry treat as loose yes for sake of for sake of cubing them into a larger container such as a half pallet as an example Another area a common it didn't affect us fortunately we got to learn from Tarsus's.

Implementation with serial tracking but that's another area that a lot of people don't understand is switching on serial tracking has serious repercussions It's not just scan a serial when it comes in and that's it you're going to have to go count individual serial numbers while you're doing your stock take If an inventory transfer replenishment takes place you've got to deal with those individual serial numbers So it's really important to understand in the context of your config what dependencies there are in your master data and to test a subset of your data to see whether that stock actually flows When we did early unit testing it was all very high level We were testing the flows but no one actually looked at the product that was being shipped and whether that made sense So yeah that's the comments on master data is just understand what role it has to play in your system.

Cool Sorry is there another part I was just saying if you were to go back and do it again what would you do differently I think we should have owned master data as an organization We should have owned the process of collecting it We'd contracted a third party and sent them on their way They arrived at a bin looked at what the ERP thought was on hand and they captured the master data they captured against what was supposed to be in that bin The reality is it was completely different stock So if we'd owned that process from day one but this is all item master data right Another critical part of master data is your warehouse master data We had another simple thing that made a big difference for us is our location types were defined were accurate to the centimeter So we had 20 25 odd location types in the facility.

What the knock on effect of that is is you now need to define bin capacities per location type So 25 location types for every SKU you're capturing 25 capacities We ended up simplifying that by saying look if it's within a 15 15 percent range it's the same thing In all likelihood the capacity that we define will fit into the bin and that played a massive role in in our replenishment and our allocation failures because while SCALE does cube into bins if if there's no master data for to fall back on it will simply take the each and cube that in It's not going to fill a bin as accurately as a human can There's no substitute for a human who said well I could pack I could pack some like this and some like that and there's maybe one on the side and I fill that bin to the absolute maximum It's it might be a 10 or 15 percent increase in capacity but across 10 000 locations in those first few weeks that adds up that ends up choking your MHE you're not getting through your replenishment We we refer to it as the cycle of death If you stop replenishing you end up with allocation failures you then need to do inventory transfers to service immediate needs which means you're not replenishing and you fall into this trap where eventually you're no longer shipping any stock So yeah owning owning master data is the key for me What is the strategy behind this skew rationalization between the two locations Is it that I don't know fast moving items are maybe put in the fine pick section and then items that are often ordered in larger quantities in case people are not quite sure how that works Yeah so so effectively you're the fine pick zone you're picking you're using a trolley as your MHE to pick and you're picking loose products We condense based off of the algorithm we we tend to move stock closer to the front of the house just for those picking efficiencies Case pick serves two purposes One it replenishes into our fine pick zone so rather than needing to wait for an MHE to bring stock down we'll have certain items sitting in case pick purely because of replenishment and other items in case pick are items where customers order larger volumes So an example I mean something like a bale of toilet paper that would sit in case pick it's a large bulky item we pick it on it we pick it using a ride on pallet truck Cool well thanks everyone for your time on the screen are my details I think another part I just want to acknowledge in our journey is we've learned some of the people in this room like the guys from Tarsus I only met today but through Peter who had worked on their project we gained tremendous insights from their lessons Colock had us in their warehouse every other week to test our ideas and learn from there from what they've done So we're always keen to collaborate if anyone's ever in the area and wants to wants to see the exciting world of warehousing stationery you're welcome to pop into Pencil Park Thank you.