Feeds:
Posts
Comments

New Book on SAP SCM

December 9, 2009 by sapplanningadmin

Well, it was a lot of work, but my new book is now available.

Discover SAP SCM

The book is titled Discover SAP SCM and is published by SAP Press. It provides an overview of the entire SAP SCM suite and is a good book for those new to SCM, for those who work in SCM, but looking to get a broader view. It is also useful for decision makers as a guide for which specific modules in SCM offer their companies the highest opportunity. It includes an overview of all the modules in SCM, but also chapters on how SCM has developed as of 7.0 and frank coverage of topics related how to get more value from SCM and how to perform ROI analysis on prospective SCM projects.

See the link below for details.

http://www.sap-press.com/product.cfm?account=&product=H3098

Posted in APO, SCM Introduction | Comments Off

Customer Prioritization and CTM

December 8, 2009 by sapplanningadmin


Prioritization in Capable to Match (CTM) works on the principle of running some customers through the planning process, and allowing them to have inventory pegged to their requirements before others.

The Tricky Business of Customer Prioritization

Business have a number of ways that they want to prioritize customers. Different departments within companies like to prioritize customers in different ways. There are a seemingly unlimited number of ways to prioritize customers and some examples can include:

  • By customer location
  • By contract (i.e. different customers are allocated to different contracts)
  • By customer product

However, what is often not well understood for companies implementing APO, is that CTM’s prioritization capability (and what eventually becomes allocations which are managed and enforced by GATP, if GATP is in the solution architecture) is much more limited than the prioritization imagination of those coming up with the prioritization scheme. This is why it is important that the prioritization sequence not be created in isolation without understanding what CTM can actually provide. This is not to say that CTM is not quite capable. In fact, I consider CTM to be one of the strongest areas of functionality within SAP SCM. However, what it can do and can not do should be impressed upon the business decision makers, and the earlier this happens on projects the better.

How CTM Works…at a High Level

One does not need to be a CTM expert in order to understand what CTM is doing. In fact, it is simple to understand.CTM works by sort order on both the demand and supply side. CTM allows segmentation of the following:

  1. On demand side, which is made up of customers
  2. On the supply side, which is made up of inventory and planned inventory

Supply and demand is then applied to different master data selections. Thus a CTM run can be performed with the following filter or limitations:

  • For all the locations in the supply network or just one location, or any number of locations in-between.
  • For all the sources of external procurement or in-house production, for just external procurement or just in-house production, or for any combination of limited sources of the product.
  • For any time period restriction, or completely unrestricted. (Thus a CTM run could be performed which only creates allocations for one day, or have no limit on the time whatsoever)

Now that we have covered the setup and basics of CTM, we can move on to how CTM is actually run.

The Running of CTM

A CTM run uses the combination of the supply, demand and master data selection to performsequentialplanning. The actual process it uses is simple. It runs some demand segments (i.e. customers) before others. Thus, these earlier runs consume inventory through pegging, and then later runs and demand segments have less inventory available to them because the previous runs have taken it. At some point inventory is no longer available for the lowest priority demand segments.



CTM lines up your customers, or customer categories in order. In this way it is glorified queueing software.

Permanent or Temporary Connections Between Supply and Demand Elements?

CTM can be run in a way that fixes pegging, which means that once the association between the demand element and supply element is made, it can not be altered. The other way to run CTM is called dynamic pegging, where after every run all the demands and supplies are re-pegged. (We have never understood the purpose of dynamic pegging, and also never seen it used). There are many other features, but are beyond the scope of this article, and other articles that explain more detail about CTM are available in the reference section below.

Traditional Problems with CTM Implementations

An important consideration is that the more times that the supply and demand selections are segmented and more the master data selections are segmented (as opposed to running for all selections and all sources of supply) the more complex the model becomes, and the more difficult it becomes to maintain and to make changes to. What I have seen happen on two implementations is that the number of CTM profiles combined with the master data selections grows to be too large and too complex.

CTM and the Service Level Based Contacts Example

Many companies that are in the finished goods business are attempting to implement service level based planning and contracts. What this means is different customers are assigned to different “contracts.” However, if a number of customers are combined into one category, then CTM will not prevent one of them from taking inventory from others. Lets use an example to make this cleaer. Take the hypothetical 3 customers that are shown in the graphic below. They are all gold level contract customers so they are initially placed in the same CTM profile and run through at the same time.

  • Scenario 1: Because of this they all have the same priority and capability to take inventory.
  • Scenario 2: However, after running CTM for a while the company begins to notice that because customer 3 places such high order quantities onto this company, even though customer 1, 2 and 3 are all in the same priority, customer 3 takes too much inventory from the other two customers in a way that the company deems not consistent with its strategy in the market. So the decision is made to break customer 3 into its own profile.


