During the Process workshops, we always find the business users, business analysts, and architects getting excited about things that they could do with a process solution. But, that excitement typically starts on a wrong footing – The UIs and data. First step into the paradigm shift…
And that struggle often continues through the whole cycle – through the Design, the development, and through the user acceptance, and even in production. The problem is that it’s very difficult for everyone involved to get out of the application mindset that has got deeply ingrained with years of training and repeated beating-in.
I’m afraid this gets further legitimized with Rapid Application Development (RAD) and Composite Applications Development through BPMS gaining acceptance.
Now, I’m one of those who endorse such usage of the available tools, if that’s where you set your mind when you buy these tools. But that’s not the promise of the BPM tools. Do businesses buy BPMS so that they could develop the “same applications” faster and not to manage their “business processes” better? At least I have not seen a business making decision that way with a BPMS tool.
And it’s critical that the Process Solutions are treated as just that – a process solution, not as another Application. Why? Because:
- Process Design is not the same as application design. You want users to focus on processes (as-is and to-be) during process workshops. That’s the only way they can understand the importance of hand-offs, task-lists, work items, notifications, SLAs and so on.
- Process Models need to capture the set of attributes that go much beyond the data that is displayed/edited/passed through the steps. Groups, Roles, SLAs, flow-control elements, for instance.
- UI discussions can easily hog the whole discussions and let’s face it, there’s always a better UI possible. However, there are always ways to continue using the current applications serving a specific step in a BPMS executed process. If you don’t defocus from the application UI mindset, those options are not easily visible.
- Process layer (represented by the BPMS) should not serve as source of record. For instance, it’s not desirable for Customer Order information (managed through a CRM) to be edited and stored in the BPMS. The other business systems and Applications in the organization need to continue doing their jobs.
Actually, any aspect of the implementation – integration, security, deployment, and even how to document the requirements – could sway one completely off the process footing. One would want everyone involved from business to architects to developers to testers focus on the process aspects, and build & validate against the process requirements.
So, if you actually want a process management solution, don’t treat it as an Application.
The Eclectic Zone 
#1 by Ishwar Hangargi on April 9, 2010 - 3:35 pm
Hi Ashish,
Good article about the process solutions. I agree with you.
Do you have any opinion on closing the gaps between the Process Solution and UI?
I feel Process Solution talks about the business processes and UI talks about screen and data level.
Thanks in Advance,
Ishwar
#2 by Ashish Bhagwat on April 9, 2010 - 5:00 pm
Ishwar, Thanks for taking the time to read it.
There are various ways to address the UI related aspects in the context of a process implementation. Normally, quickest way to get a headstart is to leave the existing apps as they are and implement the As-Is process layer with hooks to the existing apps – where users know that the applications would continue to play their role as earlier. You could start with a swivel chair approach to go through the process and application at the same time.
But remember this is just a headstart with an objective to bring the process paradigm in. Once users start understanding the importance of the workflow, one can start bringing in the complex patterns on UI and data.
We normally recommend an iterative infrastructure and technological track on top of the BPMS while in parallel the iterative Business Process tracks can proceed. But, then there’s one more thing – the moment you are tweaking the underlying BPMS too much for your needs, may be you didn’t make the right choice in selecting the one that you need in the first place. So another best practice is to develop process with developers taking an oath to not touch the code unless…(fill at your level of process leniency)! 🙂
#3 by Craig van Zeyl on April 10, 2010 - 12:54 am
Hi Ahsish
I’m in absolute agreement that the solution engagement needs to start very much higher than the application level. Most workflow solutions are bought to deliver “pretty” and efficient programming which rarely changes anything.
We focus on high volume, time critical, human touch workflows – insurance claims management being a good example. We recently analysed our past projects to determine why some were very successful and others went the path of most resistance and the outcomes were interesting. Those customers that focused, in the first go live phase of the project, on “who does what when” were the most successful. These project focus on: ensure everything that creates work is captured – classified including SLA – SLA and skill based delivery – bake in QA & compliance, provide real time monitors – provide detailed reporting metrics. These projects had the most successful organisation adoption and the lowest cost/risk/time. These projects always preserved their existing line of business systems as the transaction entry. e5 merely manages and delivers work. These clients very quickly went on to the more complex process optimization and automation phases on an interative basis. Great outcomes for the customer and great reference sites for us.
Those that chose to drive their workflow project as a toolkit to invent new IT driven applications failed to deliver the end user enthusiasm that leads to continuous improvement. Without user motivation these projects go into maintenance mode waiting for the next new application thing to save them.
So I guess it comes back to us as process advisors to not oversell our products in the first place and to educate our business owners on the most appropriate project approach.
Regards
Craig van Zeyl
#4 by Ashish Bhagwat on April 10, 2010 - 2:59 pm
Craig, you bring out two good points. One, the customers that are more focused on process outcomes have better success at Process initiatives. Have to be, right!? And second, and very important on the necessity for the consultants and product vendors to not get swayed by the immediate temptation to please the customer. It’s not easy when you’re looking at quick success with the product while it takes an incremental effort to move to the new process paradigm. Good consultants and more confident vendors don’t get so easily swayed by this dilemma. But a lot of times vendors & consultants are confused as well 🙂
#5 by kswenson on April 10, 2010 - 3:56 pm
You make some excellent points here. Very similar to my piece from a year and a half ago:
http://kswenson.wordpress.com/2008/11/25/bpm-is-not-software-engineering/
You point things that people should and shouldn’t do, and I agree, but you need to consider the audience. It is the IT department that purchases BPM software, not the business people. When choosing BPM, the IT department chooses it for the programming capability.
To get straight to your point about the solution should not be an application, there should be two separate efforts: (1) create the data flow (to/from the execution environment, not flow between people), data transformations, and user interface, and (2) to define the sequence of activities, the rules, the choices, the roles, and the deadlines. This latter set is “non technical” and the programmers should “keep their hands off it”. In otherwords, the programmers design an environment that has no business process in it, but is ready for a business process to be poured in. The business people should be able to focus on the aspects you point out above, without the distraction of UI discussion. Moreover, each business group should be able to pour their own process in, without any need of programmer involvement or oversight, without any attempt or need for a programmer to “simplify” or “regularize” the process in any way.
This slide set covers a lot of these concepts:
However, the people who buy BPM may not see it this way. All we can do it try! Excellent post!
#6 by venkatesh on April 10, 2010 - 9:48 pm
Hi Ashish,
very good article!
#7 by Pawan on April 17, 2010 - 11:48 am
IT companies have made organization slaves of how they should work. Time and time again we find that managers / workers can not think of process without screenshots. Again and again one come across the reasoning of “it would not work as the IT system can not support it”.
To circumvent this we use something simple – “MS EXCEL”. When we do As is to Should be – we create excel sheets with formulas fed in as formats and reports. Linking these sheets work well in terms of data feed and data accuracy.
Once managers get use to reports and workers get use to formats (read 10-16 weeks), pick the excel document with the process flow and get it IT enabled. Every one by then is use to formats and reports and acceptability is much higher.
I can vouch for the above as it is an integral part of our implementation strategy and it works time and time again.
#8 by Ashish Bhagwat on April 18, 2010 - 6:54 pm
@Pawan, your recommendation to use the Excel based screenshots (I’d refer it as wireframe though) is excellent one – only provided it doesn’t mislead he users from the actual UI that they may actually see later… all about expectation management as well. However, in my post, I’m not trying to hint on avoiding the UI completely through the process implementation. The point is about not considering the UI as the central to the solution, actually the UI that you use through the development process would be an actual one – facilitated through the BPMS tool capability. And the UI will have to remain light weight even in production unless a proper portal integration approach is used…
And @Keith, never got down to conveying how much I appreciate your addition to this. I’ve gone through the post that you suggest – excellent piece. Always nice to hear from you…
@Venkatesh, Thanks for the appreciation. Glad you liked it, keep coming – and feel free to add comments… 🙂
#9 by Alana Schock on April 21, 2010 - 2:30 am
Like everything else you publish, great post – and very timely given all of the discussion on case management lately.
This very discussion came up at my company today. I’m a BPM Program/Product Manager – which is an overly-fancy title for all kinds of roles that I play in our BPM projects, but my primary responsibility is to ensure high quality project and product delivery for IT-provided solutions that are generated from the many BPM projects that go on in our business. Incidentally, the solution outcomes of our BPM projects are not always BPMS solutions – many times our data team delivers solutions to business process problems that are identified as part of the business process management lifecycle – or our external portal needs to be enhanced in some way to resolve a process issue or opportunity further down the line in the business process. The majority of my time, however, is spent on BPMS process solution implementations (previously our ECM-based workflow implementations before our BPMS acquisition).
We’re recently struggling with what you could basically call a failed attempt at implementing a complex process in our BPMS. I feel this is most likely because we didn’t realize and handle the case management dimensions of it in our original design. But the relevant aspect of this story to your post has more to do with the design approach of this now mostly-abandoned BPMS process and where it might have gone wrong.
We were assisted in the design and BPMS implementation of this business process by unquestionably talented external BPM consultants. However, knowing the behavior of our BPMS and how it handles task filtering and retrieval (not ideally), I had an inkling during our design sessions that we might end up with problems, but I was still relatively new to BPMS implementations in our newer system (vs. my experience with our workflow system).
When I specifically highlighted my concerns around the usability of what was shaping up to be a very activity/task-laden process and suggested aggregating certain tasks performed by the same process participant into a single UI (yet still attempt to retain process task visibility, SLA measurement and enforcement of certain business rules) I was very adamantly told more than once that this was “app dev” thinking vs. process thinking. Despite my attempts to help the process owners visualize what this might look like to the end user in their day to day, minute to minute experience of it in the BPMS, and return trips to the process portal it might cause for the same process instance/process participant, the process owners, along with me, were ultimately swayed by our experts to go with the “assembly line” BPMS implementation that almost directly mirrored the activities in the future state business process design.
However, a few months later after we implemented the process and had released the consultants, we had BPMS process user mutiny on our hands. The users hated having so many tasks to complete with no payoff to them, they literally felt that there were “too many activities”. For now, they’ve mostly abandoned it and returned to a simpler workflow process we had implemented for them previously until we can optimize the BPD to find the balance between process visibility and the user experience they understandably demand from a good business application.
So, it is with this experience in mind that I read your post. While I agree with much of what you say, I struggle a little bit with the idea I gather from your post that this is an “either/or” proposition – process solution design or application design. In our experience, I think it’s fair to say it’s more of a “both/and” approach that works best.
Our best BPMS and workflow implemented solutions seem to come of a focus on and exchange between both future state business process design and sound application design (and development) principles – in an almost back and forth type of way: evaluation of the future state real world “business process” (and all of the activities/tasks therein, including the ‘off BPMS radar’ ones, like phone calls to resolve exceptions or system to system integrations not yet implemented/the swivel chair activities) informs the design of the future state “virtual world” business process definition and execution in the BPMS, which in turn ultimately informs the execution of the “real world” business process, including activities not managed in the BPMS, and so on in.
The experience I’ve shared here tells me that implementing the future state business process exactly as defined by the business in the BPMS without at least using application and user experience (including but not limited to UI) design skills to understand which of these activities should be aggregated and implemented within a single BPMS actvitiy/UI could land you in place where you’ve implemented activities/tasks solely for the sake of illustrating the future state business process and automating a process map – rather than focus on optimizing the user’s experience of the application and potential “filter, find and select” task overhead that comes when you implement an activity in a BPMS without any automation payoff to the user. I believe that this highlights the importance of Forrester’s advocacy of the “Business Technology” approach and the evolution of business and IT working together – the interaction, exchange and blending of the process and technology skill sets at the same table – finding balance between the business process design and its goals, application design, IT development and data management standards and regulatory and security requirements (not a complete list, but I’m sure you get the picture). This is why I think we really need to invoke both types of practices at once – business process solution design and application design.
#10 by Ashish Bhagwat on April 22, 2010 - 4:37 pm
Alana,
You have brought up few excellent points, thanks for writing in such detail. Let me address one by one.
The fact that a business process problem, that becomes a BPM opportunity, may not end up getting solved with only BPMS. Absolutely. The BPM ecosystem is not only BPMS, but a combination of various technologies. I have delved into this on another one of my posts on BPM ecosystem. So, you may as well have a portals project coming out from a BPM opportunity, or an ETL load into an analytics engine or even a CEP based events trap and processing working with a BPMS to handle exceptions.
The one example that you took on user experience v/s task list driven UIs is pretty common actually and we often face this dilemma. In such cases the decision needs to favor the solution that makes users’ lives easier! And I don’t feel an inner conflict when I say that. At the solution needs level I would still want to address that aggregation of the tasks and combining the data for users in the best ways possible for the user. And even the task pages should be designed so as to get everything for the user that is required for them. The technical part of the solution in such cases needs to leverage on the portal technologies and various portal integration techniques, and the data level integration at the backend. This should not lead a person to believe that the whole back-end application logic and data schema needs to be brought into the BPMS. That’s it.
The arguments used by the BPMS vendors for not doing certain things may vary but most often the required may not be done due to the inherent limitations of the product and primarily due to the non-extensibility. In one case, one of my customers replaces the whole J2EE based portal of BPMS with a .NET based framework that the users were comfortable with – & using the process engine for the workflow. But even then, we followed the principles I speak about.
And a portion of your comment also refers to forcing the sequential process solution on a potential case management opportunity. So, there we go – you may want to refer to this interesting thread on EbizQ – http://bit.ly/da77iU
– Ashish
#11 by Peter Brand on April 24, 2010 - 2:14 pm
Hi Ashish
Where are my comments? Completely vanished?
Not to speak of your Reply.
Yes, I still think, the discussion could have benefited from a bit more of well-defined terms.
Forgive me, I am new to ‘LinkedIn’ (as to this group).
Seems, I have to try to start some separate discussion on my thesis: Business-Process Management by means of BP-Engine is a deadlock and the source of IT/Biz mis-alignment.
Peter
#12 by Ashish Bhagwat on April 24, 2010 - 2:40 pm
Peter, our discussion is on LinkedIn – http://bit.ly/bS79FC
And this is my blog, not really “linked” to LinkedIn forums directly 🙂
I do appreciate your comments but can’t move them here. In fact I’d love to see your thesis in a discussion…
Cheers,
Ashish
#13 by Peter Brand on April 25, 2010 - 5:40 pm
Sorry Ashish
Yes, I realized that I am arriving at two different places, your blog and this ‘News Discussion’. But I have no idea how to access the ‘News Discussion’ (other than via an E-Mail Link). If I chose ‘News Discussion’ from the Menu on the LinkedIn Webpage for Gartner BPM (Xchange) Group, I always get:
“”Es sind derzeit keine Diskussionen für Sie verfügbar
Sie können jetzt News-Artikel mit Ihrer Gruppe diskutieren und an diese weiterleiten.
Einen News-Artikel einreichen””
i.e.: “For you, there are, currently, no discussion available, …”
So, for me this Web-application does not work the way I would expect.
But, after all, you are right: I should try to start a well-focused ‘Discussion’ on my thesis.
Thus, agian, forgive me and thanks for your hint.
Peter
#14 by Peter Brand on April 28, 2010 - 7:35 am
Hi, Alana
Isn’t it surprising that, when it comes to design the UI, you/we are facing the problem of how much of the ‘Business Process’ we have to present to the user: Is it just one task (one process step) or should it better be a coherent piece (section) of the process.
For me, your question is: Should the application logic, driving the BP-engine, be kept back from or made transparent to users? I think, in both cases (extremes), the user is facing an application, the only difference being, that in the second case, she experiences: the application is referring to a process.
According to my opinion and experience, the core question in this scenario is more of the following: Is it fine that the user-interface TO THE PROCESS is identified with an UI to some BP-Engine program, rather than immediately tied to the process state, whose capture needs nothing than a databse and a proper frontend. If you are interested in the details of this suggestion, please contact me: peter.brand@mastering-it.com.
Regards Peter
#15 by Anthony on February 16, 2011 - 11:48 pm
I actually think you have put your finger on what is WRONG with the BPM/Workflow paradigm. You end up with an impedance mismatch between the the applications and the work flow — they fight each other to some extent.
The problem is that the BPM engine keeps process state independently from the applications, rather than asking the applications for it. Force.com’s (weak) data oriented workflows seem like a step in the right direction to me.
Good article.
Anthony
#16 by Ashish Bhagwat on February 20, 2011 - 10:35 am
@Anthony, to some extent the problem of Process Engines keeping the state independently is built-in with the principle of a separate Process Layer on top of the Business Apps / Systems. While data and systems logic requires a bottoms up approach of integration, the process management requires a top-down approach. Not an easy problem to solve.
For instance, OrangeScape (www.orangescape.com) has a business rules and data oriented approach to build applications with an abstracted out approach, but it’s not a BPM platform even though you can build workflows and system orchestrations all alike. It’s an application development paradigm still.
It all boils down to an organization’s Enterprise Architecture and how they plan to use various platforms/products available. The intention behind a BPMS is different from that behind an Application development platform.