Enterprise Resource Planning systems (ERP) are information systems that are transaction oriented. They are backbone systems that track orders, production, financials, etc. They tend to answer the question “What is the current state of my business?”

Supply Chain Planning (SCP) systems are information systems that enable a company to link their vendors and customers. They help companies to respond to changes in their processes and market place using optimization and simulation techniques. They tend to answer the question “How can I respond to the current situation in the most effective manner?”

Typically, a company can expect the following benefits:

Inventory reductions 20-40%.

Order fill rates and On-time shipments which are typically measures of customer service improve by 10% or better.

1-2 % reduction in operating costs.

Total SC management cost reduced 10%.

On-time delivery of median companies can improve 15%.

Typical company can improve asset utilization by 15%-20%.

Leading companies have a 40%-65% advantage in cash-to-cash cycle time over average companies.

ERP solutions have improved the quantity and quality of information, but they have not necessarily provided users with true decision support. To understand this, we have to remember that the primary purpose of an ERP system is to continually track how a company’s activities impact its financial status. In order to do this, ERP systems must work at a transaction level of detail. They capture every receipt, production activity, and material movement.

Although this greatly improves the quality of data, it is very cumbersome to do analysis, forecast, or plan at this level of detail. As a simple example, financial “Executive Information Systems” have been developed to meet the slice-and-dice analytical requirements of managers who need to actively monitor business performance. The technology that makes ERP systems so valuable in preserving data integrity also sacrifices the ability to do strong analysis. The result is supply chain planning modules that are simplistic, and often slow.

Many current ERP vendors now offer product extensions that allow for some degree of supply chain planning (SCP). These extensions use different technology to enable more sophisticated analysis, and they interact with your core ERP system much in the same way as other best-of-breed solutions. However, the range of functionality they offer is uneven, since many ERP solutions have difficulty moving far from the simplistic planning modules they already offer.

Next generation SCP systems offer the decision support to understand what customers will want, how to make it, how to ship it, and where to hold inventory. The spreadsheets and manual systems that were once used to interface with a company's ERP are quickly becoming a liability. SCP systems are designed specifically to leverage your ERP data, and combine this with supply chain performance information to improve daily decisions. What-if analysis becomes faster, and more realistic. People can test the outcome of their decisions before they commit resources, and each has a view into how their input affects the entire organization.

Typically, Supply Chain Planning will address all or part of the following processes within your company:

The Internet has reduced the cost of communications between companies, so connectivity is no longer a limited factor. Effective external collaboration builds on effective internal collaboration, so the first step is to ensure that your internal systems and processes are in order. The second step is to understand which collaborative relationships have the greatest potential return for your business.

You need to answer two key questions about your internal systems and business processes.

Look at the basics: Is supply chain information available to users across your company? Can people slice and dice data from a common source to meet the needs of their job function? Do you have dynamic reporting of performance information? Is there a common planning process for evaluating the interactions between customer demand, material availability, production capacity, and distribution? If you have difficulty in managing your own data, adding that of others won’t provide for better internal decision-making. Many companies still find that their data and decisions are fragmented across the different business functions.

The scalability of your systems and processes affects the cost of collaboration and the likelihood of success. Can current staffing levels deal with the additional information and interactions required by external collaboration, or will additional resources be required? Spreadsheet based planning processes are very labor intensive, and have limited scalability.

Once you are satisfied with your internal capabilities, you should look at your customers to identify the prime candidates for collaborative interactions. The specific factors to consider with vary with the industry that you are in, but a universally productive exercise is to plot customer volume versus demand variability. The customers with both high volume and high variability are prime candidates for collaborative planning.

Methodology to assist in implementing the systems and processes.

A repository for my business rules and procedures.

A system or process to identify problems (early warnings).

Tools to optimize supply and demand.

A detailed finite scheduling module.

Understand your company’s supply chain and its important aspects.

Get buy in from upper management and identify a champion.

Identify opportunities for improvement and quantify the benefits.

Be prepared to educate the organization. Too many companies do not prepare their organization for the amount of change that will occur.

Choose the correct vendor to work with. Know each vendor’s strengths and weaknesses. Speak with companies the vendor has worked with in the past.

Bring together the best people in your company to be part of the team.

In their rush to capture the potential benefits from supply chain management (SCM) initiatives, companies often fail to consider how they affect the daily lives of the people in their organization. On paper, a “big bang” approach may appear to be the fastest way to capturing benefits, but it is also the most disruptive way of introducing new tools and processes.

