Supply Network Planning (SNP) is SAP’s supply planning application. SAP APO is a broad advanced planning suite that includes, depending on how you count, around ten modules (although the bulk of its implementations are in just four modules). The relevant modules for supply planning and production planning are called Supply Network Planning (SNP) and Production Planning and Detailed Scheduling (PP/DS) respectively. As with all of the APO modules, SNP and PP/DS work in conjunctionwith each other. While there is some overlap (which will be explained), these are traditional sequential and supply planning first applications. Their design goes back to the mid-1990s, and both products are patterned off of products made by i2 Technologies,
SNP is part of the SAP APO/SCM advanced planning suite. It is the highest quality and most stable module in a suite, but that is not saying much because the overall APO suite is of overall poor quality.
SNP’s design is from the mid-1990s and offers three planning methods. They are the following:
- The SNP heuristic: This replicates MRP (material requirements planning) – which creates planned production and planning procurement orders.
- SNP Deployment Heuristic: The replicates DRP (distribution requirements planning) and creates the stock transfers between the locations in the supply network which is the deployment plan.
- Capable to Match, or CTM: This is an allocation method of supply planning that allows the prioritization of supply versus demand. So one could have some supplies processed in through the supply network before others, and some demand processed before other demand. CTM has no deployment method, so typically the SNP Deployment Heuristic is used to create stock transfers.
- 3. The Cost Optimizer
- The Network Optimizer: This creates the planned production and planning procurement orders. It works by setting a series of costs, both explicit costs (such as storage costs and transportation costs). Implicit costs (such as the cost of a lost sale), and then have the optimizer attempt to minimize these costs when it creates supply plan (and initial production plan) against a set of constraints. SNP then uses what we call method modifiers, which are master data that typically batch the orders to economic quantities.
- The Deployment Optimizer: This works the same way as the Network Optimizer, but it leaves out production – so uses the existing production plan as an assumption.
As with other supply planning systems, each method has some method modifiers that make the planning output realistic. That is if the order quantity created by the planning method is 320, but an economic quantity is 400, the order is rounded up to 400. A variety of controls of this type are placed in the master data which assigned to a product and location combination as is shown in the following screenshot.
The Lot Size tab of the Product Location Master has two sub-tabs. These two sub-tabs contain the method modifiers. SAP SNP has an enormous number of fields on its product-location master. In contrast, Demand Works Smoothie has a single “tab” for all of the supply planning parameters. While Demand Works Smoothie can adjust these parameters within the interface in groups, SNP cannot, but instead one must use a specific master data mass update transaction, which is inefficient, and most users do not do.
SNP has been designed more for sales than for effective implementation, and the more advanced methods in SNP – which is the main reason SNP is selected by companies, are poorly designed, meaning that SNP is not able to deliver more value than applications with much more straightforward methods.
None of this is unique to SNP. Instead, all of SAP’s APO modules give advanced planning a black eye, because of their poor quality. The problem is not advanced planning, but in the fact that buyers are not able to differentiate a bad solution from a good solution. Some very good supply planning applications can add serious value to a company. SNP does not happen to be one of them.
SNP is primarily implemented by large consulting companies, which while they may occasionally staff experienced personnel, do not fundamentally understand how to manage advanced planning projects, and can never lead their clients to choose the best planning applications. The major consulting companies are still stuck following approaches that have been shown not to work that is rooted in the first generation of planning products that were introduced in the 1990s.
This is a primary user interface view in SAP ERP. Most companies who implement SNP have already implemented SAP ERP. SAP APO is a more recently developed product versus SAP ERP, so it has a more sophisticated user interface (although it still lags all other advanced planning products that we cover)
Both of these views provide similar information, but the Product View is much more powerful and multi-faceted. (Although it’s not an elite user interface design, it is much better than the similar view in SAP ERP). SAP APO has something that SAP ERP does not have: the Product View can show more detail on peggings. A “pegging” is a connection between a supply element and a demand element. While a pegging is a single connection between demand and supply, a chain of peggings can show the relationship between a purchase requisition at the end of the supply network and a sales order or forecast at the very top of the supply network. This is shown in the following graphic.
The SNP 1 Tab holds both delay and non-delivery penalties. Because these penalties can be applied at the product level, some products can be prioritized over others based on differentiated non-delivery penalty costs. As with the other costs added to the optimizer, these costs are traded off against other costs. These costs are not necessarily the final costs that the optimizer uses because SNP has something called cost profiles, which can be used to further, adjust the cost values that are distributed in many different locations. The overall setup and maintenance of these costs are confusing and onerous. SNP is a complicated system to troubleshoot – and so once it is configured, it typically stays in the same state for years, because a small change can completely alter the output because of the interaction with so many settings.
SNP is marketed as a leading solution, but it does not have the most advanced method in supply planning, which is inventory optimization and multi echelon planning (MEIO). There are some reasons why MEIO is a far better method than cost optimization for supply planning. However, one of the most important is that service levels are far easier for companies to set than determining their costs. SAP argues that this functionality is integrated with SNP through their SmartOps acquisition – however, as is discussed in the SAP SmartOps analysis, this is only partially true.
SNP has a very high maintenance footprint, a maintenance level that is unsustainable for buyers that activate the more advanced functionality. This maintenance requirement catches companies unprepared, which is why in all of the SNP post go-live evaluations we have performed, SNP is in a state of disrepair.
As with every software category, which we cover where SAP has an entrant, SNP is the highest TCO application. SNP also has the lowest rated user interface of an application in this category, and this is just one of many reasons that SNP has low user adoption.
All scores out of a possible 10.
Vendor and Application Risk
SAP SNP is a bit of a hypothetical application which is designed more to be sold to buyers than to be implemented and maintained. SNP has an enormous amount of functionality contained within it, but like all the SAP APO modules, the functionality is hit and miss. SAP spends a great deal of time beating around the bush and future promising, bouncing messages back and forth between support and “Platinum Consultants,” but the fact is most buyers confirm the same problems with the various functionalities that are known not to work well.
Likelihood of Implementation Success
This accounts for both the application and vendor-specific risk. In our formula, the total implementation risk is application + vendor + buyer risk. The buyer specific risk could increase or decrease this overall likelihood and adjust the values that you see below.
Risk Management Approach
The best approach to implementing SAP SNP is to keep expectations low and keep the configuration as simple as possible. Using the SNP optimizer or CTM is very time consuming and once configured takes a great deal of effort to troubleshoot – and many issues will invariably arise. Keeping the configuration simple is critical because as the highest maintenance application in the supply planning software category, SAP SNP can quickly end up creating a support load that overwhelms the buyer. Activating functionalities like subcontracting, or attempting to model constraints from suppliers is asking for trouble.
Finished With Your Analysis?
Brightwork MRP & S&OP Explorer for Tuning
Tuning ERP and External Planning Systems with Brightwork Explorer
MRP and supply planning systems require tuning in order to get the most out of them. Brightwork MRP & S&OP Explorer provides this tuning, which is free to use in the beginning until is sees “serious usage,” and is free for students and academics. See by clicking the image below:
Software Selection Book
Enterprise Software Selection: How to Pinpoint the Perfect Software Solution Using Multiple Sources of Information
What the Book Covers
Essential reading for success in your next software selection and implementation.
Software selection is the most important task in a software implementation project, as it is your best (if not only) opportunity to make sure that the right software—the software that matches the business requirements—is being implemented. Choosing the software that is the best fit clears the way for a successful implementation, yet software selection is often fraught with issues and many companies do not end up with the best software for their needs. However, the process can be greatly simplified by addressing the information sources that influence software selection. This book can be used for any enterprise software selection, including ERP software selection.
This book is a how-to guide for improving the software selection process and is formulated around the idea that—much like purchasing decisions for consumer products—the end user and those with the domain expertise must be included. In addition to providing hints for refining the software selection process, this book delves into the often-overlooked topic of how consulting and IT analyst firms influence the purchasing decision, and gives the reader an insider’s understanding of the enterprise software market.
By reading this book you will:
- Learn how to apply a scientific approach to the software selection process.
- Interpret vendor-supplied information to your best advantage. This is generally left out of books on software selection. However, consulting companies and IT analysts like Gartner have very specific biases. Gartner is paid directly by software vendors — a fact they make every attempt not to disclose while consulting companies only recommend software for vendors that give them the consulting business. Consulting companies all have an enormous financial bias that prevents them from offering honest advice — and this is part of their business model.
- Understand what motivates a software vendor.
- Learn how the institutional structure and biases of consulting firms affect the advice they give you, and understand how to properly interpret information from consulting companies.
- Make vendor demos work to your benefit.
- Know the right questions to ask on topics such as integration with existing software, cloud versus on-premise vendors, and client references.
- Differentiate what is important to know about software for improved “implement-ability” versus what the vendor thinks is important for improved “sell-ability.”
- Better manage your software selection projects to ensure smoother implementations.
- Chapter 1: Introduction to Software Selection
- Chapter 2: Understanding the Enterprise Software Market
- Chapter 3: Software Sell-ability versus Implement-ability
- Chapter 4: How to Use Consulting Advice on Software Selection
- Chapter 5: How to Use the Reports of Analyst Firms Like Gartner
- Chapter 6: How to Use Information Provided by Vendors
- Chapter 7: How to Manage the Software Selection Process