Thursday, July 13, 2006

What to do when BPM is too much and email is not enough?

I was reminded of this little problem a couple of times today. Does anyone out there have a good response to this question?

When I need a business process driven application that has a large number of users and low complexity process, where do I turn?

BPM seems overly complex, while email doesn't provide me with the control and reporting I require. Is there a toolset that fills the gap?

Should I select a point-application from a small vendor, build it myself with open source, or just build on top of a BPMS?

Looking at it from a requirements point of view:

  • Complexity of process: a few steps and simple decisions
  • Change process: rarely needs changing
  • Number of users: 5000 (20% concurrency)
  • Volume of cases: 200 new cases per day
  • User interface flexibility: important
  • Reliability and availability of application: important
  • Security model: hierarchical
  • Document storage: small number attached to cases
  • Metadata: 40 attributes, many being free-text entry fields
Some people have said that the process engine of BPM suites is the way to go, but this has implications in terms of cost and integration complexity. I have heard others offer that they would just build the application on top of a database and some enterprise portal tools. A further offer was to use an integrated document management and workflow tool. Someone even suggested using the Microsoft workflow (I have no experience of it, but instantly scoffed when I considered the scalability aspect of many users).

What would you do with a request like this when the business needs an answer and a proof of concept system in under 2 weeks?

Technorati tags:

5 comments:

Anonymous said...

If you already have a BPMS this is the way to go. 5000 users (1000 concurrent) is by no means "small" application by BPM standards. BPMS has ability to rapidly change UI and monitor performance. Among the leaders, Lombardi, Savvion, or Adobe would probably work well.

Phil Ayres said...

Bruce,

I think I agree that if a BPMS was already in house, that is the way to go.

My main fear with selecting a BPMS solution in this scenario is around the perceived complexity, and the real cost (long term).

After the first week of process implementation, the process modeling capabilities are unlikely to be used again for another 12 months. And in a 8 step "review/approval/issue tracking" type process the power of the process engine will hardly be tested, and probably much of the conditional logic will require scripting anyway.

So I'm struggling with balancing the need for scalable access for 1000 concurrent users (therefore the worry about mid-market point solutions) against the fact that 95% of the power of the BPMS would not be used beyond serving up cases to users.

I'm still need some convincing...

Cheers

Phil

Phil Ayres said...

I have also had some interesting responses to this question on the
Yahoo BPM group
for anyone that wants to follow both.

Anonymous said...

Have you considered using google spreadsheets? Today they have a very simple sharing mechanism. If they could extend it to support a simple routing slip, I might become the solution with the lowest barrier to entry for this type of "zapplet"[1]. -Edwin

[1] zapplet waisted $100M of funding to try to address this problem - yes $100M!?!

Phil Ayres said...

Edwin, thanks for getting me back into the 'business processes in a spreadsheet' approach - its one that keeps coming back to bite me. I'll certainly take a look at what Google can provide.

For everyone's information, other interesting approaches have surfaced, from using issue/ticket tracking applications, the use of commercial and open-source BPM, through to building the application on top of Amazon Simple Queue Service, to at least handle the guranteed delivery and locking of cases (I'm going to credit Ismael Ghalimi at IT|Redux with introducing me to this one, even though I can't remember why!).

Each option has its appealing features, depending on the appetite for software development in the organization in question.

The book is still open. I'd love to hear of any different approaches.

Cheers
Phil