I used to question whether there was a value opportunity to develop all automated workflows using one workflow management system, but no longer. It’s clear to me that using different system approaches to automating workflow is important. Our company uses three distinct approaches to automating workflow.
The first one is what I call “native workflow,” meaning workflow capability inherent in packaged business applications. Our work management system which manages execution of activities at our electric generation plants and substations, is one example of how mainstream application vendors have effectively integrated workflow management into their applications. Another example is our project management system, which provides automated workflow around the project life cycle activities. The clear advantage of native workflow is the level of integration of the workflows with the feature and functions of the application.
A second approach is using custom code to build in workflow automation in custom applications or in situations where workflow automation needs to execute in a disconnected state, such as a mobile device that has no connectivity in the field. We also find this type of solution works better when workflows need to run on different types of mobile devices—a requirement that is only going to become more complex over time.
Thirdly, which is the focus of this article, is the use of a standalone workflow management system. We find this system to be useful in automating those business processes that aren’t native to a core system or when the native workflow is just too expensive to implement. Below are some examples of workflows automated through the standalone system, but there are many others.
• Reviews and notifications around compliance processes
• Contractor worker request form
• New employee on-boarding activities
• Expense report review and authorization
• Employee personal time off requests
An important clarification is in order here. When we think of workflow management, we tend to also lump in electronic forms. In the marketplace, these can be separate products. Indeed, years ago, our company originally decided to use two separate vendor products. We did this because our workflow management vendor didn’t have electronic forms that could integrate with data tables. This was a key differentiator for us, as we are using an ETL process to take employee and organizational hierarchy data from various tables in our HR database to use as source data in the electronic forms and workflow. This process allows us to ensure accuracy and completeness of production forms and workflows as this data changes over time. We’ve seen the electronic forms feature in our workflow management product mature to the point where it is now viable for us if we wanted to switch.
"Sure, training is required on the tool itself, but we found we could train someone with no coding experience to build workflows"
In looking at our approach to development, a couple of critical success factors come to mind. Basics in development still apply: Make sure you have a business owner, conduct requirements planning, document your design, maintain a test-and-development environment, and ensure adequate system and user testing. If you have time for formal business process modeling, flow diagrams can help define requirements more precisely, leading to more accuracy and completeness in early designs. Having said that, we’ve also seen where even the most elaborate flow diagrams still fall short of identifying all the requirements. Flowcharts aren’t for everyone. Some folks just need to see the workflow in action. To address this, we’ve adopted the spirit of the agile development methodology, breaking workflows into smaller modules and developing incremental designs that the user can see and test early in the design process. It should be noted that, although the agile approach tends to accommodate more frequent changes, this type of development can lead to frustration for the user, because they are more active in the design process than traditional development and they may perceive these early prototype reviews as premature. To avoid frustration, we’ve learned to educate our users on the front end of projects as to how the agile process will be more iterative to the user on the front end, allowing for a better product delivery on the back end.
Some high-level tips on development: Define a retention period for all the workflow history records. Without retention periods, these workflows will generate millions of records and deplete storage capacity. When building workflows, remember to design your history log in a way that’s helpful for troubleshooting. We’ve found that error logs in our work management system are too basic to really contribute to resolving issues.
From a skills perspective, traditional developer skills are not required for success with standalone tools. Sure, training is required on the tool itself, but we found we could train someone with no coding experience to build workflows.
Mobile delivery should be a factor in your approach. We found that our workflow management system did not extend well onto mobile devices, such as phones and tablets. We’ve since resolved that using application virtualization.
Build it and they will come. Early success at building workflows will likely lead to a barrage of new requests, so have a process to prioritize work and ensure that enough cross-training is conducted to ensure continuity if your developer resources go on vacation or leave permanently. Plan for increasing workflow maintenance time as more workflows are put into production. We have found that, as more users utilize a workflow, new ideas on how to streamline it or add to it will follow, so allocating post-production time to tweak production workflows is important.