The first point they make is that for most companies, Excel is not a viable S&OP tool.

• Anyone who has done extensive work in Excel knows that it is a very powerful tool that works best with smaller data sets.  Companies managing a complex supply chain soon find that they are stretching Excel’s boundaries to the breaking point.
• Modern S&OP process have a significant “what-if” component to them.  While it is easy to make high level changes to Excel, understanding what the real impact of these changes are, is simply not possible.  Consider a typical S&OP decision…what-if we were to add a promotion for this product line? A simple question, but a complex answer.  Sure, you can change the forecast quantities in Excel, and that can show change to revenue.  But what-if the product line is constrained?  What is the purchasing spend going to be to support this?  A simple Excel model simply cannot support this level of granularity.
• Excel doesn’t support alerts or lend itself to managing by exception.  Once your S&OP plan is set, you need to monitor performance against it.  Sure, you can see how you’ve performed at the next S&OP meeting, but isn’t that too late?

I’ve gone into some details about how Excel is not the right tool for S&OP (and other things) in other posts, if you are interested, you can find them here;

Is Excel the right tool for S&OP
How are spreadsheets like cockroaches
The endless debate: Is S&OP about technology
When spreadsheets go bad

So, if Excel is not the right tool for S&OP, what is?  Rather than call out a specific tool, let’s look at some criteria that you need to consider when looking for an S&OP application:

• I mentioned that Excel is not a good tool for S&OP is because it doesn’t support “what-if” analysis.  This is obviously something you need to look for in any tool for long range planning.  But simply allowing you to hive off a version of the plan and make a change is not enough.  The “what-if” analysis must provide detailed analysis as to what the impact of a given change will be throughout the supply chain.  A key supplier of low level components was just hit by a flood and won’t be shipping parts for six months – what impact will this have on my production?  What-if demand increases on one of my product lines?  What impact does this have on a constrained resource?… on my contract manufacturers?… on my suppliers?  Only a system with full supply chain analytics can address these questions.

• A related requirement is integration.  If you are going to provide answers to the “what-if” questions above, you will likely need to have detailed information from multiple manufacturing centers around the world. These centers in all likelihood are running a variety of disparate ERP systems, so your tool will need to integrate across all these systems and bring the data in to a single environment.

• As mentioned earlier, the ability to monitor performance against the plan and report on exceptions is key.  A S&OP plan is good.  A S&OP plan that you monitor and react to when underperforming is truly powerful.

There are several other factors that can play into your selection of a system for S&OP, but I think these are key ones.   What tools are you using for S&OP planning?  Are you evaluating new tools?  What factors are you considering?  Comment back and let us know!

It has been said that Henry Ford used the two-bin system in the early production of his automobiles.  As you know, each bin had to be equal in size to hold the quantity used during the lead time of the part with a little extra for unforeseen emergencies.  When the first bin was emptied, a reorder card was sent to Purchasing to reorder another bins worth.

The two-bin system assumed, falsely, that all demand quantity was, for the most part, steady and continuous.  Because of this false assumption, there were many problems with stock shortages and inflated inventories.  There was also a problem where you had to stock lots and lots of different sized bins to operate such a system.

In the 1930’s some mathematicians worked to eliminate the “lots of different bins” problem by devising the Reorder Point quantity formula.  Here they said the reorder point quantity on hand was equal to the demand during lead time plus some added safety stock (RP = DLT + SS).  This formula allowed the two-bin system to still be used and stocked on any shelf without the bin problem but still falsely assumed all demand to be steady and continuous while still generating stock outs and inflating inventory levels.

Can you see the magic in the two-bin Reorder Point formula?  A lot of people can.  Reorder points are still used in many of the new sophisticated ERP software packages today.  Heck, I even read a published article where one author thought that MRP didn’t work for whatever reason and suggested we should do away with MRP in favor of a 3-Bin Kanban with two bins on the shop floor and one at the supplier.  After reading this I remembered the old saying that “Those ignorant of history are doomed to repeat it”.

