As Requested; When Requested; Where Requested

Amazon.com’s competitive advantage over regular retail has typically been around good prices with the thing you are looking for being available. In essence, they are an online, extreme extension of the big box store.

The downside has been that if you want it now, you have to either pay extra for expedited shipping, or get it somewhere else.

Meanwhile, retailers have been attacking Amazon’s price advantage by working hard to put them in a position where they have to collect local sales taxes, leading to a number of court cases plus Amazon actually pulling their presence OUT of states to avoid having economic nexus.

Now Amazon has reversed this trend, and is starting to build very local distribution centers, promising, not next day delivery, but same day delivery – as in order it today, get it today.

The analysts out there are all saying this is the “death of retail” – assuming, I suppose, that although Amazon can change its strategy, brick-and-mortar retailers are, somehow, frozen in theirs. “Death of retail” really means “We analysts, while certainly not admitting we never saw this coming, can’t think of how we would respond.”

Ultimately someone will figure it out.

But I digress.

The point is this:

Short lead times AND high variety of offering AND good prices are what customers want, and that is what anyone in the business of fulfilling customer needs should be striving for.

The ultimate transaction is “I’d like one of these.” followed by “Here you go.”

Just because you can’t figure it out doesn’t mean others aren’t trying to.

Where does this ultimately lead?

This video speculates what would will happen when Amazon figures out how to deliver what you order the day before you order it. Enjoy. Smile

 

Latest Travel Tales

Greetings from Gate 29 at GSO.
I was supposed to be in Atlanta by now, but the plane had an earlier maintenance problem.

I actually got to the gate just before they closed the door on the previous flight.
I knew the outbound was running behind schedule, and I would likely miss the connection to Atlanta, so I asked the logical question:
“Are there any seats on this flight?”
“Yes, but it would be a $50 fee.”
“I’m likely to miss my connection, it is going to cost you at least $100 to put me up in Atlanta.”
(attention turned to someone else)

So… I am now rebooked in a first class ticket on a flight to Seattle in the morning.

Had a great kaizen week, I’ll share over the weekend.

Job Instruction for Risk Reduction

I stumbled across this PDF file on The Hanover Group’s web site:

“Job Instruction Training (JIT): Controlling Your Workers’ Compensation Costs Through a Better Work Environment.”

The page essentially summarizes the contents of the TWI Job Instruction pocket card.

There is a reference at the bottom saying to “Access our policyholder education safety series online at www.hanover.com” but I can’t find the link on the main site. It might be buried in a section only available to policy holders, or this PDF might be an orphan page that the Google bot found.

Regardless of the backstory on the Hannover site, it indicates that at least someone in the insurance industry understands the importance of consistent training as a prerequisite to consistent job performance, as a prerequisite to consistent job results.

Remember: Your front line leaders are teaching every day. If you want to know what they are teaching, go look at what their people are doing.

Also remember that your managers are teaching the front line leaders what is important. If you want to know what the manages consider important, go look at what the front line leaders emphasize.

If you don’t like what you see, consider changing what, and how, YOU are teaching. But we discussed that a while ago.

5S With Purpose

The team was driving toward a consistently executed changeover process as a target condition.

In the last iteration, the process was disrupted by a scrapped first-run part. The initial level cause was an oversize bit in the NC router resulting in an out-of-spec trim and oversize holes.

This occurred in spite of the fact that there are standard tools that are supposed to be in standard locations in the tool holders on the back of the work pallet.

Upon investigation, the team found:

  • The previous part had a programming error calling out the oversize tool from the wrong location.
  • All of the operators were aware of this, and routinely replaced the “standard” tool with the one the program required.
  • After that part was run, the standard condition had not been restored.
  • There was likely a break in continuity between operators here, but that was less clear.
  • The two bits are only 1/8 different, and hard to distinguish from one another across the 10 feet or so of the work pallet.

The team addressed the programming error, but among the thousands of other programs out there, they were reasonably certain that there were other cases where the same situation could be set up.

