To a black-belt, looking at problems from a SIPOC point of view comes naturally… creating process flow maps, identifying potential inputs, identifying internal and external customers, etc. These activities are (or should be) core to implementing a given black-belt project. To an engineer that has not been though six-sigma training, many times these processes are not explicitly followed, but rather the inputs are assumed in some way. These inputs could be assumed based on experience, process knowledge, or even only by what data is available. To the integrated black-belt, these assumptions can lead to frustration when interfacing with an engineering problem-solving team.
In order to bring the team together, its important for the integrated black-belt to let his/her leadership get the team past these assumptions. One way to do this is to challenge the assumptions brought forth by team forcefully, yet eloquently.
A typical conversation between a product engineer and an IBB (integrated black-belt in manufacturing) may start like this:
Product Engineer: The design allows a +/-1 mm deviation from nominal and currently the widgets are out of tolerance we all know that this is causing the problem with the final widget assemblies.
How the IBB responds to this concern is dependent on the circumstances, however there are two basic ways: immediately defensive or immediately inquisitive. A defensive reaction in this case almost always builds a wall between team members, and gives the impression that you’re not a team player. However, this reaction is natural, since as an IBB, you immediately question weather or not your product development colleague has considered the pertinent inputs to the problem.
Ive found that the inquisitive approach almost always yields better results. Your colleague may be absolutely right. Build a mutual trust with your colleague based on the fact that you will investigate the issue from the process side and give an update at the next meeting. Before then, perform your analysis if solid data is available using the appropriate tools (tolerance stack-up analysis, ANOVA, etc) to isolate the potential causes and bring those to the table. If solid data is not available (poor R&R, etc), then bring that fact to the table. In either case, take the time to illustrate the methods you used to draw the conclusion(s). This will allow the whole team to learn new methods of root cause identification.
And above all else, if your colleagues statement is correct, then begin activities to improve the process as soon as possible without delay. This will build even more trust and the beginning of a good working relationship with your colleague.
I’d like to hear about some of your experiences with IBBs and how the interface works with the non-trained population. Please share your thoughts.
