Six Sigma Round-up
Posted by: meikah | 16 January 2007 | 11:29 pm
Today, I made the rounds of Six Sigma blogs to know the what the other blogs are saying about Six Sigma, Lean Six Sigma, or other quality strategies.
Over at iSixSigma Blogosphere, Sue Kozlowski plans to write a book, which she will title The 27 Lean Six Sigma Leadership Secrets of Abraham Lincoln: Uniting your organization to a common purpose. Sue shares her remarkable observations of how management and leadership books are titled: some number and, to use her term, leadership-oriented nouns. I say go for it, Sue!
Six Sigma Blog reminds us what Six Sigma is: a disciplined, data-driven approach and methodology for eliminating defects in any process. Failing to understand the concept of Six Sigma, an organization cannot begin to work toward near perfection, or so it says. Well, Six Sigma does not necessarily promise perfection at the end. Instead, it promises continuous improvement. An organization becomes aware of its processes, the defects, and will be on the look out to improve every non-comformant along the way.
Lean Six Sigma Blog poses the questions: Why do Lean Six Sigma consultants continue to deliver training using an inflexible batch method that also carries the highest cost? Shouldn’t Lean Six Sigma methods be used to deliver Lean Six Sigma training? There’s a point there. There is an underlying issue on which method is more effective and less expensive, online or classroom training. Espousing on lean, these trainings should be streamlined (i.e., be lean) to get the most out of one training.
And for some Six Sigma statistics, Quality Hero is giving a sample t-test. It is simply presented and explained that renders the information very useful.
Filed under: Lean Six Sigma, Training, Data, Statistics, Six Sigma References
No Comments » |
How Six Sigma Treats Data Mining to Improve Processes
Posted by: meikah | 7 November 2006 | 12:07 am
Time and again, we say that data and data mining is crucial in Six Sigma deployments.
Today, let me share with you five brief case studies of trucking companies that are hitting their numbers right. eTrucker.com features:
Case Study 1
Pitt Ohio Express, Pittsburgh
In 2001, Pitt Ohio Express began building a business intelligence tool named Cube-IT, which gave the less-than-truckload carrier new insights about the profitability of each customer. In the past three years, the company has eliminated $40 million in unprofitable business while significantly growing overall.“From my view, this whole business intelligence platform allows us to bring together all of our customer information,” says Scott Sullivan, vice president of information technology services. “We are moving to be a more customer-centric organization. We no longer give general rate increases.”
Case Study 2
Bison Transport, Winnipeg, Manitoba, Canada
Bison Transport developed a homegrown program called the “Order Ferret” that provides management an analysis tool to make complex pricing decisions on the spot. Users click on an Order Ferret icon while working in the central dispatch screen to bring up a grid of various pricing and profitability data.“We can make decisions based on real data, as opposed to estimates or guesses,” says Dave Fulawka, director of business development. “You’re not just eyeing a graph or trend. Your decisions are more precise.”
Case Study 3
B.R. Williams Inc., Oxford, Ala.
Wanting to assess profit on a trip-by-trip basis, B.R. Williams in 2002 developed a database and analysis tool using Microsoft Access that helps it make quick changes in lane pricing due to varying external factors, such as toll expenses, fuel prices and backhaul rate.“We are soliciting more freight in certain lanes because they are more profitable,” says Greg Brown, president. “We know now where our niches are, and we solicit around those lanes.”
Case Study 4
RayTrans Distribution Services, Matteson, Ill.
By integrating two separate databases — a custom transportation management system and a software-based phone system — RayTrans has identified patterns in how successfully dispatchers in its brokerage division use their phones. The company also monitors profitability by day at multiple levels — by terminal, department, dispatcher and truck.“Once you get profitability by day, you can really tune your operations,” says Jim Ray, president.
Case Study 5
Shaw Industries Group Inc., Dalton, Ga.
To guide its data mining efforts, fleet managers at Shaw Industries follow Six Sigma methodology, which companies use to analyze the efficiency of any process. Shaw’s analysis begins by converting all cost variables into a common metric — performance per pound of flooring — to help managers identify top and bottom performers.“Essentially, that’s why we do Six Sigma,” says Randy Black, e-business manager. “Measures fluctuate based on the volume of shipments, but over time you see trends because we unify shipment data to the poundage level.”
*Photo credit: MorgueFile.com
Filed under: Benefits and Savings, Services, Data
No Comments » |
Lean Manufacturing and Six Sigma
Posted by: meikah | 4 July 2006 | 11:37 pm
There has been a lot of talk about going lean and combining it with Six Sigma. Some even doubt that these two can actually work together, and is there proof that they really do?
Personally, I see no reason why the two can’t work together. Both are about streamlining, thereby reducing waste/defect to improve processes for the ultimate customer satisfaction. This scenario is most visible in manufacturing companies. One industry that is working toward lean manufacturing and going Six Sigma is the pharmaceutical indusrty.
Just recently, Pharmaceutical Processing’s Editor-In-Chief Mike Auerbach moderated a live webcast titled Lean Manufacturing, Gaining Efficiencies and Maintaining Compliance on the Plant Floor. The panel included Bill Fitch, VP of Life Sciences, Business & Decision, who discussed how pharmaceutical manufacturers can implement lean and maintain regulatory compliance; Dr. Pankaj Mohan, Manager of Global Process Engineering at Eli Lily & Company, who talked about his firsthand experience in implementing Lean Six Sigma in a pharmaceutical production environment; and Dennis Constantinou, Senior Director of Life Science Industry Strategy at Oracle Corporation, who discussed how information technology can help in a lean enterprise transformation.
I picked up pieces of information from the excerpt that link lean manufacturing with Six Sigma.
Mike Auerbach: Bill, can you give us an example of where process improvement potentially conflicts with compliance?
Bill Fitch: That’s a good question. When we look at the value of making a change to a manufacturing process, we need to evaluate if it is a minor change or major change. If it is a minor change, simply identifying how that change impacts the quality aspects and safety aspects of the medicine, and then providing a report to FDA at the end of the year will be satisfactory. However, if it is a moderate or major change, that would require a supplement to be submitted to FDA. So at the end of the day, you need to evaluate the change that you’re making and the potential challenge that it causes from a commercialization standpoint, especially if it is a product that is already currently on the market.
Mike Auerbach: Dr. Mohan, do you think that value stream mapping is the foundation in all lean environments, and how does value stream mapping link with the DMAIC process?
Dr. Pankaj Mohan: Well, the value stream really sets or fills the hopper that feeds the DMAIC process. So instead of just doing this in a non-structured way, a value stream map can thus provide a very structured and a critical way of thinking through the whole process before you actually begin the process.
Dennis Constantinou: I’d like to comment on that. Before anyone begins any lean initiative, we really need to have an understanding of our business processes. And those business processes need to be highly defined, and not only take it from a business process, but expand that to an entire value plan. We need to be able to do that and have that highly documented and be aware of those processes to the nth degree in order for us to go in and implement any type of solution. Thereby, we can go in and even perform that cost benefit analysis that you were talking about, and being able to do that. Without that, I find it will be very difficult to approach a lean initiative in any kind of structured manner.
Mike Auerbach: Is software validation at the enterprise level and manufacturing data gathering level a stumbling block to implementing IT solutions with lean and six sigma?
Bill Fitch: I would say absolutely not. Does it add additional complexity? Well, sure. Whenever you make a change, you have to deal with evaluating, taking your worst approach and looking at what the current system is, how the system supports the business to make a determination if revalidation is necessary or not. But I think that is something that is inherent in the business and those changes are something that have to be dealt with. Simply being pragmatic about it is the way that you need to approach it.
Dr. Pankaj Mohan: I personally feel that there is no lack of data collection. We can collect collectively in this industry a lot of data. The challenge is to convert this data into knowledge. That is where the various levels of data technology interaction happens. I think that the key challenge is basically taking the data forward and converting it back into useful knowledge that can help lean and can help the process.
Mike Auerbach: How do you reconcile the massive amounts of paperwork generated during validation with the concepts of lean manufacturing?
Bill Fitch: That is a difficult one to reconcile because obviously the very exercise of validation is rigorous development of documentation. So I don’t really know if you can apply the principles of lean to validation. Again, it is a set of discreet activities and different types of documents that have to be put together to show evidence/proof that a system has been developed, tested and functioning and operates for its intended purpose. Unfortunately, you can’t do that with less documents. However, you can take a risk-based approach and be pragmatic about it. In the old days, people would validate all of the functionality of a system. Now the approach is slightly different in that we identify where the regulations impact the functionality or how the system is used. And we’re able to scale validation accordingly, so we don’t do necessarily testing of everything. We don’t conduct the same types of tests on all of the different functionality aspects of the system. So, I guess in a way, I don’t know if I would call that lean, but it is pragmatic.
Dr. Pankaj Mohan: I mean, I personally feel that the validation is crying to be leaned. Many companies have taken a lot of initiatives. I think the key here is to kind of set up the framework with risk-based approach, and then have an efficient documentation trail and execution protocol.
Here’s the entire log of the webcast.
Filed under: Tools/Toolkits, Manufacturing, Lean Six Sigma, Data
No Comments » |
Does Data Mining in Six Sigma Have Privacy Issues?
Posted by: meikah | 28 June 2006 | 7:50 pm
There could be. After all, these data include that of their customers, suppliers, and their own. I believe this information is important and private. Read about privacy of data on Global Business Watch today.
Filed under: Data
No Comments » |
Checking on Six Sigma Data
Posted by: meikah | 29 May 2006 | 2:10 am
A major component of Six Sigma is data, or data mining. In fact, acquiring and storing good quality data is the key to a successful Six Sigma initiative.
Several months ago, I wrote about certifying data through Six Sigma. I mentioned about establishing data standards through service level agreements (SLAs) and administering them by an organized data governance structure. However, before you can do this your data must have some of the following typical metrics: accuracy/precision, completeness, reliability, availability, timeliness/freshness, consistency, and uniqueness.
Now, let’s assume that you have certified data and you’re well on your way to your Six Sigma project. How then do you ensure that you have quality data through and through?
You can ensure data quality (DQ) in two ways: off-line and in-line.
The off-line DQ process is run outside of the certified data production process, while the in-line DQ process is run in synchronization with the certified data production process. The relationship between the two DQ processes is shown in figures and comparative analysis here.
After doing the DQ, it’s now time for you to take action. You can do two processes that ensure your DQ is indeed measurable.
1. Scoring: This process focuses on evaluating the metric data captured in order to provide a measurement (score) of the degree of the data quality. This score is published with the data and available for use in reporting so the end data consumer can understand the degree of confidence that can be placed in the data.
2. Monitoring and control: This process focuses on capturing and dealing with the metric data that is captured during the measurement processes. The emphasis here is data quality and process improvement. This is a straightforward process for determining a course of action to take based on a set of parameters and rules. During this process, the following sequential steps are executed:
- Collect: The monitored data points are collected and stored. The storage may be temporary or persistent.
- Classify: They are then classified and categorized based on the type of check performed, the priority of the data quality check, and user-selected data quality attributes.
- Detect: Rules are executed based on the classification of the data quality data points. If a data quality fault is detected, an action is taken.
- Act/control: If a fault is detected, a sequence of one or more actions is initiated. These may include providing e-mail notification, fixing the fault, aborting the data quality job stream or continuing with the job stream while noting exceptions.
- Log: The detected fault and the resulting actions are stored in a log file that can be used for auditing or analysis.
By going through these steps, you are not only gathering data but already you are also evaluating the kind of data you have. With high quality data, you can then so statistical process controls and other statistical tools en route to improving your processes.
Below is an example of a real-world Six Sigma DQ process.
A major U.S. financial institution is well on its way to implementing a data quality/certification process across all of its enterprise data, which currently comprises 80 sources. The first step in this process was driven by the bank’s regulatory compliance requirements. The bank needed to supply Sarbanes-Oxley compliant demand deposit transaction data to its finance data warehouse where data is aggregated, analyzed and used for reports to management, regulators and investors. As part of the assurance process, this data was processed through a data hub where the mainframe-supplied demand deposit transactions are extracted, converted, and transformed into a form usable by the bank’s financial accounting system. In addition, a robust monitoring and control process was used to implement the tights rules and thresholds required by the bank for detecting potential faults during both profile and process checks:
- Collect: The numbers of records and bytes are captured after key lookup and aggregation steps. A user-defined check of total average monthly balance is also calculated and monitored.
- Classify: These data quality checks are classified as high priority/alert checks.
- Detect: Values are compared to a moving average of previous months’ values. If the values deviate greater than 5%, a fault alarm is raised.
- Act/control: If a fault is detected, an alarm is raised and a message is sent to both system operators and data analysts familiar with demand deposit data transactions. Further processing is stopped until a resolution is reached, which may be a decision to continue processing or to correct errors and re-initiate the transformation process.
- Log: The data quality check point values, the fault and any subsequent actions are logged.
Source: Six Sigma Data Quality Processes