People tend to cling to the way they currently perform their jobs. A common element in the “big bang” approach is rapid introduction of technically sophisticated tools. If an SCM initiative is viewed as increasing the difficulty of a job function, or creating a more complicated work environment, the initiative usually encounters resistance. In this case, an opportunity is missed – where SCM could have actually consolidated the work required for decision-making, and made the user’s job more meaningful.

An incremental approach to supply chain management – one that prioritizes efforts in a measured fashion – is often most credited with considering the “change enablement” needs of a company, and generating excitement and support for the efforts early on.

It is important to realize that simply providing users across the organization with supply chain performance visibility can create strong benefits, including:

A common view of enterprise performance; this can often assist in identifying and prioritizing next steps.

Less ‘silo’ thinking as people share information across functions.

Shared decisions that people own.

This improved visibility generates tangible dollar benefits, and is usually a prerequisite to the introduction of more sophisticated decision making tools.

Another benefit of an incremental approach is that it limits investments in resources – both financial and human – to clearly defined projects that build on experience and knowledge across the firm. This last point is very important to consider: It difficult for an organization to accurately define how it will use tools and methods that it has no experience with. Using an incremental approach, as an organization gains experience with new technology, it can more clearly articulate future requirements. Priorities may also shift due to changes in the business.

In short, identify clear needs that affect people across functions and promote information sharing and dialogue across the company. Priorities will then become visible, and a phased approach will accelerate benefits, generate enthusiasm, and allow for learning that will create a sustainable process for improvement.

If you want people to participate in a collaborative process, it helps to give them capabilities that improve their productivity. Unfortunately, past initiatives to improve supply chain performance often involved creating more systems for people to interact with, thereby adding to their workload.

Three critical capabilities are needed to improve productivity across a broad range of business roles.

Make all relevant supply chain information consistent, current, and in one place. This includes plans, schedules, and supporting data. Even today, people spend too much time pulling data from a variety of sources and trying to make it consistent.

Let people easily extract information in the format and level of aggregation that they need. Many companies still run their business with fixed format reports, which means that people either manually manipulate information into the format they need or develop other sources for it.

Make it easy to move the information into the normal desktop tool set, avoiding the manual re-entry of data still found in many companies.

These capabilities may seem trivial, but they are still largely missing from most supply chain job functions.

OLAP stands for On-Line Analytical Processing. This technology has the ability to explore multi-dimensional data interactively, going beyond the fixed, two-dimensional views normally found in spreadsheets and printed reports. OLAP capabilities are often used to support collaborative planning processes.

An example is the easiest way to illustrate this. A newly appointed supply chain manager wants to understand production variability in a business where a product can be produced on more than one line at more than one plant. The standard view of production data is a weekly total by product, but he would like to drill into the data further to see production by product and by plant. Production variability at one plant is noticeably greater, so the next step is to drill further down into the data to see production by line at that plant. He notices significant variability with one product on a single line. To see if related products share this variability, he then looks at production by product family for each line.

In the past, the supply chain manager would have ask someone to create a new report each time he wanted to see more detail or to expand the number of standard reports to include every level of detail that might be of interest. In the first case, there is a delay between when he needs the report and when he get its. In the second, the volume of reports is overwhelming.

The advantage of OLAP is that it lets the supply chain managers interactively drill into the data to generate desired views as needed. They can start at a detailed level and generate views that are more and more aggregated. Or, they may go back and forth, as in our example.

Three capabilities are required to make this kind of analysis possible.

The tool needs to be able to access data and perform calculations rapidly.

User interfaces must be flexible and intuitive.

The tools must provide multi-user support.

OLAP tools pull data from a relational database, prepare the data to speed up aggregation, and create a data structure called a cube or hypercube in computer memory. It should be noted that data preparation may include some partial aggregation. The user then accesses the cube through an interactive interface to work with the data.

Of course, every technology has shortcomings that go along with its benefits. Large OLAP applications see a trade-off between the time required to create the cube when the OLAP application is initially loaded and the response time for working with the cube. These applications may need tuning to optimize performance. In addition, since creating the cube may involve partial aggregation of the underlying data, many OLAP tools are view only. In other words, they don’t allow editing of data from the cube because they are unable to disaggregate it into its underlying form.

CRM refers to a broad range of software that supports the sales function. Two themes commonly associated with CRM are using computer technology to enhance sales effectiveness and providing consistent information to the customer across all available interfaces. From a Supply Chain Management perspective, CRM supports the execution of the sales process and ties into data sources shared by other business functions.

