@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 1997Defining 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.
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.
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)
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:
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."
- 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?
-
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
