The Data Heads

In a recent post I described the difference between the Voice of the Customer (VOC) and the Voice of the Process (VOP). I used a simple Input => Process => Output diagram to explain that both the VOC and VOP have an important role in evaluating our systems and processes. I said that it isn’t a case of one being right and the other wrong, or one being better or worse than the other. Both approaches have their place. But they are different.

It seems to me that the biggest issue comes when we confuse the two approaches.

I suspect someone is confusing the two approaches when they point to a control chart with subgrouped data plotted on it and say something like:

“When I see a point out near our limits then I know we’re getting close to going out of spec.”

On the surface this seems like a reasonable thing to say. And it must be reasonable because I hear it so often. So why do I get all worked up when I hear it?

(Because I do get worked up. I have a hard time not jumping up and down and raising my voice. )

“When I see a point out near our limits…”

The issue is that the point is the average of the data in a subgroup.

Lets look at a picture:

We’re looking at three subgroups of data.

What is your vote?
Specs are 25 plus or minus 5, we have no problem, right?
Specs are 25 plus or minus 1, we should worry, right?

Here is the actual data:
Sample A: 24.9, 25.0, 25.1
Sample B: 20.0, 25.0, 30.0
Sample C: 20.0, 20.5, 33.0

And here is what it looks like plotted on the same run chart:

Plotting subgroup averages on an X-Bar chart and then comparing those average points against the specifications is misleading. You’re blurring the use of VOC and VOP. Don’t stop using either loop - but don’t try to use them at the same time.

Have you ever seen the VOC and VOP loops confused? What issues has it raised for you? Use the ShareThis button below to mark this page, leave a comment, tweet me, schedule a conversation, or call 800-958-2709.

In the weeks leading up to American Thanksgiving and the rest of the holiday season, I found myself buried in a couple of projects related to the release of GainSeeker Suite, Version 8; and a course in Appreciative Inquiry. In the process, I got out of the blogging groove. (Version 8 is pretty cool. It includes some brand new modules that will help you get more value from your data, and make it even easier to use. More on the new version in subsequent posts. Likewise, I’ll write more about my interest in Appreciative Inquiry in the weeks and months to come.)

Now my editor at Quality Magazine is prodding me, so it is about time to get back in the rhythm, even though I still have some tasks on Version 8.

My last post at Quality Magazine on ‘Defining Quality’ (which was a revision of ‘What are they thinking…?’ published here) generated a number of thoughtful comments from readers. I really appreciate hearing other perspectives on the questions I posed in the post, especially this comment:

Only in the world of utopia are there processes with zero variation and where only Green or on target values are produced. In the real world you have to look at each process and determine the ability and cost required to reduce process variability. In some cases it may be more cost effective to use an inspection system (like a vision system) to inspect out defects, then it would be to reduce the variation that creates these defects. The rule I use is if prevention is not practical and if detection methods are effective and reliable, then the inspection method is the right choice. When detection is difficult or not reliable, then prevention efforts must be taken.

This got me thinking about a model for inspection that I’ve found helpful in recent years. Here it is:

Bear with me because this graphic still needs some explanation.

If you look at this carefully, you’ll see that it is a typical ‘Input - Process - Output’ diagram. If you look at it even more carefully you’ll see that it is there are two loops on the graphic. The question isn’t so much which loop is right and which is wrong. The question is: Which loop is primary? Which loop is emphasized?

Both loops start in the middle with an observation or a measurement. The right-hand loop is the Voice of the Customer. I’ve highlighted it here in yellow:

The right-hand loop compares the observation to the customer’s requirements and asks “Does this meet the customer’s requirements?” If it passes, you can ship the product. If it doesn’t, you have a couple of options.

If your product fails to meet specs in a manufacturing environment, your options are to Scrap, Rework or Downgrade the product. In a transactional world, your options are to Remediate, Replace, or Compensate. In either situation your options for response are always reactive and wasteful.

