The Essential Guide for POSDM to POSDTA Adoption and Migration
Today, retailers are being confronted with a host of challenges to stay competitive. Changing customer behavior, shifting sales channels, diversified payment methods, and fierce market competition make retailing more challenging than ever. The frequent shift of retail trends on-demand challenges the retailer to deliver a consistent customer experience and upends the sales cycle. The increasingly dynamic nature of retailing has multiplied data volumes to a dramatically high level. These massive data volumes need to be orderly structured to support a better customer experience journey.
Those who effectively capture, process, and utilize their data will win the race. However, this requires advanced data warehousing, provisioning, and intelligent integration platforms to feed the data in real-time and process volumes of POS data efficiently.
Retailers need to embrace a strategy to adopt and migrate to SAP’s POS Data Transfer and Audit (POSDTA) from POS Data Management (POSDM). Though POSDM is in no way inferior to POSDTA, it has some significant limitations in terms of future support from SAP and lacks some of the advanced features of POSDTA.
In this blog, we will explore POSDTA and how to effectively migrate from POSDM to the new platform.
Understanding POSDM and POSDTA
POSDM is part of SAP’s Retail solution and the SAP NetWeaver Business Warehouse portfolio. It helps retailers make informed decisions by feeding point-of-sale data into the data management system.
POSDM reduces data duplication, fragmentation, and redundancy and serves as a central data hub. It accelerates the data analytics and reporting capacities of retailers and improves their response capabilities.
POSDM is a standardized retail solution that can be employed as an independent application or integrated with SAP platforms. It is delivered with a pre-defined integration architecture to support a large volume of POS data from multiple channels.
POSDTA is SAP’s state-of-the-art, next-generation solution and is one of the foundational components of SAP’s powerful and feature-rich Customer Activity Repository (CAR). CAR is a retail-specific platform with multiple embedded applications like sales audit with POSDTA. CAR also includes and supports add-on apps for planning. While sales audit is an important component of CAR, the two are not synonymous. The other components of CAR include Demand Data Foundation (DDF), Unified Demand Forecast (UDF), On-Shelf Availability (OSA), Omnichannel Promotional Pricing (OPP), Multichannel Transaction Data Management, Inventory Visibility with Omnichannel Article Availability and Sourcing (OAA).
POSDTA was built on SAP’s in-memory HANA database meaning it can analyze and deliver data faster than previously possible. It acts as a central hub to collect POS transactional data for processes such as sales audit. This inbound data is validated, audited, and summarized by SAP’s POS Inbound Processing Engine (PIPE). Subsequently, from PIPE, the data is federated to other integrated applications for improved visibility. In POSDTA, data is structured in a way that users can easily interpret. Also, it makes transaction data available to the applications via virtual data models and separate SAP HANA views.
Key Differences Between POSDM and POSDTA
The key differences between POSDM and POSDTA are the user interface (UI), the ability to analyze data by sales channel, the database integration options, and ease of master data replication.
POSDM runs on conventional databases, although the newest version of POSDM can run on SAP HANA; POSDTA was built to run natively on SAP’s HANA database platform, enabling it to take full advantage of the power and speed of HANA. In POSDM, there is no standard table for viewing compressed data, while POSDTA’s standard table is available to all data formats. Access to the TLOG is one of the significant components of the POSDTA system, which is not available with POSDM.
Further, in POSDM, master data updates are performed once or a few times a day. In contrast, POSDTA updates master data in real-time using system landscape transformation from SAP ECC or S4/HANA. These real-time updates mean retailers can react faster with strategies such in-store specials, featured sale opportunities, etc., during store hours, not after the fact.
Another advanced feature of the POSDTA solution is the ability to differentiate data from various sales channels such as online, POS, mobile, etc., enabling retailers to better and more quickly understand how each sales channel is performing and make timely adjustments to inventory, sales strategies, etc., while in POSDM, sales channel stratification is not available. In addition, POSDTA enables gross margin calculations based on the sales price, which is made possible by updates to the cost price in the POS Workbench.
Visibility of unprocessed sales data is another key advantage for migrating to POSDTA enabling users to query TLOGUS to obtain accurate, store-level unprocessed sales data.
POSDTA (CAR) Migration Considerations
There are three key elements to address in the POSDM to POSDTA migration and implementation process: sizing, configuration, and custom code. This is the right time to look at how much data to migrate from your current POSDM to POSDTA as a key decision point to avoid processing issues in the future.
To execute the POSDTA migration process seamlessly, we’ve mapped out a recommended path and approach.
SIZING: It is imperative that prior to migrating transactional data, proper sizing be calculated based on the data volume, file structure and fields. POSDTA’s data storage capacity should be sized properly because the data is stored in a flat format in POSDTA and does not correlate 100% with POSDM storage.
CONFIGURATION: While initiating the migration, the existing configuration is recorded in the new transport. However, the configuration is transported only after the code is migrated, while additional configurations are made available for accomodating the new features in POSDTA. Also, the System Landscape Transformation should be enabled in the configuration journey, and the master data should be replicated in CAR.
CUSTOM CODE: The custom business add-ins within POSDM related to the POS inbound processing engine can be transported to POSDTA. Once the transport is complete, the business add-ins need to be activated. Subsequently, the tables and BW (business warehouse) objects related to POSDM need to be replaced with AMAP tables and objects.
Keeping the above considerations and recommendations in mind will help ensure a smooth migration process from POSDM to POSDTA.
