Pull in some older stuff from the wiki
This commit is contained in:
Jason Thistlethwaite
@@ -0,0 +1,8 @@
|
||||
Seemingly unsolvable, stress-inducing or morale-sinking situation that seems to latch on to anybody who gets involved and won't let them alone. Usually, this is because the problem is being caused by an external factor the people involved have no real control over.
|
||||
|
||||
## Narrative example
|
||||
|
||||
Bob and Sally are tasked with keeping the kitchen clean, organized, and safe. Meanwhile, John and Sarah are responsible for making 60 sandwiches per hour. The standards set by management, as well as the layout of the kitchen and equipment available mean John and Sarah can only make enough sandwiches if they work in an unnecessarily messy and unsafe manner.
|
||||
|
||||
In the above situation, there isn't much either group can do. If either group succeeds at their goal, it most likely causes the other group to fail.
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
A help vampire needs so much help with their work you have to do it for them. Kind of like a [[Time Vampire]], but basically forces you to do their work for them or they won't go away. A slight variation of this can be a person who asks so many questions about assigned tasks we're discouraged from assigning them any work.
|
||||
|
||||
## Narrative example
|
||||
Tom's making pizza while Jerry is setting up the Christmas tree. Tom calls over Jerry to ask some questions about how to kneed the dough. Once Jerry gets there, Tom keeps asking more and more questions or interrupting Jerry before he can answer. Jerry ends up _showing_ Tom how to make the pizza by doing most of the work for him.
|
||||
|
||||
The end result is Jerry does most of the work while Tom just watches or asks questions, and the Christmas tree doesn't get decorated on time.
|
||||
@@ -0,0 +1,9 @@
|
||||
Person who makes a habit of loudly intruding into the work environment with distracting announcements at unexpected times.
|
||||
|
||||
![[Pasted image 20230130123825.png]]
|
||||
## Narrative Example
|
||||
Tom and Jerry are on the phone with Bugs Bunny to talk about a business deal. Suddenly, the Koolaid man runs into the room and starts shouting about his new Discord channel.
|
||||
|
||||
Tom and Jerry are all interrupted and confused, and getting back on track is both time confusing and stressful.
|
||||
|
||||
The Koolaid Man might even be upset or confused they react rudely to his behavior.
|
||||
@@ -0,0 +1,8 @@
|
||||
Such a huge number of resources are devoted to a project it actually derails or delays the project.
|
||||
|
||||
## Narrative example
|
||||
Tom agrees to help Jerry change some light bulbs this weekend.
|
||||
|
||||
Tom shows up with a van full of tools, several step ladders, safety equipment, and three helpers.
|
||||
|
||||
Getting the situation under control and dividing the work takes longer than if Jerry had just done the work himself.
|
||||
@@ -0,0 +1,22 @@
|
||||
Work we expect to be done, but nobody is clear on when, why, or who is doing it.
|
||||
|
||||
## Narrative example
|
||||
Tom and Jerry talked about how much they like pizza for an hour or so, but didn’t make any plans to get pizza.
|
||||
|
||||
Later, Jerry goes grocery shopping without buying any pizza. Tom is surprised Jerry didn’t buy any frozen pizza.
|
||||
|
||||
Neither person actually asked or agreed to buy frozen pizza, but Tom expected Jerry would buy pizza because they talked about it for a long time.
|
||||
|
||||
## Common causes
|
||||
|
||||
### 1) Acting or relying on assumptions
|
||||
We assume someone else “has common sense” or will take a “reasonable action” based on our own ideas of what’s reasonable or normal, which they may not share or understand.
|
||||
|
||||
### 2) Lack of rapport
|
||||
We haven’t worked together for very long, so we don’t communicate very well. We haven't yet gotten a feel for what's normal or how to communicate with each other.
|
||||
|
||||
### 3) Lack of initiative or clear triggers
|
||||
We are expecting to be told what to do, so we aren’t taking initiative to find and solve problems on our own. It might also be a person doesn't understand they're supposed to react to a certain situation without being told each time.
|
||||
|
||||
### 4) Slacking off by pretending we don't understand
|
||||
Someone is slacking off or avoiding work by pretending they don't understand what's expected from them.
|
||||
@@ -0,0 +1,22 @@
|
||||
Person or situation that eats up unreasonable amounts of time, often on a regular or ongoing basis.
|
||||
|
||||
![[Pasted image 20230130121149.png]]
|
||||
|
||||
## Examples in Story Form
|
||||
|
||||
Tom spends a lot of his time walking around every day talking to people about pizza places or asking them questions about pizza.
|
||||
|
||||
Other people are annoyed about this because they have other things they need to be doing, and Tom is interfering.
|
||||
|
||||
Tom puts pizza menus all over the wall where important notices are supposed to go, so it takes people longer to find information they actually need.
|
||||
|
||||
# Common causes
|
||||
## 1) Misunderstanding or disrespect about someone else’s priorities.
|
||||
|
||||
We assume the other person has the time or interest to spend on something they actually don’t, so we keep wasting their time with it or interrupting them to talk about it. We probably believe we’re being helpful or friendly.
|
||||
|
||||
## 2) Information is not fast or easy to find, so we ask about it instead of looking it up.
|
||||
|
||||
## 3) We don’t have a clear todo list or schedule, so we think there’s nothing else we should be doing.
|
||||
|
||||
## 4) We are intentionally wasting time because of misaligned priorities, like if somebody is often talking to a friend on the phone instead of helping do the work.
|
||||
@@ -0,0 +1,30 @@
|
||||
A project appears to go completely off the rails from what was expected, and morphs into something nobody intended. Usually, it's unclear exactly why or what happened.
|
||||
|
||||
## Narrative Examples
|
||||
|
||||
![[Pasted image 20230130122600.png]]
|
||||
Tom and Jerry agree to have a cookout with a few close friends, where they’ll have burgers and hot dogs.
|
||||
|
||||
Tom will get the beer and Jerry will pick up the food.
|
||||
|
||||
For seemingly unknown reasons, 50 people show up with a rock band and multiple kegs of beer. There’s a bouncer for some reason, and nobody knows why. Nobody is exactly sure why it happened, and they start blaming each other.
|
||||
|
||||
## Common Causes
|
||||
|
||||
### 1) Acting on incorrect assumptions
|
||||
We made assumptions about what everyone else wanted or expected and took action on that without communicating about it first, maybe to impress people.
|
||||
|
||||
We probably thought we were helping.
|
||||
|
||||
### 2) Disconnected communication channels
|
||||
Multiple side channels of communication are present, leading to fractures in consensus. Basically a rumour mill.
|
||||
|
||||
This can happen when people who weren't initially supposed to be involved overhear a conversation about the project and decide to get involved, but the majority of those already working on it don't know that.
|
||||
|
||||
### 3) A narcissistic personality is involved
|
||||
A narcissistic personality is present, who feels empowered or validated by causing the unexpected, unplanned results.
|
||||
|
||||
## Side effects and contributing factors
|
||||
Werewolf Projects often lead to a [[witchhunt]], where people become focused on placing blame for the werewolf project. In other cases, an [[Inquisition]] can be formed, where kneejerk rules are put in place that do more harm than good.
|
||||
|
||||
Primary contributing factors may be [[telephone]] or [[quija board]], which lead to the confusing circumstances or broken communication that caused the werewolf project.
|
||||
@@ -0,0 +1,4 @@
|
||||
A possible bad event which becomes cyclicly talked about, but there are no actual solutions that are proposed.
|
||||
|
||||
## Narrative example
|
||||
Tom is very worried about a comet hitting the planet and whiping out civilization. Each time he and Jerry have a conversation or try to plan anything, the conversation struggles to move forward because Tom makes everything about the comet.
|
||||
@@ -0,0 +1,25 @@
|
||||
Project that sporadically gets attention but never seems to move forward, as if it's neither really alive or dead.
|
||||
|
||||
## Example
|
||||
|
||||
Tom and Jerry keep talking about making homemade pizza on a Friday.
|
||||
|
||||
Several times, they have each shopped for pizza ingredients, but nobody has successfully made a pizza. They have spent a lot of time or money on it though.
|
||||
|
||||
They both know about it, but neither of them can make a concrete decision about either definitely making the pizza or deciding not to make pizza. It just sort of hangs around on the eventual todo list, without ever being canceled or completed.
|
||||
|
||||
## Common cause
|
||||
Inability to make a decision or adhere to one. Nobody is in charge of the situation or can call any shots about it, and there is an underlying competition or misalignment about resource allocation or plans nobody is deciding about.
|
||||
|
||||
## Other causes
|
||||
|
||||
### 1) Chaotic environments and context switching
|
||||
The environment we’re in is too chaotic for any plans to work.
|
||||
|
||||
### 2) Shifting requirements
|
||||
We can’t make progress because the nature of the work keeps changing.
|
||||
|
||||
### 3) Avoiding conflict
|
||||
One or more people involved don't really want to do the work, but they're avoiding saying so in order to avoid confrontation.
|
||||
|
||||
For example, Tom and Jerry often talk about going on a fishing trip together, but Tom actually doesn't like fishing with Jerry for some reason. Rather than explain why he doesn't like fishing with Tom, he just always has some reason he can't go.
|
||||
@@ -0,0 +1,5 @@
|
||||
#angrySpirits
|
||||
Angry Spirits are a way to talk about common communication or motivational issues at work. We find it helpful to characterize them this way so they're easier to talk about.
|
||||
|
||||
The idea is to provide some framework for understanding what sort of communication issue
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
**Kaizen Handout / Cheat-sheet**
|
||||
|
||||
This handout describes the three criteria an improvement must meet to be “[[kaizen]]”. An improvement that doesn’t meet all three criteria cannot be considered kaizen.
|
||||
|
||||
**1) Other** **people,** **processes, or areas the improvement might affect have been considered.**
|
||||
|
||||
**2) The improvement is a one-time change, provides lasting value, and can be acted on right now.**
|
||||
|
||||
**3) There is a way to measure the improvement.**
|
||||
|
||||
|
||||
**_Elaboration / Whys_**
|
||||
|
||||
**1) Other people, processes, or areas the improvement might affect have been fully considered.**
|
||||
|
||||
This is to make sure the improvement does not cause new problems in other unrelated areas. Sometimes an improvement can seem great, but causes problems for other people.
|
||||
|
||||
Example of the problem: Multiple people access a supply cabinet on a regular basis, and they have trouble finding what they’re looking for. If one person reorganizes the cabinet without speaking with others first, they might make it harder for other people to find what they need.
|
||||
|
||||
|
||||
**2) The improvement is a one-time change, provides lasting value, and can be acted on right now.**
|
||||
|
||||
This is to make sure:
|
||||
|
||||
- The improvement doesn’t just add an extra step or more work, unless that extra step or work decreases the _overall_ amount of work in some lasting way. The exception can be making a schedule for something if one doesn’t already exist.
|
||||
|
||||
- The improvement won’t be delayed or forgotten because we’re saving up money, waiting for something to go on sale, or expecting some other person or group to help. It can also be a problem when the improvement has a lot of complicated steps or multiple people required to put it in place.
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
author: Jason Thistlethwaite
|
||||
tags:
|
||||
- CI
|
||||
lastRevised: 2021-08-05
|
||||
---
|
||||
[Kanban](https://en.wikipedia.org/wiki/Kanban "https://en.wikipedia.org/wiki/Kanban") is a method of communicating requirements in lean manufacturing invented by Taiichi Ohno, an engineer for Toyota. It aims to improve efficiency in production environments by preventing overproduction and reducing overhead.
|
||||
![[kanban.png]]
|
||||
Kanban works by implementing a few basic concepts:
|
||||
|
||||
1. All work is accompanied by a “card” that has the instructions on it.
|
||||
|
||||
2. The cards are numbered, and there is a limited amount of them.
|
||||
|
||||
3. When a card is completed, it gets returned to the person who put the instructions on it. This let's them know to provide more instructions, and the work is completed.
|
||||
|
||||
|
||||
Often, the card isn't a physical piece of paper.
|
||||
|
||||
## Kanban Board
|
||||
|
||||
A kanban board is like a dashboard showing where all the cards are currently located in each production line, and how many exist for each step of production.
|
||||
|
||||
|Workflow|Needs Done (10)|In Progress (3)|Finished|
|
||||
|---|---|---|---|
|
||||
|Make a Pizza||||
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
aliases:
|
||||
- site reliability engineering
|
||||
author: Jason Thistlethwaite
|
||||
lastRevised: 2021-12-18
|
||||
---
|
||||
# Site Reliability Engineering, aka SRE
|
||||
|
||||
A practice originating at Google from 2003, SRE is a methodology for ensuring the reliability and performance of interoperating systems.
|
||||
|
||||
Much of this article is the personal opinion of our current CEO and co-founder, Jason.
|
||||
|
||||
# Why
|
||||
|
||||
We see droves of people prepping for the end of the world in ways that probably won't help them, then they die in car crashes because they don't wear seatbelts. During COVID, we saw people panic buying household supplies they don't need, then losing their jobs.
|
||||
|
||||
Humans struggle to be honest with themselves and one another about how well they are truly prepared for disasters, as well as how probable disasters truly are.
|
||||
|
||||
SRE as a practice, although it comes from software engineering, works to identify and implement reliable solutions to probable disasters.
|
||||
|
||||
# What
|
||||
|
||||
SRE as a practice focuses on the following 4 things:
|
||||
|
||||
- Automation or elimination of anything repetitive that's also cost-effective to automate or eliminate (also known as [[Toil]]).
|
||||
|
||||
- Avoidance to pursue much more reliability than what's strictly necessary. Defining what's necessary is a practice by itself.
|
||||
|
||||
- Systems design with a bias toward reduction of risks to availability, latency, and efficiency.
|
||||
|
||||
- Observability, as in, the ability to be able to ask arbitrary questions about your system without having to know ahead of time what you wanted to ask.
|
||||
|
||||
# How
|
||||
|
||||
SRE was designed for application to software systems, but like many such practices, it can be helpful to adapt for other uses. A proper SRE implementation includes the following aspects:
|
||||
|
||||
1. [[Toil]] management as the implementation of principle 1.
|
||||
|
||||
2. Defining and measuring reliability goals, such as SLIs, SLOs, and error budgets.
|
||||
|
||||
3. Designing for and implementing observability.
|
||||
|
||||
4. Defining, testing, and running an incident management process.
|
||||
|
||||
5. Capacity planning.
|
||||
|
||||
6. Change and release management.
|
||||
|
||||
7. [[Chaos Engineering]]
|
||||
|
||||
## Toil Management
|
||||
|
||||
Toil management is the practice of regularly identifying [[Toil]] in the business and ensuring there is forward progress at reducing it. LDR implements this in a few different ways
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
aliases:
|
||||
- Rack Flags
|
||||
author: Jason Thistlethwaite
|
||||
lastRevised: 2021-10-25
|
||||
---
|
||||
# Inventory Flagging / Tagging
|
||||
|
||||
|
||||
Color and icon coded tags or flags are attached to racks and pallets in the building to indicate their purpose, status, and who is responsible.
|
||||
|
||||
Icons and colors are used so the information can be quickly understand at a distance.
|
||||
|
||||
Each flag or tag has a space to write a Redmine ticket number that explains further details.
|
||||
|
||||
This is intended to be a [kanban](https://kb.ldrprep.com/processes:continuous_improvement:kanban) style signalling system (eventually), but is not yet implemented that way at the time of writing.
|
||||
|
||||
## Flag Icons, Meaning, and Usage
|
||||
|
||||
| Icon | Color | Meaning |
|
||||
| ---- | ---- | ---- |
|
||||
| ![[Pasted image 20240131161508.png]] | ORANGE | **CHECKIN** <br> <br>Inventory is waiting to be checked in. The customer hasn't been officialy notified it's here. <br> <br>This needs to be attached as soon as the inventory arrives, along with the date of arrival. <br> <br>If the inventory needs checked in a special way, the flag should reference a Redmine ticket explaining that. |
|
||||
| ![[Pasted image 20240131161514.png]] | PURPLE | **STUCK CHECKIN** <br> <br>The inventory cannot and should not be checked in, but the customer is aware it's been delivered. <br> <br>The date should reflect when the customer was notified. <br> <br>There must be a redmine ticket explaining why it can't be checked in, who is responsible, and what the deadline is for a solution. |
|
||||
| ![[Pasted image 20240131161519.png]] | RED | **REFURB** <br> <br>The inventory is destined for refurb. <br> <br>The date should be the day refurb received the rack to their queing area and updated all items to Refurb In Progress. <br> <br>If refurb cannot process the inventory within 10 days, it should be updated to Customer Service Needed, and the flag should reference a Redmine ticket explaining why the inventory cannot be processed. |
|
||||
| ![[Pasted image 20240131161525.png]] | GREEN | **STOW** <br> <br>The inventory needs to be STOWed. <br> <br>The date should reflect when the inventory was released for STOW. <br> <br>If the inventory needs to be STOWed a special way, the flag should reference a Redmine ticket explaining what needs to be done, by who, and when. |
|
||||
| ![[Pasted image 20240131161531.png]] | YELLOW | **NO MOVE / PREP** <br> <br>The inventory is part of an ongoing or staged project and should not be moved or messed with. <br> <br>The date should reflect when the project was decided about / started. <br> <br>There must be a redmine ticket referencing who is doing the project, the instructions, and the deadline when it will be completed. |
|
||||
| ![[Pasted image 20240131161536.png]] | BLUE | **OUTBOUND** <br> <br>The inventory is waiting to be picked up. <br> <br>If the inventory will not be picked up the same day, the flag must reference a ticket that explains who is picking it up, when, and any relevent documents. The ticket must be assigned to Dock Crew. |
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,19 @@
|
||||
---
|
||||
author: Jason Thistlethwaite
|
||||
lastRevised: 2021-04-17
|
||||
tags:
|
||||
- checkin
|
||||
---
|
||||
Also known as Ident Tags, these are stickers which identify inventory in the warehouse and are used to keep track of it. This process covers how these stickers should be used and placed on inventory.
|
||||
|
||||
## Placement
|
||||
|
||||
These stickers should always follow these rules:
|
||||
|
||||
1. They go on the smallest side of the box, unless the item doesn't have rigid corners (like a bag).
|
||||
|
||||
2. They are _never_ covered with tape. Tape causes the labels to fade and become unreadable.
|
||||
|
||||
3. Any other barcodes near them are crossed out or covered to prevent accidentally scanning the wrong label.
|
||||
|
||||
4. If any box has more than one Ident Tag, they should all be on the same side of the box.
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
aliases:
|
||||
- Quality Control
|
||||
- Arnold's Pizza Shop
|
||||
author: Jason Thistlethwaite
|
||||
lastRevised: 2021-04-17
|
||||
tags:
|
||||
- accountabilty
|
||||
- quality
|
||||
- QMS
|
||||
---
|
||||
# # QC vs. QA: What are quality control and quality assurance?
|
||||
Quality Assurance is the act of designing processes that reliably produce the correct results.
|
||||
|
||||
Quality Control is the act of regularly inspecting results to make sure Quality Assurance is effective.
|
||||
![[Arnold's Pizza.png]]
|
||||
## In Story Form
|
||||
At Arnold's Pizza Shop every pizza is supposed to come with pepperoni and bullets on it. Arnold's customers depend on it.
|
||||
|
||||
**Arnold's Quality Assurance:**
|
||||
|
||||
1. Arnold posts a large sign in the kitchen:
|
||||
|
||||
1. It shows a picture of what the pizza should look like.
|
||||
|
||||
2. It reminds staff to double check: every pizza must have pepperoni and bullets.
|
||||
|
||||
2. Arnold instructs his staff:
|
||||
|
||||
1. Each pizza is supposed to be double checked by a second person before it goes to a customer.
|
||||
|
||||
2. That person has stickers with their name on them. They put the sticker on every pizza they check.
|
||||
|
||||
3. The servers and delivery drivers check every pizza to make sure it has a “checked” sticker.
|
||||
|
||||
All these steps work to ensure every pizza will have the correct toppings: pepperoni and bullets.
|
||||
|
||||
## **Arnold's Quality Control:**
|
||||
|
||||
Arnold needs to be sure his staff are actually following these instructions. He needs to be sure the sticker guy is really checking pizzas instead of just putting stickers on them.
|
||||
|
||||
So Arnold puts some quality control measures in place:
|
||||
|
||||
1. He informs customers they can win a free pizza if their pizza doesn't have the “checked” sticker.
|
||||
|
||||
2. He randomly watches the cameras once in a while to make sure the checker is really checking pizzas.
|
||||
|
||||
|
||||
He might put some incentives in place. Arnold's a tough guy, so his incentives aren't the most friendly but they work:
|
||||
|
||||
1. If a driver or server gives a pizza without a sticker to a customer it comes out of their paycheck.
|
||||
|
||||
2. If Arnold catches anybody applying stickers without checking a pizza, they are fired automatically. All employees are told about this multiple times, and signs are posted.
|
||||
|
||||
3. For every 1000 pizzas sold without any complaints about missing pepperoni or bullets, his employees get a bonus.
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
author: Jason Thistlethwaite
|
||||
lastRevised: 2020-05-23
|
||||
---
|
||||
# Shadow Processes
|
||||
|
||||
A shadow process is when something that has formal standards or processes is instead accomplished some other way that's not officially recognized. Shadow processes often become a de-facto way of doing things, usually without the knowledge or authority of the people who are supposed to be doing them.
|
||||
|
||||
The term “shadow process” comes from a phenemona called [shadow IT](https://www.skyhighnetworks.com/cloud-security-university/what-is-shadow-it/ "https://www.skyhighnetworks.com/cloud-security-university/what-is-shadow-it/"), where information technology changes or decisions are made and implemented without the input of the designated IT people within an organization. IT is not the only place shadow processes can exist.
|
||||
|
||||
This article is intended to document what shadow processes are, and the benefits and problems they can create.
|
||||
|
||||
## Example of a shadow process
|
||||
|
||||
Imagine the work day officially starts at 9am, and everyone is supposed to be at work and at their stations by 9:05am. That's the official company policy.
|
||||
|
||||
However, most of the people in one department often arrive pretty early at 8:45am, so their manager begins to expect them to be early. Within that department a shadow process now exists, where the start time expected by the manager is different from the official starting time of the company. The manager also regularly allows people to leave earlier than the official end of the work day.
|
||||
|
||||
This is intended to be a neutral example, because shadow processes are neither inherently good or bad.
|
||||
|
||||
## Why do shadow processes happen?
|
||||
|
||||
Often, a shadow process manifests when a group of people have a need the official policies or procedures don't solve very well, so they begin handling the situation differently, often in semi-secret. Many people probably know about the shadow process, but it's likely not written down anywhere.
|
||||
|
||||
In the example above, where the start and stop time for a department has developed into a shadow process, it seems to make more sense for the people in that department. They're apparently early birds and would rather leave earlier than come in later, and the official process doesn't do anything to help with that.
|
||||
|
||||
However, it may shift problems elsewhere:
|
||||
|
||||
- Customers expecting the workers to still be there before 5pm might be confused or upset.
|
||||
|
||||
- It might cause inter-departmental issues.
|
||||
|
||||
- There may be reasons for the official start and stop time that the management within the department doesn't know about.
|
||||
|
||||
- New employees unfamiliar with the shadow process could be seriously confused about it.
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
author: Jason Thistlethwaite
|
||||
lastRevised: 2021-04-17
|
||||
tags:
|
||||
- accountabilty
|
||||
- quality
|
||||
---
|
||||
# Unexpected Item Audit
|
||||
|
||||
Unexpected items are items we received that don't match what we were supposed to get. That can mean they were misidentified at checkin, somebody accidentally entered the wrong quantity, or we truly did receive items we weren't supposed to.
|
||||
|
||||
The problems this can cause are pretty serious, so unexpected items should be verified by a 2nd person on a regular basis.
|
||||
|
||||
## When to do it: How to know when it needs done
|
||||
|
||||
On the employee dashboard there is an icon that represents the number of unexpected items received recently, as shown in this picture.
|
||||
|
||||
![[Pasted image 20240131161111.png]]
|
||||
If this icon is green, as shown above, that means no unexpected items have been checked in. Nothing needs to be checked.
|
||||
|
||||
**If this icon is yellow, as shown in the picture below, an audit needs to be performed.**
|
||||
|
||||
![[Pasted image 20240131161139.png]]
|
||||
This indicates 34 unexpected items are in the warehouse.
|
||||
## What to do
|
||||
|
||||
Clicking on this icon will generate a list of the unexpected items, showing what they are and where they are located.
|
||||
![[Pasted image 20240131161214.png]]
|
||||
**Process:**
|
||||
|
||||
1. Write down what time you started the audit. You will need this later.
|
||||
|
||||
2. A designated person should go find all the unexpected items that have been checked in since the last time this audit was performed.
|
||||
|
||||
3. Once they find the items, they must double confirm the item is real and is correctly identified.
|
||||
|
||||
4. If items are not real, cannot be found, or have been misidentified do this **immediately**:
|
||||
|
||||
1. Using bulk update, change the item condition to “Customer Service Needed”, and add the comment “inventory under investigation”.
|
||||
|
||||
1. This marks the inventory so the customer does not try to ship it out of the warehouse.
|
||||
|
||||
2. Pull the inventory to a designated spot for checkin mistakes, and update the location to that area.
|
||||
|
||||
3. Write down what happened and turn a report about it into the Director of Continuous Improvment.
|
||||
|
||||
5. If the item _is real_ and correctly identified, no action is needed.
|
||||
|
||||
6. Once you are finished, write down your start time from step one, along with your name, in a designated spot so the next person knows they don't need to check unexpected items checked in before your start time.
|
||||
Reference in New Issue
Block a user