comment 0

How to Identify Potential Continuous Improvement Projects

There’s an old business axiom that if you want to find a business idea, truly listen to the complaints of others because the solution to that problem probably has a market. And something similar can be said about continuous improvement projects, though there are additional questions you should ask before investing company resources.

To quote Dr. Jordan Peterson, before you decide what problems to solve, notice what bothers you.

First, pay attention to what bothers you. If you can’t actually name the problem, you can’t solve it.

Second, be careful of who and what you’re identifying as the problem.  You might be blaming the easiest target instead of the actual one, and there are times that we blame the official, approved target instead of the actual root cause.

And if you make the problem too broad, you can’t really solve it. “Precision may live tragedy intact but it chases away the ghouls and demons.” If you blame “management”, “the economy” or an “ism”, you’ve made the problem too big to be solved. Nor do you want to destroy everything, including what works, in the name of fixing the real, small problem. You can address problems like a product that doesn’t fit customer expectations anymore or researching new niche markets that use your product.

Third, ask “Can you fix it?” If the answer is no, ask who could solve it. There are times where the problem requires enlisting help to solve, whether you need to redesign the product or take the issue to your supplier. If the answer is “no one”, then look for something else until you find something you can fix.

Fourth, consider the return on investment for fixing the problem. It isn’t worth spending a hundred thousand dollars trying to fix a problem that wastes thousands of dollars of material. Nor should you invest hundreds of hours fixing minor annoyances unless these issues truly impact the bottom line.

Advertisements
comment 0

The Quality Habit, a Reflection

“Quality is not an act, it is a habit.” I’ve heard this quote attributed to Aristotle, though there is some debate about this.

Another variation of this quote is “We are what we repeatedly do. Excellence, then, is not an act but a habit”. But what does this quote mean for industrial engineers?

 

Habits are learned behaviors, something you intentionally start out doing and then maintain. Introducing best practices doesn’t matter much if you don’t implement them and stick with them.

 

Habits can affect one’s overall behavior, but it is that behavior that determines culture. That’s demonstrated by the axiom “One’s actions are a better indicator of beliefs than one’s words.” Management saying quality is number one is irrelevant if day to day decisions are contrary to that mantra. Conversely, management and employees whose actions are consistently of high quality and people mindful of such can maintain quality in operations and service delivery even if the culture isn’t specifically hyping it up.

 

Quality only gets better if you get in the habit of looking for ways to improve it and then train the new and improved methods to the point they become a habit. If you don’t monitor during the learning period and “sustain the gain”, people revert to the old ways, their old habits.

Habits can be good or bad. Bad habits can ingrain poor quality, such as shortcuts and rushing through the job. Good habits ensure high quality.

Good habits can become bad habits as things change. You need to re-evaluate your habits to see what you need to stop doing in addition to how to improve on what you choose to continue doing.

IE and BI – the Intersection of Industrial Engineering and Business Intelligence

A classic Peter Drucker quote is “What gets measured, get managed.” A quote attributed to W. Edwards Deming is “You can’t manage what you don’t measure.” Big Data attempts to collect as much information as possible in the hope that the data can be used to make better decision. However, you will still fail if you don’t ask the right questions, give information to the wrong people, fail to give it to the right people at the right time or waste time trying to make sense of it all.

Many enterprises are struggling to manage the firehose of data they’re funneling in, much less mining it for useful information that might be turned into insight (wisdom). We’ve seen a rise in Business Intelligence tools to try to literally make sense of it all. This is leading to a number of changes in industrial engineering and business in general.

Business intelligence expertise is increasingly seen as essential to work in data analysis for manufacturing planning, demand planning and operational decision making.

If you’re going to work in consulting or analytics, job descriptions often ask the candidate to have experience with business intelligence or operation research tools if not both.

Engineers who work in sales or support regularly work with business intelligence experts, if they are not one themselves.

If you’re working as an analyst to improve business operations, you’re likely going to be expected to know how to design, write and publish reports through commonly used business intelligence tools like Cognos.

IT hasn’t entirely replaced time studies.  However, productivity experts regularly use business intelligence tools to study the productivity of different groups and review business operations.

Quality engineers are starting to be expected to know how to write queries of databases and business intelligence systems.

Business intelligence reports may provide leads on aspects to improve or document the changes that have taken place after process improvement projects.

In the case of CMMS and manufacturing systems where nearly everything is tracked by the Internet of Things, business intelligence tools may be how you get the information you need to do your job.

In summary, business analytics is focused on analysis while industrial engineering tends to be focused on improvements, but the distinction is starting to blur.

Quality Assurance vs Quality Control vs Testing

While the terms quality assurance and quality control are often used interchangeably, there are differences between the two disciplines. Likewise, quality control and testing are sometimes used interchangeably, though the terms are not exactly the same thing.

 

The Definitions

Quality assurance is a process designed to ensure a system meets its objectives. Quality assurance tries to design processes that deliver the consistent and correct results every time. It includes verifying processes already outlined are followed. QA tends to be pro-active. Per one Dilbert strip, QA involves telling people how to do their jobs so that they do it right.

http://dilbert.com/strip/2016-09-17

Quality control refers to the activities to evaluate whether produced items and services meet standards. It tends to focus on defects in specific deliverables, checking performance or dimensions against pre-determined standards. QC is, by definition, reactive, because it finds imperfect products after the mistake is made.

Testing is the process of trying to find defects. Testing procedures need to be documented so that they are followed consistently by everyone who receives them. The test plans need to call out the right hardware, software and supporting information needed to follow the same test every time. And they need to be kept up to date as industry standards change, hardware evolves and the software behind many automated testing systems changes. Even things like where you store information on test results and test scripts need to be documented.

 

Quality Assurance vs Quality Control vs Testing in IT

QA in IT ensures your process is defined and appropriate. What is the scope of the project? Do we have a formal test plan? QA is the full software development lifecycle.

QC tries to identify defects in the product. The classic case is the database of bugs found during software testing.  One definition of QC was always executing the program, while QA may involve theoretical or administrative reviews. In the case of QC in IT, you have to run the software to find the ways it doesn’t deliver results appropriately, errors out, or literally locks up.

In IT, testing is running your software and hardware tests. And QC is specifically the software testing life cycle. Test plans should specific the IT architecture and hardware used for testing. After all, putting something on the wrong test bed is going to cause it to get very different errors than if the right one were used.

 

Does Automation in Software Testing Eliminate the Need for IEs in IT?

Quality automation engineers take it one step further and write the code that runs automated tests per various test cases and generates a report of defects.  However, you cannot assume this automation of testing is always accurate or complete.

In one instance, an engineer demonstrated his automated test script to replace manual testing that was going on, and we watched a number of error messages pop up. And because the script was only looking for errors like access control limit notices during the automated test, the dozens of popups generated weren’t recorded as errors by the script. And if the quality automation engineer isn’t clearly told what constitutes a success, you could get events like a report being generated counted as a pass when the report itself doesn’t show all the data or contains other errors.

In summary, no, automation doesn’t eliminate the need to apply quality assurance and quality control to any aspect of IT even if one can automate many tasks.