Having seen a couple of approaches to codifying BP's I've formed the following opinions:
a) Less code is better. Business processes evolve. Software delivered in waterfall doesn't. In XP, adding features etc. sucks when your data model is shifting under your feet. (see also: why BP's should be expressed in (e.g.) a scripting language, not in compiled files.)
b) More freedom is better. People will ask "why can't I do X" where X is "attach an Excel file to the approved version of a final report, if the accountant signed the books in the last weekly meeting" - and coding that in Java or even a scripting language is stupid.
c) Less structure is better. Structure should be emergent, then inferred, not imposed. Evolved structure is seamless. Imposed structure is rigid and inflexible.
d) The more users, the better. Network effects increase an organizations net investment into a solution, and therefore (hopefully) increase its net benefit.
Posts
2 comments:
I think it depends heavily on wich kind of BP you are talking: accounting rules or ISO procedure dont change that easily and you must certify that all rules are respected.
c) depends also of the data itself accouinting is not natural a contract neither but other must information are more versatile.
What I think is that you have some businsess process that need to be handled in a rigid way other not.
The same apply to data.
I think the best approach is to have both :p.
Look for an Heldesk system: you need to have a very formal system to be sure that all customer gets answer in time but you need also lots of freedom for processing the issue/bug .
The data you need to solve the issue is not always the same; the people, ressource and process involved to solve a particular problem can vary and so you need different BP some very rigid (formal interface to the customer) and some not.
I'm an extreme anti-structuralist! So OK granted, as we said at breakfast there are places where BP's need structure (one-nil to Gael!)
I also think that you have a point when it comes to the necessity of structuring business proccesses (two-nil!), *however* I think the structure should be in what people do, not in the software they use.
Of course the software can help enforce structure, as in the helpdesk example, but as we said there should also be ways for people with relevant permissions to short-circuit the structure. We're back to making an infinitely complex and recursive system again :-)
Post a Comment