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.

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.

IE Lessons from Dr. Jordan Peterson’s Advice

While Dr. Jordan B. Peterson’s advice is widely applicable in a variety of areas, there are snippets that are particularly in line with industrial engineering principles.

  • Make at least one thing better every single place you go.

One way of describing the goal of industrial engineering is “better and better”. The definition of better itself is variable, whether you want it cheaper, faster, using less, or an improved design.


  • Tell the truth.

You cannot solve a problem if it is against the rules or culture to admit it in the first place. You cannot fix something if you aren’t allowed to share solutions or talk to those with the most knowledge about the issue.


  • Assume that the person you are listening to might know something you need to know. Listen to them hard enough so that they will share it with you.


One way to look at this is to give people your whole attention, because the little details and passing mentions may be the most important information … and it is what you’ll miss if you give them half your attention.

Another variation of this is how often people do surveys or solicit feedback only to skim over it, analyze it in aggregate and use intermediaries for what seems like the sake of efficiency.

Early in my career, a manager listened to my advice on solving a problem based on heavy theoretical reading. He replied, “If you want to find the solution, start with the people who are dealing with the problem.”

On one occasion, the seals were falling off a PCB board’s air ducts. I went down to the manufacturing shop, talked to a production head, and he put together a test of wash processes and adhesives on the seals. A line operator assembled the combinations of seals and adhesives on junk boards, we ran the lots through wash cycles, and we found the fatal combination. It took two hours. I returned to work in time for an engineering meeting, where I stood up to discuss the results. Most present had only started to consider how it might be testing. Asking the person with the most direct experience with the process resulted in an answer.

Many assemblers knew short term work-arounds that could be turned into permanent design solutions or had recommendations based on years of experience building, fixing and deconstructing the product. After several years in product development and production support, I was surprised to later find that many engineers were reluctant to talk to those on the shop floor … or even asked me to join in the meeting for my shop floor experience so they didn’t have to talk to the people doing the hard work.

  • Imagine who you could be, and then aim single-mindedly at that.

Burning platform, anyone?


  • Work as hard as you possibly can on at least one thing and see what happens.


Define progress for the moment – faster, leaner, simpler, more efficient. Then apply a fitting continuous process improvement methodology toward that goal. Re-evaluate and sustain the gain. Remember that you can shift the focus after you achieve a goal.


  • Nothing well done is insignificant.

Don’t denigrate small process improvement projects or modest gain in an area. We worship big projects, major wins, ignoring the fact that small, incremental progress can achieve the same or more and with less risk.

This same mentality is why politicians prefer big infrastructure projects over maintaining what’s already been built. Filling potholes and preventative maintenance aren’t as sexy as a new highway or overseeing a major equipment upgrade.


  • Remember that what you do not yet know is more important than what you already know.


It is the problems you don’t know about that are about to explode, hopefully not literally. It is the root causes you don’t realize are affecting your process that have the greatest impact on your quality.


  • Be precise in your speech.
  • Do not hide unwanted things in the fog.

I put these two together because of the tendency to use heavy jargon, whether it is in the hope of seeming more educated and thus justify one’s stance or in the misguided belief that if you rename something, the seriousness of it is reduced. The end result in both cases is confusion as to the issue involved unless you’re up to date on the jargon and often misunderstandings as to the severity of the issue. And sometimes people use the euphemisms and jargon fitting for a Dilbert comic to try to hide the severity of a problem.


  • Notice that opportunity lurks where responsibility has been abdicated.

Need ideas for a process improvement project? Look at the things others have given up on but really wish was solved.


How the IoT Could Affect Industrial Engineering

The Internet of Things is moving from the realm of theory to real world application. This is in some ways the extension of facility monitoring systems that many IEs have worked with to the broader world, while it extends the network to everything else in the facility from back office equipment reporting energy usage to your finished product continuing to send data to your organization after shipment. Here are a few ways IoT could affect industrial engineering.

  • IEs working in industrial automation will need better training in data mining and analysis of data flooding in from the IoT whether detailed reporting from everything contributing to the assembly line.
  • Potential faults and impending failures make manufacturing management much more proactive.
  • If shipped product is able to send data back to manufacturers to diagnose failures, failure analysis becomes a real time skillset and requires stronger customer service skills.
  • If products can report failures to manufacturers the same way computers can send failure reports to Microsoft or Apple, there will be far more data to mine for understanding the root causes of any type of failure.
  • User experience is revolutionized by the amount of information IEs in this field get regarding how systems are actually used.
  • Just as managers need to learn how to use business intelligence software, IEs will need to learn how to use software developed to summarize IoT data and control increasingly self-sufficient factories.
  • Total Predictive Maintenance will become standard and include far more data points and equipment. For example, you’ll need to plan on replacing sensors monitoring everything as well as the equipment itself.
  • Programming and information security become more important to the average industrial engineer.
  • Smart automation will expand from the biggest or newest factories to many more manufacturers.

What would you add to this list?