They wanted to ensure that it was very clear when there were non-standard tools in the standard locations.

Their initial approach was to create a large chart that called out which tools were to be in which holders. Their next experiment was to be to put that chart up in the work area.

 

“What do you expect to happen?”

That turned out to be a very powerful question. After a bit of questioning, they implied that the operator was to verify that the correct tools were in the standard positions before proceeding.

“How does this chart help them do that?”

They can see what the standard is.

“Don’t they all already know what the standard is?”

Yes…..

“So how does this chart help them do that?”

Now, to be clear, the conversation was not quite this scripted, but you are getting the idea. The point was to get them to be specific about what they expected the operator to do, and to be specific about how they expected their countermeasure to help the operator do it.

One team member offered up that maybe they could color-code the standard tools and their holders so it would be easy to check and easy to see if something was off-standard. That way, even IF the situation came up where the operator needed to deviate from the standard, anyone could easily see what was happening.

(I should add that they have already put an escalation process into place that should trap, and correct, these programming errors as they come up as well.)

The tools were color-coded over night, and in place the next day.

Color coded tool holders.

This wasn’t a “5S campaign,” nor is there an audit sheet that tries to measure the “level” of visual control in the work space.

Rather, this is using a visual control to visually control something, and reduce the likelihood of another scrapped part (and therefore, disrupted changeover).

Over the last week, the work cell has been improving. When things are flowing as they are supposed to, changeovers are routinely being done within the expected time.

But there are times when their standard WIP goes low; there are times when someone gets called away; when the flow doesn’t go as planned. When those things happen, they get off their standard.

The next countermeasure is to document, clearly, the normal pattern for who works where, for what inventory is where. Then the next question is “How can anyone verify, at a glance, whether or not the flow is running to the normal pattern?”

More visual controls. Ah.

Now we are seeing the reason behind 5S. It will come in to that work area, step by step, as the necessity to make things more clear arises.

Simple Solution to Complex Problem

This video captures a crucial aspect of lean thinking – searching for the simple and elegant solution.

We can’t say this is an obvious idea, a lot of very smart people have been working on this problem for decades.

But it is a simple idea. Sometimes the search needs to be outside of the regular domain people are used to working in.

The web site is here:http://creativemachines.cornell.edu/jamming_gripper

The other aspect of lean thinking that is captured here is keep working to solve the problem. I run into so many technical people today who are so convinced that the problem is unsolvable with current technology that they either give up, or look to advance the state of the art in some (usually expensive) way.

One thing I am glad to see is a trend in engineering schools toward making things rather than just designing them.

Organize, Standardize, Stabilize, Optimize

As I work in the field, I continue to encounter a desire to get right to optimal results – “Why aren’t we working to eliminate all of the waste?”

Once people start seeing opportunities, there is a great temptation to try to simply engineer a new process and implement it. This is especially true in value stream mapping processes. The future state map seems like an engineering specification – just make it look like this, and all of these issues will go away.

The “kaizen bursts” are supposed to represent the obstacles in the way, but they often show up as “action items” instead as people are tempted to make this into a project.

But the messy reality in the actual workplace (gemba) requires a far more methodical approach.

The title of this post is from four steps that a consultant friend shared with me years ago. As I converge my own practice toward guiding people through implementing the daily improvement culture vs. implementing the tools, I am finding these words a handy mantra. This is how I have found myself explaining it lately:

image

Organize includes all steps required to make the current condition apparent. This can include 5S activity, but is by no means limited to that.

You want to know enough about what is going on that you can tell the normal, intended, pattern from one which has been disrupted by an obstacle or issue.

In other words, you know how the process should operate if people don’t encounter any serious issues.

This allows you to standardize.

This is not a standard in terms of something you are trying to enforce.

Rather, it is a standard that you are striving to achieve each and every time the process is run.

“Did we make takt time with this work cycle?”

“Did this changeover go the way we intended?”

