ldr/LDRDocs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add some more info about muninn, dmaic reports, etc

Browse Source
This commit is contained in:
Jason Thistlethwaite
2024-02-02 13:46:05 -05:00
parent 5e51be5b4c
commit eec9e281fc
4 changed files with 275 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Processes/Continuous Improvement/DMAIC/DMAIC Reports.md
+257
View File
@@ -0,0 +1,257 @@
---
tags:
- CI
- accountabilty
- QMS
- quality
author: Jason Thistlethwaite
aliases:
- Muninn Report
---
DMAIC reports such as provided by [[Muninn]] or the [[QC Sort Tool]] measure deviations from the expected workflow. Each time a step is done differently in the work and is noticed quickly, the customer is most likely perceiving 1.5x as many deviations from what they expected. This compounds as processes feed into each other.
Taking the [[3-Day]] process as an example:
1. The checkin person assigns a category to items.
2. The next person performs the inspection.
3. Somebody STOWS the item.
4. Somebody pick/packs the item.
Each time one of those steps is done differently than normal, the following is also true:
- Differences occur 1.5x more often than we notice
- The differences compound, adding more deviations to each step afterwards
[[Six Sigma Done Wrong and Described Badly]] may serve as a succinct way to understand the basic purpose of these reports.
### Example of compounding nature
| | | | |
|---|---|---|---|
|**Step**|**Base Deviation Rate**|**Base Perceived Rate**|**Example deviation**|
|Presort|1.00%|1.50%|1% of the time, package gets sent to wrong place|
|Checkin|5.00%|7.50%|5% of the time category is not set the right away|
|Inspection|5.00%|7.50%|5% of the time, we don’t take the right pictures|
|STOW|5.00%|7.50%|5% of the time, the package gets put in a weird spot|
|Pick/Pack|1.00%|1.50%|1% of the time, the package is shipped late.|
||**Total perceived deviation:**|38.25%||
The chart above is just an example of how deviations compound, the numbers used are not accurate.
In the above chart, we're modeling that we notice a 1% deviation in Presort, which means deviations probably happen 1.5% of the time. We just don't notice or catch the extra .5%
That sounds very small, but when you total up all the deviations across the service line, it can result in something like the customer getting a different result than expected 38.25% of the time.
## How to understand the QC Sort Report
The service covered by [[3-Day]] and [[QMS - Returns Triage and 3-day]] has a dedicated tool for catching the most common deviations after the work is completed. This section applies the DMAIC concepts to that report.
![[QC Sort Report.png]]
The report above shows a 10.16% deviation rate between January 29, 2024 and February 2nd. That means that even though we detected 10.6% of the work was performed differently than expected, most likely a total of 15.89% was actually done differently.
This report works by checking for very straightforward indicators something in the intended work process was not done the intended way.
| Flag | Explanation |
| :--- | :--- |
| billingIssues | The total fees charged to the item don't match what the model of the work expects, indicating some variation in the process led to the workers adjusting a charge, overcharging, charging for something unusual, etc. |
| missingConditionCheckbox | The workers forgot to check 1 of 4 boxes indicating who probably caused the condition of the item. |
| nonFinal | Work leaving the area was not actually finished. |
| expectedCSN | The proper way to mark an item we received was actually something different wasn't (or couldn't) be followed. |
| picturesNeeded | We either didn't take pictures or we forgot to upload them. |
| dimensionsNeeded | Some deviation in the process caused us not to record dimensions properly. |
| badOrMissingComment | Every item we inspect, except New ones, should have a 30+ character comment explaining why we selected the condition. This flag indicates some deviation in the workflow caused us not to do that. |
| fatFingerDims | Any dimension of a product or box we measured was recorded as longer than 99 inches. This flags because it's not normal for us to work on items that large. |
| itemNumberIssue | We scanned a barcode as an item number, but it was either something else or the item number we scanned was not activated. |
Each of the things measured above are highly straightforward steps in the work that are done repeatedly every day by the workers. When we detect any flag about these things, it indicates the overall process is probably deviating from what's intended more than we realize.
### Example: applying this to the DMAIC above
| | | | |
|---|---|---|---|
|**Flag**|**Count**|**Percent of Total**|**Customer Perceived Rate**|
|total|315|100.00%||
|failed|32|10.16%||
|pictureSpam|28|8.89%|13.34%|
|billingIssues|22|6.98%|10.47%|
|unexpectedCount|10|3.17%|4.76%|
|missingConditionCheckbox|7|2.22%|3.33%|
|nonFinal|6|1.90%|2.85%|
|expectedCSN|5|1.59%|2.39%|
|picturesNeeded|3|0.95%|1.43%|
|dimensionsNeeded|3|0.95%|1.43%|
|badOrMissingComment|2|0.63%|0.95%|
|fatFingerDims|1|0.32%|0.48%|
|itemNumberIssue|1|0.32%|0.48%|
|||**Total:**|62.82%|
By applying this to the actual rate of detected deviations from the week shown above, we can see that the actual deviation rate the customer perceives is probably closer to 62.82%. Meaning, that over the half the time we finished the Inspection step of that process, the results are not what the customer was expecting.
That actually seems about right, since about 65% of the emails we received from the customer during the 1st half of January were complaints.
#### Are deviations necessarily complaints?
No, not always. There are several cases where deviations don't necessarily cause a complaint, such as:
- The problem created only effects people who work here, so the customer doesn't notice it, or the complaint we get seems unrelated:
- Eg: something done different during Inspection causes minor annoyance or confusion during Picking.
- Eg: something different happened during STOW, which caused orders for a different customer to become delayed.
- The result is beneficial for the customer, but harmful to us.
- Eg: we undercharged for services.
- The customer starts to think it's normal because they've mentioned it several times before and it hasn't improved.
- Eg: We take more pictures than they want, and we keep doing that, so they just start to think complaining won't help.
## Muninn DMAIC
The Muninn DMAIC system is more of a business-wide DMAIC implementation which monitors several different deviations across the business.
### itemCheckin
Muninn monitors the following things about items that are checked in:
#### skipped item numbers and regressions
Item numbers are intended to be used sequentially during checkin.
Muninn will flag when either:
1. A worker skipped numbers, like going 1, 2, 5.
2. A worker used numbers in reverse order
Muninn flags this because there is no beneficial, known reason for a worker to do either of those things.
For instance, if we see that Muninn has a 3.7% warn rate about this over the past 24 hours, it most likely means item checkin, in general, is deviating from what's expected about 5.6% of the time.
### boxCheckin
Muninn monitors the following things about packages we checkin.
#### unexpected
Muninn will warn when the percentage of unexpected items received in the same package is above a certain threshold, depending on the type of order that was sent to us:
| Order Type | Threshold |
|:-----|:-----|
| EZ | 20% |
| FBA | 40% |
| PREP | 10% |
At the time of writing, it is debatable how useful this warning is. It is fairly normal to receive unexpected items with returns or removal orders.
#### no items (not autorequest or forward)
Muninn warns if a box was checked in without any contents being recorded. This warning does not trigger for autorequests or forwarding orders.
### inspectionPictures
#### Missing Pictures
Muninn considers that a returns inspection order should have a minimum number of pictures associated with each package, as follows:
| Situation | Number | |
|:-----|:-----|:-----|
| Box | +2 | |
| Item | +1 | |
| Ridiculous Package | +1 | |
So for example, if a single package was received and had one item inside, Muninn would expect 3 pictures minimum of that box.
### autorequestPictures
#### no pictures or way too many
Muninn trips this warning if an autorequest has less than 2 pictures or more than 8.
There isn't any known reason to take fewer than 2 pictures or more than 8 for any such package, so this flag tripping means something very unusual is going on with the work.
### refurbInspect
This applies to situation where we are refurbishing or inspecting items. Muninn monitors the billings applied to such items and it flags in the following situations:
#### refurbPricingUnexpected
The total Inspection or Refurbishment charges applied to an item don't match the price for it's category.
Since these charges are applied automatically as long as the correct category was set for an item, this should never flag unless something unusual has happened.
#### refurbishPrep
Items received in a Prep order should rarely receive any Inspection or Refurbishment charges. This flag trips if they do.
#### suspiciousFeeTypes
This flag trips whenever an item we inspected or refurbished is charged any of the following types of fees (directly to the item):
- Pick/pack
- Repacking
- Take Picture
- Depot Fee, Depot Shipping, or Depot Pick/Pack
- Shipping
- Relabel
- Additional Service
- Professional Subscription
- Storage
- Disposal
- Consignment
- Prep Charges
This is because these fees should rarely be billed directly to any item under the normal work we do, except in very usual situations that should probably involve a manager anyway.
#### nonFinalInspectFees
This flags when an item has Inspection or Refurbishment charges applied to it, but the item is not in a condition indicating completion.
| **condition_name** | **is_final** |
|-------------------------|--------------|
| Refurb Pending | 0 |
| Refurb Approved | 0 |
| Refurb In Process | 0 |
| Repair Pending | 0 |
| Repair Approved | 0 |
| Repair In Process | 0 |
| Depot Pending | 0 |
| Depot Approved | 0 |
| Depot In Process | 0 |
| Disposal Pending | 0 |
| Disposal Approved | 0 |
| Disposed | 1 |
| Used - Like New | 1 |
| Used - Very Good | 1 |
| Used - Acceptable | 1 |
| New | 1 |
| Used - Good | 1 |
| Service Declined | 1 |
| Defective or Damaged | 1 |
| Customer Service Needed | 0 |
| Certified Refurbished | 1 |
### picklistReport
#### slowPick
Flags when a picklist is taking longer than 30 seconds per item on average.
#### incomplete
Flags picklists that are not finished.
#### lateStart
Flags picklists that were started more than 24 hours after they were created.
### categoryChangeReport
Flags when any product we've previously set a billing category for has it's category changed for some reason.
There are very few cases we've identified that's actually *supposed* to happen. It nearly always indicates some sort of mistake. In most cases it means:
- The person who originally set the category chose the wrong one
- The person made a mistake, and is fixing it
- The person is changing the category for unofficial or unauthorized reasons
### presortReport
#### noOrderAfterDeadline
A package that cleared [[Presort]] is still not associated with any order after 3 days.
#### returnedOutbound
A package we previously shipped out has been scanned in Presort.
#### lateOrders
Muninn flags when orders that cleared presort still haven't reached the checkin step after so many days. The threshold depends on order type:
| Order Type | Threshold |
|:-----|:-----|
| EZ | 3 days |
| PREP | 2 days |
| FORWARD | same day |
### carrierPickupReport
#### noTracker
The package was scanned in Carrier Pickup, but it's tracking number is still the default value for a new box. This indicates the package might have been handed to a carrier without the new shipping labels being applied to it.
#### missedPickup
An order marked OUTGOING contains packages that were never scanned in Carrier Pickup.
#### badPickup
A box is recorded in Carrier Pickup, but the status of the order is not OUTGOING.
#### noPackLocation
A package in an outbound order that has a status other than PENDING, has no location set for the package.