Hi Guys,

I would like to know more on Business process mapping and the common tools used for mapping.

Someone help me pls.

Stalin.

Hi,

Data flow diagrams is a fine process mapping tool - but there are lots out there and they can all be made to be fine process mapping tools if (like with any tool) you know what you are doing.

Tony asked a great question "how is a process defined?" and gave the answer "by its inputs and outputs". That does not work for me: if a process is defined by its inputs and outputs then I can have a 'process' of input first number of my cash card PIN. The input is a number and the output is a prompt for input of the next number.

I can also have a 'process' of "run my bank account" where the input is all the set up, transactional and close down data I need to run my bank account and the output is all the responses to all the inputs.

I can also have a process with no inputs but just outputs: "ring alarm on alarm clock" - the time is calculated internally by the clock so no input....

I can also have a process that has no outputs just inputs: "close atm application"

Something is wrong here and I suggest it is the definition of process which turns out not be defined by its inputs and outputs.

So, if I'm so smart what it is the correct definition? Tony: I'd be really interested to get your comments on how I understand this works: Top level processes are relatively straightforward: a process is a connected series of activities intended to achieve a desired outcome. So the idea is that having started the process "withdraw cash" there are a connected series of activities (potential sub-processes or just lines of process execution logic - not code!) that will handle the desire of the process initiator to "withdraw cash".

One thing to bear in mind here is that having initiated "withdraw cash" the process must come to a predictable conclusion to leave the solution in a stable state - i.e. it cannot just stop mid-process and leave the initiator and/or the solution in a state where other processes could be initiated. There are other factors that need to be considered when identifying processes but too much for this post...

Defining sub-processes is not straightforward and is also beyond the scope of this response to document (life's too short!!!).

Having said all that, as Tony rightly points out: a process modelling tool that cannot (or does not) capture process inputs and outputs is pretty useless.

Guy

Great discussion - I think some very good points have been made.

On my current project we've taken a service-oriented approach to business modeling that incorporates the process into the larger context of a 'service'.  We define the service by:

• Description (what is the goal of the service?  What business value does it provide to the client?)
• Client
• Provider
• Inputs
• Outputs
• Interaction (essentially a black box use case model - what does the client see?)
• Implementation (the process that implements this service - could be several variations for a given service)
• Requirements (business rules, services level agreements, etc. that impact how this service will work)
• Dependencies (what services does this service depend on?)

You can see we're trying to capture what both Tony and Guy are mentioning are important aspects to understanding what a business is trying to do for  specific goal in mind.  Sometimes this definition has proved tricky (for example, we've had to create services where the client and provider are one and the same to demonstrate a sub-process that is encapsulated in larger one), but overall we're finding it to be fairly robust.

We initially used BPMN for the implementation model but moved to more generic UML-based 'activity diagrams' for simplicity when showing the models to business people (BPMN has a lot of potential, but is currently applied unevenly and its breadth can make diagrams confusing to the layperson).

For BPMN, I also found this slide deck to be a useful overview:

http://www.omg.org/docs/pm/05-12-06.ppt