individual-entry-BA-Blog

« Banks, customers and decisioning | Main | Speed (of decision-making) matters to customers »

business process and business rules

At the NY Brainstorm BPM Conference, we had an interesting panel on the relationship (current and changing) between "business process" and "business rules."  The answers were intriguing.  Before revealing the answers, it would be interesting to pose some of the questions to the bloggers to see if the panelists and bloggers agree.  So, here are three very important questions.

(1) How do you model or describe "business process" for your projects (e.g., activity diagram,  process chart or swimlane, use cases, other, all of these?)

(2) Do you anticipate adopting a business process modeling standard (e.g., BPMN)?

(3) How do you represent business rules in those business process modeling deliverables?

First time on the EDM blog?
Subscribe to the EDM blog feed or check out some other recent posts:

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83451629b69e200d83511d83169e2

Listed below are links to weblogs that reference business process and business rules:

Comments

Tom Griffin

I work at a Fortune 100 transportation company, specifically in the role of a business systems analyst supporting the billing function. The business rules debate has been one that has been going on since I was hired and doesn't look like it's ending anytime soon.

In terms of modeling, we use dataflow diagrams over the newer uml techniques. Most of our work is batch processing, where understanding how data is transformed takes a priority over user interaction (there is minimal user intervention, mostly only in exception scenarios).

In terms of adopting a standard, it's very difficult to switch gears once you and your stakeholders are comfortable with an existing approach. For instance, we could train our analysts in BPMN - but our internal customers would be left in the dark. Our company is so large, such a change would only make sense if driven from the highest levels - which has proven to be organizationally and politically impossible.

Finally, business rules: We document business rules that govern the outcome of processes. We tie them to the business processes that they are associated with, however, we are clear to differentiate them from processing rules. Business rules dictate acceptable business outcome, processing rules enforce the business rules.

In my experience, the spirit of each of the modeling techniques is generally the same. Furthermore, what we're trying to do with rules is generally similar - although we're calling things by different words (requirement vs rule, different types of diagrams, etc...).

Ian Graham

On Barbara von Halle's three questions:

(1) How do you model or describe "business process" for your projects
(e.g., activity diagram, process chart or swimlane, use cases, other,
all of these?)

All these things, but Activity/Process diagrams can get very 'big' very quickly. You need to modify Ivar J's definition of use cases to do this with them and you need to switch viewpoints between 'goal-oriented conversation between agents' and 'collaboration between agents' to get at the subtleties of a process.

(2) Do you anticipate adopting a business process modeling standard
(e.g., BPMN)?

Horses for horses is my favourite standard. BPMN looks better than activity diagrams but use cases (as modified by yours truly) can give a (usefully) different view on a process. BPEL is great for low level service automation. Also, for high level, organization- wide models, my 'mission grid' technique is much more tractable than any of these detailed notations. (Ref: Object Oriented Methods - 3rd Edition.)

(3) How do you represent business rules in those business process
modeling deliverables?

Again, multiple methods: As pre/post conditions in use case specs; as encapsulated constraints arising from type (class) diagrams; as free standing (policy blackboard) rules; as decision trees; etc. However, they should be written in a standarrd style a la Rulespeak or similar.
(Ref: Business Rules Management & Service Oriented Architecture. )

Hope that helps somewhat. I put the refs in to save having to type out swathes of explanation but it ain't advertising, honest; OOM is in fact out of print now. ian(commercialatsign)trireme. com if you want to know more.
Regards,
Ian

The comments to this entry are closed.

Search Site


  • dmblog.fico.com

Subscribe

  • enter your email

Upcoming Events

  • FICO Tools & Analytics User Forum 2012
    BERLIN: September 11-12, 2012 LONDON: September 18-19, 2012 Gain new insights for improving business performance through advanced analytics and decision management tools.