Main Area and Open Discussion > General Software Discussion

Software for Business Process Modeling?

<< < (3/10) > >>

IainB:
@superboyac: What exactly are the requirements and outcomes that you have when you say:
"What I need is something that can do Business Process Modeling."
--- End quote ---
For example - swim-lane diagrams (which you have already identified).
I ask this because your requirements will generally tend to determine what is the most useful tool for you.

(Sorry for this rather long post, but I thought it could be useful.)

The last time I researched this for a client, to answer a similar question, several points came to the surface:

* There are approx 75 software packages that were on the market that professed to "do BPM".
* Drawing/diagramming tools: the majority of these packages (about 70) were diagramming tools. These are essentially designed for drawing charts onto paper-based output, and some are identified in the discussion above - EDGE Diagrammer, SmartDraw, iGrafix, MS Visio, MS Word and PowePoint (yes, those too are legitimate diagramming tools!). They are all pretty good at what they do.
* There are several different "methodologies" that you find in use:
* * Process symbol drawing standards: the classic "Taylor" diagramming standards (unchanged from the Industrial Revolution) - archaic, but still in use today and perfectly valid for process diagramming purposes. These diagrams are unambiguous and easy to communicate to users.
* * Process system logic drawing standards: the main one is Rational Use Case. These diagrams are great for system design, but near-impossible to communicate unambiguously to users.
* * BPMN (Business Process Modelling Notation): This is a relatively new standard having emerged over the last 6 years or so, and seems to have been developed by a consortium of software suppliers interested in devising a new standard and cornering the market for that standard. The software using BPMN enables logical modelling and diagramming, but tends to be very costly - Aris, Sparx, Oracle BPA Suite (is Aris), Telelogic System Architect. BPMN diagrams are relatively unambiguous and easy to communicate to users. Costs are typically about US$30K+ to distribute this category of software via a server in an enterprise.
* * IDEF0/IDEF3: these two IDEF standards have been around for years and have stood the test of time. Theyare very simple and logical. Diagrams using these standards are very easy for users to comprehend and critique.  These standards were originally developed for US Dept of Defense use, and the software to build models using these standards was funded by DoD. The FiPS for these standards are dated about 1991 (from memory). IDEF0/IDEF3 are two of a set of about 15 standards, and are the ones that relate to BP modelling and decomposing such models into DFDs (Data Flow Diagrams). IDEF was de rigeur for all US government department process modelling, has been used by government and commercial enterprises in the US, Canada, Europe, Australasia, Vietnam and Thailand. There is a text or guide book issued by the US GAO that describes when/how to use it for BP analysis, improvement, and rationalisation. The software is now owned by CA and is called CA Allfusion BPM. It is part of a CASE tool suite where you can, for example, feed BPM models into an E-R modelling tool, and feed E-R models into a BPM model - it is very powerful and time-saving. This is proper BP modelling where models exist in a logically coherent database, and you never need to print out your models on paper. You project them onto a wall and discuss them with users, dynamically changing them as you discuss them. When finished, documentation can be automatically generated (including diagrams) in HTML - so it can all be on an Intranet for people across the enterprise to access. (No paper required.)
In 1998 I found myself in a bit of a spot as the lead BP engineering consultant when we bid for and won a contract in Thailand, where we had to collect and re-engineer all the core processes of a Thai government Department, and draw up specs for systems to support these processes, for a 7-year plan to automate what were then largely manually-operated processes.  We were going to do it the conventional way (paper-based) as we had been taught in school. However, when we got there, we discovered that another - rather famous - consultancy had preceded us, offering to do much the same thing, and had been thrown out and not paid - their work had not been perceived to add any value. Fortunately, one of our team was a data analyst, and he was using an E-R modelling tool called ERwin, and he said it was part of a CASE suite of tools that included a BP modelling component (BPwin), that could enable capture of the processes in a logically coherent database. It used standards called IDEF0/IDEF3 that I had never heard of before. I quickly obtained a trial copy of BPwin. The IDEF0/IDEF3 standards were brilliantly simple, and the tool was not difficult to learn to use (I taught myself, using the handbook). Over a long weekend (4 days, with little sleep) I succeeded in developing over 100 AS-IS processes model diagrams covering the core processes of the client organisation - all drawn from our consultants' extensive field notes (discovery). I was amazed at having been able to achieve this and the client was blown away by it (so was I!). We then taught the client process improvement group personnel to use the tool and collaborate with us in improving the models and re-engineering them into TO-BE models. These formed the basis for future system development. The models were held in a database where different modellers could be assigned to work on different parts of the models, so they would be "checked out" of the database whilst someone was working on them, and checked back in again when finished and ratified for integrity by the process participants and owners.

