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.