Tag: Technology

Posted on

3D Printing as a Kaizen Tool

One of the tenants of TPS is to learn as much as you can, as quickly as you can, with as much future flexibility as possible. This is the whole point of JIT.

The more quickly something can be built or mocked up, the more quickly it can be tried and tested, and the more quickly we learn what improvements can be made.

We are seeing the beginning of a revolution in fabrication technology as 3D printing starts to move out of high-end prototyping shops and into the mainstream.

This (very entertaining) video tells about an open source(!) 3D printer design that can be had for about a little over a grand. (USD$1250)  (makerbot.com)

Open source means that you can grab the technology and scale it if you want to.

 

Why I Love My 3D Printer

The step from one-off prototyping to full mass-customization is a small one. It is just a matter of time. The ultimate die change is none at all.

So – rather than looking at the limitations of this technology, look at the possibilities.

Posted on

Thinking About Improvement

Although it caters to the I.T. community, Tech Republic sometimes publishes pieces could have that have a wider application. Here are two of them.

In Five ways of thinking that can fell I.T. leaders, author Ilya Bogorad lists some limiting beliefs that can result in the I.T. folks being marginalized in the company. She says:

I often encounter situations where I can’t help but feel that an IT department could be a runaway success within its organization if it weren’t for the beliefs that their leader seems to hold. I want to share with you a small collection of such limiting beliefs. There are five in this list but I could have just as easily added another twenty.

Reading those five things, my feeling is that I could easily substitute the term “Continuous Improvement” where ever “I.T.” appears, and maybe a couple of other very simple edits, and most of the article really strikes home.

Read it, tell me what you think.

That article, in turn, links back to another called Costs and benefits of projects: Looking beyond the dollar sign. Same point. In this world of seemingly having to put up a positive short-term ROI for every idea, we deprive ourselves of so much innovation it isn’t funny. Just what is the ROI of “getting it right every time?” It’s pretty hard to calculate, but I’m pretty sure the opposite is more expensive.

Posted on

Computers and Muda

In a short, but interesting, thread on lean.org, Emma asks an interesting question: “Can an IT system support Lean?” She goes on to point out a general trend she has seen where the “kaizen guys” offer a lot of resistance to the introduction of sophisticated I.T. systems.

“Lean” stuff aside, I offer this recent post on Tech Republic, “The Seven Habits Of Wildly unsuccessful CIOs.”

Though the article is written about individual CIO’s, it applies to the sub-culture of information technology in general. However, there are a few points where I think the scope should be expanded.

#1, “Acquire technology simply because it’s new” talks mainly about upgrades. I would expand this to discuss “Acquire technology simply because it’s cool.” I.T. folks are biased toward computerized solutions. Now that’s great, and it is what we pay them for. But often there is a simpler way, perhaps with the information system as an enabler rather than the centerpiece. One of the fundamental principles we taught at a previous company was “Simple is best.”

In #3 “Create solutions in search of a problem” the article emphasizes off-the-shelf solutions vs. an in-house solution to everything. Again, though, I want to take the title of the paragraph and expand the scope. Just because it is slick and “does this” and “does that” does not mean it is useful. More features, and for that matter, more information, is not necessarily better. I want just what is necessary for the next step in the process. Any more provides a distraction, an opportunity for error.

#4 “Reach beyond the competency level” is classic. If you don’t know how to do it, please don’t say you do. It is OK to take on an experiment, but please control it and understand it before it is imposed on everyone. And make sure the “solution” solves a “problem.”

#6 “Failing to understand the relationship between technology and business” – read the technology chapter of “Good to Great” and “The Toyota Way.” Those both offer great insights on how great companies use technology as a multiplier without making it a boat anchor.

If you are an I.T. person, and are encountering the same push-back that Emma is from your kaizen people (or for that matter, push-back from anyone), I would recommend you read the article. Then do the following:

For each key point in the article, write down how an I.T. organization that does exactly the opposite would perform and behave with its customers. This is creating the idea of the ideal supplier.

