In S/4HANA transformations, first, we need to decide whether to only migrate the current system or to aim at some process improvements. Usually, some re-engineering is done, although most processes could stay as-is. The work is done on process levels and steps end-to-end.
Parallel, you have a great opportunity to work on data management topics. Usually, ERPs have lots of surrounding systems and even hundreds of integrations – to systems that do not have the same data model and same entities. What causes issues is the new S/4HANA is not aligned with the surroundings, and vice versa. A great tool to support common understanding is business glossary.
It could be target operating model has not been revised, and the need for a new data model and other required data management elements have not been understood. In many organizations, data-related responsibilities are fragmented across different departments and functions. Money and time is tight: minimum changes allowed, perhaps no changes desired in surrounding systems.
It could be we are only aiming to replace the old ERP with S/4HANA – however, we should provide at least some tangible results for the business, and we should start right-to-left: what are we aiming as a result, how your company is driven, how processes, underlying data model, data flow and updated business glossary should support this? Usually, data models and dimensions require changes, and process improvements are needed. For example, to speed up the month-end closing process.
SAP organization structure changes are affecting data model design, and data flows would help to define on which level data is needed along the end-to-end process, step by step, inbound, and outbound SAP landscape. The target should be to stay as close to standard as possible without custom dimensions. S/4HANA dimensions should provide required data further to the end-to-end process until consolidation, group reporting, planning, and forecasting.
The less variation we have in data flows, the less complex the implementation for integrations. Often the vision is to standardize and simplify. However, in practice, due to various reasons, point-to-point integration is still allowed – without analyzing data flows and aligning end-to-end.
In parallel with process work, data flow definitions are artifacts that should be included in S/4HANA programs. The current SAP methodologies do not very well consider data aspects – although basic integration data sets, analytics dimension, and KPIs, among other requirements, would be discussed in design workshops.
The target may be even more complex nowadays when many S/4HANA transformations are done in a hybrid architecture, where hyperscalers may host data lakes and other solutions utilizing SAP data. The system landscape's complexity is rising, which sets more requirements for aligning data models. However, canonical models are past – it is understood you cannot drive organizations from one truth. You need to accept and balance diversity in a world where mergers and acquisitions are a common way forward. An enterprise or corporate data model at a sufficient level is still required.
The most beneficial is to align SAP data model with new and revised business objectives before the S/4HANA transformation starts and even before program planning really starts. Target operating models and business requirements should be recorded, and transformation should be based on them.
Data stream with data architects is recommended. This is fairly new in S/4HANA programs but has already proven its significant role in success. If neglected, data and its various angles are usually not fully aligned, and this will eventually lead to extra work later.
Senior Business Advisor, BearingPoint Finland