Showing posts with label Process Engineering. Show all posts
Showing posts with label Process Engineering. Show all posts

Friday, April 20, 2012

Growing a Business is like Migrating Services to the Cloud

Green GiantWhen a business is in a transition between sizes, for example from Small to Medium-sized, all the business systems are expected to be able to grow with it at the same pace and at the same level of quality. Many don’t realize the demands of growth don’t necessarily scale well without fundamental changes in how it operates both in their management controls, process workflows, and the responsibilities of the personnel managing the processes.

The same holds true for migrating applications and services to the cloud. When applications are hosted on internally owned and managed servers, the maintenance and reliability of the hardware and software is managed by internally controlled resources. When they are moved to the cloud, organizations lose the level of control of quality and reliability unless fundamental changes to the system are made to be more fault tolerant, flexible to demand spikes, and redundant in the event of hardware failures or response times as a result of a multitude of causes, such as human errors, cut transmission lines, and power outages. Read an interesting account of how Netflix uses their Chaos Monkey to insure the best user experience even during major system failures.

On the surface, just doing more of what was always done may look like the growth process is healthy and successful, but there are probably obstacles looming just out of sight waiting for the right time to surface. A healthy dose of planning and evaluation with a multi-disciplined team can go a long way to preventing catastrophe or at the very least identifying the potential risks.

 

photo credit: Mykl Roventine / CC BY 2.0

Monday, September 26, 2011

Seven Effective uses of Technology in Business

rocketmanThis is Part 2 in a series about the role of technology in business improvement. In Part 1 we explored Five Ways to Incorrectly Use Technology.

Organizations can experience significant benefits applying technology in scenarios where:

  • technology can be a catalyst for innovating around a process.
  • the majority of the perceived process waste has been removed.
  • the ability to improve the process without technology has reached its threshold.
  • technology is better suited for poka-yoke, such as eliminating math errors or guiding complicated work flows.
  • the risks of injury or danger to employees can be reduced or eliminated. Examples are un-manned military drones replacing pilots in hostile areas or using robots in automotive paint spray booths.
  • the mechanical burden of maintaining the process using manual methods becomes a hindrance to productivity.
  • information or collaboration needs to be shared across geographic boundaries.

photo credit: jurvetson / CC BY 2.0

Tuesday, May 17, 2011

Transforming Tribal Knowledge to Standard Process

Instrument PanelOrganizations lament over the risky dependence on Tribal Knowledge to run their business. Extracting the knowledge from the key individuals is not as simple as asking them to write down everything they know about a process. People holding the Keys to the Kingdom are frequently making heavy use of intuition and hard won experience that can’t be dumped to documentation immediately upon request.

A deliberate structured iterative process is needed to reveal, define, and understand the processes and criteria that people use to solve daily problems, make decisions, and manage in their specific operational areas.

Here is one generalized variation of a method to extract and structure tribal knowledge into a repeatable process complete with decision logic.

  1. Following the 80/20 rule, identify and document the 20% of the process that represents 80% of the normal conditions and decisions of the typical happy path.
  2. Create a visual holding place, if one doesn’t already exist, for the data (actions, issues, and decisions) associated with the process - probably in time sequence. This can be as simple as a spreadsheet.
  3. The objective of the visual system is to have a wider  perspective of the norm so that the exceptions and non-standard conditions are more readily exposed for investigation and clarification.
  4. Apply what I call pattern-based process improvement and creative slicing and dicing of the data to begin to fill in the missing pieces that are currently only understood by the people with the “keys to the kingdom”.

This method is best executed with participation between the mentor (process expert) and at least one other person with “outside the process” eyes to distinguish between the intuitive knowledge and explicit knowledge. The additional participants are part of the audit process to verify if the process is being standardized in a form that can be operated by other non-experts.

 

photo credit: ben.fitzgerald / CC BY 2.0

Friday, September 3, 2010

Using Lighting Systems to Guide Standard Work

Several years ago I was working with a supplier to help them reduce the rate of defects to their customer. One of the specific defects was the parts packed on the pallet out of sequence. Their customer assembles products on a line where each product on the line is a different part number. The supplier’s objective was to pack the subassemblies on pallets in a sequence synchronized with the order their customer was building their product.

To make matters worse, each of the supplier’s customers worked in a different sequenced order when taking the components out of the pallets. Some customers took the subassemblies off the pallet in a counter-clockwise direction, others clockwise, or in a z-pattern. This made it too easy for the supplier line workers to accidentally pack the parts out of sequence. One misplaced part could cause a lot of expensive downtime to investigate and resolve.

I proposed a process at the supplier’s packing station that projected light into the correct position in the pallet to place the next subassembly (based each customer’s specifications) in the correct sequence order. It was a system similar to the one in the video - but they weren’t making mixed drinks.

Friday, March 19, 2010

Keys to the Kingdom? No Thank You

photo courtesy Rich Anderson http://www.flickr.com/photos/memestate/40499846/Who really wants the keys to the kingdom? Management often thinks the person that has them does so for the wrong reasons. That they want to hold the company hostage for selfish reasons. There are exceptions, but I generally believe they are victims of circumstance.

Why do they have the Keys in the first place?

It is not as common in processes that are widely understood. Typically it occurs in areas where one or more of the following are present:

  • complicated processes
  • process outputs have implications or dependencies in other areas or processes
  • process is not well defined
  • exception handling responses are non-existent or not well understood
  • long duration between repeat occurrences of an issue
  • many different issues - few obvious similarities
  • minimal direct control over inputs
  • lack appropriate preventative signals or controls
Sink or Swim Syndrome

One common reason a single person has all the information and control over a critical process is they were tasked with solving a complicated problem or cluster of problems in the area which required extensive research, experimentation, trials, and hard won learning.

Process Grandfathering

Some complicated processes are passed down from one person to the next via long term on-the-job training and mentoring that is time consuming and impractical to include multiple individuals.

If they are the experts, why don’t they fix the process?

The process roles people play can be generally characterized by the following:

  • problem solvers
  • designers
  • operators
  • protectors

All the roles are important to successful, repeatable processes, but might not be applied in the appropriate proportions. People often have the skills and play multiple roles, but depending on specifically which roles are in highest concentration, processes can lack the necessary detail and structure to prevent someone from having the Keys to the Kingdom.

High profile processes are frequently high profile because when a problem surfaces it has serious negative consequences that require quick resolution. The problem solvers are thrown at the problem to protect the organization. Problem solvers are valuable to the organization for their ability to root out causes and put interim corrective actions or workarounds in place. But, if the problem solvers are not also process designers, they may not have the skills or the time to put the necessary long term corrective actions, preventative process controls, and documentation in place.

How does your organization prevent Keys to the Kingdom? Thoughts?

Photo attribution: http://www.flickr.com/photos/memestate/ / CC BY-SA 2.0

Tuesday, December 8, 2009

Even Subject Matter Experts don’t have all the Answers

indjection molding Don’t underestimate the value of asking questions of the people that operate a process on a daily basis, even if you are a Subject Matter Expert (SME). Countless times I would go out to the factory floor and find technicians and operators violating fundamental rules while trying to keep a process running. The initial reaction is to immediately stop them. In reality, they are keeping the process running daily even while breaking widely understood industry standards and practices.

Before I set to tell them everything they are doing is wrong (I don’t really do that), I ask a lot of questions about the situation:

  • what are they doing?
  • why are they doing it?
  • what symptoms exist at the time that “require” their action?
  • are the symptoms always the same?
  • how often does this happen?
  • do they do the same thing every time to correct the situation?
  • do the other technicians and other shifts do the same thing?
  • are there other industry accepted alternatives?
  • have they been made aware of alternatives and are they comfortable with them?
  • does the “accepted” practice even work?
  • what is the result when the “correct” process is used?

Most of the time they know what they are doing is wrong, at least on some level. Odds are they are doing it because it’s a recurring problem, and the practice keeps production going. It is all to easy for a SME or engineer to say a practice is unacceptable and walk away without working with the front line people to find an acceptable alternative that works both theoretically and under the less-than-ideal real world conditions they are working under.

Often the answers to the questions provide valuable information about the root cause of the problem they are trying to work around. See my related post about Questions Lead – Answers Follow for more information. Theory is great in the classroom, but in the real world there are many other factors that have to be considered to derive the true solution to a long standing problem. Questions are an often overlooked problem solving tool, especially when it must be administered by someone who is supposed to be “the expert”. Don’t let your expertise get in the way of your ability to effectively solve problems. With that different perspective and the help of the regular process “operators”, I have witnessed significant long-term improvements even in areas where I had no prior knowledge or expertise.

Monday, September 21, 2009

Pattern-Based Process Improvement

blown glass pattern Pattern-based process improvement is a practical method of making improvements where an exhaustive analysis and re-engineering exercise is prohibitive. The process consists of looking for patterns to identify key characteristics of a process that might provide valuable insight about opportunities to improve the process. A prerequisite to finding patterns is having data or information available for review.

Real world example

Objective: Improve how parts are scheduled across manufacturing work centers to reduce late orders and unnecessary expediting.

Background: A supervisor of a manufacturing facility schedules orders on a number of similar manufacturing work cells. He normally uses the following information to create the schedule based on his experience, a few rules of thumb, and some light calculations:

  • order due date
  • current schedule of orders on the work cells (capacity vs. loading)
  • change-over time (the  time it takes to change the machine to accommodate a different component part or assembly)
  • order quantity
  • estimated production time (time it takes to process the parts through the work cell)
  • physical size and shape of the part on order

Method: The supervisor uses intuition based on a large number of observations to make decisions (Bayesian statistics) when creating the schedule. The idea behind pattern-based process improvement is to begin to quantitatively blend the supervisors experiential knowledge and Bayesian intuition with the data to create standard work that improves the predictability of the scheduling process.

Start by looking at the historical data about how the work cells were scheduled in the past. This method works best when the data is in a spreadsheet or database so the data can be looked at from several angles. Sort and group the data multiple ways looking for patterns or trends – good and bad. How much you can learn from the exercise depends on how much information is available and how valuable that information is. For example:

  • Are there part sizes or size ranges that are commonly scheduled on certain work cells more than others?
  • Are there work cells that have more downtime, more change-over time, more schedule changes, or expedites?
  • Is there a pattern to size vs. quantity or quantity vs. work cell?

If you can find a desirable pattern or a trend, determine if it is possible to create a rule that would make the pattern a more consistent part of the standard scheduling process. If the pattern is associated with a negative result, determine if there is a way to detect the pattern early, or eliminate its presence completely. It is important when using pattern-based process improvement, the output of the process is monitored carefully to fully understand the effects of the change. Sometimes changes introduce new issues. This should be looked at as an iterative improvement process, not a “set it and forget it” tactic.