Then take a hard look in the mirror. Compare your actual attitudes, beliefs, behaviors with that list. Talk to your customers, and ask them how they perceive your organization.

You are likely to find gaps between the ideal state you defined and your actual performance. If so, develop a plan to close those gaps.

Posted on

Who Took My Grease Pencil?

I was in a popular “Gold Rush” themed restaurant the other night, and they were struggling with a new table assignment system.

In the past the system was very simple. When you arrived, you told them your name, the number in your party. They wrote your name on a list, and gave you a pager. They had a laminated chart of the table layout, and marked tables as occupied, uncleared and available with a grease pencil. As tables became available, they moved down the list, triggered the pager, and took guests to the table. As tables were cleared and bussed, they were reported as available.

No more. Now there is a computer screen with the layout on it. They hand you the pager, and I suppose it gets logged in to “the system” as a party of 2, or whatever. And the computer pages you when an appropriate table is available. Sounds great, doesn’t it?

Of course the system is new, and the team was struggling a bit. That is expected, it is unfamiliar. But as we handed in our pager, I commented “I thought the grease pencil worked just fine.” The response was “Tell me about it.”

Now I suppose the technology enables them to track all kinds of great metrics like table turnover, etc. But if it is like most similar software implementations, those benefits are solutions in search of a problem. They are justifications for the expenditure.

I am always very wary when someone proposes to replace a functioning manual process with a computerized one. The main reason is this: The people who do the process no longer can improve it.

With a chart and a grease pencil, the team owns the process and readily understands the (non-) technology behind it. If they find a better way, it is easy for them to make an improvement.

Bury the process in a computer and you take that away. All the team can do is blindly execute whatever the programmer thinks should be happening. Programmers are smart people, but they generally do not have to execute their process hundreds of times a day. Maybe a few times – or even a few days – for testing, but not day after day. They do not, and can not, see the small issues that accumulate to become aggravation.

Before you introduce a “high tech” solution into your work area, think long and hard.

EXACTLY what is the current situation? EXACTLY what standard of performance is not being met by the current process? EXACTLY what are you trying to achieve? Remember that “automating the process” is a countermeasure, and that a “manual process” is not a problem. Let me say that again: If your problem statement says “Process is manual” then you do not yet understand the problem, and there may not BE a problem. What, exactly, about this manual process does not meet your expectations?

If the problem is that the process is labor-intensive or cumbersome, then you are getting closer. But jumping to automation still is not appropriate here. Have you carefully studied the process to see why it is labor-intensive or cumbersome? Have you looked at every step, every motion, and evaluated:

  • Why is it necessary?
  • What is the purpose?

Don’t know? Then that step is a candidate for elimination as pure waste.

  • Where should it be done?
  • When should it be done?
  • Who should perform this step?

These questions give you insights that let you combine operations. Administrative processes, especially, are full of redundant work – people looking up or entering the same information at different times in different places, or copying information from one place to another. Your goal is to take the remaining operations, the ones which passed the “Who / What” test and rearrange the steps into the best logical sequence, with the right people doing them.

  • How should this task be done?

Take the remaining steps and simplify. Make the job easier and quicker. Jigs, fixtures. In administrative processes – forms, templates. Find sources of error and mistake-proof them. Work out the method.

When you are done with all of this, then take a look at what is left. NOW, if there is a problem that has not, or cannot, be solved within the existing context you might consider an automated solution as one possible countermeasure… but don’t reflex there, unless you want to turn your kaizen over to programmers.

Last Thought – what about those great metrics the automated system can collect? Question: Do they pass the “Who Cares?” test? What is your plan to use those measurements to know where you are, and are not, performing to your standard? What is your plan to use that information to target improvement activity? Keep in mind that you cannot get performance simply by measuring it, any more than calculating your fuel mileage makes your car drive further. The purpose of measurement is to compare What Should Be Happening vs. What Is Actually Happening so you can compare your results against your predictions to see if the process is working the way you expect it to.