Archiving and Purging – Understand data and process managed by solution.
In my previous post, I had discussed about the high level steps for archiving, so at the next level, let us explore data in a typical BPM Application.
The data model designed in the solutions implemented in BPM platforms, allows the design team to extend and customise data models as per the requirements of the process being implemented. The data design for BPM solutions is more towards complementing the process being orchestrated than managing data as System of Record (SOR).
If we take a look at the data model used in BPM or Case management applications, we can classify the data into the following categories:
♦ Data generated
It includes the following:
– Process related data generated while a case flows through a process or for each instance of process-run. This data pertains to inflight cases and historical cases, or resolved cases.
– Performance related data like SLA for inflight tasks and KPIs for completed tasks, and this is mostly the statistical data collected for each process execution. This data is mostly used in business activity monitoring and to evaluate the performance of the processes and actors involved in the process.
– Audit data that is captured during each task and step in the process, on completion of tracking and analysis.
– 60-80% of the data in a typical BPM application will be pertaining to the data generated, which is more related to the process implemented, rather than the actual business data related to customer profile, or Loan or policy or Health care claim.
Most of the BPM and Case Management platforms provide clear differentiation between the attributes generated by the platform and the other attributes.
♦ Data referenced
– Application specific data models designed within the application would mostly be a container of the reference data required for the process, which are loaded from different System of Records (SORs).
– These attributes get updated every time a case /process moves from one step to another, and always contains the final state of the execution.
– BPM solutions reference business data from different System of Record (SOR) systems.
– Solutions can reference these business data in real-time through web services, or they can make a copy of the business data once it gets pushed from the downstream system.
– Referenced data gets constantly updated from System of Record (SOR) and it would always be in a transient stage within BPM.
♦ Data captured
– In some cases, the solutions might be built in the BPM platform to capture the data for business objects like “Loan and Policy”. In these scenarios, the process of capturing data is implemented in BPM.
– Once the required data is captured, the respective System of Records are updated to maintain the records of these business data.
– The solutions handling the data capture cannot be considered as a System of Record (SOR).
When we approach a solution for data retention we would mostly deal with historical data of the process /case that is completed.
Only when we analyse the data and categorize it as above, will the team be better equipped to untangle the knots around data retention, regulation and compliance.
The best practice in enterprise solutions is to capture key milestones of the process progress and process completion in a System of Record (SOR) or MDM or Core system.