However, now the question is should customer 3, which is now in profile B always be run below customers 1 and 2 in profile A. They are after all the same priority level and paying the same premium contract rate. If they are a big customer, there will be plenty of pressure to sometimes run them first. Perhaps a compromise can be reached. In this hypothetical example it turns out that customer 3 is really only “hogging” the supply for 4 to 5 products. The agreement is made to create two CTM profiles for this customer. One for products that it does not over-consume, and one for products that they consume at an acceptable rate. This third profile will be profile C.

Conclusion and Key Observations from CTM

The decision by sales is to run customer 3 first for what is now profile C first, then run profile A with customer 1 and 2, and finally run profile B. Where there was once 1 profile, there are now three. Now imagine how many scenarios like this pop up during and after an implementation and its easy to see how the number of profiles can quickly get out of hand. Part of the problem is that there can be the assumption on the part of the business that CTM performs prioritization magic (it really doesn’t, it simply sequentially allows some demands to come in before others), and secondly there can be the assumption that there is no cost to setting up finer and finer levels of prioritization. This is also not true. Every time a CTM profile is created it has to be maintained. Every time a new policy regarding prioritization is brought, the CTM profile(s) need to be changed. It is a simple relationship, and it holds true for planning in general. That is the more detailed the planning, the higher maintenance the solution, and relatively speaking the less maintainable the solution will be. The right balance is never what is perfect for business requirements, nor what is lowest maintenance for IT, but somewhere in between. That is a level of complexity that the company is willing to pay for to maintain.

Related Material

If you are interested in reading into more detail on some of the topics presented in this article these other articles may be of interest.

CTM Introduction http://sapplanning.org/2009/05/09/ctm/

The CTM Profile http://sapplanning.org/2008/09/18/ctm-profile/

ATP Categories http://sapplanning.org/2009/09/19/atp-categories/

How Pegging Works

http://sapplanning.org/2009/05/06/pegging-in-scm/


Posted in CTM | Comments Off

How Marketplaces Influenced the Collaborative Aspects of SAP SCM

November 25, 2009 by sapplanningadmin


All software begins with an idea. In this post we will discuss the inspirations for some of the more collaborative aspects of SAP SAP.

SNC Related to B2B Marketplaces?

An interesting question to ask is how SAP’s relationship with Commerce One influenced its Supplier Network Collaboration (SNC) product. At first glance it may be difficult to detect. After all, SNC is not a marketplace component after all but a collaboration product. It is designed to connect a buyer to suppliers by providing them a hosted solution to login to. In this way it is one (the buyer) to many (the supplier) rather than many to many (many buyers and many suppliers) which is the design of a B2B marketplace. However, at least conceptually, SAP was openly discussing the importance of collaborative forecasting and collaborative inventory back in 2001, at least within the context of marketplaces. So we can’t say we have compared the code of the few marketplaces that SAP constructed with Commerce One, we can see some areas of functionality that SAP clearly adopted from its marketplace experiences and incorporated in to SCM.

Marketplaces and Freight Tendering in TP/VS

One area that most definitely did affect SCM was one of the few marketplaces that was actually semi-successful, FreightMatrix by i2 Technologies. Of all the marketplaces of plastics and electrical components, it turns out that a meeting place between shippers and carriers (or 3PLs) is quite necessary. This allows shippers to place shipment out to bid, and for multiple carriers to bid on the freight. This is now represented by the transportation tendering functionality in Transportation Planning and Vehicle Scheduling (TP/VS).

This Historical Impact of Trends on SCM

While a number of the hyped area of supply chain never became common practice, some of the concepts, such as cross organizational supply chain planning and execution eventually did become incorporated in SCM. What the industry, along with SAP learned in the intervening years between the initial prominence of companies like i2, Manugistics, was that advanced planning was only one component of the advanced supply chain functionality desired and needed by companies. Another lesson, which is not frequently discussed, because it does not promote sales, is advanced planning can not be implemented at just any company. Advanced planning’s main draw, optimization was oversold as a mechanism for supply chain improvement. It was too sophisticated for most clients who were looking for an improvement over the planning capabilities in SAP ERP, but not necessarily ready to commit to optimization.


Posted in Main | Comments Off

The Rise and Decline for Supply Chain Optimization

November 25, 2009 by sapplanningadmin


Optimization has proven much more tricky to implement that originally thought. Optimization where the company must agree internally in order to set costs, is far more difficult to implement than where the optimization is essentially a black box.

Optimization: A Solution That Drove and Industry

In its early years, APO was sold on its ability to perform optimization. This is primarily because it was an industry wide practice to market advanced planning software in this way. In fact, APO or Advanced Planner and Optimizer – had the term directly in its name. The term optimization has two meanings as generally used. One is more of a business use, which basically means to produce the best outcomes. However, in the area of operations research, from where supply chain optimization originates, it has a more specific meaning. For those that did not do work in operations research or advanced mathematics, (which is a sizable portion of the business community and the executives who evaluate SCM) its more technical definition is unknown. For this reason we wanted to explicitly define it here.