I see people tolerate this waste for all kinds of reasons. Perhaps there are other, more expensive issues that need to be addressed before this problem can be tackled. Perhaps the cost of getting rid of a problem seems too high. Perhaps they’re just used to it and can’t imagine any other way of doing business. Some of these reasons are probably better than others, and I’m really not here to pass judgment in this blog. The point that I want to be clear about is that the right hand loop - the Voice of the Customer Loop - captures waste and protects the customer. There is nothing wrong with that (actually there are some good things about it). But it doesn’t prevent the problems from recurring.

The left hand loop starts at the same place, but has a very different impact. This is the Voice of the Process Loop, highlighted here in green:

The Voice of the Process Loop also requires an observation or a measurement, but here is the crucial difference. Where the Voice of Customer Loop compared the observation against specifications, the Voice of the Process Loop compares the observation against what is expected.

On what do we base our expectations? Well you can guess that it isn’t a specification - or anything that is derived from a specification or a requirement.

We base our expectations on our past experience with the process. This is why we call it the Voice of the Process. The best way to tap into our past experience with the process is with the humble control chart.

The control chart tells us what we need to know about the process. If the data we observe shows no patterns, no shifts in mean, and no more variation than we’ve experienced before, then we have reason to conclude that the process is stable. Once we know the process is stable, then we can still ask ourselves “is there a way to improve (reduce) chronic variation? This can lead to improvements in the process or the inputs to the process.

If the process tells us that it isn’t stable, then we can (and should) address that. We can focus our efforts on improving the process or the inputs to the process.

Using the left-hand loop - the Voice of the Process Loop - is how you improve processes and ultimately reduce or even eliminate the need for the Voice of Customer Loop. In an ideal world our processes are well understood and stable, and we don’t need to check against specs because we know that we’ll always meet customer requirements.

In the meantime, we live in the real world. In the real world, inspections against specifications are a reality and will probably be around for a long time. They’re useful and I would be the last to advocate their complete elimination.

But they don’t lead to process or quality improvement, or to an elimination of the waste associated with failure to meet requirements. To get there you need to pay attention to the Voice of the Process. You need to stabilize your processes and then systematically reduce chronic variation.

Where is your emphasis? Which loop do you follow? What are the biggest challenges you face or have faced in shifting your emphasis to the Voice of the Process Loop? Use the ShareThis button below to mark this page, leave a comment, tweet me, schedule a conversation, or call 800-958-2709.

One of the really important aspects of the Data Cost / Value Matrix is how reducing the cost of data can help you get more value from data.

This came up again the other day as we were debriefing following a recent deployment for a new customer. This customer is about to undergo a major cultural transformation because we helped them automate real-time data collection and analysis. In the process, they will shift from a Product Control to a Process Control way of looking at the world. Ultimately this will reduce costs, increase customer satisfaction, and (we hope) drive new business.

This customer makes electronic devices. Their products are complex pieces of equipment, and at a couple places on the production line, the various component parts and the final assembly pass through an automated test stand. This test stand runs the unit though dozens - even hundreds of electrical tests. A unit has to pass all of those tests to be released to their customer.

Sounds like a winner, right? One hundred percent inspection. Nothing bad ever escapes to the end user. And we have the data to prove it. Boy, do we have data. Entire databases of rows and columns of numbers. Every one of them in spec.

Except it doesn’t work that way. Some units pass all the tests with flying colors - and then fail out of the box or early in the life of the product. Here is what the data for one test parameter looks like plotted on a histogram (this isn’t actually the customer’s data - it’s just representative):

In this example, everything is well within spec - it should all be good.

When you look at this data in time series on a control chart it looks very different:

Viewed this way, this data tells a completely different story. If you look closely you can see a couple of signals that the process is unstable, even though everything meets spec. In a complex environment with dozens of critical - and interconnected - variables, these unstable values often directly correlate to the early life and out of the box failures.

Learning to rely on the control chart is the shift from Product Control to Process Control. It is often a tough shift to make - especially when everything is in spec.

What makes it even harder, however, is the sheer volume of data they need to sift through to find those signals. Hundreds of test parameters, hundreds of units tested every day. Automation is the only way you can keep up with the data. By automating the data collection and analysis process you can empower people to make that cultural change.

What about you? How can reducing data costs make it easier to get more value from your data? Use the ShareThis button below to mark this page, or leave a comment, tweet me, schedule a conversation, or call 800-958-2709.

