Form Simplicity

Forms and the fields they contain can become big, overarching monoliths of information that in reality can be too much for the intent of the system and hold data that is already within systems used in the processing of the work. When organizations look at their forms and fields, it’s important to consider two things at the onset of a Business Process Management Software (BPMS) project:

  • Is the process being considered for BPMS primarily driven by content (i.e. scanned images, PDFs, Office documents, etc)?

  • Will the process play supporting role in the organization or is it meant to be the “single source of truth?”

Please note that I used the term “process” in both questions and not an overall BPMS platform or system. I did that because one process within a BPMS system could be different from the next. Most BPMS platforms offer the ability to have multiple processes working under a single software implementation so when organizations consider these questions, it should be at that level. There should also be consideration given to the system at an Enterprise BPM level but these are broader considerations and I’ll devote a separate blog on that in the near future.

Let’s dive a little deeper into these two considerations:

Content Driven Processes

Content driven processes are those where one or more documents are the basis of the work item as it lives within the workflow. These include scanned images, imported PDF or Office documents, emails, or faxes. The opposite to a content driven process is where work items contain only data from an online form or data fed from another system or a more elaborate system where data and content are considered equals. For the purposes of today’s discussion, I am only referring to forms for work items with content and under the next consideration.

BPMS as a Supporting Role

The second thing to consider is if the process is a supporting role to the technical architecture of the department or organization to which the process is in. Big organizations like the idea of using BPMS as the “single source of truth” or the “system of record” and that is a great goal, especially in the context of Enterprise BPM but sometimes a particular process doesn’t necessarily lend itself to that goal or simply doesn’t apply. Additionally, there could be organizations that don’t need BPMS in that role because they already have systems in place that act as the system of record, so the BPMS platform plays a supporting role to that system. Think of the BPMS system as a means to replace file cabinets and folders moving from desk to desk. This type of implementation is what I am talking about within this blog.

Why the Distinction?

So why do we have to ask these questions? First of all, you should always be asking questions! The key to a successful BPMS implementations is asking a ton of questions up front and making sure you know and understand the answers before a single line of code is written. Proper BPM analysis is essential with any BPMS project no matter how small.

Second, and the point of this blog, is that these answers dictate how you should approach the form building and data elements of the work item within the BPMS process. Why is this important? Because forms and data that go beyond what the system is supposed to be add unnecessary complexity and maintenance to the system. Let’s take a look at an example.