“In mathematics, linear programming (LP) is a technique for optimization of a linear objective function… Linear programming is a considerable field of optimization for several reasons. Many practical problems in operations research can be expressed as linear programming problems. Certain special cases of linear programming, such as network flow problems and multi commodity problems. Although the modern management issues are ever-changing, most companies would like to maximize profits or minimize costs with limited resources. Therefore, many issues can boil down to linear programming problems.“ – Wikipedia

Linear vs. Discrete Optimization

Optimization works best in situations that are perfectly “linear,“ that is inputs can be increased or decreased in a continuous fashion. An example of a linear input would be an order quantity. Perfect linear optimization would mean that any order quantity from zero to infinity could be placed and fulfilled. In reality, supply chains are not perfectly linear problems. For instance, the lot size is a discrete value which limits the flexibility of the order quantity. One item may be ordered in units of 50. If 135 units are desired and the current inventory is less than 35, then 150 must be ordered to meet this demand. SCM has a number of techniques, such as lot size, than alter the problem being solved from perfectly linear, to discrete, or what is known as a step function. This is very important to making the resulting recommendation realistic.

The Decline of Optimization

However, while optimization drove development in SCM at one time, it no longer does. The evidence for this is that optimization is an option in three of the older modules (SNP, PP/DS and TP/VS), but is not an option in any of the newer modules (EWM, SNC, EM, SPP and F&R) Furthermore, the core optimization functionality in SCM has been stabilized for some time. A related story to this is that optimization did not meet its originally envisioned potential.

What is Actually Running the Solution?

There is a story at the client of an advanced planning vendor that the optimizer engine that was running in the background was not operational for a number of days, and no one noticed. This was because the planning was primarily being performed by heuristics that had been custom coded with scripts and the solution was not using the optimizer at all. Whether the client knew the optimizer was not being used is unknown. This is more common than a reading of press releases and industry periodicals in the area would think. While optimization is what sold a lot of supply chain software, but it was not necessarily what the customers of these solutions went live with. As is evident from our example above, this experience is wider than simply SAP SCM.

Why Not Optimization?

If optimization did not “change the world“ of supply chain, the question naturally becomes “Why not?“ There are probably a number of reasons, however, in our view one of the most prominent came down to implementation and maintenance difficulty combined with company knowledge. Implementing and maintaining optimization methods requires a great deal of effort and long term investment. Secondly, optimization requires a great deal of discipline and knowledge on the part of the implementing company. Many companies want the benefit of advanced planning, but are not culturally, financially or prepared from a skills perspective to make the sacrifices required in order to obtain the outcomes they desire. More often that not, companies want simple solutions that delivery value over a short time horizon. That is not what optimization delivers. On the other hand, software deserves some of the blame as much advanced planning software has been designed to be more complex than is necessary.

Conclusion

Optimization is always the most complex and difficult of implementation, but also brings significant benefits if implemented correctly. However, for most that mountain is too high to climb. I sometimes get email from technical people who really like optimization and wonder why I am “negative” on it. This has nothing to do with whether I personally like optimization or not. I am reflecting the experience of companies, most of which are unsuited to use it. A lot of money has been spent or wasted on optimization that could have been used to solve much more simple problems in the business. Solving these simpler problems has a higher payoff, and thus should be addressed first. In addition to lower investment, the returns from optimization have not been encouraging, and thus its incumbent upon me as a consultant to bring these failures to light for clients, and the direct them towards solutions that have a higher probability of success.


Posted in PPDS, SNP | Comments Off

The History of APO and the Influence of i2 Technologies

November 24, 2009 by sapplanningadmin

Introduction

In order to understand SAP Supply Chain Management‘s (SCM) design, its important to understand the environment when it was first developed and released and how the environment changed as SCM was continually developed. This history below is seen through the lens of the author who began in SAP ERP, and then switched to i2 Technologies, before moving into SAP SCM several years later. It is an interesting story, which we have not seen documented elsewhere, and which also provides an insight into SCM in terms of its design and orientation. This history can, if internalized and analyzed, be used by companies to make informed decisions about future supply chain implementations.

SCM Origins

SCM (as Advanced Planning and Optimizer (APO)) was introduced at the height of the advanced planning trend back in 1998. This was a period where i2 Technologies was the number one advanced planning vendor, and Manugistics was close on its heels. Its hard to conceive of at this point because SAP SCM is so dominant in the advanced planning space, but SAP was not seen as a factor and was not predicted to become one.

