| by David Ginsberg |
| The electronic procurement and assembly industry has a variety of complex challenges: Short product lifecycles, complex bills of material, volatile demand, non-existant or inaccurate forecasting, demanding customers, component obsolescence, material lot sizes in excess of customer requirements frequently changing supplier leadtimes, and a never ending stream of engineering changes to the bill of material and approved vendor list (AVL). All of this combines into a soup called “ERP”. |
ERP, together with the MRP engine it encompasses, was supposed to crunch all these numbers and tell us the right part to buy at the right time, the right delivery of that part, the right start date and quantity for the assembly, and the right completion date for that assembly. The problem is that ERP crunches data, not knowledge. To the computer, a bad number and a good number look the same. By the end of the ERP/MRP process, compound levels of bad data have been intermixed with the good data. It is left to the users to police, react, expedite, return and churn. The value added is not very high on these activities. Often this “formal system” trains the users to get the job done through informal processes or going to “the right person.”
If there is any chance for manufacturing systems with millions of pieces of data and hundreds of thousands of transactions and updates to coordinate hundreds of workers and thousands of activities; then the data must be accurate. This is old news and not very exciting. |
| The old way of accomplishing this was to print out volumes of reports for human beings to mark up and enter back into the system. Then do it again and again. Each week the report would be printed. Each week, hopefully, someone would have the time and expertise to fix what was broken. Each week more broken data would require the same fix to the same criteria by the same person with the right knowledge. |
| The obvious question is “If we know how to identify and fix the bad data, why not define the fix and have the computer do it before it ever has the chance to affect any downstream process or decision?” What if each time we were burned by bad data causing us to make an incorrect decision, we defined the problem in a way that a computer can understand it; and then turned the computer on itself? |
| The knowledge used by human beings on the back end, can in many cases be defined to fix problems on the front end. This is accomplished through 3 methods: |
- The data in the computer can fix another piece of data elsewhere in the computer. For example, perhaps a standard cost can be pulled from the first or most recent purchase order.
- An expert can define the if/then conditions to be run as a routine script in the database: For example, if the leadtime is zero for a purchased part, set to 8 weeks for now so that MRP will run correctly; then dial in the exact number later as it becomes known. Variations can be thought of by commodity classification or integration to the supplier’s database.
- Exception reporting: Last, and least preferred are paper reports and web alterts. These must be kept to 3 pages or less; as most employees do not have time to go through massive tab-runs and corporations can’t afford larger staffs for this type of activity. Define what matters deliver it succinctly and monitor that it continuously improves over time.
The results can be amazing. Some of the more tangible real-world benefits have been the elimination of most shortages, false expedites, over/under builds, and the need for status meetings. Why meet when the data is real time, accurate and being acted upon? The few fires that remain are real, and everyone knows they are real. They get undivided attention and support.
|
Use the computer to fix the computer. |
NOTE: Silicon Valley contract manufacturer Sonic Manufacturing uses this system across 30 end customers and 15,000 active MRP part numbers; and for 10 years has not required a shortage meeting. Everyone obtains accurate status off of Expandable in real time. |
Exceptions and expedites beyond the data/plan are then communicated in real time between people; no meeting required. |
About the Author |
| David Ginsberg has been an Expandable user since 1994 and has deployed the system at five technology companies and two contract electronics manufacturers. David holds an MBA and CFPIM and is a technical advisor for supply chain integration providers. You can read more from David Ginsberg at CounterOps where he blogs about issues related to operations and supply chain management (http://counterops.wordpress.com). |
|
|
  |
|