Vendors apply the CRM label to a wide range of applications that include the following:
(Note that many of these applications overlap with each other.)

Interface management: Telephony applications that display customer attributes when they call, automated voice-response systems, web-based applications for sales and customer feedback, call center software, links into customer ordering systems, and software for administering e-mail sales efforts.

Contact management: Software to manage leads, track and measure progress through the sales cycle, log customer input, and store customer attributes.

Data management: Applications that provide a common repository of customer data to support interactions across all available interfaces (web, telephone, EDI, etc.) and collect customer history.

Analysis: Manual tools for exploring customer data. Quantitative techniques to identify groups of customers with common attributes, develop and deliver customized pitches, and analyze market trends. More specialized applications address inventory policies, store layouts, and product displays.

Many vendors claim to provide one-stop shopping for CRM, but companies may utilize 5 or 6 different vendors in a CRM initiative.

After Y2K, the software industry searched for marketing themes that would continue the large-scale expenditures for software that occurred prior to 2000. The first major post-Y2K theme was E-business. When E-business lost momentum, the next major marketing theme was CRM.

A number of companies launched major CRM initiatives. Typical projects had budgets of $30 million to $60 million over a three-year time span. As might be expected with something so ill defined, outcomes varied greatly. Gartner reports that half of all CRM projects failed to produce benefits. More recent efforts are smaller in scale and address specific areas of functionality.

Both Lean Manufacturing and TOC are complementary to the use of APS. APS includes anticipating customer requirements (Demand Management); planning and coordinating activities across the different business functions (Sales & Operations Planning); defining the timing, volume, and sequence of production activities and material movements (Scheduling); and ensuring that customer ship date commitments are realistic and consistent with business priorities (Order Commitment). All companies perform these functions, either implicitly or explicitly. The details of what they do and the effort they expend vary with the size and characteristics of the business.

TOC is a specific scheduling methodology that emphasizes scheduling the production bottleneck first, and then letting the schedule for the bottleneck drive the rest of the production activities. People have used a variety of scheduling tools to do this when there is a well-defined bottleneck for production. While Eli Goldratt has made TOC a semi-religious ideology, it breaks down if the bottleneck moves as your product mix changes or if you can flex capacity to shift bottlenecks as demand increases.

Lean Manufacturing focuses on improving the efficiency of executing production activities. Its core is a participatory approach to implementing continuous improvement. First, the value of each step in the production process is assessed; next, steps with no or little value added are eliminated or minimized; finally, value-added steps are made more efficient. This process gets into the details of the production process, by considering how material moves through the plant and how materials, tools, and machines are positioned. In other words, the techniques associated with Lean Manufacturing are used to control and synchronize the flow of materials through the plant, which can be a real headache in many discrete manufacturing settings.

Lean Manufacturing results in improved yields, reduced lead and cycle times, and fewer quality problems. These are the parameters used by APS tools that can be updated as they improve. In the absence of good APS tools, significant delays are likely in determining how these improvements in manufacturing performance translate into improved customer service, reduced inventory levels, and captured additional revenue.

Much of the perceived conflict between APS and Lean Manufacturing comes from competition for consulting budgets. Fortunately, it’s not an ”either or” proposition since companies need to plan effectively just as they need to execute effectively.

Integration of different computer applications is a necessary evil. Companies have always had to connect their financials to the applications that handle the details of sales, materials management, manufacturing, and distribution. These details vary from one business to the next, and-despite the claims of ERP vendors-no one product addresses them all. As a result, a small industry exists around Enterprise Applications Interfaces (EAI).

Over the years, improvements in technology have reduced the cost and effort required to link different applications. In addition, vendors have moved to more open designs to eliminate many of the integration issues that hampered businesses in the past.

Originally, computer applications were very inward looking. They expected data in a certain format, acted on it, and stored the results in a specific way. Just passing data between two applications required code-level development. You either modified one of the applications to address the differences in data formats, or you created an intermediate application. The development effort increased rapidly as you increased the number of applications to be linked since code-level development was required for each pair-wise interaction. While only one interface is needed to link 2 applications, 6 interfaces are required to link 4 applications, 10 interfaces are required to link 5 applications, and so on.

Not surprisingly, these interfaces developed a bad reputation because of the effort and specialized skills required to develop and maintain them. In other words, interface development required people who understood the proprietary formats and work flows used by both systems. In addition to creating the interfaces, they had to synchronize the interactions between the two systems so that the output from one application was complete and accurate when another application accessed it. Further complicating the problem was the fact that changes to any one application, such as the installation of a new release, could mean revisions to a number of interfaces.

