Archived How to fix my backroom location accuraccy???

Status
Not open for further replies.
Joined
Jan 17, 2015
Messages
1
Im a backroom team leader for a store and after 4th quarter our location accuracy is a mess, any ideas how to get that location accuracy back to green
 
Last edited by a moderator:
We try to be anonymous here. I suggest changing your username and refrain from using your store number in posts. Corporate stalks these forums.
 
Dude I know what store you are at with nothing more than a 2 second Bing search.

Accuracy starts with training and if your scores are a mess you might want to talk with the people who back stock to start..
 
I'd suggest a baseball bat, applied to kneecaps of known offenders. Or at least that's my dream with my one issue...

...otherwise start checking the last pull date/time and trouble shooting who might have touched it last. Have a meeting with anyone who touches the backroom and refresh them on best practice. Emphasize not burning items.
 
Pull up the location accuracy report, See who is making the most errors and why ( ie m delete usage, improper locu usage etc) Also, in the past ( when there was payroll ha ha ) we would locu and restore the top three worse departments in the backroom. Ie, if toys 1 was red...you locu and restore the aisle. However, these days there never seems to be the payroll to this . Another thing to check for is to make sure your item merge report is getting done. This can and will affect your backroom location accuracy.
 
Somewhat off topic, but the Item Merge is a complete waste.

The ability is there for item conversions. They are used frequently for most departments. All in all they are basically the same thing. A becomes B. Only for the Merge you have to LOCU to get the old UPC/DPCI off location and add the newly associated DPCI with the same UPC on location. Conversions do it automatically.
 
Somewhat off topic, but the Item Merge is a complete waste.

The ability is there for item conversions. They are used frequently for most departments. All in all they are basically the same thing. A becomes B. Only for the Merge you have to LOCU to get the old UPC/DPCI off location and add the newly associated DPCI with the same UPC on location. Conversions do it automatically.
Except for anything in the casepack locations, or any time the upc didn't update to the new dpcis.
 
Except for anything in the casepack locations, or any time the upc didn't update to the new dpcis.

And that people don't actually do the damn merge report and don't re-sto the product properly. I have found so much crap that should have been completed and the reports said they were worked. But nope they just re-sto'd it with the old DCPI. And no one pulled the old pick labels.
 
And that people don't actually do the damn merge report and don't re-sto the product properly. I have found so much crap that should have been completed and the reports said they were worked. But nope they just re-sto'd it with the old DCPI. And no one pulled the old pick labels.
Every bakery dept change I've had this issue. It's like we can't even pretend to care.
 
And that people don't actually do the damn merge report and don't re-sto the product properly. I have found so much crap that should have been completed and the reports said they were worked. But nope they just re-sto'd it with the old DCPI. And no one pulled the old pick labels.

Hence why there should just be a conversion. Both the DPCI and UPC are re-associated with the new DPCI.
 
I am not going to address how it should be done, but can the idiots doing the current process do it right? Don't lie and say you worked a report when its given time to ignore everything but what you are doing and yet you still screw it up.

Cause we do know who you are and you really don't want to have to explain to me how you screwed up an entire report. Cause you can't.
 
I am well aware of the process. I owned it back when it began. Back when it came to the store in a message board. No Excel spreadsheet to do most of the work for you.
 
Hence why there should just be a conversion. Both the DPCI and UPC are re-associated with the new DPCI.
Items are stored into the SLS via dpci, not UPC. The logic does not have the capability to delete and resto a given product when a dpci changes, hence the reason for the item merge. It would be costly to fix this.

As it is now, when you scan an item into location, it converts to dpci then stores the item info. If it worked the other way, storing the UPC, item merge would not be necessary.

Changing the logic would be costly, so the item merge report is a stopgap measure meant to bandaid a problem in the actual programming of the SLS.
 
How do the audits tie into BRLA? I had thought the audit fixes errors, but it looks like it fixes errors and then counts against your BRLA.
 
I'd look at BRLA TM and demote the high bafflers to flow until the truck is done, then have them come to the back. See if their location accuracy improves.

My STL's fix idea was to scan an item in STO after you pulled it anytime it asked you to pull less than the quantity in the location. This way you could backstock anything that was a baffle into the location. I actually do that before I pull it, then pull 1 more than it asks for if the quantity is lower than actual. This way it will ask me if I pulled all, I say no, then it will let me know if it wants more or not. This however will not fix accuracy, but idgaf. My job is to identify the morons.
 
I'd look at BRLA TM and demote the high bafflers to flow until the truck is done, then have them come to the back. See if their location accuracy improves.

My STL's fix idea was to scan an item in STO after you pulled it anytime it asked you to pull less than the quantity in the location. This way you could backstock anything that was a baffle into the location. I actually do that before I pull it, then pull 1 more than it asks for if the quantity is lower than actual. This way it will ask me if I pulled all, I say no, then it will let me know if it wants more or not. This however will not fix accuracy, but idgaf. My job is to identify the morons.

So with your method you're creating the baffle so you can track who did it? Plus that seems like a lot of time to go into sto for everything when pulling cafs.

Also I feel like this assumes that every correct CAF pull will always ask for all of a specific item from a location..
 
Last edited:
one team member doing someone thing wrong can DESTROY location accuracy. The best thing you can do for location accuracy is educate the team, they need to understand exactly how errors are calculated and what causes them. Also, the team member location accuracy report does not cover everything it only shows you if they are doing certain things wrong they could still be making errors and not show up on the report.
 
You could also cheat the system and have your team LOCU instead of using M-delete, that is if your a fan of doing extra work just to make a score green.
 
So with your method you're creating the baffle so you can track who did it? Plus that seems like a lot of time to go into sto for everything when pulling cafs.

Also I feel like this assumes that every correct CAF pull will always ask for all of a specific item from a location..
I've gotten super fast with it using toggle and the left arrow for return. If I toggle over to STO and there are 6 in the location, but it asked for 4, I will hit return, toggle back to pull, and pull 4. If it says there are 4, but there are actually 6, I will pull 5, it will ask if I pulled them all, I will say no, then it will tell me if it wants more or not. Now the baffle has been created, but it will be fixed in the audit.
 
I've gotten super fast with it using toggle and the left arrow for return. If I toggle over to STO and there are 6 in the location, but it asked for 4, I will hit return, toggle back to pull, and pull 4. If it says there are 4, but there are actually 6, I will pull 5, it will ask if I pulled them all, I will say no, then it will tell me if it wants more or not. Now the baffle has been created, but it will be fixed in the audit.

I would not really recommend this method. It can be useful to check items in STO to see if they are located; for example after you pull 6 of an item and there is 1 left in location check in STO to see if that one is still located, if it is not located I would just throw it on the pull.

Also, the audit does not erase any previous baffles from your metrics. It leads you to locations where errors occurred and you fix the problem as to prevent any future errors. But the errors have already occurred so they still count against your location accuracy. Fixing things in the audit will also not cause additional errors to be counted against your location accuracy.
 
Status
Not open for further replies.
Back
Top