What this Thailand experience taught me and the other consultants is:

* that we need to raise the process of business process modelling to CMM Level 3 or higher, and that we can do this if we automate the process of BP modelling to a large extent.
* that we needed to be constantly aware of emerging standards and technologies and how they could be employed to help us improve the quality and speed of delivery of BP consulting assignments.
* that the use of CASE tools such as BPwin enable improved productivity so that you can expect to save 50% on the timescale for a typical BP analysis, save 50% in people (need fewer BP analysts), with corresponding very significant cost-savings. (This has also been demonstrated and achieved in several similar assignments subsequently.)
* that a lot of good and useful thinking is done via DoD-sponsored methodologies and tools (e.g., PERT, CMM, IDEF0-14, BPwin).
By the way, the BPwin software was ultimately acquired by CA and is now the BP modelling component in CA Allfusion Suite.

After the Thailand experience, I made a firm promise to "never again go back to using the old process diagramming/modelling approaches", and I have assiduously tried out all the new/changed BP modelling tools. I am not really interested in and have little use for process drawing/diagramming tools - they are all fine. Most of them will be able to "support" BPMN and IDEF0/IDEF3 - which only means that they can draw the boxes, lines and other symbols.

Amongst the pukka modelling tools, the BPMN standards tools - though very expensive - are very good, and, because they lend themselves more to IT systems design (which is why IT people will tend to prefer them and find them easier to understand) they are quite popular with IT system architects, who sometimes even seem to develop a religio-ideological fervour about them.
However, for pure business process modelling (not system design) the BPMN tools must come a distant second to the IDEF0/IDEF3 process modelling standards tools (there is only one really - CA Allfusion BP) - when what you want is absolutely clear and unambiguous definition of business processes. This tool includes ABC (Activity-Based Costing) which is a real boon to evaluating the cost-effectiveness of your AS-IS or TO-BE process whilst you are modelling it - after all, it's a business decision as opposed to a technical decision as to how to operate any business process, so the activity costs will be important. This tool is relatively low cost (about US$3K per copy, and you won't need many copies) and would be indispensable to any organisation trying to move up the CMM continuum to Level 3 and above.

I will generally use whatever standards my clients want me to use on an assignment. When I was contracted to doing a business process re-engineering exercise for a major Oracle vendor in 2009, I was told they wanted to use BPMN and the Oracle BPA Suite (this is the Aris software, but with an Oracle badge). They had not used either before. When they started to enable their license to use it, they realised that it was still hugely expensive and that they could not afford it - even given the dealer discount. So they decided to use a non-BPMN process diagramming and documentation tool that was owned by one of their subsidiaries - with the same result (still hugely expensive and they could not afford it - even given the dealer discount). Then they asked my advice. I did a quick survey of the market and gave them the $ numbers and a recommendation - it was a business decision. Ironically, the client selected and bought CA Allfusion BP - because: it was cheapest; it met all their needs (they changed their standard from BPMN to IDEF0/IDEF3); they got ABC into the bargain (which gave unexpected benefits).

superboyac:
IainB, thanks so much for the in-depth story.  There's a lot going on there that i don't understand, but I was able to follow most of it.  This is very fascinating.

Right now, the only thing I'm doing is diagramming.  I just draw boxes and arrows that make a flowchart.  It sounds like the things you do are a lot deeper than all that, and I want to know what it all means.  What is going on there?  What is the thing that you do (in layman's terms)?

From what I can piece together, it is this:
A company has a certain way of doing things--their business processes.  It may not be written down or formalized, but it's there.  So you come in and formalize what they do.  You make a database (what's in it?) and you create some kind of system that does something.  I have no idea what it is.  What is the end result of all of this?

In our case here, the end result will be a manual that accurately depicts how things are done here.  So, an employee who gets assigned a project can go to the page (or website, whatever) and follow the instructions of how to complete his job.  Is this the end product of all of this?

There are so many technical terms, and strange, complicated lingo for all of this.  What does this have to do with IT?

We have Oracle here also, and there are talks of bringing in their BI stuff and integrating it with our stuff.  What that means is not known to me.  I've heard a little about their BI tools, and all I know is that they help manage stuff that businesses do.  yeah, I don't know much, i know.

David1904:
You might like to take a look at this http://www.yworks.com/en/products_yed_about.html
The program is yEd Graph Editor - and the price is right!
I only downloaded it myself a couple of days ago and have just begun to look at it. The range of diagrams you can create appears excellent, and a good number of samples are provided - some of which are business modeling with swim lanes etc.
The output looks very nice too.

Example graph