By now you can figure out that I don’t believe in two-bin, reorder point magic, however I do believe in statistical forecast models.  I believe that all forecast models are wrong.  I don’t like to forecast at all but I realize that sometimes you just have to.  I’ve been trying to come up with a forecast model for the six numbers of the Powerball drawing for years.  When I come up with an accurate model, I’ll let you know.

Forecasts are simply guesses requiring constant vigilance and adjustments to history.

Two-bin reorder points assume parts are totally independent of each other so you have to forecast for every single part.  That’s a lot of guessing and adjustments to history which requires a lot of maintenance.

The MRP planning process was devised to avoid most of the smoke and mirrors hocus pocus by a dramatic reduction in the amount of forecasting (guessing) you have to do.  MRP has product structure.  The idea here is only to guess where you have to (Independent Demand) and derive (Dependent) demand from those fewer guesses via a product structure therefore requiring much less maintenance.

When you need reorder points for “C” items use the MRP generated Time Phased Order Point (TPOP) which utilizes independent, derived, unsteady and discontinuous demand, a future blog topic of mine.

An early practitioner who became famous in our field, Ollie Wight, described a good, realistic schedule as basic and fundamental to the health and integrity of a good MRP planning process.  He also described the aftermath result of poor unrealistic scheduling as the informal systems of hotlists and shortage meetings engulfing the formal planning process.  The MRP planning process still exists, today, in its original form, as the foundation of our evolved MRP, Closed Loop MRP, MRPII and ERP systems.

Back in 1973, I was a young college graduate living in Columbus, Ohio.  I was very fortunate in my first job as a Materiel Controller (Buyer/Planner) to work with the first computerized MRP software package developed by IBM and APICS, the IBM PICS (Production and Inventory Control System) Package.  During those two years I learned a lot about the computerized MRP planning process and wondered how this complicated and detailed process was ever achieved prior to the invention of the computer.

IBM in cooperation with APICS modeled this software package from the most efficient manual planning processes of manufacturing companies such as Steelcase and Black and Decker.  These manual planning systems utilized Fixed Lead Times for purchased parts and a combination of fixed and variable lead time elements (fixed move, queue, setup and variable run time per unit) for the manufacturing lead times of make assemblies. Mfg. LT = Move + Queue + Setup + (Order Qty. * Run Time per Unit).

A week after being walked out the door due to the 1975 recession I found employment again in Columbus, as an Inventory Control Analyst (Shop Floor Scheduler) for a heavy equipment manufacturer of electric driven coal mining machinery.  This company was in business since the late 1800’s and it was there I found the manual planning process that preceded computerized MRP planning.  It was a complete manual MRP planning process utilizing Acme Visible index cards with lots of clerks running around posting entries to transactions.

I had to be totally retrained by some senior schedulers who wore green cellophane visors as headwear and striped long-sleeved shirts with arm bands.  I thought to myself that these were the type of schedulers who planned the production of the bombers of WWII and the 1957 Chevy Bel Air.  Wow!

There was one retraining session that will always remain in my mind.  The senior scheduler was judiciously studying one of his ledgers and said to me “Here, we have to create two manufacturing orders for this gearbox assembly, a 10 piece order for final assembly and a 5 piece order for a spares requirement.  They are both due on the same due date but we have to release the final assembly order on June 1^st and the spares order on June 15^th”.

I questioned him and asked since the orders were both for the same gearbox and due on the same date, why not set the release dates the same for both orders?  He stated that the orders were for different quantities and releasing them both on the same date would unnecessarily overload the broaching and Bridgeport machining operations.  He was doing CRP in his head!  He was also using the true manufacturing lead time elements of move, queue, setup and runtimes so the smaller quantity spares order could be released at a later date than the larger quantity production requirement.