“Did we make a good part this time?”

(for Brian): “Did we get the quote out in two days?”

Once you know how the process is supposed to work, and what results you are supposed to get, you can clearly identify those times when it doesn’t work that way, or the results are not what you wanted.

imageStabilize: Now you can begin marching up the PDCA ramp toward the standard as you work to stabilize the process by systematically eliminating the issues.

Of course, for this to actually work, you must have a process to flag problems right away, pounce on them, clear them, and then feed them into a follow-on process that works to solve them.

As you apply countermeasures to sources of instability, you are adjusting the standard itself to include those countermeasures, making it more robust.

So Stabilize and Standardize play off one another in successive PDCA cycles.

imageNow… here is the trick part. Optimize can be indistinguishable from “Stabilize.” It is more of a semantics issue than anything else, and honestly, it isn’t worth arguing about.

Why?

Because as a process becomes stable, you are going to keep driving toward perfection, True North. You are going to have intermediate-term goals you are trying to reach that keep you moving forward. You are optimizing as long as you are moving in the right direction. So there isn’t really a distinctive point of shifting gears, there is only the most important issue to address right now to hit the next target condition.

Another Customer Story

I was in a newly opened store of a large big-box outdoor sports store, and saw an item on display that I had already decided to buy this summer. The displayed price was actually a bit less than what I had been encountering online, so I went ahead.

Unfortunately the one “in stock” on the shelf turned out to be a different model (in the wrong slot), and I didn’t complete the transaction. (A retail nightmare, where the customer clearly wants to buy a big-ticket item you thought you had, but actually didn’t.)

The salesperson behind the counter offered that I could order the item from their web site, have it shipped to the store, and I could pick it up without incurring any shipping charges. Seemed fair enough.

I went online, but the online price was higher than the in-store price. In a sort of reverse from the story I told in December, I emailed customer service and asked if they would match the in-store price for the item.

In a few minutes I got a reply, with an “Incident Number” that said they would, but I would have to call in the order to the 800 number.

All well and good.

I called, and of course “catalog sales” had to refer me to customer service.

Customer service, in turn, had no way to look up the “Incident Number” on the email. “I don’t have any way of referring to that…” (Yeah, go ahead and tell the customer what you can’t do.)

I was referred to someone else (in email? I don’t know). He could not look up the number either, so I read the email exchange back to him. He honored the price, took the order, and it is on the way.

But really?

What is the “incident number” even for if nobody can reference it? In this day and age of networked and cross-linked everything…. what can I say? Perhaps my old I.T. background showing here.

Bottom line:

Turn around and face your systems from the customer’s perspective. Spend some time in the chalk circle. Think through how your process responds to unusual situations.

If a customer refers to something that you should know about your own process, but don’t, there is a kaizen opportunity here. You have an obstacle in the way of smooth seamless customer service. What concrete steps(s) will move you toward eliminating that barrier and smoothing things out?

“No Question…Sketch!”

One of the more famous tools taught by Chihiro Nakao of Shingijutsu fame is to direct the learner to observe an operation and “sketch the flows.”

Another Time Ideas article by Anne Murphy Paul, How to Increase Your Powers of Observation, validates Nakao’s instinct.

She makes the distinction between casual observation that we all do, and scientific observation.

[…]scientists train their attention, learning to focus on relevant features and disregard those that are less salient. One of the best ways to do this is through the old-fashioned practice of taking field notes: writing descriptions and drawing pictures of what you see. “When you’re sketching something, you have to choose which marks to make on the page,” says Michael Canfield, a Harvard University entomologist[…]  (bold emphasis added)

The common factor here is that, like scientists, we don’t want to simply watch a process, we want to observe it. We want to predict what we think will happen, and then observe to confirm or refute our predictions.

While casual observers simply sit back and watch what unfolds, scientific observers come up with hypotheses that they can test. What happens if a salesperson invites a potential customer to try out a product for herself? How does the tone of the weekly meeting change when it’s held in a different room?

