How Important is Domain Expertise?
Submitted by Abhishek on Thu, 2014-02-06 10:14
sxc.hu
While working with our BPM Research, we came across several Domain specific implementations and several products talking about having them built into the product. It made me think, does it really add value? Do you really need domain specific components within the BPM Framework?
Domain specific components could be Form Fragments, Data models or even Graphs and reports that make sense to a particular domain. For example, in Customer Service, this could mean the number of requests you resolved within the specified SLA. Do go deeper, if the product has specialization in "Call Centers", they could have processes that monitor SLA's or a voice call.
Well having built in components definitely saves time, as you do not need to reinvent the wheel. You could start servicing your customers within days rather than waiting for weeks (a Typical BPM Implementation time-frame could be 4-6 weeks for your first process).
However, the downside is that industry specific solutions seem to be very rigid. With variations in how processes are implemented worldwide, a Financial Risk Calculation process may not be same for a company in UK and US. The processes could act as a good starting point, but from our experience, it takes a longer effort to understand what has been done and then modify it. Not to mention, the vendor should be willing to share the code with you.
That said, I feel a better choice would be those products which have a smaller components that you could plug in. For example, a KPI Widget that allows you to set your parameters or a Generic adapter to SAP would be much easier to use. Your efforts would go in assembling the application rather than hacking it.
Another approach, which falls in between the two happens to be one in which you could actually build reusable components. You could define widgets and fragments for different resource types you have. Every workflow could then use this centrally managed component.
Hope this was useful. Comments and suggestions are welcome.
Domain specific components could be Form Fragments, Data models or even Graphs and reports that make sense to a particular domain. For example, in Customer Service, this could mean the number of requests you resolved within the specified SLA. Do go deeper, if the product has specialization in "Call Centers", they could have processes that monitor SLA's or a voice call.
Well having built in components definitely saves time, as you do not need to reinvent the wheel. You could start servicing your customers within days rather than waiting for weeks (a Typical BPM Implementation time-frame could be 4-6 weeks for your first process).
However, the downside is that industry specific solutions seem to be very rigid. With variations in how processes are implemented worldwide, a Financial Risk Calculation process may not be same for a company in UK and US. The processes could act as a good starting point, but from our experience, it takes a longer effort to understand what has been done and then modify it. Not to mention, the vendor should be willing to share the code with you.
That said, I feel a better choice would be those products which have a smaller components that you could plug in. For example, a KPI Widget that allows you to set your parameters or a Generic adapter to SAP would be much easier to use. Your efforts would go in assembling the application rather than hacking it.
Another approach, which falls in between the two happens to be one in which you could actually build reusable components. You could define widgets and fragments for different resource types you have. Every workflow could then use this centrally managed component.
Hope this was useful. Comments and suggestions are welcome.