The most important lesson I learned from the senior schedulers was the impact of the accuracy of the true manufacturing lead time elements to the success of the overall schedule.  The lead times elements had to be accurate with as little padding as possible.  Too much padding and you will overload limited resources and start the jobs too early along with bringing in purchased material too soon thus inflating inventory levels.  Too little padding or lack of lead time would release the jobs too late and not give the shop floor enough time to complete the orders on time.  Too little manufacturing lead times also schedules the purchased materials in too late and then when the informal shortage meetings are held you are in a constant expedite mode to move up the jobs on the shop floor and pull in the purchased material.

Stay tuned for part two tomorrow where I’ll discuss Manufacturing Lead Time Overrides.

This was a fascinating time for supply chain. High tech electronics led the way with increasingly shorter life cycles for products aimed at a customer base that was quickly becoming more educated and demanding. The early stages of Response Management as its own category were set (with Kinaxis coining the term and defining the category by the way). There emerged the first of two components of Response Management: “sense and respond.” For the most part this was all about anticipating demand because at this point historical analysis was of no use. Companies needed to get even closer to the customer, product life cycles became more difficult to manage, and it was the contract manufacturers who took the lead with emerging Response Management capabilities. From a functional standpoint, the requirements for a world class Response Management system were being defined:

• One place for all global supply chain data and information. More often than not this is coming from many different systems in different formats and different time zones
• “What-if” simulation anytime. For example what if demand dropped earlier than expected? What if this product was promoted? People could no longer wait for answers. They needed to know the risks and how best to respond or it could ultimately mean a loss of market share.
• One place for all supply chain participants. Demand and supply managers could no longer do things in silos. They needed to collaborate efficiently to effectively respond to change.

Even through all this, the term Response Management was still slow to catch on (though there were some industry analysts that understood and bought in See report: Response Management: Next Wave of Supply Chain Innovation?)

The second component of Response Management began to make headlines. The first component, “sense and respond,” I think was exciting. New product introductions, emerging markets, anticipating demand. Highly competitive aspects of supply chain and the companies that were the leaders started to be recognized, for example today you can go to The Gartner Supply Chain Top 25. This second component though does not yet have a catch phrase associated with it and is much different than “sense and respond.” Trying to think of something that is respectful of the human tragedies associated with this component of Response Management you might call it “respond responsible.” We are talking about the catastrophes nobody can “sense.” You don’t have to look too far for examples but since 9/11 they seem to be more frequent. I’ll just point you to my last blog, “Top 5: What Else Could Go Wrong?” for other examples. On top of the human element, supply chain professionals still need to source supply, allocate limited inventories and respond with confidence to their customers.

It has taken these events for many companies including the big ERP vendors to recognize that there is a need for something between planning and execution. Something when things don’t run like clockwork, when demand is unpredictable, or when you get hit with the unexpected. Response Management has arrived as an official category that companies will start, or for some continue to build strategies around.

• Let’s start from the perspective that a control tower is a decision making tool, not merely a visibility tool. Visibility is a precursor, a building block. In optimization parlance, visibility is an adequate but not sufficient definition of a control tower.
• A key requirement of a control tower is that several simulations can be performed to test high level hypotheses at a granular level to determine the potential effect on operational and financial metrics, as well as identify any constraints.
• A control tower by definition must cross functional and/or organizational boundaries. I think we can all agree that the term implies a view across a fairly broad span of operations, not a narrow functional perspective.
• Because a control tower crosses function and/or organizational boundaries it must support collaboration in order for people to be able to share perspectives and arrive at consensus and compromise that balances competing objectives and performance measures.
• Direct people to what is important and alert then to what is critical, and of course within their span of control.
• Identify consequences to underlying events, as well as the people who are responsible for both the events and the consequences, so that they can arrive at a joint resolution.

