Fair enough, here are some issues I've seen at my store with the new app. Remember, this app isn't even a month old.
PATHING :
- Pathing is way off. One example is the other day I was sent to A which for our store is up front near the checklanes. Then it sent me to F to our seasonal section with is on the complete opposite side in the back corner of the store. Then it sent me BACK to A an aisle away from the first location. Then it sends me to Infants and then BACK to A in the same aisle I was in previously. This is consistent and has gotten worst. The sad thing is the point of the pathing is to cut down on wasted movement, but thus far it's just adding to the time and increasing workload and decreasing productivity...
See above comments on this...
SKIPPING DPCI's :
- So you figure out the pathing is way off, so instead you skip items to get to a location closer and more productive, however, once you find said DPCI, it kicks you back to the beginning and forces you to skip all those items again. Once you repeat this and find the next DPCI, you have to continue doing this, skipping through DPCI's constantly. This is unnecessary and should just continue along to the next DPCI instead of trying to force you to take it's path. Also, often times things DPCI's drop out of order, so even though you've skipped enough times to know which DPCI to expect next on the list, it'll show up later in the pathing. It's just off and very strange.
This shouldn't be happening; I'm having our engineers validate this. It should resume at the next location not at the beginning of the path. We did have a defect when skipping backroom locations then working a SF item, then bringing you back to the BR. This has been fixed though. Please check this and let me know if it's still happening. Can you send me an example of where the DPCI first showed as one location and then went to a different one or in a different part of the path?
ASSORTMENTS :
- Maybe it's just our system, but now pulling assortments doesn't indicate what assortment box you need to be pulling, instead it just lists the DPCI of the item needed for the order, thus not actually pulling the DPCI nor the assortment since you can't individually unlocate a DPCI from a location that's directly tied to an assortment box. First issue this creates is the fact you have to pull down every box of assortments to find the right one, so if you have a shelf with 10 big boxes of assortments, now you're looking through them to try and match the DPCI needed...and this isn't productive. The second issue is the fact that since it's just telling you what DPCI is needed, it's not actually pulling it...you're literally just reaching into the box and pulling out what you need and leaving the assortment located and then next time when a team member goes back there to pull that specific item for a guest wanting it, it won't be there because it was pulled previously (which is why it's so important to pull the entire assortment box). So...you probably recognize this (hopefully, I am sure a lot of team members don't or just don't care)...so then you toggle over to manually pull the entire assortment box...this just increases the workload and lessens productivity. If this isn't happening, it'll just potentially create errors (because a team member might assume it pulled the assortment and pull it down when it fact it doesn't do it). Move had the opposite issue where it never showed the DPCI until you pulled the assortment it asked for and thus committing to the order suggesting you pulled and have the actual item...problem with that was that if someone previously pulled that item from the box and left the assortment, you were left with nothing and had to go and find the item elsewhere...this created issues. Fact is...they really need to implement a system where it tells you what assortment box you need to pull while also SHOWING you the DPCI you'll be looking for after pulling the box. Regardless, the move app had a more sensible approach...it indicates what assortment box you needed to pull and then you took it from there...the new system forces you to go on a scavenger hunt.
Assortments are the devil. There is work in progress to remove them altogether in 2019 sometime. Can't wait. The ePick app should have you pull the entire assortment carton and then have you find the specific item that is needed for the order. Is this not happening?
CASEPACK QUANTITIES, POTENTIAL ERRORS AND HALF FULL CASEPACKS :
- Something else I've noticed is that it'll send me to an upper case pack location (tied as such) and as an example, ask for 4 eaches, but the casepack is full with 6 eaches. Then after pulling it, it only wants 2. It's simply not asking for case packs or just confused on the quantity of most case packs. So now you have to toggle over and pull the remaining amount that it did not ask for and pull the full casepack. Unfortunately, not all team members will do this and simple pull the asked amount. Now this isn't new because sometimes Move would have had this issue, but not near as much as I've seen with ePick. It's constant and just adding to the workload. It honestly had very little sense of the actual quantity of most casepacks. You'll get some team members that'll know better and pull the items to prevent the error or you'll get some who don't know or are just lazy and leave partial casepacks. The fact you can't type in a higher number to pull to indicate to the system there is actually more there to register an error is silly. Pulling more isn't going to impede on the order in any way...it'll just create more stock to deal with afterwards. I also don't like the fact that if you don't scan all items in location, it deletes those items because the fact is if I go to location with 20 items in that location and it asks me for Q-Tips and the remaining items are all shampoo and hair related product, I can tell the different between Q-Tips and a bottle of shampoo. It shouldn't even really mess with overal location accuracy, only location accuracy specific to that item...that way I'm not needessly wasting time scanning 20 items that are obviously not the product because the product isn't in the location it should be...
If the system thinks that the casepack is 4 but in actuality it has 6. This is a merchandising set up issue on the casepacks. Although if it says 4 but there are 6, then you should type in 4 and the system should pull it out of location. If this isn't happening we have a problem. Move and ePick use the same logic, so you should see the same behavior. I will talk to some folks on typing in higher than the casepack quantity and see if we can create a report as this would identify the merchandising discrepancies so those can be fixed. The scanning all items in the location was implemented as a way to audit the locations as you're already in that spot instead of having a TM come later and audit it. The thought is to save time and audit more frequently.
CROPING OF OPU ORDERS AND BULK ITEMS :
- This issue might be under debate as I am sure some will like it. It was indicated as design feature when the new app rolled out that ship alone items pulled for OPU would be in it's own category and not cropped in with smaller items, but this just creates more work because if you used move long enough, you knew how to navigate around this issue to begin with (since you could just type in DPCI's and locations when putting the items in location). So this change in my mind wasn't completely necessary, but now we are also finding that the system is very pick and choose on how it crops regular items. An example is the other day we had 10 DPCI's for OPU, but instead of giving you all 10 items to pull, it gave me 6 for one batch, forcing me to use a second cart location (this is another issue I'll touch upon later) so I could prevent walking back and forth between the backroom and guest services by doubling my footsteps and increasing time. Sometimes the system will give you all the OPU's to pick at once and sometimes it'll only give you some of them...so what happens if you have 20 DPCI's over a string of orders...are you going to pull 4-5 at a time and repeatedly walk up to guest services over and over? This is fine for slow team members, but personally I am pretty fast and often times I kill multiple birds with one stone by pulling several batches at once. The system just needs to be consistent...or better yet just give team members the ability to choose how many DPCI's they feel comfortable with pulling.
Somebody mentioned the same behavior above...can you PM me more details? OPU is set up to have 10 eaches in the batch. It should always fill to that level and even go beyond that in order to keep an order together. So if you have 10 eaches that are 2 different orders, they should drop into the same batch for sure. I'd like to know when this happened, what batch/orders you were working so we can try to replicate this.
BATCHES AND HOW THEY ARE TIED TO CARTS :
- This is a big issue I personally have being that now once you start a batch, regardless of the number of items in said batch, you are now tied to the cart location you scanned to begin the batch...even if you didn't pull anything. Before, you could begin a batch and it wouldn't tie to a cart until you scanned at least one DPCI, so you could simply jump in to see how big the batch was or to see what items are being asked for. I often times could enter a batch coming back from lunch just to see if I could pull an item or two on my way back to increase productivity...but now you can't do this...you're stuck to a cart once you simply enter. Like I was talking about with OPU picks and cropping. Before I get start working on OPU's and if a pick dropped in before I pulled anything, I could just back out and restart and add that dropped over to my task list of previous OPU's I was about to pick...but now I can't do that...once I start...I'm stuck with that cart location until it's completed and so the only way to get around this is to just use another cart location...and if another OPU drops while doing those and I want to cut down on time...I have to type in yet another cart location, unncessary using many carts and just creating more of a possibility for the system to incur an error and getting the batch/cart locations stuck for days. It needs to go back to way the Move worked where it doesn't tie you to a a cart location until you pulled your first item...
Will look at bringing this back...I'll add to the backlog.
ERROR CODES AND ISSUES WITH CARTS BEING IN USE :
- Last week half of our carts were in use due to the system running into errors and not letting people back into paused batches or batches being stuck in our system and repeatedly completing and then popping back up on the paused list, thus not allowing anyone to use that cart location to do other pulls. Maybe we just had bad luck and other stores hasn't really ran into this issue, but last week we had a lot of cart locations unncessary in use and CSC is of little help because they just tell you to wait and they'll escalate. After 4 days, it got resolved...however...to add to headache, all those orders that were 4-5 days old flooded back in instead of getting bounced to another store to fullfill while the issue was being worked...just making the guests wait longer and putting more pressure on the store. Move had it's issues, but not near this amount...even when it rolled out.
This should be fixed with this weeks' deployments/fixes. These stuck carts were mostly due to an assortment issue bug.
TIMING, INACTIVITY AND ALERTS :
- There are also a lot of issues when it comes to "inactivity" while in a cart. If you haven't scanned a DPCI for 5 minutes (maybe a little more), it'll kick you out of your cart once you find that DPCI and scan it, forcing you to have to rescan your cart and then scan the item again. Not a big deal really, but silly and just increases pull time. It's just unnecessary. Also, maybe it's just our store, but there's been a rash of issues with the new app talking with the alert system and often times we'll get goal time approaching alerts for orders that dropped in only 15 minutes prior, or we'll get ghost alerts and no OPU's drop in. Or even worst, sometimes we'll get alerts for new orders, but they won't be dropping in and then 15 minutes later they'll flood in, giving us 15 less minutes to complete these orders. We've also gotten missed goal alerts for orders that were completed 30-45 minutes after the order dropped. Just a lot of issues that add headaches and suggests out unreliable the system is.
Some of these alerting issues dropping at strange times can be due to orders dropping late to your store. These have happened frequently as the Order Management System which is the brain that allocates orders to stores is replatforming to Guest Order Management. That transition caused lots of late dropping orders over the last few weeks.
That's just to name a few. Personally I didn't have a lot of issues with the Move app, namely on how OPU's were scanned in because if you used the app long enough, you figured out easy workarounds by typing in DPCI's locations, however doing things one by one cut down on potential messups where the new system gives little indication besides a small green dot (it should just grey out an already scanned item) and if you have a big order of 20-25 items (I've had several orders like this already), then you have to scroll through this big list of items just to double check your work where previously you couldn't move on until that item got scanned into location...but I understand...the big reason this new app got rolled out was to address this concern that most team members took issue with how the Move app worked.
All in all...maybe my store had just been unlucky and ran into a lot of issues where other stores has had it easy and not encountered them...but I've had more headaches with this new system than I did with the year of using Move and a new issue seems to pop up every day. The app needs to allow team members to dictate the workload a little more, give more details when it comes to what you're pulling (specifically assortments) and less interacting with accuracy counts.