Sometimes a picture is worth a thousand words. I have four pictures - and I’ll still need a few words to explain them. Hang on for the ride…

In the last two posts I’ve been talking about why Short Run SPC (Statistical Process Control) has been on the increase, and I’ve described the three most common Short Run Coding methods. This post shows a simple example of a Target / Nominal control chart.

First some background: We’re tracking a cut-off process. For this process, the operator resets a target value. The company makes several sizes of these parts, and any one part (length) may run for a few hours or several days. Depending on customer demand, a part that runs today may not run again for a week, or several months, or even longer.

If we keep data for two of these parts on separate charts here is what they look like:

(Click on either chart to open it full size, in a new window.)

If you use traditional SPC, you have to put these parts on separate charts because the scaling is all goofed up. Notice how the target for parts on the first chart is about half an inch while the second is about three-quarters?

What isn’t as easy to see is how these charts disguise the gap in time between process runs. If we put the second chart on a time-series graph this becomes a little more obvious because you can see at least three separate runs for this product. Notice the of the way the points are clustered on the chart.

So there are at least two problems with traditional part-based SPC charts in this type of environment: You can’t see the gaps in time in subsequent runs for each part, and you can’t see what was happening to the other parts during those gaps in time. That’s the problem with focusing on Product instead of Process.

The Short Run Control Chart takes care of those problems by coding the expected variation (in this case the target) out of the data and plotting data for all the parts on one chart.

On this chart, I’ve shaded the data for the first chart in red and the second part in green so you can see how they interact on the Short Run Chart.

The first goal of Statistical Process Control is to detect signals of process instability. Do you see how that is works in this example? If you look closely at the point shaded in green at the right side of this chart you see that it is actually the 7th point of a seven point run above the mean. The traditional SPC chart (the last point on the second chart) at the top of the page misses this signal completely.

Do you see any other signals in the Short Run chart that the traditional chart misses? Use the ShareThis button below to mark this page, or leave a comment, tweet me, schedule a conversation, or call 800-958-2709.

As described in this post, Short Run SPC (Statistical Process Control) relies on clever coding techniques to deal with the expected variation in a process. Once you strip out the expected variation, any variation you have left is the true variation of the process. You can plot this on a control chart and treat it as you would any other process data.

The key to coding the data effectively is to form families and retrieve the coded data by family. The challenge arises when one begins to form these families. What constitutes a family? The basis for family categories must be logical, rational and meaningful in understanding the process. Some are obvious: similar part geometry, similar materials, similar operations, etc.

Remember that we wish to focus on Process Control and not Product Control. A shop may produce many different part numbers on a single machine. While each run is different, the same operations are performed over and over. Different types of families can be formed depending on the processes. A step in forming these families is to identify which coding method applies.

There are three methods of coding Short Run data, Target/Nominal, Range/Short Run, and Standardized. Here is a flow chart for helping you select the correct coding method:

(Click to open full size in new window.)

Use the Target/Nominal method when the target or nominal values vary from product to product, but the expected variation is the same and the subgroup size is constant. A good example of this are fill weights for packaged goods. In this situation the manufacturer may be putting the same product in a variety of package sizes to sell through different channels. Because the same commodity (a liquid with a constant viscosity and density) is going in each bottle, the expected variation in the fill weights from bottle to bottle is the same, and the company always uses the same subgroup size. The only thing that changes is the target weight (4, 8, 16, or 64 oz size, for example). Other examples are film thicknesses or machined features such as OD or length.

The second type of coding method is the Range/Short Run method. Use the Range/Short Run method when you are not confident that your process contains the same amount of variation from part to part.

For example, a rubber molder makes similar products with very different materials. Some of the products have a very high carbon content, and are therefore very stiff. They have a very tight tolerance. Other products have a high silicon content and are soft - even mushy. They have very loose tolerances. This is a great application for the Range/Short Run method because both target and tolerance vary. The Range/Short Run method makes it possible to see charts that are not biased by a known and expected source of variation in either the target or the range.

The third coding method is the Standardized control chart. Use if when you have different subgroup sizes for different part numbers. The Standardized Chart codes out expected variation in Target and Range, and, removes the expected variation due to differences in subgroup size.