The analogy of the airport control tower has great deal applicability to supply chains. All of the systems required to manage airplane departures and arrivals, airplane cargo management, bookings, maintenance etc. are interwoven into a real-time mesh of information and decision making in addition to the visibility that an elevated position and radar afford. In contrast company supply chains, by and large, are separate, isolated, data ‘islands.’ The very best of these typically have ‘batch’ type connections to each other. When things go wrong the signals are late to arrive and impacts difficult to estimate. Imagine a supply chain world that is run like the world’s airports, with common standards (like pilot/tower communication always in English) and systems designed to communicate with each other in real-time. This is a very instructive model with standards and collaboration at its heart.

Below is what Sameer Patel wrote earlier this year in a blog titled “2011 Business and Technology Forecast,” with my emphasis:

As organizations increasingly start to see the benefits of deploying social and collaborative initiatives to improve employee, customer and partner engagement, they will soon begin to realize that the decade old notion of streamlining repeatable processes made popular by ERP and CRM system-of-record deployments was largely over promised. In practice, customers and prospects have unique questions not answerable in the knowledge base or by marketing; employees living in rigid ERP systems need to constantly find experts who have the best answers and to collaborate with them. And reseller partners are constantly spending time looking for the right answers not available on asynchronous partner portals to keep end customers happy. Silo’d but open collaboration initiatives on activity streams and other enterprise social networking utilities currently being deployed will expose such engagement not historically possible in an ERP or CRM laden design. Consequently, LOB and IT leadership will realize that traditional process approaches and fluid collaborative constructs need to come together to truly accelerate business outcomes.

My definition above focuses on the process and organizational requirements, but also on some key functional capabilities. What is clear from Sameer’s perspective is that by definition the solution will not be coming out of ERP or CRM systems. I think his observation that;

… they will soon begin to realize that the decade old notion of streamlining repeatable processes made popular by ERP and CRM system-of-record deployments was largely over promised.

is particularly important because for years these systems have been sold on the promise that they encapsulate best practice processes. If a process is repeatable isn’t it by definition a standard process and not a best practice process? OK, I concede that the process may be best practice and repeatable in a few organizations, but if everyone deploys a standardized best practice process, is it still best practice? I could go on forever on this topic, but I will leave it to Sameer’s devastating observation that;

In practice, customers and prospects have unique questions not answerable in the knowledge base or by marketing; employees living in rigid ERP systems need to constantly find experts who have the best answers and to collaborate with them.

And I will go further to state that not only should a control tower identify the experts for the employees, but in addition a control tower should allow an employee to suggest a resolution and to test its efficacy against operational and financial objectives. By all means get an expert to validate the assumptions and results, but all too often it will take too long to get expert feedback, especially if the expert must be identified, the problem described to the expert, and then have the expert investigate resolution in a separate system. The customer or prospect will have moved on to other problems by then.

In other words a thin collaboration capability that is little more than sharing ideas without the capability of evaluating the impact of the ideas is not likely to be of much value and is only a slight improvement on using phone, FAX, and Excel attachments. The issue isn’t that humans don’t have ideas, but rather that they don’t have a timely and effective manner of testing their ideas at a sufficiently granular level to ensure both feasibility and value. This is the key to having an effective control tower.

Gartner has also being weighing in on the topic of control towers, although nearly all the article focus on logistics visibility, hardly a ground breaking areas.  (Any references I make will require access to Gartner materials for full viewing.)  In an article titled “Supply Chain and Manufacturing Outsourcing Discussion with Supply Chain Leaders” published on (Michael Dominy, Hussain Mooraj; Nov 22, 2010), the authors define a control tower, that goes beyond logistics, as follows:

a “control tower” or centralized shared service organization to manage relationships and information between the company and its outsourced manufacturing, logistics and other service providers.

Unfortunately they don’t include a mention of collaborative decision making, but they do go on to state in the same article that;

Even if a partner delivers the supply chain visibility and events across the ecosystem of supply chain partners, the enterprise must control and direct the response across the supply network.

