How Supply Chain Projects Morph Into Black Holes
McVey - October 19, 2002
A black hole is an object whose gravitational pull is so strong that nothing
- not even light - can escape from it. Although predicted by Einstein's
General Theory of Relativity, the existence of black holes in our galaxy
and elsewhere has only recently been confirmed. A black hole forms when
a massive star dies and collapses under its own mass.
all but a few astronomers, black holes are unknown in the realm of ordinary
experience. Analogs do exist, however, in the more terrestrial domain
of business process reengineering and take the form of supply chain management
to their gravitational counterparts, supply chain management implementations
can grow to vast, unanticipated proportions, enveloping unbudgeted amounts
of time, resources, and money. A crucial difference between the two is
that supply chain projects can be kept to a manageable size by making
careful preparations and setting realistic expectations at the outset.
The following real-life examples offer insights that may help prevent
your supply chain project from collapsing into oblivion, taking your enterprise
months into the implementation of a factory scheduling system at a mid-sized
PC assembly facility and one month before going live, planners were asked
to help perform the system test of the application, during which daily
workflow would be checked against requirements.
involved making a survey of the next few days of PC orders, the required
components indicated by the Bill of Materials, and the current inventory
so that new components could be procured in time to meet the demand. Planners
relied on a metric known as "days of inventory," calculated for each component
SKU (stock keeping unit) by subtracting all components needed for each
day of production successively from inventory until the inventory was
exhausted. The number of days that would bring inventory to zero was that
component's days of inventory.
the new system had no capability for computing this value and planners
found that to generate it, they had to page through hundreds of scheduled
orders, sorted by finished SKU, use the software's capability for reverse
BOM explosion to get the components, total the needed components by SKU
in a spreadsheet and then manually subtract the totals one day at a time
from the inventory, also provided by the system. The software selected
for the new system had no capability to produce the required metric. Needless
to state, the manual steps completely derailed the workflow and the planners
Under pressure to finish the implementation, the project team resolved
the system shortcomings by writing a custom report in Microsoft VBA (Visual
Basic for Applications) and Excel. This required four additional weeks
at roughly $60,000 per week:
additional weeks of interviews with planners to understand the metrics
and development work by a VBA programmer
by one additional week of testing by the frustrated and increasingly
spite of the efforts, the completed solution was an unsatisfactory compromise
between mitigating budget overrun and delivering the required reporting
to appreciate the importance of existing reports and metrics to planner
communication between planners and the project team in the early stages
of the project
to adequately screen candidate software packages for advanced reporting
practices that might have prevented the problems
off, the project team needs to prepare a list of detailed requirements
by involving end users and then conduct a careful evaluation of several
packages to find the one that best fulfills them.
- End users,
those who will be working with the new system on a daily basis, should
be included in the project implementation phase early on. Managers need
to give these key users time off from their normal duties to contribute
their expertise to the project. This commitment requires the support
of top management.
prototyping provides a basic system to users who then have a tactile
understanding of what the new system will look like and how it will
- Implementation of a demand/supply matching system for two separate
PC assembly plants, one owned by the company and the other, a contract
- The system was needed to support new channel programs designed to
facilitate replenishment of reseller inventory by allowing resellers
to share requirements via EDI (electronic data interchange). This was
an ambitious departure from existing procedures that relied on telephone
communication between resellers and demand planners.
project schedule was based solely on the start of the new channel programs
without regard to resource constraints. In addition, the supply chain
software vendor gave optimistic release dates for the software to be used,
which were taken as firm by client management.
working 65-70 hours per week, the undersized project team of 15 people
had no hope of conducting a thorough design and test implementation. To
make matters worse, less than three weeks were allotted for receiving
the new server, installing the software on it, and configuring it to run
the software in a live setting. The vendor consistently failed to meet
its expected release dates due to other projects and clients. Resellers
could not keep up with required milestones for the implementation of EDI
three months into the project, almost at the proposed conversion date,
the project team and management conceded defeat.
project timeline was redrawn by factoring in the number of skilled resources
available, realistic software release dates, and firm delivery dates for
the hardware server. Also, the new plan included the development of interfaces
to allow resellers to input inventory and demand data independent of EDI.
The system went live six months after the original conversion date. Estimated
budget overrun: $2.5 million.
- Implementation was squeezed into an overly aggressive three-month
project schedule to support the inauguration of three new reseller channel
- Failure to realize the barriers to be overcome in implementing new
business processes, i.e., obtaining commitments from resellers to share
inventory data with demand planners
Best practices that might have prevented the problems
- Timelines should always be constructed using a bottom-up approach,
where project milestones are determined by the availability of people,
software, and hardware.
- No supply chain management solution will work unless the business
processes it is designed to support are agreed upon by the parties
involved. Obtaining this agreement should be an ongoing process that
starts before the technical aspects of the project begin and continues
through the implementation phase by allowing all organizational entities,
both internal and external, to understand the new changes.
Background and Requirements
multinational semiconductor manufacturer
chain planning software implementation at the headquarter planning division
responsible for creating production requirements for seven wafer fabs
and assembly/test facilities and allocating supply to customer orders
- The new
system was to support four main activities:
- facilitate development of consensus forecasts
- allocate different categories of supply to forecasts and orders
based on business rules
- generate finite capacity plans and schedules to be passed to
- promise orders to customers based on supply allocated from inventory
as well as planned and actual production
to support all four activities were implemented in parallel using a
"Big Bang" approach
the user test, in which headquarter planners were allowed to play around
with the system tested version of the software and make suggestions, the
project team was inundated with requests for additional functionality.
The project team dictated each of these to the software vendor who was
responsible for making customizations to the core software. Not only was
the vendor unable to make all the requested modifications in time, it
viewed the changes as well beyond the originally agreed upon scope. Deadlines
slipped and the development environment became chaotic with all the requested
changes, which caused more delays.
top management finally intervened and put a freeze on modifications to
the software. It also split the project into four phases based on each
headquarter planning activity to allow the project team to focus on fewer
requirements at one time. The last phase of the project was completed
nearly one year after the originally scheduled "Big Bang" conversion date.
Estimated budget overrun: $4 million.
- The client
failed to appreciate the size of the undertaking and tried implementing
the four areas in parallel to save money.
- The client
was unwilling to table new functionality requests for a later release,
causing severe scope creep. Best practices that might have prevented
project scope spans multiple business functions, a phased implementation
approach can be used to reduce the complexity of the project. Lessons
learned in the early phases can often be applied to succeeding phases.
scope should be decided at the outset and adhered to throughout the
implementation. New requirements that arise during the implementation
should be prioritized and only the "must-have" changes should be made.
The rest should be saved for future releases.
From a broad perspective, many problems result because the complexity
of supply chain management projects is underestimated by corporate management.
supply chain packages are installed on top of ERP or legacy systems requiring
an array of interfaces to be developed. Linking different applications
requires a profound level of understanding about the data that is passed
back and forth between them.
from technical complexities, managers fail to appreciate
the bottom line impact that supply chain management tools can have on
their businesses. Even with the expanding compass brought to supply chain
by B2B collaboration, this perception will be slow to change.
it is important to remember that, even with good preparation, experienced
resources, and an enthusiastic project team, all supply chain management
projects are guaranteed to bring unanticipated problems and dead ends.
Successful projects are not those that finish without a hitch, but those
in which project managers adapt well to adversity and persevere in spite
of the problems.