Initially, vendors tried to discourage customers from modifying their products because the modifications made it more difficult to install future releases. However, when customers insisted that vendors make these interfaces easier to implement, vendors created Application Programming Interfaces (API). An API let customers link their own code to applications without modifying the internals of the product. Although API's were a big step forward, customers still needed to create an interface between each pair of applications needing to exchange information.

The emergence of relational databases (RDB) greatly reduced the number of interfaces needed to link a group of applications because they simplified the process of connecting multiple applications by serving as a hub. When each of the applications connected to the RDB, data could move between them without the need for specific pair-wise connections. At the same time, Structured Query Language (SQL) emerged as the standard language for queries. SQL provided a generic language for managing the movement of data through the RDB.

With the move towards client/server computing and the evolution of the Internet, applications added the ability to send and receive messages. As a result, operating system providers and third party vendors created components and tools to support these interactions.

Then, vendors added scripting capabilities, which could send data to other applications or interpret data sent by other applications. These scripts were analogous to Microsoft Excel macros in that they did not change the application but were part of the data the application acted on. If a vendor provided backward compatibility between releases, the interfaces would not be affected by the installation of a new release.

Next, software vendors created "middleware" to support connections between different data management products running under different operating systems.

Clearly, computing environments have become more homogenous, further simplifying connectivity. Generally, operating systems options have distilled down to Windows on the desktop and Unix variants (like Linux) or Windows on servers. Such simplification makes it easier to utilize technology for connectivity provided by operating system vendors. Two major examples of this technology are ActiveX and Java. The top three relational database providers (IBM, Oracle, and Microsoft) control about 90% of the market, thus making it easier to rely on connectivity tools available from these vendors. Even more recently, the Extended Markup Language (XML) has emerged as a common format for passing data between different applications.

It is important to realize that the evolution of connectivity over the past 20 years, and associated reduction of cost, indicates the degree of need. The creation of interfaces between applications has gone from code-level changes to proprietary applications, to the creation of scripts using generic components and languages that leave the applications unchanged. RDBs act as data hubs, eliminating the need for a host of pair-wise interactions.

Dire predictions on the cost of connecting to other applications will remain a staple in the sales arsenal of many software companies (including your ERP vendor). Despite that, the need for connectivity will continue to increase as companies move into the era of E-commerce, where they not only have to integrate their internal applications but also must connect to their business partners as well.

Our experience has been that throughout any one project plan, you should attempt to show measurable deliverables within any six-to-eight-week time period. After about two months of work, people start to lose patience and, more importantly, their ability to adopt new ways of working is tested. So the trick is to break a large project up into self-contained units that take no more than two months to implement.

A good example is a large multi-national chemical company that wanted to improve inventory management. While there were many opportunities to improve inventory performance, management decided that global inventory visibility was the best first step in that direction. Within four weeks, people across the firm were able to report on inventory by any combination of attributes and in terms of volume, value, or days supply. Not only did the improved visibility identify pockets of inventory that could be reduced (accelerating business benefits), but people were also given a tool that provided them decision support very quickly. Users across the planning organization began thinking more globally and gained comfort in utilizing technology to support better decision-making.

The question of “when” is not as important as “how” technology is introduced. Technology for technology’s sake is never a good decision. However, at almost any level of supply chain planning (SCP) sophistication, technology can play an enabling role. The key is to identify what core choices your team is making on a daily basis and then to identify opportunities to help support them in doing so.

An example: “Jane” manages a small supply chain team for a $400 million manufacturer. The five of them have only recently begun to review their processes, and they hope to improve both their own skills and the core operational routines with respect to planning. Most of their analysis is spreadsheet based and involves individual data extracts from their ERP system, which takes time and effort. Supply chain performance information is not easily available, and she feels that, in many ways, analysis is not valued in her organization.

At first glance, it may appear as if technology is putting the proverbial cart before the horse. However, a good first step might be to provide her team with a strong analytical base for supply chain performance. By providing her planners with the capability to easily analyze demand, identify trends, view global inventory balances and set up some simple metrics, Jane is also setting the stage to identify and prioritize later initiatives. She is also introducing technology in a way that is non-threatening and that provides quick benefits to her team.

