Process Functionality vs Website Functionality
[Editor’s note: This is a guest post by Prashant Gadgil, one of the most accomplished BPM practitioners in the industry. We are lucky to have his services at BP3, as he has left a trail of successful customers and awards in his wake. In this post, he turns his focus to the challenges of moving a web app to BPM… ]
Since the late 1990s there has been an explosion of websites, internal and external, hosted by various organizations. In technical terms, we call them web applications. Back then, BPM products were in their infancy and they matured significantly only in the last few years. So in those early years, with lack of pure-play mature BPM products, companies built their own internal websites to support a “process or workflow engine” embedded in them. They did lots of customizations and enhancements to it over the years to support their users to execute their business’ ever changing “processes” through that website. But this was not easy. Websites put some limitations on how much process they can build in and how frequently they could change it to respond to business environment.
Now when these same organizations start on a BPM journey with a third party product for process platform (e.g. IBM BPM), one of the common statements we, as BPM practitioners, hear in early stages of client projects is: “So this internal app has supported our processes for so many years, and now we want to migrate the app to a BPM platform to improve our processes…”. It is a logical choice at a high level, but with a caveat.
Often the strategy and implementation of this endeavor gets obscured and mired in problems when business users start defining process requirements for the new tool. Since they have used the previous web app to support their process for many years, they tend to think of new requirements of the new tool also in terms of how it exists today in the old tool, instead of changing the thinking to out of the box from process standpoint. Normally it is most beneficial if you implement the “process” portion of the old platform into the process tool and keep the “website” portion of the old platform in the old platform (or similar new version) itself or some modern version of it. You are likely replacing the old platform because it was not flexible enough to support your ever changing process needs. But it is important to keep in mind that just like it is difficult to implement and support a “process” in a stateless website, if you’re looking for ROI from your BPM environment, the ROI is in the process improvements, not in recreating your non-process web-app in a new technology stack designed for processes.
So what are the tell-tale signs or rules of thumb to look for potential “process” functionality in your old platform? I would put the following, either independently or in combination, which will make them fall in the process arena:
- Functionality which requires login to the website to access it
- Functionality which is visible only to some, not all, users after login
- Functionality which is visible to the a user at some times and not visible to the same user at other times
- Functionality which refers to some Status (and sometimes also Sub-status) values, to search for or to filter by etc.
What these signs point to is that there is some “stateful” nature of that functionality embedded in an otherwise “stateless” website. In BPM terms, this kind of functionality should be transferable to some BPD (Business Process Definition) with appropriate swim lanes and tasks. Remaining functionality may be visible to all users or at all times or both or won’t have any dependency on any “status”. This will likely fall in what I call as pure website functionality.
Identifying this difference early on is of utmost significance to decide what functionality is the right candidate to be pulled off the old platform into the BPM process platform and which of it can stay where it is. Process oriented functionality inherently has some cycle times associated with it which can be measured and improved to remove the process bottlenecks using a BPM process tool.
Let me illustrate with a quick example. On a brokerage website, I would typically have links for various items and just to name a few:
- Search for nearest location of the company
- Check balances in my various accounts
- Transfer money between accounts
- Apply for a loan or check for my loan status
- Trade securities
- Download some documents
- Submit a request for opening a new account
- And so on…
Applying the above simplistic rules of thumb, I can guess that 4 and 7 sound like a “process” to me since it is not purely in my hand to complete those things in one sitting on a website and I will see different links or status depending on where that loan or account application is within the brokerage company. So only those 2 items appear to be “process-driven” which can be the best candidates to be moved into a BPM process tool. Others appear to be pure stateless web functionality which most likely does not involve any other human touch or status dependency and hence may be a better fit for the web application platform itself.
So next time you want to hear that client wants to migrate their existing web application platform to BPM platform, take it with a pinch of salt and request a deep-dive discussion about this. I promise that both of you will thank each other in the end!