I can only presume that being able to control and direct the response across the supply network implies the ability to reach
a timely and consensus decision on what that response will be.

What I do like about this Gartner article is that it includes a maturity model. I am often guilty of describing nirvana without painting a picture of how to get there and the steps between. Something else that is brought out by the Gartner diagram and article is the applicability of control towers to outsourced environments. In other words when key operational activities are outsourced it is necessary to get on overview of the operations in order to provide the control and direction to the extended supply chain.

So far I have focused very much on the definition of an “operational” control tower. In my next blog I will weigh in on a “corporate” control tower that focuses more on the needs of the executive level. In the meantime please give me some feedback. I’d love to hear your ideas about control towers and the convergence of consumer-led social networks concepts, enterprise 2.0 ideas, and control towers.

Brand owners are quick to discover that the first critical impact of outsourcing is the loss of visibility of detailed supply and demand data that they once held in their own ERP systems. Without this visibility they cannot make information-based supply management decisions. While getting access to detailed supplier supply and demand data is usually their first focus, it soon becomes apparent that tools that can allow them to view, analyze, and manipulate this data are also a very high priority.

The following are ten critical data issues to be considered in structuring the supply chain data model for maximum utility.

Capture Core Data From Partners

More and more frequently, outsourcing agreements include provisions for data sharing, which address both content and frequency of data feeds. Working closely with suppliers to understand the details of this data is a critical component of the collaboration process.

1. Part numbering issues

Part numbering schemes will usually vary across supply chain nodes. How will common or equivalent part numbers be established for global planning and netting? Cross-referencing supplier parts to brand owner part numbers is the most common approach.

However, it may also be necessary to consider parts in groups for netting purposes. For example, some suppliers may identify parts at the revision level, while others do not, or planning may be done at a product line level, not the detailed part level. System support for use of alternate parts and/or aggregation of supply and demand across multiple parts may be a critical requirement.

2. Core supply node master data and supply-demand details

Parts, bill of materials (BOMs), on hand inventories, local order policies, priorities, scrap, and yield factors are usually required for each supply chain node, as well as all active demand and firm supply records. It should be possible to match the local planning behavior of the outsourced supplier reasonably closely. This becomes particularly important when there are multiple levels in the supply chain. Incorrect planning at one level can radically skew requirements for downstream suppliers.

Semiconductor manufacturing provides one example here, where wafer fabrication, assembly, and test may all be handled by separate suppliers with potentially different lot sizing, lead times, and yield factors at each stage. Without matching each supplier’s planning policies it would be impossible to accurately plan for product availability.

3. Supplier constraints, both capacity and material based

Suppliers may have shared constraint information, and sourcing may be constraint-based. For example, a supplier may commit to producing a fixed quantity per week of a specific part, or grouping of parts, or he may commit to a fixed percentage of available hours on a particular manufacturing line. If known, these constraints should be reflected in sourcing rules and should be adjustable by the planner for simulation.

4. In transit quantities, lead times

At any given point in time, a significant portion of the existing inventory may be in transit between supply nodes. Clearly, synchronizing the timing of data collection for all nodes, including in-transit quantities is critical, if data collection is not real-time. In practice, getting the in-transit data right is often one of biggest data hurdles and a clear understanding of how in-transit quantities relate to supplier commitments is mandatory. For example, are current supplier commitments net of in-transit shipments, or should commitments be decremented by in-transits?

Lead time information is normally available by supplier, but, when modeling the full supply chain, transit time between partners becomes more and more important to model cumulative lead time.

Click here to check out part 2.

While I can’t comment on the specifics of what the study authors have found, I have seen many instances where traditional ERP systems simply don’t align with the needs of the business.

1. Many ERP systems don’t allow you to see forecast and actual customer orders in the same view.
2. Many ERP systems have an “all or nothing” approach to capacity planning – you need to fully populate capacity planning data and track actual performance at the operation level or you can’t do capacity planning.
3. Some systems only present views on a part by part basis – so you can’t see aggregated details without running a special report
4. Most systems make it very difficult to try what-if scenarios and get timely results.

