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.
Figure 1 is the first version of a form needed for a business process. It’s simple and holds all of the basic data to find the work item. This is very key for content driven and supporting BPMS processes, keeping it simple. The fields on the form should only be used to find items through search tools and to support the underlying workflow.
In this form we have the basic information of the customer including first and last name, full address, their account number, the type of document/content that is a part of the work item and the date it was received. This is basic information that provides all that is necessary to find the work item later: by last name, by account number, by document type or by received date. In most cases, that constitutes 90% or more of the data needed to locate an item.
The form also has two buttons that are essential for working the form: A Cancel button that closes the form and does not save any changed or added information and a Route button that sends the work item to the next step in the workflow.
The Figure 1 form would work fine in just about any process but there are some tweaks that could (and probably should) be made to make it better so let’s look at Figure 2.
All of the fields are the same but now we’ve added some minor enhancements to assist the users in making sure the data is correct:
Added a drop down list of states;
Added formatting to zip code so entries can be validated against it;
Added formatting to Account Number to ensure correct entry;
Added drop down list of doc Types;
Added formatting to the Received Date.
These are great additions to the form that help alleviate some errors that could cause problems down the road. We are still well within the basics of form creation as it applies to a content driven, supporting BPMS process. It should be noted, however, that the complexity level for this form has now gone up a notch:
Validations – Each field that has a validation has the unique configuration of what that validation should be and an alert to the user when that validation fails. This alert can be simple red line under the value to indicate a problem or, as most users want, a message that displays indicating the problem with the formatting. While this could be a simple “Invalid Format” message to be used for all field validations, it’s common for the business to want a field specific error message such as “Account Number must be formatted ##-#-####.” Again, in most systems, this is not hard to do but just another thing to have to add, test, and potentially change later.
Drop Downs – Drop down boxes are invaluable for a form because it controls the values available and helps the user to select from a list of choices instead of manually adding a wrong value. Consideration needs to be given to how the drop down value are maintained. Are the values in a database table, SharePoint list, or worse, are the values hard-coded in the form? The BPMS platform will dictate what options you have for populating a drop down but it is up to the organization on who will maintain that list? If the only option is hard coding, the answer is usually IT since they are the only ones with access to the underlying form code (although with Low Code implementations, it is possible for end users to make changes). If the values are stored in a database table or SharePoint list, will the end users have access to maintain these lists? Generally, this is not the case so either a value change request goes back to IT or users are given specific security access to do an update or some sort of web based application is built that allows these types of changes. Again, more complexity and maintenance although probably a necessary evil because the benefits of drop down boxes outweigh the overhead.
Enter the User
Form complexity usually happens when the business users want the form to go beyond what it was originally intended. Remember, we’re talking about a process that is content driven and plays a supporting role to other systems. That means the data on the work item should primarily and only be for locating it or to support workflow routing.
And yet, the users want more. They want information about the customer, they want added features to find matching documents, they want an automated worksheet to assist them in some fashion. All of this, while certainly achievable with a BPMS platform, steers the process away from what it was originally intended to be. Additionally, most of the data requested to be on the form is already available in another system, notably, the primary system of record. Duplicate data is a bane to an organization and unless that data is absolutely needed in order to move the work item through the workflow or to find it, it should not be on a form in a process that is dedicated as support.
When these types of demands are placed on the BPMS system, not only does it go beyond what the system was intended to be, it adds more and more to the complexity and maintenance of the system itself. Let’s take a look at a form after it has been augmented with the requests from the business user:
With the above form, we now have…
More than double the number of fields;
Added additional customer information such as the gender, date of birth, effective date of the customer and their Paid to Date - information that is available elsewhere;
Further defined the Doc Type by adding another drop down (and the associated maintenance of that drop down) with a Type Code. This is common when the Doc Type isn’t enough to clearly define the work item’s content but this is simply poor analysis on the front end. This information should have been clearly defined up front. And, instead of just making the Doc Type values more accurate, the solution was to simply add yet another field which not only adds to form complexity but adds another field the user must manage with the work item;
New buttons have been added that saves changes made on the form without closing it and provides an automated look up of matching work items within the system. Just about all BPMS systems provide search tools so by replicating this feature, even if it’s automated to add in the values from the form, becomes a bit redundant;
Because trying to get all of this information on one form is difficult, the form has now expanded to a tabbed form – one that holds the basic customer data and another to provide that requested worksheet. This could also be done with a two-page form or, worse, a really big single form;
The added worksheet not only has new fields but also has to do calculations such as adding up what a new premium would be for a requested change and if that change needs to be immediate, what the pro-rated premium would be based on the Change Effective Date and the Paid to Date.
All of the above needs to be designed, developed and now the form has to include not only formatting and connections to the various drop down lists, but also calculations for the worksheet that includes formulas and must be tested to make sure it is working correctly.
Understand What You Are Getting Into
Remember that the running theme to this series is Getting Back to BPM Basics. I’m not writing this saying that all forms should be simple and that the end users just have to live with it. In more complex processes; data only style workflows; or where the BPMS system is being used as the “single source of truth,” having fully functioning and robust forms is a great and very useful tool. Most BPMS platforms offer this style of smart forms and many can do so without a lot of coding.
BUT understand what you are getting into.
For every field validation that is included, for every drop down that is created, for every button that is added, there is not only the development of such features but also the testing and maintenance associated with it, not to mention regression testing when new fields or functionality is added. This all adds up and if the new field or functionality goes beyond the intent of the system then it’s important to ask why is it needed or to point out that the data is available elsewhere, like the system of record, and does not add value to the BPMS implementation.
This can be a tough call in a lot of organizations but that’s why the upfront analysis and asking all those questions at the start of a BPMS project is so important. A BPMS system can change over time and what was once supporting could become primary but it should happen as part of an overall strategic initiative and not just because a group of users don’t want to refer to another system.
Another point to consider with the simple approach to forms and fields is the ability to integrate this type of BPMS process into other systems, like the system of record. By keeping the fields minimal and related primarily to searches, the BPMS process can be tied to an outside system utilizing web services or APIs provided by the BPMS platform. This allows much easier integration since the calling system simply has to pass the search criteria to the BPMS platform and then display the returning image within that system. The extra fields added for the end user’s benefit can become unnecessary with this type of integration.
Keep It Simple…Someone
There’s always a way to make something more complex. In fact, it’s pretty easy to go overboard. What seems to be harder is making something simple and keeping it that way. Understand the focus and intent of your BPMS process and then relate that back to the forms and fields you create.
By sticking with the simple approach (as long as it continues to make sense to do so), not only will your forms be simple, but so will the training for the process, using the system, maintenance for the process and testing any changes made to the process. By taking this approach, organizations will discover that a little simple can go a long way.
