It's a Numbers Game

There's two ways to skin this cat: direct and indirect. Direct is best when you got a little sore on your knee. Indirect is best when you feel bad all over. Most times, you feel bad all over.
For the "sore knee" scenario, there are a lot of tools you can use. Root Cause Analysis has been around for a while, and it's great for locating problem sources. This starts with a specific symptom (durn widget doodads are too big!) and works back towards sentinel events that caused them (machine set to wrong size)
The problem with some of the "sore knee" tools is that they imply a one-to-one correspondence between part A and part B. Pull on part A, they tell us, and part B goes out of whack. Most times these connections are identified correctly, yet the larger picture is never addressed (we have to pull on Part A because Part C tells us so, etc) Starting to address larger causes leads to "analysis paralysis", where you start taking apart the entire business looking for the Ultimate Cause Of Everything. Which is usually: management sucks! (just kidding! just kidding!)
How about going at it from the other end? List your hundred steps to make the widget, then figure out the top three or four that you need to make better. This has the benefit of being immediately actionable: once you know the 3 or 4 steps you want to work on, there you go. The problems here are: 1) What are my steps for doing my job? (most people don't know), and 2) What's the worst thing we're doing? (Most people don't agree, or if they do, won't tell the boss honestly)
To some degree, you're lucky if you're in software. Most times somebody has made a master list of everything to do (whether it helped anything or not) and stuck it in a manual somewhere. So it's just picking what's hosed up and what's okay.
But you've got a hundred employees. And a hundred steps in your process. Asking each employee about their opinion would mean over ten thousand questions! Not to mention the diagnostic questions: you just don't want to know what to fix, you want to know why its broken. You could easily get into hundreds of thousands of questions.
Let the computer do it. Plug in your magic corporate recipe, mix in some diagnostic indicators to help you resolve issues you find, and add in your people. Now "tag" the people into various groups: managers, workers, testers, internal/external. Let the computer handle the interviewing, the correlating, the math and reporting. Spend an hour or two, nothing more, and get some real data to work with. Then go start working your solution. That wasn't so hard, was it?