There are many more examples, but what is interesting is what happens when ERP users don’t get what they need from the ERP system; they try to get the information someplace else…typically from Excel.

I’ve talked in previous posts (How are spreadsheets like cockroaches?, Is Excel the right tool for S&OP?) about the dangers of running your business on Excel.  Excel is a fine tool for creating charts and doing one time analysis, but things start to fall apart when you start building business processes on it. Like a foundation for a building, the software you build your processes on is critical.  A weak foundation, and your process will come tumbling down. So why is Excel a weak foundation?

• Excel propagates multiple copies of “the truth”. How many times have you gone to a meeting where two people presented different versions of what is supposed to be the same data?  Whose data do you believe?
• Excel allows non-validated business logic. Who created the spreadsheet? How sure are you that the formulas used are correct? In my “How are spreadsheets like cockroaches?” post, I cited a study that showed that 90 percent of spreadsheets in use by businesses today contain serious errors.  Errors that could result in you making a bad decision.
• Excel has a poor collaboration model. Many processes today require inputs from multiple people.  Excel doesn’t handle concurrent edits well, so often processes must be structured such that edits happen consecutively. This can prolong processes, especially if you have difficulty getting people to make their changes on-time.
• Complex processes result in complex Excel worksheets. I managed the S&OP process at a manufacturing company in a previous life.  The S&OP spreadsheets for our four product lines were built up from multiple component workbooks.  Macros were used to manage the rolling time window. When something went wrong with the process, I was guaranteed to spend days trying to debug and pick up the pieces.  Things went wrong far too frequently.

So, what’s the solution?  Use ERP to manage transactions but stop looking to your ERP vendors to solve all your supply chain problems.

In our personal life, we wouldn’t go to the same vendor for everything would we? For example, I use my bank’s website to manage my day to day transactions. They are very good at it…they’ve been doing it for years.  However, to manage my budget and to look at my spending patterns, I use Mint.  I looked at my bank’s budgeting offering and while it sounded good…it didn’t fit my needs.

My advice? Look at what your ERP vendor offers, but be sure to look at other offerings that are available. You might just be surprised at how well these tools meet your needs, and with the many on-demand services available, you won’t be looking at a large capital expenditure or an ongoing IT burden.

Are you using third party or best-of-breed supply chain solutions? Comment back and let us know your thoughts.

The first question I had when reading the article was what does Jim mean by ERP? The systems or the vendors? In response my question Jim replied by email that:

For me the ERP system is that collection of tightly integrated apps that manage and support transaction processing. I believe that such a system creates a valuable foundation for companies to build or buy applications that can deliver insight, process differentiation, and process innovation. Kinaxis’ applications are a very good example of using an ERP foundation (or what Gartner now calls Systems of Record) to provide insight and innovation.

This is consistent with my perspective and, not surprisingly, with several of Jim’s colleagues at Gartner. Tim Payne, for example, classifies solutions into ‘process automation’ and ‘process innovation’ in an article titled “The SCP for Process Innovation Landscape” (May 27, 2010).

By Jim’s definition then ERP would fall into ‘process automation’. Dennis Gaughan, in another First Things Monday article from June 20th, 2010 and titled “Is It Time to Rethink Your Enterprise Application Portfolio Strategy?” outlined an approach to reclassify applications based on the role they play in the organization (with the goal of accelerating the pace of change for IT). Those categories were (see the original post for full descriptions):

• Systems of record — These are the systems that form the foundation for your enterprise and manage the information necessary to run your business.
• Systems of differentiation — These are the systems that help drive differentiation for your company. They connect to customers and trading partners, as well as help speed time to market and overall agility. They’re more collaborative in nature, and while they leverage data from systems of record, they capture and maintain additional information.
• Systems of transformation — These systems create innovation for your organization. They’re often developed out of ad hoc processes and tied to specific initiatives, so they can have very short life cycles.