These three coding methods will account for every short run situation that you are likely to encounter. Let me know how they apply in your situation. Use the ShareThis button below to mark this page, or leave a comment, tweet me, schedule a conversation, or call 800-958-2709.

Lately I’ve been hearing more and more interest in Short Run SPC (Statistical Process Control). Maybe it’s because of the economy, or maybe it’s because more manufacturers are adopting lean production techniques with goals for Zero Setup Time. Whatever the cause, more manufacturers seem to be shifting to shorter and shorter production runs.

Some people jump to the conclusion that they can’t apply SPC with runs of any one product that are shorter than, say, eight or ten hours. In my experience, this is because they’re thinking only of Variable SPC, or because they’re thinking the “P” in SPC stands for Product instead of Process.

The problem, of course, is that when you base a control chart on the product, you may plot a series of points for a couple hours, and then put the chart away for a couple months until you run that product again. When you pick up the chart again, the first set of points you plotted have almost nothing to do with  what you’re doing today. You end up with a stack of meaningless charts with mostly meaningless and disconnected data on them.

In most situations you can eliminate this problem using what I like to call “clever coding” techniques. I’ll describe these techniques in more detail in another post. Right now I want to explain when you can and can’t use clever coding.

The basic rules are that you can use clever coding whenever you can explain all the expected variation between any data you intend to place on the chart, and the process that produces the product is essentially the same.

By these definitions, clever coding is perfect for:

• Processes that use the same tool. For example, the overall length for several products where the length is set by adjusting a stop on the machine.
• Many electronic tests
• Fill weights
• Hardness, durometer, density or some other physical property

You won’t be able to use clever coding to mix features on a control chart if the process is producing very different key characteristics. You can’t use a Short Run Variables Control Chart to mix data from, say, an outside diameter followed on the same chart with a weight, and then a cycle time. The chart has to have some consistency.

If you have short production runs making unique, one-of-a-kind products then you probably need to shift to defect (attribute) data.

In an upcoming post I’ll look at the coding methods in more detail. Until then, use the ShareThis button below to mark this page, or leave a comment, tweet me, schedule a conversation, or call 800-958-2709.

I’m tickled that The Elkhart Truth picked up our story about our tree planting project today. With Arbor Day coming up this Friday they devoted part of a page to local efforts to support trees, and our story was the lead.

When I announced the tree project in this space, I mentioned that I would come back later and share another baby step we’re taking to reduce our carbon footprint. Compared to all those trees, this one seemed small - almost trivial. But then I ran the numbers and it turns out that this one small step cut our electrical consumption by 16%. All of a sudden it didn’t seem so trivial after all.

Back in early February I started writing down the reading on our electrical meter every morning when I got to work. I subtracted the prior day’s reading to get the amount (in Kilowatt Hours) that we used the prior day.  If I missed a day (or the weekend), I just took the difference and divided it by the number of days to get the average rate for the period.

After about a month I pasted the data into GainSeeker Suite SPC Software and came up with this chart:

I also calculated the average daily cost and sent out this memo to my staff:

Here is the challenge: Lets pay attention to your own personal habits and see what we can do to chip away at our electrical consumption. Here are a couple of things you can do:

• Turn off monitors and desktop pcs on evenings and weekends.
• Minimize use of space heaters.
• Unplug any chargers or DC devices that aren’t actually charging anything. (An AC/DC charger consumes power if it is plugged in and not charging anything.)

You may have other ideas. Please try them out.

There are certain computers (like our servers) that need to be up all the time. But lets see what we can do if we try these minimal steps.

I’ll take the difference between now and sometime towards the end of April and buy lunch with the money we don’t give to the utility company. If it is a dollar a day it will be pizza. If it is more, well it will be nicer.

Then we continued monitoring the meter every day. Here are the before and after results on one chart. The Anchor Point (the vertical red line in the center) marks the day the email went out, and the shift in our process.

According to GainSeeker stats, the average daily consumption dropped from 1.9KWH to 1.6KWH. This is a 16% reduction - achieved by something as simple as turning off equipment that isn’t being used!

We had a nice party!

