consists of defining the data in an accurate, but too detailed
manner. Defining routing steps that are really suboperations of
major operations, placing part number levels that are not needed in
the bill of materials, and loading individual work center data for
every piece of equipment in the plant are examples of
project team loaded a five step routing with an
additional 15 steps that were really elements of the five major
steps. This resulted in detailed information that appeared
desirable in their conference room pilot. In actual practice,
however, the extra reporting requirements placed an enormous
burden on the operators. It also greatly confused
the information on the dispatch lists and capacity plans. No
one believed that the value of the information was
as great as the cost of reporting, so the timeliness and accuracy of
the data deteriorated. Soon, the reports based on
this data became unusable.
wants their data to be accurate, but some carry the
drive for accuracy too far. This can result in excessive reporting
requirements, unstable schedules, unnecessary systems
modifications, and users' unwillingness to use the systems.
Precision overkill includes providing too much detail for making
gross level decisions, measuring and changing
planning data and factors too frequently, creating
too many categories for reporting activities, and using units
of measure that are more precise than necessary.
their request for proposal sent to potential software
suppliers, one company specified a requirement for over 50
different "hold" status codes to identify the different
reasons why an order could be stopped in manufacturing,
ostensibly for the purpose of performing a Pareto analysis
and fixing the problems causing these interruptions. The real
reason for the requirement was that these codes
had been modified into their current system and they wanted
the same capability in their new one. Investigation showed
that the manufacturing and quality control people
entered these codes had for several years been using only four of
them and ignoring the existence of the other forty-six.
The people who were supposed to analyze the data from these reports
were also not using them as intended.
It is easy to see how the new system could become complex
as a result of requirements like this.
Tools that do not fit the application—Sometimes
software tools that are not needed are installed. Sometimes
the wrong tools are applied to a given task. "Since
it is in the software, we might as well use it," is a statement
that has led to added work for little benefit in more
than a few companies.
of a large assembled products manufacturer agreed to be responsible
for the Sales and Operations Planning process and the capacity
that accompanied it. The people responsible for presenting
the capacity information in these meetings believed
that the management team would rather have the more
accurate and detailed Capacity Requirements Plans generated
from their shop floor control system than the rough cut Resource
Requirements Plans included with their
S&OP module. They presented a 350 page CRP report with
weekly details for every work center in the plant at the monthly
S&OP meetings. Management soon stopped trying to make
capacity decisions in these meetings and delegated
these decisions as an post-meeting responsibility
to Planning and Manufacturing.