We are happy to be classified, as per Jim’s email, in the ‘systems of differentiation’ and ‘systems of transformation’ categories defined by Dennis. There is no doubt that, as Jim states, systems of record are an important aspect of the IT infrastructure. One has to take orders and issues invoices, balance the books, and keep the employees happy and the org chart updated. Stability and regulatory compliance are key attributes, as is risk avoidance. Tim, in the article referred to above, ranks different characteristics of automation and innovation as follows:

But as Dennis writes, it is the systems of differentiation and innovation that allow companies to behave in a different manner, which provide agility and respond dynamically to changing business needs. I would argue that this space requires a different DNA, not one commonly found in ERP vendors, which are focused on things like risk avoidance and regulatory compliance. Innovation cannot be bound by these, but of course innovation must respect them.

Supply chain is like that, only more so. Your customers want their orders confirmed and their goods delivered on-time…or you fail. I think we all can agree that the timeframe in which customers expect their answers is shrinking too. They expect to know within the day, sometimes within the hour if you can accept the order. To succeed you need to get results fast, you need to get rapid results!

Let’s say it’s Monday morning and your ERP system has just run and you have a fresh new plan.  Then the phone rings and it’s a new potential customer with a large order that could turn into an ongoing relationship. The only catch? They want the items inside of lead time and they need to know today if you can handle the order. How do you solve this problem? You simply can’t solve this using your ERP system. Why?

1)    You don’t want to load the order in your production ERP system because you don’t yet know if you want to accept the order.  You certainly don’t want to trigger new Purchase orders to support an order you don’t know if you can accept! Even if your system supports what-if analysis, it takes hours to set up the new scenario before you can even begin your analysis.
2)    If the product in question has a complex BOM, you must do a full MRP run to truly understand the implications of the change.  Most ERP systems run MRP on a nightly or (**GASP**) weekly basis because MRP takes so long to run.
3)    Once the analysis is done, how do you know what the impact is due to the order you just added.  First, the traditional ERP interface is designed to work on a part by part, screen by screen basis.  Evaluating a complex change this way can take hours or days.

Typically, users give up on their ERP system and revert to spreadsheets to try to guestimate whether or not they can accept the order. They manually try to figure out what they can or can’t make.  They call or fax suppliers to see if they can expedite orders. Hours (often days) later they have a “best guess” as to whether or not they should accept the order.

Some companies try to avoid these issues by holding lots of inventory. Of course we know that this comes at a significant cost and typically, you end up with too much inventory of the wrong part. Other companies simply prescribe to the “Load and Pray” approach of accepting the order and praying that it gets done. These companies can be recognized by their sub 60 percent on-time delivery metrics and the line of angry customers outside their doors.

So let’s look at how to get rapid results.

There are numerous capabilities that are required by any planning system to enable rapid results;

1)    Instant what-if capability. This is the ability to instantly create a scenario, make a change and see the impact of that change.
2)    Alerting. A rapid result system needs to alert users to a situation that needs to be addressed. This is more than alerting that you have a new order.  It’s letting you know that this new order is going to be late…or drive significant new purchase orders…or will cause another order to be late.
3)    Powerful real-time analytics. A rapid result system needs to replicate the same calculations that your ERP system is doing, but do it in seconds rather than hours. The results of these analytics needs to be displayed through an interface that makes it simple to see the impact of your change.
4)   Collaboration. Many supply chain problems cannot be solved by a person working alone. A rapid result system needs to enable the sharing of information with a team of users and manage the responses from those users providing a clear picture of the final result.
5)    Alternative comparisons. There are many ways to solve a problem, however it often isn’t clear which approach is best;  one approach may meet the revenue targets, while another reduces manufacturing costs. A rapid result system will compare the possible resolution scenarios, scoring them against corporate goals and will clearly show which approach is best.

