This third BPM blog post in our guest series by Sandy Kemsley explores five primary use cases for combining content and process. Bringing to light document-driven processes, case management, document lifecycle processes, exception handling, and non-document classification processes, Sandy reveals why it’s important for businesses to consider an integrated approach rather than keeping content and process siloed.
Although I’ve spent the last couple of decades focused on process, my roots are in that most basic overlap of digital content and process: the “imaging and workflow” systems of the 1980s and 1990s, where a paper document captured by a scanner would trigger a process that routed the document image to a person for manual processing. Process automation has become a lot more sophisticated since then, and is often driven purely by data rather than documents, but I still see a lot of applications where unstructured content is an essential part of a process.
Here are some of the main use cases for content in the context of a process:
- Document-driven processes. This is the closest to those imaging and workflow systems of old, where the creation or capture of a document initiates a process, and the purpose of the process is to perform actions related to that document. In most cases, the document itself is unchangeable once created: think of it as the instructions for the process. An example is a loan application, where a customer fills out a form at the bank (or online), and that triggers an approval process inside the bank. The process may execute steps to capture the application data from paper, request more information, or escalate to a senior loans officer before the final steps of making a decision on the loan and issuing the funds. The original loan application is never changed, and there is typically a regulatory requirement to retain it for a specific period of time.
- Case management. A cross between document-driven and data-driven, case management focuses on resolving cases rather than executing a single process, and gathers all content related to that resolution in an electronic “case folder”. The case folder and its contents, which includes a record of the processes and decisions applied to complete the case, is managed as per corporate content retention management policy.
- Document lifecycle processes. Documents created inside an organization, rather than those submitted by customers, may go through an approval process, and may be continuously revised over their lifetime. The lifecycle process – create, review, approve, publish – exists purely for the purpose of creating the content. An example is a product manual, where a technical writer writes a document describing the product usage, which is then circulated to other writers and graphic artists to gather additional content, then to other parties for branding, legal review and final approval. The final version is published on the customer-facing website, and printed for packaging with the physical product. When a new version of the product comes out, the product manual goes through the same revision and approval cycle, ensuring that the content is accurate and published in a timely manner.
- Support documentation for exceptions in data-driven processes. Arguably, most of the automated processes today are data-driven rather than document-driven or document lifecycle: straight-through processes such as financial transactions that don’t require human intervention. Although unstructured content is not required for most process instances, additional information may be required for exception handling. An example is a dental insurance claim: normally, the claim for a standard procedure can be submitted online, approved automatically and paid without human intervention, but if the claim exceeds a pre-set limit, it is escalated to a claims adjudicator for review. The adjudicator may request additional documentation from the dentist or patient, which is reviewed manually and attached to the claim process instance in order to justify the claim.
- Classification and analysis processes for non-document content. The previous use cases primarily address unstructured content that we think of as “documents”, that is, the electronic version of a page of text. Unstructured data can be much more complex than that: blobs of semi-structured data such as IoT machine data or log files, photographs, audio and video. As this content is ingested into content management systems, processes that classify, recognize and perform analysis on the data may run immediately or be triggered at a future point.
Content and processes don’t always live on the same systems, in spite of the many use cases of their interaction. Consider that the goal of most content management is long-term access and retention management that may span years, while the goal of most process management a more ephemeral set of tasks that have only the lifespan of a process instance. Although most business process management (BPM) systems provide rudimentary capabilities for storing content, most organizations prefer to store content that requires access management and retention management in their enterprise content management (ECM) system, then connect it to a BPM process instance when required. Many ECM systems have document lifecycle processes built in, and although they are not capable of handling the other use cases discussed above, they are sometimes pressed into service as a simple BPM system.
Where I am seeing an interesting hybrid of process and content is in low-code platforms that are being used by “citizen developers” and professional IT staff to create case management-style applications. These platforms contain content and process components – in fact, they are often built on top of existing BPM and ECM systems – plus analytics, decision management, event management, predictions, machine learning and user experience. The platforms provide the ability to rapidly assemble these building blocks into custom web applications, with the BPM, ECM and other services interacting seamlessly.
Over the years, I’ve learned two things about integrating process and content: first, almost every process application has some sort of content associated with it; and second, most process-centric developers underestimate the potential complexity of handling the content in the context of the process application. You can use the scenarios above to identify the style of your process/content application, but will also need to consider how the content gets into the process, who can view and update it, whether it needs to be accessed from outside the process context, and its eventual retention and disposal.