[b]the zero-code myth[/b]- if you want your processes to execute and to get integrated into a larger picture, you have to code something in. I have not yet seen a fully integrated solution that gets to executable stage only via the properties panel.
[b]the superficial data modelling[/b]- the BPMN standard puts a serious treatment of data outside its scope. This is a mistake. Most data today needs to be persistent and it has to have a logic that is easily accesible by BPMN. Let's say this is not dead, but not yet born.
Fact is business logic never changes so make generic store in database ........ Highly disruptive and such as your view has been the challenge.....!
I am struggling right now with this and I happily report that it is a beautiful battle and beautiful code wins everytime :-)
I started learning a bit of Java, that's how much I believe in the zero-code myth.
- Bogdan Nafornita
- 1 year ago
Declarative removes hard code the "the map IS the app" sure calculations complex calculations algorithims may need the "geek" input but not the business logic all pre-coded just configure direct with users!
I thought of BPMN might be dying?
Also, let's not forget, the demise of workflows chiseled in granite: today's best BPMSs can be changed by the users as they self-improve the workflow to optimize their own part of the business. Along with this the once stone-mason guardians of process automation are being replaced by ever eager innovators striving to reduce human effort and streamline business activities.
Take those self-improvements and refine them within the context of "this is how the performance characteristics of this app affect the overall performance of the infrastructure its deployed on given the idiosyncrasies - "tips, tricks and traps" - of how this solution, this platform likes to do things, does them well and how, and how not.
- Patrick Lujan
- 1 year ago
- the idea that BPM is a project -> No, it's daily business
- The idea that a process is 'a few blocks with arrows' -> No, that's just a picture of the workflow
- The idea that every process can be managed 'standardized with a workflow tool' -> No that's just one type of managing a process
- The idea that BPM = Automation -> Partly it might be, but managing processes needs more than automation
As for what is dead or dying well I guess BPEL for one? Also the BPM tag as application software feels like gone as more recognise it is the BPM discipline in thinking that sets up requirements; the end result should describe what is actually does? The tag emerging is “Adaptive” is the obvious one. It is what we call it and it is not just for Case Management.
- Peter Johnston
- 1 year ago
1 Confusion between “planning of work” (i.e. process template) and “observing work” (i.e. process instance)
2 Process transforms inputs into outputs
3 Process is a flowchart
4 Process equals to BPMN
5 An end-to-end process can be expressed as a flowchart
6 Process is just an illustration of the real work
7 Coordination of activities within process may be implicit
8 Process is a flow-of-resources
I can remember when Business Intelligence meant creating a datawarehouse and building all the integrations painstakingly one at a time. The result was a half million dollar project just to deliver a few graphs to a few executives. Now it is an off-the-shelf app and a few minutes in zapier or something similar.
In this environment we cannot justify the figures many charge for BPM. It has to come down by a factor of ten or more to gain real traction and take its rightful place as the underpinning technology for the business.
The second, surely is Waterfall Development. This Chinese whispers system of Analyst, Architect, Developer makes absolutely sure that the users and customers are abstracted from the process and that the business needs are forgotten when the process finally comes together.
And the third is IT only process design. Processes need to change fast and the only way to make this happen is for business people to be given the keys. And the way to keep control is to make sure that their decisions are data-driven. By releasing the data the process yields and delivering it in meaningful ways to end users, we can create such obvious areas for change that we can predict how the path will go, eliminating all the arguments on direction, method and measurement of results which dog so many processes. IT only process design says only we can see the data, so the obvious ways to improve the process are hidden from view and people are left arguing from positions of ignorance.
+44 (0) 1491 874368
+44 (0) 7590 677232
Maybe the "hope" for agile BPM projects... BPM is in-fact expanding and during its conquest runs into more-than-a-few islands of resistance. The biggest "fortress" standing against the BPM-tide are age-old methodologies (i.e. waterfall).
BPM is now entering a new phase where "process aware" applications are the norm. BPM is becoming an add-on core feature to many enterprise back-office systems (applications)... hence the blending and inter-breeding between technologies and their come-alone methodologies.
[*] The idea that BPM is a set of libraries that programmers use to cobble together process applications.
[*] Simulation, possibly the most expensive shelfware ever sold, useful in a tiny percent of cases (missions to Mars, perhaps).
[*] The restriction of BPM to back office applications. BPM is in the field and in the customer's hand. Time to step up our UI/UX game.
- E Scott Menter
- 1 year ago
- Page :
However, you are not allowed to reply to this post.