You Getting Your Software Cart Before Your Process Horse?
by Dave Garwood
How is your ROS ...
return on software? I suspect many companies would answer "poor"
or "disappointing" at best. Enthusiasm for investing in
new software, particularly large ERP-type systems, is very low. Yet
the need for reducing costs and sharpening the competitive edge has
never been greater. The business press frequently features impressive
success stories about companies who implemented new "systems."
My experience supports their stories. It sounds like a proven cure
is readily available, but the terminal patient is apprehensive about
taking the medicine!
Why aren't companies more aggressively buying new software and implementing
new tools in this time of dire need? This should be a boom period
for software companies. I suspect the low ROS and horror stories from
the past are responsible for the caution and pessimism. While some
companies have experienced handsome dividends from their software
investment, too many have not.
What separates the software "Have's" from the "Have
Nots?" The "Have Nots" often blame the software. The
"Have's" know better.
What Went Wrong?
Prior to Y2K, almost every company feared a midnight meltdown on December
31, 1999. The rationalization and drive for new software was clearly
focused on preventing an IT tragedy. In truth, better business results
were, at best, a distant second motivator for the new software investment.
In fact, software sales started dropping rapidly as we approached
Y2K. A validation of the real motive for buying new software.
When the software project was launched, current practices were rarely
scrutinized and challenged. There was very little emphasis on improving
or replacing current business processes. The emphasis was on software
selection and often focused on the technical elegance of the software
and "feature match," i.e. select the package that most often
emulated the current practices -- good or bad.
So the new software was installed and now the negative inventory balances
show up as real time records. Overstated master schedules, complex
material flows, large lot sizes, long lead times, overstructured bills
of material, overloaded new product development pipelines, massive
volumes of "exception messages" and multiple sales forecasts
were still prevalent and considered "normal." Spreadsheets
proliferated and overrode or replaced the new software reports as
people scrambled to duplicate the informal systems they depended on
to run the business (and were comfortable using!). System "workarounds"
became their core competency. Entering sales orders, rounding up the
needed parts and shipping product still depended heavily on "tribal
knowledge." Many people questioned the value of the new software.
Some suggested its only value was to impress visitors when they took
the one-hour plant tour.
In truth, the new software never had a chance to succeed. It only
helped avoid the IT meltdown, which was frankly the unspoken objective.
Today, the progressive companies see the real potential and are using
software as a means to an end, not the end. They are using software
to support better business processes and help them profitably grow.
They take a different path with a different sequence of steps. They
put fixing the problem (broken processes read: horse) ahead
of focusing on new software (cart).
What Separates the Software
"Have's" from the "Have Nots?"
Business performance is measured by customers and investors. Customers
are only impressed by high perceived value of innovative, defect-free
products, meeting delivery date promises and responding quickly when
they need product. Investors are only impressed when revenues are
increasing, profits are respectable, the balance sheet is strong and
the financial reports are not quarterly surprises. If new software
is installed and these expectations are not met, everyone is disappointed.
The company becomes a software "Have Not."
All these performance indicators are a direct outcome or result of
business processes such as material flow across the plant floor, demand
management (forecast), new product development, supply chain management,
inventory transaction processing, bill of material structuring, etc.
If we change the software and don't fix the broken processes, the
results will be the same -- poor and disappointing.
Usually, many people in the company have lots of "experience"
and are comfortable in the old legacy processes. Unfortunately, much
of this experience is with old technology that has become obsolete.
They have not had the opportunity or maybe even recognized the need
to become aware and comfortable with new business process technologies
such as flow manufacturing, sales and operations planning, phases
and gates new product development, cycle reconciling, etc. They never
looked for software functionality to support the new paradigms and,
in fact, often drove the need for extensive, costly modifications
to the new software to emulate the old practices. They just did more
of the same with a relational data base and java applets! No wonder
the company became a software "Have Not." I have seen software
often modified to accommodate a computerized Hot List!
How To Be a Software "Have"
First, software should be considered a tool to overcome the obstacles
to achieve quantum leaps in business performance. Software is not
a stand-alone solution. Let's look at some business process problems
and see where software might fit in the solution.
When a sales order is received, the customer has a logical question,
"Can you promise to meet my requested delivery date?" The
old paradigm was to guess or use "standard" lead times to
get an answer. The results were poor ... the date was missed and usually
resulted in costly, heroic scrambling to do damage control. The effective
way to answer the delivery question is to look at inventory on hand,
current customer commitments and future supply schedules. From this
data, you can calculate future availability and get a valid answer
to the customer's question. This approach is easy to understand in
concept, but almost impossible to do manually. Software can do the
calculations and get the answer, but only if the inventory record
is correct, the committed sales orders are valid and the supply schedule
is reliable. If the requested date does not match projected available
inventory, someone needs to look at the problem items to see what
can be done to meet the customer's request.
A process called Available-to-Promise (ATP) is an effective tool to
determine valid delivery promises. Read "When
Can I Expect Delivery?" in our archives for
a more detailed discussion of the ATP process.
Searching for new software to determine delivery dates without being
aware or understanding ATP would likely lead to modifying the software
or overriding it with spreadsheets to help "expedite," i.e.
emulate the old practice. A customer delivery promise process using
ATP requires a combination of functionally solid software, high-quality
data, valid schedules, six sigma schedule execution and a solid understanding
by key people of managing the process. New software alone won't do
Many times, plant floor layouts have been departmentalized. All drilling
is done in the drill department, subassembly is done in the subassembly
department, etc. Material travels to each department and waits in
queue for its turn. The results are excessive lead times, large WIP
and extra overhead costs. Streamlining and simplifying this convoluted
material flow into flow lines eliminates these profit-draining, slow
response side effects. Pulling material through the operations with
kanban signals helps keep material flow in sync with needs and simplifies
the planning activities.
Breaking the work content down into discrete workstations and sizing
the work force to meet the variable production rates requires many
calculations. Keeping the kanbans properly sized and visual signals
updated as demand changes requires processing large volumes of data.
This is a job for software. However, the starting point is understanding
flow manufacturing, kanban prerequisites and preparing for a new way
to manage the plant floor. New software without this understanding
will only be disappointing.
Need Still Another Example?
Many people in every organization depend on a projection of future
product demand, i.e. a sales forecast. Forecasting is often done independently
by many different departments. Read "Spin-Proofing
the Sales Forecast" in our archives for a more detailed
discussion of this topic. Many companies thought forecasting could
be done by buying a software package that "averages" historical
data. The result? Multiple forecasts with no integrity!
The "quality" of the demand planning process has a direct
bearing on financial performance, customer satisfaction and employee
frustration. Effectively managing demand requires clear accountability
for meeting the demand plan, i.e. executing the plan. This responsibility
belongs to the people calling on customers to get the orders. They
also need to be involved in establishing the plan they are accountable
for meeting. Frequently collecting feedback from the sales force on
their piece of the demand plans and updating them is a vital cog in
this process. They also need feedback of actual sales for them to
compare to plan and improve. Sanity checks need to be built in by
aggregating data. Quotes and actual orders need to be visible and
considered. Again, software can be a tremendous aid to collect, analyze
and present this information. But if the forecasting process still
appears to be a job of averaging past history and allowing everyone
to use his own forecast, the results with new software will be disappointing.
New roles and new processes supported by the software are all needed
to be a successful software "Have" company.
The companies that used sofware to make better delivery promises,
streamline material flow and achieve six sigma demand management all
have something in common. The "Have's" got the cart before
the horse. They focused on business process first, then considered
Five Ways to Improve Your Return on Software
There are five common threads in every software investment success.
1) Educate key leaders and managers in the business so they are Rev
6.0, not 3.0 business process savvy.
2) Closely examine the business processes and make sure they are not
broken or based on obsolete process technology.
3) Quickly reach a consensus on which processes are broken.
4) Fix the broken processes before or in parallel with implementing
5) Use software where needed to support the new process.
Why not buy some ROS insurance? Get your process horse in front of
your software cart!