The next time you are in your work area, rather than simply watching, bring a bad and pencil, and sketch out what is happening.

How does the material actually flow through the process? Where does it pause, stop, get diverted?

How to people flow, move into, and out of, the process?

Where does the information come from?

Does the layout support, or get in the way of, smooth flow?

How about the tools, equipment, machines? Do they help the worker get the job done, or make it awkward?

And finally, what actually happens when there is a problem of some kind? How does the team member indicate this? What is the response?

By sketching, you force your eye to see the details that you might have missed. You force yourself to actually see, and might be surprised when that is different from what you assumed was happening.

Sharpen your eye – learn to observe like a scientist.

No question… sketch!

Struggling to Learn

One of the challenges of teaching and consulting is resisting the temptation to give people the answers. Honestly, I like giving people the answers. It feels genuinely helpful, and it provides a nice ego boost.

But according to this article on Time’s “Time Ideas” site by Anne Murphy Paul titled “Why Floundering is Good,” that isn’t the best way to teach.

In fact, it can hinder learning.

The key point is summarized at the end:

… we need to “design [teaching] for productive failure” by building it into the learning process. Kapur has identified three conditions that promote this kind of beneficial struggle. First, choose problems to work on that “challenge but do not frustrate.” Second, provide learners with opportunities to explain and elaborate on what they’re doing. Third, give learners the chance to compare and contrast good and bad solutions to the problems.

Right now we are (hopefully) in the midst of a paradigm shift in how lean practitioners and teachers go about what we do.

Traditionally, a lot of us have simply given people the answers, or at least strong suggestions. Given the time constraints and overly ambitious targets of a typical 5 day event, that is understandable.

But now we are starting to see these events as skill building, which means learning, which means the teams need time to muddle through.

I have been structuring my approach quite differently for about a year now. I’ll be the first to admit that I, too, am figuring it out, reinforcing what works well, altering what needs to work better. These days I am far more comfortable letting things move through this struggle in order to set up deeper understanding once the light does come on.

The trick is to let them fail small, and not let them fail big. The problem has to have a solution that is within reach, or they will only come away frustrated.

Thus, teaching is becoming a matter of judging the knowledge and skill threshold and making sure they don’t take on too much at once. That is part of respect for people.

One problem at a time. Single factor experiments.

A great deal of the power in the “Coaching Kata” is turning out to be the question “Which *one* [obstacle] are you addressing now?” as it rules out working on everything at once.

Scrap Bin Kaizen

If you are in a production operation, be it a factory or even administration, take a look in your scrap bins (or trash cans). What you find there can be very informative.

Is all scrap treated the same? In a lot of metal working operations, I see routine drop scrap mixed in with scrapped parts and products – things that were not intended to end up there.

If that is the case, what does it tell you about the attitude around scrapping a part? Is it routine, just part of getting the job done, like drop scrap?

If you find a scrapped part, can you find the defect or flaw that caused it to be unusable? How much work (and cost) was added after that defect was created? All of that is additional cost that added no value.

Was it painted? Partly assembled? Did it go through a bottleneck operation and consume capacity of the entire factory?

What about your trash cans or recycle bins in the office?

Do you see signs of frequent paper jams in printers and copiers? These events suck time away, and more than just the time to clear them. They cause a mental shifting of thought pattern away from the productive work that takes additional time to recover.

Here are a couple of thoughts.

Separate the routine drop scrap from bad parts that were supposed to be good parts. If you sacrifice parts to adjust in changeovers, separate those out into their own category.

Each of these is a different line of inquiry starting with the question “Why?”

Consider taking your bad parts from the last 24 hours and bringing them to a central location (or a location in the department). Conduct a “morning market” and get to the bottom of at least a couple of the root causes. You don’t have to solve all of them at once, just pick one and drive it to ground. Then another.

Scrap is not simply a material and time waste. It is a reflection of how well you really understand your processes.