Data Migration for your Pricing, Contracting and Market Access Needs – “Chronicle of a Death Foretold?”
Have you heard about “One Hundred Years of Solitude” by Gabriel Garcia Marquez? Most of us would answer “yes”. However, not everyone knows that there is another interesting book of that author: ‘Chronicle of a Death Foretold’. That’s the story about the murder. Murder everyone knew about it will happen, but no one has stopped that.
How that could be related to the pricing, contracting and data migration? Could the 20th century Noble price winner foreseen what Life Science companies will struggle with? Could the ‘magic realism’ which was his favourite style influence that? I will try to convince you that the answer is affirmative.
Pharma/Life Science companies use various IT solutions to support their contracting and pricing functions. Key examples include Revenue Management and Contract Lifecycle Management solutions such as Model N, Conga, Zilliant, and many others.
During implementations of these kind of solutions project teams often struggle with data migration. Let’s look why.
- The data migration process usually looks as follows:
- Export from the current systems manually or via integration
- Clean-up, map, merge and transform.
- Run preliminary validations.
- Load into target system
- Run post-load validations.
Getting all of the above steps right can be really challenging due to multiple reasons. The key ones include:
- The Business Rationale for why the data should be migrated is not clearly specified.
- The Scope of the migrated data is not defined or tends to become larger without business rationale.
- Key data definitions such as Product, Customer, etc. are not clearly laid out.
Let’s look at the above one by one. First, the business rationale. The approach that we have often seen is that migration happens, however there is no answer to the 1st main question: why the data should be migrated? Are the final users going to make further plans based on that? Do Managers want to use them for business analysis? Do the Administrators need a safe data repository?
What’s more and moving to the second point, the scope of data to be migrated should be set up at the beginning: what entities or objects would be migrated, how much of the history should be moved, etc. That could drive the further discussion and impact the approach to the process. The wider scope, the longer process and higher probability of the error. Big amount of data requires more human effort to prepare and might increase the project cost.
Another common business problem is how to define key entities. For example, a “Customer”. That could be completely different based on the perspective. The Customer in SAP is explained differently than in the Tender System or CRM. There should be also the granularity considered: Customer could be a department, a building, or a legal organization. How shall we treat “Product?” It could be a brand, a SKU or even a therapeutic area. Having that, which approach should be leading, and which system should be treated as source of truth? It’s a key if we want to make sure that we don’t redundant the data.
How could the issues with the data migration be resolved?
First, the purpose of the migration should be clearly set up. A Project Manager needs to understand the Stakeholders’ requirements around the future usage of that data. That could have crucial impact on the Organization if the migrated data will be used for the reporting to the Authorities.
When implementing a Revenue Management system to manage contracts, prices, incentives and government reporting functions, the system can only support those processes if the underlying data exists. Government pricing relies on upstream contract and transaction data. Transactional data relies on upstream contract, pricing, and master data. Contract data relies on upstream master data (customer, products, membership). In addition to aligning on what data needs to come in, evaluating the valid time periods for each is also critical because of the downstream dependencies, as well as statutory reporting requirements and time periods that must be available for reporting and audit purposes. Based on that it’s clear: Migration is not just about having the data. That’s the starting point. It’s critical due:
- Legal requirements (Government pricing)
- Correct orders’ processing (price counting)
- Cycle billing (first prices)
- Rebate/incentives/admin fees calculations
- Compliance tracking
Second, the scope of the migration must be clear and well documented. Business Analysts should describe source systems and each field, which will be the part of the migration. Manufacturers may have multiple sources for a data object needed by the Revenue Management system. Maybe customer information is stored in CRM or CLM applications, but also in ERP? The project team must be clear on where data should be sourced from and identify whether the source has gaps in what is required by the Revenue Management system. E.g., if ERP is noted as the source system for Customer data, it could be that industry identifiers like HIN, DEA, 340B, etc. are not currently maintained or stored within the source. Since those attributes are needed for the Revenue Management processes, the project team must work to identify if another source is to be considered where a merge must occur or is there some level of manual effort required by the business to augment what is available in current systems and tools.
In addition to that compatibility of the different sources needs to be assessed. For example, the definition and granularity of customer record in CRM (e.g., used for quoting purposes) might be different than that in SAP. Products could be another example. Manufacturer stores Customer information in different systems (e.g., SAP/CRM/ERP) vs. revenue management (e.g., Model N). Key attributes from Customer perspective need to be extracted from different systems. While migrating we need to know what new system needs and where to get it from.
Third, key definitions must be agreed among all the Stakeholders. As the perspective could be different depending on the system we mainly use and the role in the organization we are holding. Even obvious term could have different meanings and it’s better to clarify it from the beginning.
If a manufacturer is currently managing customer pricing through their ERP system, but implementing a Revenue Management system, the naming convention could be a challenge. E.g., definitions of Price List could differ. In ERP a Price List may refer to true list price, or a customer specific set of prices from a contract, whereas in future state with a Revenue Management system, Price Lists may be a referential object on a contract, but the Contract object will hold the customer specific pricing.
Distributor Rebates/Chargebacks: These are transactions that represent the difference of the WAC Price – Customer Price paid back to the distributor. Prior to implementing a Revenue Management system, a manufacturer may be familiar with referring to these transactions as Distributor Rebates, but based on system nomenclature, post-implementation those transactions are likely to be referred to as Chargebacks.
Customer: Because of the nature of complex contracting arrangements, Customer can mean many things. It can refer to the entity the manufacturer contracts with, which may be an Individual or Group entity, or may refer to the members of a Group customer that inherit eligibility for pricing/rebates as part of their relationship to the contracted entity. Furthermore, a customer is used in CRM for quoting purposes can be defined at the higher level of granularity vs that in SAP.
Based on the above, could we say that “data migration is the chronicle of a death foretold?” Does it always require a big effort where the results are never meeting expectations? Based on our experiences and some of the thoughts above it does not have to be. Data Migration is a need that can be met well and drive the business needs of an organization.