IainB:
@superboyac: In reponse to your post:
By the way, you can get hold of the abovementioned GAO manual here (click on link): GAO BPR Assessment Guide 1997

Defining a BP (Business Process): When you draw a diagram of a BP - typically into "swim lanes" - and (maybe) put words around it to describe the BP, so that it can all go into a hardcopy or online Intranet instruction manual for process participants (the people who actually operate the process) to refer to, then you are defining the BP.

Why would you define your BPs? Well, you are apparently wanting to do this to provide a BP instruction manual for your employer, where you say:
This is kind of a big deal for me and the organization.
--- End quote ---
If it is "a big deal", then you presumably want to make as good and professional a job of things as possible.
What you have is to do is operate a process for BP discovery, analysis, modelling and documentation. You might also want to add process improvement into that mix, because you are likely to stumble over potential areas for significant process improvement once you start to scrutinise a process.

You can either:

* (a) Carry out that process in the conventional manner - i.e., based on little or no theory, conforms with received wisdom, is manual and relatively laborious, time-consuming, labour-intensive and thus expensive. (Most companies will take this track, because they don't know any different).
* (b) Carry out that process using a sound theoretical approach and automation of the process as much as possible. Automation and acceleration of the discovery stage - of the process of business process analysis and re-engineering and communication of same - will result in these benefits: able to do more with fewer analysts, in roughly less than half the usual time it would normally be expected to take, and at lower cost. This is what my Oracle vendor client (see previous post) did for their ITIL process work.
You start with this premise: Anything that an organisation does is a process (a BP), by definition.
"If you can't describe your processes, then you don't know what you are doing." - W.E.Deming.
--- End quote ---

Procedure or process manuals have been around since the Industrial Revolution started, and thousands of man-hours ($$$ costs) have been and are spent on producing such documents and maintaining them. They have to be maintained if they are to keep up with the reality - which is that BPs have a tendency to undergo change/improvement in real life, regardless of the static definition of the process in a manual. Without this maintenance effort, the majority of procedure/process documents tend to gather dust and rapidly become out-of-date. In some industries, it is mandatory under law to keep process and equipment documentation up-to-date - for example, in the power supply industry where the unwitting use of outdated manuals for isolating and servicing high-voltage transformers has resulted in engineers' deaths by electrocution.
As a general rule, when in doubt, automate. If you can automate the process of BP definition and communication and automate the production of BP manuals and changes to same, to online Intranet sites, then you are likely to be able to avoid spending a heap of money on that work and on hardcopy materials and administration and maintenance of all/any forms of that documentation.

Theory: regarding the need for theory:
"Action that is not based on sound theory is irrational, by definition." (W Edwards Deming; and refer also Kepner-Tregoe)
--- End quote ---
There is a tremendous amount of ignorance, opinion and BS around the subjects of BPM (BP Modelling) and BPR (BP Re-engineering), and I have had to drag myself out of my own ignorance in that regard (still doing it).
There are three things that are probably the most useful thinking tools that I would suggest to help gain an in-depth understanding of BPs, what to do about BPs, and when:

* The theoretical CMM: refer the Google knol CMM - Capability Maturity Model
* W.E.Deming's 14-point philosophy.
* W.E.Deming's Experiment with the Red Beads.You can use the CMM to determine what CMM Level different parts of your organisation are at.
From experience, many organisations rest at CMM Level 1 ("Ad hoc") or CMM Level 2 ("Repeatable") - both are kinda chaotic. Such organisations can and do waste a lot of money and produce a lot of poor or inconsistent quality output because of the "process thrashing" that typically occurs in those Levels (where BPs are in a state of dynamic change).

More theory: general management theory defines these four basic types of management:

* Strategic management: Planning "the way ahead". Taking the helm - finding out what direction to take and steering things in that direction.
* Operational Management: Planning for and managing and maintaining the stability of operational processes and the status quo of same, so that things tick along with minimal change/accident.
* Project Management: Planning for and managing the life-cycle of projects to "do" something new (e.g., make a change to some process; implement a new computer system).
* Crisis Management: This is about reactively dealing with events that flare up seemingly unexpectedly, requiring heroic efforts to sort out. No planning is required. This is something that seems to come very naturally to us as a species (we naturally lack the ability to plan and have to learn to do it). Some managers are very good at crisis management and may even opine that things are best left untouched until they become a crisis and you are obliged to do something about them. Large companies with a CEO who prides himself on being a good crisis manager have been known to fail spectacularly. Many crisis managers can seem to be quite charismatic and are highly-regarded until The Collapse. Surprisingly, these people are allowed to vote and drive cars.        ;)
From experience, to work on process analysis/discovery and modelling, you ideally need to have the sponsorship of an Operations Manager. The other types are unlikely to be able to make time for nor sense of what needs to be done. The Ops Manager though will rapidly be able to see the importance of the work to his management responsibility, and that it could help him/her in the execution of the role.
Even with that support, if the organisation is at CMM Level 1 or 2 or somewhere in-between, and if you try to define a process, then good luck - the outcome will be uncertain. You will define it one day, and the next day it will have changed, so your definition will be "wrong" now. Such organisations are not in an appropriate state of readiness for deliberate, developmental change/improvement. So, you have been warned: if you hook yourself to the end of a flailing piece of rope, it'll be a bouncy ride and probably totally unproductive in the general scheme of things. Having tried to ride that rope and beat it against all odds, I have learned to walk away from work where the client is too chaotic to benefit from BP modelling/definition. However, if management understand the theory and the need to improve the capability maturity of core processes, then you may well get somewhere with it all, but you won't be able to do it on your own (that's why clients call me in as a consultant).

Drawing a diagram of a process can be the start of process definition. You can draw it as though it were on paper, using a diagramming/drawing tool. However, if you were able to draw that diagram in a CASE (Computer-Aided Systems Engineering) tool that captured your lines, logic and boxes and turned them into records and record attributes in a database (repository) of your corporate processes, then you would be in a novel position. You could plot the process by department (swim lanes) or cost centre (swim lanes) or by any other attribute you can think of. You can also achieve a lot of that stuff that I referred to in my earlier post. If an organisiation gets to this stage, then it will be more likely to be able to move towards CMM Level 3, at least.

However, if you use some kind of system design tool - e.g., the BPMN tool such as Aris (the Oracle tool uses that) - then I would suggest great caution. From experience, the BPMN standard is appealing to IT people (QED). It is also very expensive. Many IT system architect groups have bought this hugely expensive software because they like it (though they may have all sorts of rationalisations for buying it). Having bought it, they then find that they have little real use for it, and the thing languishes in a corner somewhere. They treat it like a hammer and go looking for nails. Every time someone wants to draw a diagram of anything, and especially when someone says "business process", out comes the old hammer. They have to make it look like it was worth spending all that money on - see? They will insist that there is no better hammer than this one - take their word for it! They know they are right, and they know better than you! It's rather like an ideological zealot. They Believe and so must you!
Belief is irrational, by definition, and Edward de Bono described this sort of situation as irrational intellectual deadlock that often affects the more intelligent (it relates to ego, which has to be "right" at all costs). I reckon it is also Ahamkara, though it has been aptly analysed in the theory of psychology as cognitive dissonance (refer the book, "When Prophecies Fail").

If you go back to Deming's quote about theory:
"Action that is not based on sound theory is irrational, by definition."
--- End quote ---
- and if you look at the theory behind IDEF0/IDEF3, then you will be amazed at how simple and applicable it is to business processes (as opposed to IT systems), and you could not fail to notice that the IDEF0/3 standards enable a rigorous focus on the process. That is presumably why the US DoD had it developed, and why GAO and government agencies mandated its use.
In IDEF0/3, IT systems only figure as a "Mechanism" to enable (support) a process. Thus IT is a dog and is to be kept in its kennel. This would be anathema to an IT Believer who Believed that the system describes the process. This is pure belief/opinion, and nothing could be further from the rational truth (refer Deming). This is also why the Rational Use Case approach is next-to-useless for unambiguously analysing and communicating BPs, despite the IT ideology that Believers insist makes it quite the reverse.

This all about business processes, not about (zero) IT. Let the business managers make the decisions, not the IT guys - even in an IT company (again, like my Oracle client). Thus, when you say:
There are so many technical terms, and strange, complicated lingo for all of this.  What does this have to do with IT?
--- End quote ---
- It has nothing to do with IT. I would suggest that you don't let the IT guys hijack the BP analysis phase and turn it into a non-productive exercise in ITIM (IT Intellectual M#st#rb#tion). They can do that, you know. I once saw a large software development group brought to its knees because of intransigent internal bickering amongst two opposing IT ideological camps over whose methodology was thickest. It stopped a major redevelopment project (the biggest such project in NZ banking) dead in its tracks whilst the debate raged. Eventually the owners shut the company down and made them all redundant. No satisfaction in your Belief being "right" there, on either side.
 

Closing with a couple of Deming's favourite quotes:
* Who is it that darkeneth counsel by words without knowledge? Job 38:2
* My people are destroyed for lack of knowledge. Hosea 4:6
--- End quote ---

IainB:
@superboyac:
Here's the link to the CA Allfusion CASE toolset.
AllFusion Process Modeler

Navigation

[0] Message Index

[#] Next page

[*] Previous page