Why is this important? Here are some statistics about my home state, Indiana, of which I am less than proud:

• Indiana produces about 95% of its electricity in coal-burning generating plants.
• Indiana ranks 5th in the nation as the largest producer of carbon dioxide air emissions from electric power plants in the United States (122,094,588 metric tons).
• Indiana ranks 3rd in the nation in terms of the number of metric tons of sulfur dioxide air emissions (responsible for fine particle pollution and acid rain).
• Indiana ranks 4th in terms of the number of metric tons of toxic nitrogen oxides emitted into the atmosphere (responsible for acid rain and smog).
• Indiana ranks 1st in the nation for the amount of carbon dioxide emissions per person from all Indiana energy sectors.

All of this reminds me of the quote that was attributed to Pogo, the famous possum: “We have met the enemy, and he is us.”

So what are you waiting on? Turn off or pull the plug on stuff you’re not using. Its a great place to start.

And while I’m thinking of it, maybe Electrical Consumption needs to be on our list of KPIs (Key Performance Indicators).

What are you doing to reduce your carbon footprint? You can leave a comment, tweet me, schedule a conversation, or call 800-958-2709.

Several years ago I started practicing what I preach, at least when it comes to making better use of data in my business. What did I do that was so radical? I started using control charts to track my key business metrics. Imagine that!

We set up a simple data entry process that my controller uses. It takes him a few seconds once a month to key in a few numbers at month end, and again every other week after cutting payroll and payables. And there is another set of numbers that we automatically extract from our call center system.

My key metrics are around revenue from a couple of sources, expenses in a couple of key, controllable categories, cash, profitability, and the number of open support calls. It isn’t perfect, but it gives me a view into the business that I would not want to live without.

Sample KPI Desktop from GainSeeker Suite

I really like the control chart format. It is such a knowledge-rich way to look at data. I know there are people who claim they can look a column of numbers and understand them. When I do that, my brain goes numb. But I find the graphic representation of data on a run chart very easy to follow. In a glance I can see the history and any statistically significant shifts in the process. I can also group data by time period so it is easy to compare quarter to quarter, or year to year.

I implemented this long before we introduced a dashboard module for the GainSeeker Suite.  I’ll get in trouble for admitting that in spite of all those cool dashboards, I still prefer the control charts.

How do you look at KPIs? What are the KPIs that matter in your job and your business? Comment, tweet me, schedule a conversation, or call us at 800-958-2709.

Dr. Neil Polhemus, CTO at StatPoint Technologies (and publisher of StatGraphics) contributed a great article in the current issue of Quality Magazine about selecting statistical software for Six Sigma. In it he lists four criteria for selecting the right statistical package:

1. How strong a background in statistics does the typical operator have?
2. What types of data are operators most likely to encounter?
3. If data are mined for information, how easily can multiple approaches with multiple options be tried?
4. How easy is it to create a report or presentation that can be shared with other colleagues?

I’ll answer each of these questions for GainSeeker Suite before the end of this post, but first I want to surface an unspoken assumption in the article and add a couple of criteria that I think Dr. Polhemus missed in his list.

The unspoken assumption is that one statistical package will serve all the needs of a Six Sigma deployment. My experience is that there are at least two broad categories of statistical software, and each has their place in Six Sigma.

Two Categories of Statistical Software

One category of statistical software is Advanced Statistical Analysis tools. Dr. Polhemus’ article outlines criteria for this group. Products in this category include StatGraphics, Minitab, JMP and others. These systems were developed (originally) for statisticians. Often Black Belts (BBs) and Master Black Belts (MBBs) depend on these packages for in-depth work in the Analysis phase. These systems are less useful for selecting projects. For the most part they operate poorly in the Control Phase. Put another way, these tools are of less use to the Champions and Business leaders who charter projects, and also of less use to Green Belts (GBs) and Process Owners who inherit and live with a project when it is completed.

The other category of statistical software is what I call Real-time Enterprise SPC Solutions. It will come as no surprise that GainSeeker Suite falls into this second group. This category comes out of the Real-Time Statistical Process Control (SPC) world. These packages are designed for ongoing data collection and analysis in a continuous improvement (kaizen) environment. These tools are, first and foremost, a tool for process owners and Green Belts. They are also tools for Champions and Sponsors (business leaders) who are chartering projects and driving business performance.

