My presentation looks at the pro’s of implementing Demantra & SCP from ResMed’s perspective, and some of the tricks and traps we have experienced
ResMed manufactures in two main sites in Sydney and Singapore and distributes through a central warehouse in Europe and a network of distribution centre’s globally to customers
In many cases we talk about the financial benefits we expect to achieve from these types of systems, however there are many non-financial reasons to implement, and these were some of the major reasons for ResMed going down this path with Oracle. Our existing systems were already performing reasonably well.
At ResMed we have achieved much of the tangible benefit from improved forecast accuracy. Increasing forecast accuracy at this point is not the path to reduced inventory because much of the inventory holding is required to support variation in the supply chain, not variation in sales. Resmed’s shipping lead time from plant to customer is around 8 weeks. Supply chain planning becomes a critical element here as an effective system is required to ensure that production and shipping occur to optimise service and minimise freight costs. Objectives will be to ensure that stock is held at an optimimum position in the supply chain hub, that distribution around the wheel occurs if it is desirable to meet objectives, and that stock is distributed on a “fair share” basis in a short supply position
Addressing or achieving the “intangible benefits” was one of the key drivers for ResMed to implement both Demantra and ASCP
My presentation focuses more on the intrinsic benefits of implementing Demantra & SCP from ResMed’s perspective, and some of the tricks and traps we have experienced
Demantra and ASCP both have possibilities that to some extent will be unlocked based on the calibre of people you have. Key users are System developers, database administrators, power users, casual users. In terms of ownership, we have placed this in the hands of the business, rather than IT, which creates more autonomy to develop the system. This won’t be the case for ASCP due to greater complexity.
We see these as the key users, each will require certain skills levels in order to perform effectively
One of the key considerations is how and where will data be loaded into ASCP, and how will the determination of destination be determined?
We captured data by warehouse/customer combination as that was the most feasible at the time. We didn’t perceive a problem as supply sources are largely handled by Sourcing rules within Oracle ERP. It is only with the move to multiple central warehouses shipping direct to customers that this has become a problem. In hindsight perhaps we should have changed to Customer/Region relationships and tried to fix the underlying data problems.
Using Customer/Region relationships
Data stability will help improve the quality of forecasts generated by Demantra. Managing supply chain processes and variations could help improve results.
It was felt that capturing data for all customers would lead to discontinuous and erratic forecasts, and degradation of system performance, however we still wanted the ability to analyse sales at a customer level. The compromise was to capture individual customer sales where the customer was big enough to generate good forecasts, and bucket sales where they were not
Within our database there are many items and parameters that haven’t been maintained over time. This has turned out to be problematic in implementing ASCP particularly as this “unclean” data makes it difficult to get to real issues. In addition, inappropriate use of fields through lack of foresight in some cases made what could have been simple/effective solutions difficult or impossible.
Utilise experience and knowledge of consultants to avoid hidden pitfalls during system development
We see constraint based optimisation through ASCP as our solution to replacing our existing systems (which are effective but not robust) with an effective and efficient alternative
Demantra & ascp
Using Oracle Demantra & ASCP in a Global Planning EnvironmentPhillip BrownResMed16 August 2010<br />The most comprehensive Oracle applications & technology content under one roof<br />
Interfaces with Oracle ERP for manufacturing & distribution</li></li></ul><li>ResMed…global operations<br />
Why implement?<br />Tangibles…<br />Positive ROI<br />Reduce inventory<br />Reduce backorders or lost sales<br />Intangibles….<br />Manage increased business complexity<br />Introduce process stability<br />Reduce dependence on specific individual knowledge<br />Provide foundation for future growth<br />
Why implement…tangible reasons<br />Maximum inventory reduction from forecast accuracy achieved<br />Current forecast accuracy ~90%<br />Variation in supply chain now greater challenge<br />Variations in shipping times<br />Delays through customs<br />Stock discrepancy & quality issues<br />The need to rebalance between nodes without triggering new builds<br />
Why implement…intangible reasons<br />Key drivers for Demantra<br />Increasing distribution complexity<br />Risks associated with reliance on individuals<br />Risks with lack of robustness in existing system<br />Need for seamless global system that facilitates accountability and visibility<br />
Why implement…intangible reasons<br />Key drivers for ASCP<br />Increasing distribution complexity<br />Need for more effective optimisation model<br />Need to remove reliance on individuals<br />Risks with lack of robustness in existing system<br />
Musings about Demantra & ASCP<br />Why Demantra wont improve your forecast accuracy…further<br />Do I have the right people?<br />Getting ASCP & Demantra to work together<br />Tips & traps…I wish I hadn’t done that!<br />
People puzzle…<br />Demantra, & to some extent ASCP evolution will be influenced by… <br />caliber of people available to perform various roles<br />defining ownership between Business Process and IT<br />Degree of autonomy of users<br />
People puzzle…<br />Key users involved with the running of Demantra…<br />System developers<br />Database administrators<br />Power users (demand planners)<br />Casual users<br />
Integrating ASCP & Demantra…<br />Loading forecasts to ASCP<br />Create customer/warehouse combinations in Demantra<br />Load based on warehouse<br />Create customer/region combinations in Demantra<br />Map regions to warehouses through dynamic combinations table<br />
Integrating ASCP & Demantra…<br />Using Customer/Warehouse combinations in Demantra…<br />simple distribution operation<br />creates visibility of warehouse demand in Demantra<br />data integrity for customer/region combinations is not available from source<br />Downside…<br />changes in Warehouse source for a given customer is not easy to update in Demantra…can lead to erroneous forecasts<br />
Integrating ASCP & Demantra…<br />Using Customer/Region combinations in Demantra…<br />allows greater flexibility to change distribution network without impacting forecast<br />could facilitate forecasts by territory/sales person or other similar splits<br />Downside<br />requires available data integrity to support this…ResMed didn’t have this on a global basis<br />
Improving forecast accuracy…<br />Modify buyer behaviour rather than modifying forecasts<br />Many sales incentives encourage customers to buy in erratic patterns. Erratic demand makes forecasting difficult. <br />
Tips & Traps…tips<br />Bucketing of demand<br />Not too much/not too little gives a balance between system performance and quality info<br />ResMed option<br />Capture data by customer for top 50% revenue<br />Bundle data of customers for next 30% revenue<br />Bundle data for remaining 20% revenue<br />
Tips & Traps…tips<br />Capture demand not sales<br />To give true indication of future potential demand<br />Recognises customer orders in the period they were requested, whether shipped or not, as opposed to shipped or invoiced orders<br />Forecasts in future periods are then based on customers desires rather than operation capability at a previous point in time<br />
Tips & Traps…tips<br />Create separate inputs for functions<br />Such as separate series to create visibility of user inputs<br />create clear override hierarchy for forecast modification<br />Creates opportunity for input of reference forecasts for future comparison or negotiation (eg Marketing/Finance series)<br />
Tricks & Traps…traps<br />Maintaining data for full spectrum of items<br />Ignoring data for “inactive” codes may present problems later for things like exception reports<br />Avoid inappropriate use of fields<br />inappropriate/inconsistent use of fields such as “Territory” makes them difficult to use for meaningful data capture later<br />
Conclusion<br />Support through implementation<br />Oracle consultants provided effective guidance in the direction we took<br />This was useful in either tempering our expectations, developing our ideas or providing alternatives to arrive at effective solutions<br />Few changes were made after implementation largely as a result of an effective collaborative approach between Oracle & ResMed during development<br />
Conclusion<br />Future direction<br />Our key challenge now is implementation of ASCP<br />Objective is constraint based optimisation<br />Horizon of at least 12 months to enter this phase<br />Implementation of unconstrained ASCP as precursor to this<br />
Tell us what you think…<br />http://feedback.insync10.com.au<br />