Pull in some older stuff from the wiki

Processes/Continuous Improvement/Kaizen Criteria Cheatsheet.md

@@ -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.

Processes/Continuous Improvement/Kanban.md

@@ -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||||

Processes/Continuous Improvement/SRE.md

@@ -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

Processes/Inventory Flags/Inventory Flagging.md

@@ -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. |

Processes/Placement of Item Numbers, ALC, and Similar.md

@@ -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.

Processes/Quality/QC and QA.md

@@ -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.

Processes/Shadow Process.md

@@ -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.

Processes/Unexpected Item Audit.md

@@ -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.

index.md

@@ -1,3 +1,21 @@
 # Welcome
 
 This is the static version of our [Obsidian](https://obsidian.md/) repository, which is used to keep track of official company processes, standards, and documents.
+
+## New Team Members
+
+New team members should read everything inside Foundations and Governance folder. The links below are the most common things you might need to reference about joining our team.
+
+[[Guiding Principles]]
+[[General Rules of Conduct]]
+[[Attendance]]
+[[Dress Code]]
+
+## Company Resources
+| Link | What it's for |
+| ---- | ---- |
+| [NMI](https://app.ldrprep.com) | WMS used for most work in the warehouse |
+| [Epic](https://epic.ldrprep.com/takePicture/) | Picture tool |
+| [Redmine](https://rm.ldrprep.com) | Project management, customer service, and ticket tracking |
+
+