Process Data Models within CCH Tagetik
Within CCH Tagetik’s CPM applications, Process Data Models (PDMs) are essential components of the process setup.
The PDM is fundamental in determining how several technical components collaborate. Everything from data entry forms, reports, account editability, validations and submission rules are dependent on the PDM. Often, in implementation projects, these tend to be seen as a low-priority and, thus, sometimes overlooked, resulting in hasty and costly last-minute shifts in the project strategy.
Where that occurs, it is often at the cost of the design, and that in itself can have serious consequences.
Simply put, PDMs are a definition of account and category editability within a process. They allow the administrator to define the combination of accounts and categories which are submitted at each stage of the workflow. The application caters for this by assigning the accounts and category combinations to the workflow model steps. PDMs are mapped to entities, allowing the administrator to define different PDMs for entities which have different task flows or capture different levels of data within the same entity hierarchy.
In the Solvency II world, examples include insurance vs. non-insurance entities, and in a more generic consolidation workspace, associates vs. legal entities or holding companies. Control Groups, or validation rules, are automatically deployed based on the account definition in the PDM. However, there is also a further option to exclude them from the entities assigned to the PDM.
Other aspects of the PDM allow the administrator to define which reports and data entry forms are applicable to each step of the workflow. This will invariably limit the entities that are seen on a form’s runtime options (when opening the form from the process) to the entities that are assigned to the PDM.
When deploying a PDM, the application defines the account editability by looking at the account and category setup, along with the set of calculation logics defined within the process. Calculated accounts will be marked as not-editable, but editability exceptions allow the administrator to override this and customise the editability. This is particularly useful when some accounts have been defined to calculate gross amounts, but the intercompany portion should be editable, vice versa, or if the calculations have been defined for certain entities and/or categories.
What are the key design considerations? How many PDMs are required within a specific process? Ask yourself:
- What granularity of data are you required to collect for each entity?
- Should the user-journey vary per entity?
- Do different entities require different validation rules?
- Should the calculation logics between entities be consistent?
We recommend defining a set of matrices to address the above, to help identify logical groupings of entities and thus the number of PDMs that will need to be created. It’s worth bearing in mind that a new PDM is still a new element that needs to be maintained within your application, so keep it as lean as possible, yet without compromising the requirements.
Once you have identified the PDMs required, think about the logical structures that you need to build a clean and maintainable set of PDMs. Try to avoid manually assigning each account in the PDM, by referencing nodes in the account hierarchy. The hierarchies can be technical groupings of accounts or even reporting rollups:
- Account Hierarchies
- Categories Groupings
- Form Groupings
- Control Group Groupings
Consider the default PDM. When used correctly, it could set a baseline for all other PDMs to inherit from and reduce the burden on future maintenance. An excellent example of this is in a well-designed Solvency II application PDM, where the default PDM is used to define the standard EIOPA reporting landscape, and then a subsequent one inherits from that but also caters for the ECB add-ons.
In summary, let’s consider that a good PDM design can reduce the risk of:
- Human error by ensuring that only pertinent accounts are editable, and others are not.
- Invalid validations being triggered, thus ensuring entities can submit.
- A myriad of errors resulting from an unnecessarily complex PDM that is difficult for the administrator to manage.
The cost of a poor design invariably means that your users need to be far more diligent, apply various additional checks and governance and spend countless hours remediating unnecessary data defects. If undetected the data defects can have serious consequences, such as misreporting. Even when detected, the efforts to get it right may itself jeopardise key reporting/submission deadlines. User experience is a critical success factor to any implementation.
Please reach out to us if you have any questions regarding PDM design, or if you wish for us to share some example design matrices. We’d be happy to help.
