Doorgaan naar hoofdcontent

Some common BPM mistakes

In a lot of projects i have done for customers there are a few misunderstandings i often see with BPM or Business Process Management.

 1) You are not doing BPM when using a BPM tool
It is often called already BPM because it is hot, but the business is not process oriented at all. This is because a BPM tool is introduced bottom up, but the organization is not process oriented at all. In fact the business is process oriented (by default there is of course always a process), but this is not analysed or controlled.

 2) Flexibility comes not for free
This is maybe in theory but in practice i have rarely seen this. Making a solution flexible requires a lot of future knowledge which is often very difficult of course. You can only make your BPM solutions flexible where you know you need the flexibility.

 3) BPM does not solve it all
As with all new hypes, this is the next magic tool that solves it all. Of course this is not the case and it requires a lot of good thinking and experience to implement a BPM solution. In fact it may be far more difficult because it often expands more business units within the organization.

4) BPM(N) is not a new programming tool
Within a BPM solution there exists a BPMN drawing toolbox. With this tool you should model the business process on certain levels. What i often also see is that Services are also implemented with this tool. However it may be better practice to implement the Service within Java or another platform.

5) Testing BPMs is not something you do afterwards
Testing is often a underestimated effort. I personally think that 1 developer needs 1-3 testers.

And there are probably a lot more ...


Please feel free to react and add more when you like.

Reacties

Populaire posts van deze blog

Microservices mindmap

"The tree" - See also   my photo page When you are fairly new within the Microservices land, there are a lot of terms fired at you. So also for my own understanding i have made a mindmap. I think it has a good status now, so that i can share it with you. As always feedback is very welcome ! You can download the mindmap here .

OSB 10gR3 and SWA and MTOM

This blog is about using soap with attachments and the use of MTOM within the OSB (10gR3). A service is created that accepts a soap with attachment (DocumentService) and translates it to a service that accepts a binary element. MTOM is used for performance reasons for the second. Some notes: * For the use of attachments you need RPC-style document instead of the usual document-style. This due to the fact that the document-style limits a message to a single . * A service can not have both SWA and MTOM within OSB. First a WSDL is setup for the DocumentService: The $attachments variable holds the attachments and the body holds the attachment data. Also other data is stored within the attachment element (see h...

Cloud to Cloud Application Integration

A lot of applications have integration possibilities, so do cloud applications. The question I got from a customer is whether to have a point-to-point integration with Cloud applications or to go through their ESB solution. This blog describes some considerations. Context The customer has a HRM application in which job vacancies are managed. Furthermore that system also handles the full applicant process flow. They also have another cloud application that handles the job vacancies. This application posts the jobs to social sites and other channels to promote the vacancies. Furthermore this application has some intelligence for job seekers to advice some new vacancies based on previous visits or profiles. The job vacancies need to be sent to the Vacancies application and applicant information needs to be sent to the HRM application, when a job seeker actually applies for a job. Furthermore status information about the job application is als...