So if you had a system as I’ve describe here, how would our new order scenario go? Probably something like this;

It’s Monday morning and the phone rings. It’s a new potential customer with a large order that could turn into an ongoing relationship. You log into the system and create a what-if scenario. You add the order and instantly see that the order is currently planned to be six days late. You drill into the causes for lateness and see that you have three late purchase components and a capacity constraint preventing on-time delivery of this new order. You share the scenario with the capacity planner and the buyers for the late parts. They receive a notification that they have been invited to help. Within minutes, you hear back from the capacity planner to say that the constrained resource can be rescheduled to meet your demand. Minutes after that, the first buyer is back to you to say that they can expedite a component, or alternatively they can get an alternate. Within the hour, you’ve heard back from the other buyers. You have two possible resolutions to look at: One, solves the problem using expedites, the other using alternates. You compare the scenarios and decide that expediting has the least impact on overall cost and you place the order.  An hour after your customer has called, you’ve called them back and can confidently promise their order will be delivered.   The start of a beautiful relationship!

Are you getting rapid results? Or are you locked in the ERP dungeon of best guesses, spreadsheets, and excess inventory. Break out!

On the lighter side check out this week’s New Kinexions episode – it’s about Rapid Results…hey what a coincidence!

That’s a wrap folks! We’ve posted all six New Kinexions episodes on our Supply Chain Expert Community. If you haven’t watched all of the episodes yet, check out our Just for Laughs section.

The article states that according to a Forrester Research report, ERP investment plans will dip this year from last, even though overall IT investment plans are predicted to increase. It also states that roughly half the companies surveyed are running on product releases that are 2 releases behind current.

It is is understandable that a lot of companies scaled back IT spending in general, and ERP system spending in particular, during the recession, but 2011 is projected to be better in terms of economic growth. If you agree with the Forrester Research, it begs the question: why is ERP system investment projected to decline, when it appears that a lot companies need to spend in order to upgrade and take advantage of the latest functionality theses systems have to offer?

The answer may lie in the very nature of ERP systems themselves. ERP systems are the transactional and processing bedrock of a corporation, and as such adhere to the following characteristics:

• Transactional stability: The user must be assured every transaction processed is recorded and processed correctly.
• Process stability: The user must be assured that no short cuts or missed steps are allowed to occur in the system.
• Data Integrity and Security: The user must be assured that all transactions can be audited and reported on in future dates, without any worries as to the authenticity or integrity of the data.

The features required to ensure a solid ERP system also limit its potential in the enterprise. ERP vendors have tried to address this issue by adding modules, but the functional issues introduced by trying to adhere to the criteria listed above and still have the flexibility and additional features to support nontraditional ERP requirements such as supply and demand planning, simulation, and S&OP support have proven almost impossible to overcome.

Could it be that now companies are starting to look at more than just survival? Emphasis is being put toward improving how the business works and reacts to change, versus just ensuring current processes are performed correctly? This shift of focus will naturally favor enterprise systems that can support coordination of the complete business ecology, along with the ability to act as the ‘brains’ of an enterprises system. These types of systems have a very different set of criteria needed to meet the business requirements of today’s corporations, which might explain the shift away from traditional ERP spending towards systems that can lead to significant improvements in operational performance, not just better transactional control of data.

The ability to implement control over the numerous transactional and data storage systems in the enterprise and bring the data together in a meaningful way is crucial to getting the entire enterprise to react to change faster and move in the same direction in a coordinated manner. Once this capability has been realized in the business, the enterprise becomes much more able to compete and out maneuver the competition.  This in turn leads to higher growth numbers, improved margins, and better ROI.

It can therefore be argued that there could in fact be a movement of investment dollars away from traditional ERP system maintenance because of the desire for companies to dramatically improve their competitive position by investing in systems which can lead to a ‘smarter’ and more agile corporation.