Of course, every situation is unique, and each deserves a unique approach to improvement. Therefore, in considering tools for advanced SCP, it is important to make sure that the solution can flex to meet the needs of your people, not the other way around. Technology can then work to make an employee’s role more meaningful, to provide support for the decisions they need to make every day, and to be readily be adopted by the team. This will be true for groups of all sizes and levels of sophistication.

The most immediate answer to your question is yes, there is much more that technology offers in supporting demand planning than just a statistical forecast. It is a solid start, though, and you can build on it.

Effective Demand Planning is more than a module for statistical forecasting. It is about understanding your customers' demand and having visibility into trends that help you plan and avoid problems. Technology supports this when it brings together supply chain performance information like shipment history and customer variability and supports ABC-style analysis of orders and profitability. Much of the gain in the use of advanced supply chain planning (SCP) tools comes from the ability to easily analyze and understand your demand data.

Refer to the statistical forecast as a 'baseline.' This single baseline should be offered to those in the organization with intelligence to make adjustments to it easily and create a forecast that is shared by various groups that have a stake in it: sales, marketing, production planning. Without the ability to collaborate in this way, multiple versions of the forecast will inevitably exist, and people will be planning from different positions. Furthermore, utilizing a common baseline creates the ability to measure performance over time, something that is absent in a process that is fragmented.

Sustainability of an application such as yours is quite frequently under prioritized when companies undertake projects for advanced planning tools. The effort often has a project champion and team that is focused on rolling out the technology, but effective change management steps are not taken to make sure that the software can be maintained by the organization long after the initial "go-live."

Supply chain planning (SCP) applications are decision support tools, not rigid general ledger applications that can remain more fixed as business conditions change. In this respect, a successful introduction of SCP tools - meaning the tool is accepted and being utilized by your people - will absolutely mean that people will want to tweak their application as they become more familiar with it. Also, as a business changes, the application must be easily modified to conform with new business requirements.

Success of your project will therefore mean the need to continually fine-tune the tool. Make sure you have technical personnel actively involved in its design and implementation. Tools that are based on open architectures like Microsoft quite often have the advantage of leveraging IT skills that already exist in many companies. Finally, build an effective and ongoing training plan that provides for your IT support professionals as well as your users.

Our experience has shown that most often, it's an understanding of the demand stream that is responsible for poor inventory performance: be it volume (too high) or mix. With hundreds and even thousands of SKU's, it is difficult for managers to have a good picture of demand characteristics that drive inventory problems.

For example, determine if you have a good handle on which products are fast moving, and which customers have a more predictable buying pattern. Identifying highly variable customers and isolating their demand can provide for more accuracy in demand planning. Moreover, general visibility into these trends is solid feedback into any regular planning process.

Visibility of aggregate channel inventory and channel warehouse inventory can also play a role in improving inventory performance. Your information systems should provide you with an easy ability to report on inventory characteristics on a daily basis that include: shipment volume, order and shipment variability, late shipments, days supply, turns and aggregate channel inventory.

This can be addressed in a number of steps. The first step is to establish an annual production plan in monthly buckets based on the aggregated demand data (by location and product). This step produces a constrained demand plan which then is used in an annual fleet planning process using the transit times between plants and customers. The fleet planning process produces an average estimate of annual fleet requirement. The planner can use this average estimate to produce a best case and worst case scenario to further analyze the impact of uncertainty on the logistics operation. This planning process has generated fleet reduction benefits anywhere from 10-40%. The cost savings is at least 2-3 times the cost of implementation.

We sometimes hear that salespeople are not inclined to participate in their firms' collaborative forecasting process. When we work with these firms, however, we see that the process for collecting forecasts from sales is quite often cumbersome. In such cases, salespeople feel as if they are being taken away from doing what they need to be doing - selling. Instead they are being asked to spend a great deal of time administering to a science that we all admit is inexact.

These objections aside, there are great benefits to having salespeople insert current market information into a demand plan. We encourage organizations moving down this road to make the process simple and to use a proper tool that allows sales to contribute in a way that is quick and easy. For example, you could begin the process by concentrating only on those customers that are highly variable and that account for the greatest percentage of shipments. Also, it is most often better to provide salespeople with the forecast and ask their input on an exception basis only for significant clients. In this way, they can provide valuable input for a change in a client order that may impact the business but do it in a way that takes seconds and is exception based.

Using Excel is often very burdensome for both the salesperson and for the demand planner who needs to aggregate the information. Excel is a great tool for a single user, but as a collaborative tool it has drawbacks because it forces a rigid process across all participants, so users end up spending too much time reconciling spreadsheets instead of doing valuable analysis.