S&OP is not a software driven project.

The recent blogs discussed how Sales and Operations Planning (S&OP) can provide the basis for a different way of managing your business. For success, it requires changes to the culture and responsibilities, managing the new process and to a lesser extent, use of software applications.

Many activities can be improved through integrating technology – new cars are more efficient and safer than even ten years ago; but a ten year old car (and older) can still be used. So it is with S&OP, it will be a better implementation (given the culture change and process are happening), if aided by the latest software applications. But not having them does not diminish the high level of success possible from better planning through changing the culture and managing the process.

It is a matter of setting expectations. The initial roll-out of S&OP will not achieve all that is possible – it will take time. S&OP will utilise data generated from your organisation’s ERP system and initially can use Excel spreadsheets, email and PowerPoint slides to assist the process, but accept their limitations. It also requires a person who understands the planning requirements and knows how to structure and drive spreadsheets (not always an easy find).

As the roll-out of S&OP occurs (typically taking about six months for participants to feel comfortable with the change in culture and process), participants will recognise the limitations of the software tools. Your organisation’s supply network is a complex adaptive system; it cannot be modelled, nor multiple “what-if” scenarios developed using spreadsheets. Nor will email  provide collaborative workflow and exception messaging.

Document requirements

This situation provides an opportunity to commence identifying the ‘wish-list’ of requirements for a dedicated S&OP application. The slow adoption of S&OP in industry has resulted in limited choices of available applications (sold mainly in America). The lack of ‘commercial off the shelf’ (COTS) S&OP applications (which could be ‘cloud-based’), means that enterprises need to consider multiple options: buying a full application from an overseas based software firm; buying multiple applications that support parts of the requirements and interfacing them, using a local software developer or working with local developers and in-house IT to develop the application.

Whatever the direction taken, a requirements document must be produced by the users. However, because users may not be confident to scope and define the  requirements, they could be written by a consultant who understands S&OP. A requirements document must always commence with the desired business outcomes and work back to the requirements.

Within the document identify the current and expected future role of the ERP system and its relationship to S&OP. Instead of a comprehensive ERP system that may not meet all user requirements, a future system structure could have ERP as the transaction backbone for the business, containing an audit trail of all transactions, plus accounting, operations control and HR records. ERP would interface with specialist supply network analysis and planning (SNAP) applications. Initially, the objective is to accept ERP outputs (Rough Cut Capacity Planning (RCCP); Master Schedule (MPS); Materials Requirements Planning (MRP) and Capacity Requirements Planning (CRP)) as input to S&OP, but later there could be greater reliance on SNAP applications as the inputs.

Master Data

As data is available from multiple applications, data management help to ensure that inputs are accurate before being uploaded into the S&OP process. This requires attention to customer and item masters, including units of measure, time horizons, bill of materials (BOM) structure etc. Also, identify the levels of accuracy required for decisions (gross margins, inventories, capacities, service levels etc.), as items are rolled-up from product line to product family.

The diagram illustrates an outline of requirements for S&OP; the actual requirement for your organisation could differ.

Sales Planning – sometimes called Demand Planning, but few organisations have sufficient market inputs to measure demand. Factors to be considered are:

• Sales history
• Sales Forecasts by product line/group aligned to a S&OP product family. based on sales channels and customers and out to the S&OP planning horizon
• Pipeline and backlog orders aligned to a S&OP product family
• Demand Shaping – incentive programes designed to increase customer and consumer demand. Includes  product promotions, price reductions, trade and sales force incentives
• Sales and Revenue Plan, with reference to internal sales targets
• Marketing plans for product life-cycle: run-outs, new and enhanced/upgrade product release timetable and product development pipeline

Supply Planning factors to consider:

• Conversion of units of measure to standard units of measure; ensuring conformity across operations
• Product lines allocated to Product families in S&OP
• Constraints: Material and component; Manufacturing capacity; Distribution capacity; Transport
• Variability of demand and supply by product family

Supply Network Map factors to consider:

The Supply Network Map is based on four elements: Nodes, Variables that can affect items at a Node, Links between Nodes and Flows of items, money, data and information between Nodes via Links. A Map allows different forecasts scenarios to be plotted for a better understanding of:

• Actions to improve supply chain performance for each forecast, new product introductions and product end-of-life situation
• Possible changes to suppliers (Nodes and Links)
• Trade-offs between costs, gross margin and customer service

Inventory Policy 

Inventory Management includes three element: Policy, Planning and Control. Policy (the investment in inventory, including safety stock targets and the location of inventory) is considered at the S&OP level. Factors to consider:

• Form and function of inventory by location – this could be included in the Supply Network Map
• Value of inventory by location
• Inventory optimisation techniques in situations where product and/or component substitution is possible, such as electronics

Document workflow and Facilitating meetings

This is the administrative level of S&OP. It recognises that people work in different departments and facilities, so is designed to facilitate the connection of people and information:

• Enabling access to documents and sharing data between participants
• Downloading of aggregated product family data
• Facilitating meetings in a S&OP cycle
• Posting questions and responses from participants

S&OP Workbench and Analysis

This is the engine room of S&OP and the most complex element of the application to design. The build requires a capability to balance across a range of inputs and possible trade-offs, requiring advanced IT skills and software tools:

• Demand – Supply balancing based on physical quantities and gross margin
  • Calculation process identifies Alerts and Exceptions
  • Participants at meetings in the fourth week in the S&OP cycle – the ‘pre-executive’ meeting and the S&OP executive meeting, need to easily visualise the information and understand the impact of various alternatives, although the level of detail will differ
• What If Analysis
  • Perform scenario analysis e.g. the impact on resources of changes in product mix
  • New product introduction and end-of-life scenarios
  • Consolidate date from multiple sources, by channel, customer and gross margin
  • Multiple time buckets (month, quarter, annual)
• Incorporate financial projections – impacts on gross margin, contribution, cash flow and working capital
• Analyse the impact of risks and opportunities – to be discussed in the next blog, published on August 15

Building an information base to assist decision making through the S&OP process is not a trivial matter. However, we are talking about degrees of sophistication. Improved decisions concerning sales and operations can be made through a co-operative team approach using basic information. As the team grows in confidence of the process, so software applications can be used to improve decisions.