While there is some overlap between the two categories, they are more complimentary than competitive. In fact, they should readily share data. Data should be especially portable from a Real-time Enterprise SPC solution to the Advanced Statistics Solution. That way BBs and MBBs can readily tap into the enterprise data sources to support their efforts.

So here are the additional criteria that you should look for when you’re selecting a Real-time Enterprise SPC System.

Criteria 5: What does it take to get new data into the system?

Advanced Statistical Analysis Packages begin with an assumption that data are in a file, in rows and columns. In this view, data are static: generated once, analyzed in some way and then saved in a folder somewhere. Real-Time Enterprise SPC Packages assume that we are tapping into a live stream of data. Each new data point contributes to our understanding of the process. (Some of the Advanced Stats Packages are beginning to recognize this, but their core competency is in analyzing a static data set.)

The ability to readily incorporate new data is what makes Real-time Enterprise software so effective in the Control Phase. Users set up automatic data collection once and then monitor the results for exceptions.

Keep in mind too that the system should collect data at all levels of the organization. Good systems will make it easy to collect and manage data from the shop floor to the executive suite. This makes it easy to capture high levels of business metrics which can be used to help prioritize projects.

When selecting a statistical package, be sure to ask:

• Can the system tap into any data source, including front-line process owners, gages, a wide variety of text files and databases, PLCs, PDAs, cell phones, and so forth?
• Can the data entry process be controlled so that only valid data can be entered into the system, in a reliable and repeatable way?
• Can data be collected automatically and without human intervention?
• Is it easy to set up and manage these data collection processes to meet all the various needs across my business?

Criteria 6: Does the system automatically test new data for real-time process shifts?

Real-time doesn’t just refer to the process of connecting to data sources and readily incorporating new data. It also refers to statistically evaluating all new data for expected variation. This is an essential tool for understanding processes. If the system does detect a change or shift, it needs to automatically communicate that to people and systems that can do something about it.

When selecting a statistical package, be sure to ask:

• Does the system automatically detect process changes using appropriate statistical tools?
• Does the system automatically let me know there is a shift through email, pagers, on-screen displays, or other appropriate means?

Criteria 7: Are Data Stored in a Robust Relational Database?

The word “Enterprise” in our category name (Real-time Enterprise SPC Solutions) tells us that we’re not looking for a point solution. There are some fine packages out there that do SPC with Excel spreadsheets. But these programs can create a data management nightmare when you are managing all the data in your business (not to mention the risk of defects being introduced in a spreadsheet environment).

An enterprise system builds a data warehouse in a relational database. This makes it possible to tap into a rich data set for selecting and prioritizing new projects. It also makes it easier to share data (and best practices) across the organization.

When selecting a statistical package, be sure to ask:

• Are data stored in a robust relational database structure with a flexible hierarchy?
• How fast are retrievals on large data sets?
• How easy is it to group or segment data?

Criteria 8: How Easy is it to Slice and Dice the Data?

A good Real-time Enterprise SPC System will collect data at multiple levels of the organization. It shouldn’t be confined to the down and dirty shopfloor data.

By capturing this data - along with information about the data - think of it as demographic information - you can slice and dice the data to find opportunities to improve the system.

At high levels it might mean viewing Overall Equipment Effectiveness (OEE) by Line, and then drilling down into various machines or sliced across all shifts. In a transactional environment it might mean tracking cycle times across all offices, or within offices by customer service rep. Being able to easily slice and dice the data makes it easier to understand the relationship of all the parts.

When selecting a statistical package, be sure to ask:

• How easy is it to drill into various subsets of the data?
• Are automatic analysis wizards available to help prioritize and focus your attention on the critical variables?
• Can you data be rolled up into dashboards and other high level summary views for easy monitoring?
• Can data be easily tagged with demographic information?

These additional four criteria are a good starting point for rounding out your tool box of statistical software for Six Sigma.

Additional information

For more information, check out these white papers and case studies:

• Freeing Six Sigma from the ‘Data Shuffle’
• Data grouping and drill down
• Walking the talk - How Micropump built a comprehensive data system to empower their people with data
• Aberdeen Lean Six Sigma Benchmark Report
• The Role of Real-Time Data in Improving Profitability and Customer Satisfaction
• Building a Six Sigma Measurement System in Financial Services

How GainSeeker performs against Dr. Polhemus’ criteria

I promised at the start of this post that I’d address how GainSeeker Suite performs against Dr. Polhemus’ criteria.

1. How strong a background in statistics does the typical operator have?

GainSeeker Suite serves a wide population of users, and assumes that the typical user has little or no background in statistics. Furthermore the system assumes that the user has many other tasks to perform besides statistical analysis.

2. What types of data are operators most likely to encounter?

GainSeeker Suite is targeted for engineering and manufacturing applications. The product is in use in some purely transactional environments too. The system isn’t particularly robust for managing survey data, but does very well with cycle times and defect/error tracking. The system is not designed for the R&D community.

3. If data are mined for information, how easily can multiple approaches with multiple options be tried?

GainSeeker is an interactive system. Users do not need to write programs that are submitted for execution. Having said that, it is not intended to function as an advanced statistical tool. Instead it readily ports data to other software systems including advanced statistics packages. Of course Gainseeker is an excellent tool for automatically updating databases and analysis.

4. How easy is it to create a report or presentation that can be shared with other colleagues?

GainSeeker pays particular attention to sharing data, analysis and reports with various user communities. Users can access data over the web, including mobile devices, and output can readily be delivered by email. In addition, GainSeeker includes a new Enterprise Dashboard module that provides easy-to-understand role-based summary knowledge.

What do you think? Are there other Critical to Quality Characteristics that we haven’t mentioned?

In my last post I described an interesting conversation with a customer about his company’s pilot deployment of GainSeeker Suite. You may recall that because of staff turnover, this plant was collecting data but not doing anything with it. The company was feeling pressure from a significant increase in raw material costs, and because nobody in the business knew how to use GainSeeker (because of the staff turnover) GainSeeker was not helping them reduce costs.

I had sat down with the corporate staff guy and the plant quality manager. We had started to review some of the data she had been collecting and used GainSeeker’s Analysis Wizard to drill down on the data and found that Shift A had the highest variance among three shifts, and the six or eight operators on that shift had very different results. (Click on the chart to expand to full size.)

Once we had this chart displayed on the screen, I right-clicked on the chart and then selected the ‘Control Limit Legend’ option. That displayed a list of the 8 different operators, along with the mean and range (with related control limits) of the data for each operator.

Here is how we interpreted this table, along with the chart:

It is clear that one of these operators (710) has a very different process. When you look at the control chart for this operator it is much more stable than the other operators, and when you look at the average for each of the operators, Operator 710 is running at about 173.4g compared to as high as 174.9 for some of the others. (See the yellow highlighted cells in the table). That’s a shift of about 1.5g.

Now here is something you need to know: the critical dimension is weight. Weight is critical because a minimum weight has to be met, but anything heavier than the minimum is given away - the company doesn’t get paid for it. So getting as close as possible to the minimum will reduce material costs - substantially.

How much?

We went out to the internet and found a site with typical raw material prices for this commodity. At the volume they were running, the difference between Operator 710 and Operator 214 came out to $457 per day. This is a 24/7 operation, so the annual cost savings between the two adds up to $166,861. And this only one line. This plant ran nine lines. So across the plant the potential savings of over $1.5 Million.

Who was the comedian who said “A million here. A million there. Pretty soon we’re talking real money?”

The other thing that will be obvious to you if you click on the chart is how much more stable the process is in Operator 710’s hands. Operator 214 would be foolish to try to adjust his average down because with the variation he is running, he’d be below specification too often.

Operator 710, on the other hand, could shift his process closer to the lower specification without jeopardizing quality.

So actually the impact could be even greater because the lower specification is 167.6g. If the process is tightly controlled with minimum variation, you can shift it towards the lower spec, reduce material consumption by as much as half a million a year!

Here is another way to visualize what they’re trying to do:

So is there money to be made here?

Looks like a safe bet to me.