|
Are
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 it. Want Another Example? 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 new software. 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 new software. 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! |