At one time i2 Technologies and SAP entered into a joint development relationship that SAP eventually broke off (the details of how and why are unknown to us), however, while the relationship never resulted in a product, it is clear from analyzing the early APO footprint that SAP was heavily influenced by their relationship with i2. What we can not say is how many of the ideas or methods from that partnership ended up in the APO product. However, because we worked at i2 we can provide an insight into i2‘s functionality and scope during the partnership.

APO’s i2 Influence

Planning engines need a lot of memory. The SAP SCM name for this memory area is called liveCache.
At the time i2 was very strong in factory planning and supply chain planning. They were known for memory resident engines that were able to plan and re-plan very quickly. Up until this point, planning systems would not pull the entire problem into memory, but would write back and forth between a database. I2’s contribution was to load the entire problem into memory, which was only possibly because of the hardware improvements in memory capacity and price. They were also one of the first companies to use the term “optimization“ in the supply chain space for its marketing literature, and also in promoting the benefits of supply chain optimization. The term optimization soon became a buzzword and highly desired functionality, even though many of the executives and their supporting managers at companies, as well as analysts, most likely did not understand the operations research based meaning of the term. i2’s early successes at companies such as Texas Instruments made industry sit up and take notice to take a look at this “advanced planning thing.“ Its hard to believe as I write this, but at one time i2 was actually viewed as a threat to SAP’s core ERP product. A number of analysts began disparaging SAP for not having an advanced planning suite. In hindsight this interpretation seems quite unfounded, as the two applications do different things. Even if i2 and Manugistics had continued to grow and SAP had never brought out APO, companies would still need SAP ERP because advanced planning applications do not actually process the recommendations. There was some discussion by arm chair theorists about getting rid of execution systems all together, but that was always a myth. Planning systems always need an execution system, like SAP ERP in order to do this. However, unfounded it was part of the psychology at the time, and most certainly influenced SAP’s decision to seek a partner in the advanced planning space. These vendors were bringing out functionality in supply chain that made SAP ERP seem staid at the time. In this way APO can be seen as a defensive product brought out to neutralize the momentum of vendors like i2 and Manugistics. From reading statements of SAP executives at the time, it seems that they were not particularly enthusiastic about developing APO and were probably perplexed that some customers were even interested in this functionality. While there is some overlap between the two, planning and execution systems are primarily complimentary.

The Early Versions

The earliest versions of APO impressed no one, and it almost certainly would not have survived if SAP had not given the product away for free at existing SAP ERP accounts. Furthermore, because SAP had always outsourced such a large percentage of its consulting to the large consulting companies, they were literally some of the first adopters of APO. It is estimated that in the early stages ¼ of all the APO installations were at consulting companies that had setup training systems.Thus APO had two strong selling points that the niche advanced planning vendors could not match, even while the functionality greatly lagged:

  • Large consulting companies had the incentive to promote APO with their SAP ERP clients as they would get more of the consulting work. (the niche vendors never had the relationships or outsourced the same percentage of consulting to the major consulting companies)
  • APO was integrated to SAP ERP (for details see chapter 9).
  • SCM’s early incarnations featured five modules:

1. DP
2. SNP
3. GATP
4. PP/DS
5. TP/VS

This solution design was limited to these modules as late as APO 4.1, although Internet Collaboration Hub (ICH) appeared for some time before 4.1, but never became a completely developed module until later releases.


Posted in Definition | Comments Off

The Differences Between ERP and Advanced Planning

November 24, 2009 by sapplanningadmin

This post is for those who either have the question, or are questioned on the differences between traditional ERP and advanced planning.

Supply Chain Planning vs. Advanced Planning

It’s important to draw the distinction between supply chain planning and advanced planning. Supply chain planning is covered by the modules of SAP ERP Sales and Distribution (SD), Materials Management (MM) and Production Planning (PP). These provide supply chain execution functionality along with some basic planning functionality (safety stock and MRP, basic forecasting, availability checking, and production planning among a few others) but none of these modules cover advanced planning. Advanced planning is future based and deals in different scenarios, presenting them to planners, which then pick the best alternative. In advanced planning the plan may be recreated several times before it is firmed and sent to the execution system. True advanced planning systems cannot execute recommendations; they can only make recommendations. Thus while SAP had supply chain applications for some time before APO, APO was SAP’s first venture into advanced planning.

Looking historically back as SAP’s motivation for creating SAP APO, SAP at the time was being pressured by analyst firms and Wall Street to create a separate set of applications, rather than incorporate advanced planning within SAP ERP. Planning systems work fundamentally different from transaction processing systems. At one point, SAP felt that advanced planning was overly esoteric and would only ever be desired by a small fraction of their customer base. Somewhere along the line, and in the early stages we propose it was primarily driven by market expectations (as we explain further on) they changed their view and developed their own advanced planning suite.


Posted in Definition | Comments Off

Older Posts »