What is a composable ERP?
Composable ERP as the same suggest is an ERP system made of components from different vendors, different technologies. From the historical point of view I hope I'm not making any heresy to say that this was the way how SAP started "back in the days". At that time (and still the case) SAP was a company producing the most reliable SAP FI system in the world. All other parts of a modern ERP system were at that time done in legacy/non-SAP applications. Later on SAP ERP became an integrated system having all other modules (Sales and Distribution for OTC, Materials Management for PTP, PP for Manufacturing, LE for shipping). When we go back to 2023 many of the SAP customers still use 100s or 1000s of nonSAP applications connected with integration platforms (like SAP Process Orchestration or SAP Integration Suite) to their SAP ERP core. One of the very commonly decentralized applications is the warehouse management system. SAP has always supporter this scenario and even provided a certification path for ISV called - Decentralized Warehouse Management Scenario (DWMS). In this article I'd try to highlight why using a Decentralized Warehouse scenario makes sense, what are the common challenges and how to solve them. Another aspect of the same might be the usage of 3PL (3rd party logistic provides) which may also act as a decentralized warehouse and even thought it's not managed within the company premises it still constitutes a part of composable ERP.
Why use a Decentralized Warehouse (also in 3PL scenarios)?
Decentralized warehouse management in SAP scenarios allows the use of multiple, independent warehouse management systems that can be connected to a central SAP ERP system. This approach for warehouse management allows for increased flexibility in operations, as each warehouse can be optimized for its specific needs and requirements. For example, one warehouse may specialize in fast-moving items, while another may focus on slow-moving, high-value items, etc. Decentralized warehouse management also provides more accurate inventory tracking, as each warehouse is responsible for maintaining its own inventory levels. This eliminates the need for manual inventory reconciliation between different warehouse locations, which can be time-consuming and error-prone. Additional factor is also cost - in most cases the cost of external WM system would be much less to comparable solution from SAP (important - not taking the cost of implementing the integration between the two).
In case of a 3PL scenario the external system might even be another SAP system but since it's not managed internally it needs to be connected with the use of the interfaces.
What are the common pitfalls with composable ERP and Decentralized Warehouse in particular?
- Integration - in order to connect two applications from different software vendors you need to create a few integration scenarios. In case of the 3PL it's exactly the same even if SAP WM is being used at the other end. Those projects are very well known and you can get a lot of experienced consultants but make sure you use the DWMS scenario and not the standard message outputs for orders and deliveries (yes many SAP external warehouse management projects are not aware of the standard DWMS scenario prepared by SAP). Inbound delivery integration shown in the Figure below.
Outbound delivery integration shown in the Figure below.
- Reconciliation - everyone believes this is the last thing you need to worry about (transactions are most important) but let me tell you this, if due to wrong setup and reconciliation the material levels are not the same in WM and SAP ERP it will not work that well... to say the last.
- Testing - while integration and reconciliation is something most SAP projects are aware of, not a lot of companies think about the fact that SAP developers and SAP functional consultants (OTC, PTP) will not be able to run most of their tests without asking someone from the DWMS/3PL site for help. What this might cause apart from delaying the project and resulting with not tested, wrongly working interfaces is the lack of autonomy for SAP developers and SAP functional consultants while working on such an important project.
What are the possibile mitigation scenarios?
- Integration - make sure to get a team who understands that DWMS scenario is not using standard IDOCs (DELVRY03/ORDERS05) but runs with it's own special interfaces like SHP_IBDLV_SAVE_REPLICA04, SHP_OBDLV_SAVE_REPLICA03, etc.
- Reconciliation interface/report is as important as all other interfaces and needs to be well thought of. Don't put it at the end of the list only because is has to be run just a few times, it's as important as inbound and outbound delivery interfaces.
- Decouple - you don't need use external WM resources every time you run an SAP test.
Get familiar with the concept of simulating 3rd party systems (in case of local WM) and B2B partners (in case of 3PL scenarios) called Service Virtualization to get full control There a whole FREE openSAP course just on that topic (you can find the link in the references section)
Conclusion
DWMS scenarios can work perfectly for many years but before you implement those you may want to understand not only the benefits but also challenges and the ways to avoid those.
References
DWMS scenarios from help.sap.com
Free openSAP course on simulation of 3rd party systems - "Avoid SAP S/4HANA Project Delays with Third-Party Systems Service Virtualization"
- SAP Managed Tags:
