Business Process Management
********* This article is a stub ***************
Why make an article on Business Process Management(BPM) when the Wikipedia article seems to cover it pretty well already?
The reason is that Optimal BPM has quite a different approach to BPM than most others.
The project attempts to avoid complicated BPM terminology and try to unify the technical and administrative viewpoints removing many of the reasons to have conflicting viewpoints.
Also, through simplicity of development, administration deployment and maintenance, and by having good structure "by design", less specialized competencies are needed.
Problems with process/system development
In this day and age, business process development normally means that some amount of systems development has to be done as well.
So many of the systems development problems will arise during the business process development.
Bottom Up versus Top Down
A classic conflict in the development of computer systems, has been the tendency for many technically minded developers to start at the bottom and working themselves upwards.
This means, first develop the low-level components of a system, like logging, database access and so on, and finish by developing the GUI.
As a consequence the user interface and experience is not seldom an afterthought, a consequence of the technical design of the system.
Obviously, this annoys the customers. However, the system might have a more stable technical foundation.
Doing it the other way around, Top down, causes the opposite problems. Often one ends up with a good user experience and quicker development.
From a technical standpoint, however, the system is often not very future-friendly and developers might have to be forced to choose inferior techniques and architectures.
As developers and management gets more experienced, they tend to realize that these viewpoints need to be combined.
Still, this conflict seems never-ending, in spite of the many methodologies and paradigms that have evolved over the years.
This is because the two groups still work in their ends of the spectrum.
Even if one gets the others' viewpoints at the meeting, it is then quickly forgotten and problems arise again.
So, even though concepts like the daily scrum has ameliorated the problem somewhat on the technical side, it continues to be very much an issue, especially in smaller companies.
When developing a new system, or in the case of Optimal BPM, also a new business process, to have the support of management is key for its success.
Because always, the successful implementation of a new or modified business process also needs to have the support and commitment of the end users.
Otherwise end users will only see the new system as a problem, and not want to be involved in testing or giving feedback.
In many cases, they will simply not use the systems or change their ways if they haven't been involved.
Management are the only ones that can organize all the different groups.
It is however important for management to not try and combine the inclusion of a new process/system with efforts to make their employees work harder.
Process optimization is a way to enable personnel to work more efficiently which have many advantages in itself.
If people feel that they work efficiently with less annoyances:
- the work effort will be more tolerable and their workload will feel far less demanding(i.e work harder)
- they can focus on the business problems, and less on the practical problems, leveraging their competences
- they feel that they are learning something, and will then be more willing to give back to their employers
- annoyed coworkers lowers morale for the whole group
- other workplaces will seem less appealing.
And the list goes on.
Combining a business process project with other attempts is not recommended and will complicate matters significantly.
It is also important to involve the IT department in an early stage. Or "IT guy", if it is a smaller company.
If IT feels that they are getting an incomprehensible mass of complicated systems to maintain that creates a large number of problems, they will not be more enthused than the end-users and the project might become a failure for technical reasons.
This applies mostly to commercial ventures, but to comply with regulations and attain certifications that dictate high levels of auditing, reporting, availability security, monitoring and other features is often very costly.
It is therefore common that these areas are underestimated and either aren't implemented fully, and has home-brewed and sometimes downright odd solutions that both causes headaches and increasing maintenance costs.
Optimal BPM addresses these issues by:
- make things so simple that IT and management and the user groups involved can work with the business process development on an almost equal footing and join their viewpoints.
There should be a minimal number of situations where management doesn't understand the technology and IT doesn't understand the business vocabulary.
- use a notation that *all* can understand, management, IT and end-users. This is why Simple Process Notation is being developed.
It does away with the extremely symbol-heavy and complex notation of BPMN and reduces the number of symbols to 2 or maybe three.
To be fair, BPMN attempts to encompass all complexities of a system using symbols, SPN doesn't, because there is no actual need to.
Challenge: Here is an overview of BPMN 2.0. Try and explain it to a non-BPMN-expert. Technical or other background.
- make it very easy to insert custom scripting in the processes, minimize the need do involve specialized consultants.
- sacrifice some hallowed features that most organizations in most cases actually doesn't really need in full, like long running transactions(however internally, Optimal BPM employs the concept).
By using simpler models, many steps are greatly simplified.
- provide a complete infrastructure for all the demands industry standards and regulations demand.