Sorry, this entry is only available in Русский.
Posts Tagged ‘ACM’
From time to time we are approached by prospects requesting task control automation by BPM.
The idea is simple: someone assigns tasks by setting goals, responsibles and terms. It’s easy enough to develop a system automating terms control, due dates reminders, statistical analysis, etc.
There is a Russian idiom “The Hamburg Score”. It comes from a legend saying that professional wrestlers of the world gathered in Hamburg once per year at the beginning of XX century to find out who is the best. The point is that they did it for themselves, not for public.
This story came into my mind at bpmNEXT conference because of its unique atmosphere: no marketing stuff, no lead generation, no speculations about what BPM is – nothing of what one may expect at a typical BPM event. Just a professional showcase of tomorrow’s BPM. » read the rest
Basic BPMN Assumptions:
- All information is stored
- Organization has a mechanism of tasks assignation and transfer
- Every task is accompanied by appropriate instruction
- Every task has standard duration and there is a way to control it
3. Every task is accompanied by appropriate instruction
Another way to simplify the diagram: keep in mind that a text description and/or instruction can be attached to a task. » read the rest
Sorry, this entry is only available in Русский.
Adaptive Case Management was one of the most discussed BPM topics in 2010. It transformed from fuzzy marketing noise into a more or less consistent concept over the past year.
Why “more or less”? Because even the authors of “Mastering the Unpredictable” - probably the most authoritative book on ACM to date - say in the preface that there is no consensus among them, so the book in essence is a collection of articles. Nevertheless there are more similarities than differences in their positions, hence the consistent concept.
Positive Side of ACM
ACM extends the idea of process management into areas that were tough so far: processes a) rapidly changing and b) essentially unpredictable.
Re-engineering once emerged as the idea of managing business via processes that were perceived as once yet very carefully planned procedured. Life has shown the limited applicability of this concept. It turned out that end-to-end and cross-functional business processes - that is, processes presenting the greatest value in terms of bottomline figures - are a) too complicated to program them in one iteration, and b) changing more rapidly than we are able to analyze them by traditional methods.
As soon as these concerns where perceived BPM appeared in its current form - as a discipline that combines managing business by processes and managing processes themselves i.e. their execution, analysis and optimization within continuous loop. Executable process diagrams improved communications between business and IT opening the way to deal with complex processes; rapid prototyping via BPMS and agile project implementation allowed rapid business processes changes.
Exactly how rapid? We have reached a three-week cycle in our projects which I believe is a good result taking into account the inevitable bureaucracy of release management, testing and production system upgrade control.
But what if this is not enough - if changes to the process should be introduced even faster? Or more likely if a process is so compicated that we repeatedly find that some transition or activity is missing in the diagram?
And here is the final argument in favor of ACM: what if the process is fundamentally unpredictable? Examples: a court case, the history of a medical treatment or technical support dealing with user’s issue. You can’t plan activities here because tomorrow will bring new actions taken by the opposing party at trial or patient’s new test results. It’s even hard to call it a process because process implies repetition, yet no two instances of these “processes” are identical.
These are standard ACM examples. I would also add the no man’s zone between processes and projects e.g. construction work. In a sense, construction of a house is a process because it consists of simiar activities. But at the same time, no construction work goes without troubles and complications which make each object a unique project.
Or let’s consider a marketing event: there is a template indeed but each particular event is peculiar. Same for new product development… there are many such half-projects/half-processes in every company.
What Shall We Do With Unpredictable Processes
If you can’t foresee then act according to the situation. We must give user the ability to plan further actions for himself, his colleagues and subordinates “on the fly”, as the case unfolds.
Luckily the user in such processes is not an ordinary homo sapience but so called knowledge worker. A doctor (recalling House M.D.), support engineer or construction manager - any of them could write on a business card:
These are people trained to solve problems and paid for this job.
How the problem of volatile and unpredictable processes was approached so far:
1. By editing process scheme by business users on the fly.
For example Fujitsu Interstage BPM lets authorized users edit the schema of a particular process instance right in a browser. And even more: the modified scheme can be later converted into a new version of the process template. But it turned out to be too complicated - users simply don’t use this functionalty. Keith Swenson says on the matter: “Creating an activity at runtime needs to be as easy as sending email message; otherwise, the knowledge worker will send email instead.”
2. By ignoring the problem: there is software automating case work but it doesn’t operate in terms of processes.
For example you can create a folder in the ECM for each case and upload documents, attach tasks and notes. Or you can treat a case as a project and draw a Gantt chart. But both options won’t give process monitoring and analysis and most importantly - the knowledge of what tasks a particular type of cases consists of will not be accumulated and reused.
ACM inherits BPMS approach to process execution, monitoring and analysis but replaces “hard” templates with “soft”: ACM template doesn’t dictate what should be done but rather prompts what the user could do in current situation. The user may reject these clues and pave his own way. He may use more than one template or instantiate a case from scratch and not use any template.
Graphical process diagram is thrown away and replaced by a tasks list (tasks may be nested). Apart from the tasks list a template defines the data structure: entities, attributes, relationships.
There is no more business analysts and business users: it’s assumed that users create templates themselves and organize them into a library, thus making available to others.
So far so good but I have some concerns about this proposal.
Concern 1: Technology Instead of Methodology?
ACM advocates (or maybe only the most radical only) seem to believe that more advanced technology is all what organizations need to become more efficient: BPMS is outdated but ACM is the solution.
I don’t know… maybe I’m too unlucky but the business people that I meet are indifferent to technology, at best. Techies are speaking about how a new technology works but business people are only interested in what they will get. Productivity increase and processes transparency sound good but how will they affect the bottomline figures?
The bottomline result of a BPM initiative depends on two things: 1) quality of proposed solutions - how efficient is it in managing and optimizing processes and 2) what process was selected for the initiative. Typically, an organization has a small number of processes or just one process which is a bottleneck. Improvements in this process directly affect the company totals while any other improvements affect them at a minimal degree.
If your BPM consultant is professional enough then the first component is secured. But the problem is that the second component of success is beyond his responsibility.
And as a matter of fact, it’s beyond anyone’s responsibility. Business consultants generally know what to do (which processes to deal with) but they have little knowledge of the process technology. BPM consultants, by contrast, know how to do, but don’t have a clear vision of what to do. No system (BPM system is no exception) can establish the goals for itself - it can only be done at super-system level.
After recognizing that there is a competence gap some time ago, we developed the value chain analysis and productivity gap identefication methods to be applied before the BPM project starts. The project takes about a month and results in clear vision of where the BPM initiative should be targeted for best results and what these results shall be.
Getting back to the ACM: it seems that it discards process methodology along with process diagrams. Process analysis skills and process professionals are not needed any more because knowledge workers are so knowledgeable that they know how to do the job better than anyone else.
Maybe they do but let me ask: better for whom - for the company or for themselves?
I am afraid that orientation to the customer doesn’t come automatically. I’m afraid that knowledge workers as well as clerks engaged in routine work tend to create comfort zone for themselves rather than clients. I believe there is still much to be done in process methodology and promising new ideas - e.g. the Outside-In approach - have yet to become common practice.
ACM proponents criticize the “process bureaucracy” - business processes change approvals and other regulations. Bureaucracy is certainly bad… but it’s even worse without it. I don’t believe in empowerment as much as ACM people do and I don’t trust that knowledge workers will self-organize and the library of case templates and business rules will emerge magically. In my opinion, this is utopia. There must be strong leadership and process professionals trained to analyze company’s activities in terms of benefit to the customer, quality and cost.
In his last interview to Gartner analysts process guru Gary Rammler criticized BPM for the lack of business context:
“I think there is only one critical condition for success that must exist - and that is the existence of a critical business issue (CBI) in the client organization. If there is no CBI (hard to believe) or management is in deep denial as to the existence of one, then serious, transforming BPM is not going to happen. Period. There may be misleading “demonstrations” and “concept tests,” but nothing of substance will happen. How can it? Serious BPM costs money, takes time, and can upset a lot of apple carts, and you can’t do that without an equally serious business case. I guess you could argue that a second condition - or factor - is that the internal BPM practitioner is about 70% a smart business person and 30% a BPM expert. Because the key to their success is going to be finding the critical business issue, understanding how BPM can address it, and then convincing top management to make the investment. I guess those are the two conditions: an opportunity and somebody capable of exploiting that opportunity.”
I’m afraid that neglect of a process methodology in ACM will result in ignoring this promising technology by business.
Concern 2: No Programmers?
ACM assumes that not only business analysts are not needed but programmers as well.
Sure it would be great. BPMS vendors try to reduce the need of programmers in business process implementation, too.
Reducing is OK, but eliminating them completely?
Simply replacing the process diagram with the task list probably isn’t enough because there still are:
1. Process architecture.
When dealing with process problem the most difficult is to figure out how much processes are there and how do they interact with each other - for an example, please refer to my “Star Wars” diagram. If you did that then the remaining job - internal process orchestration - is no difficulty. If not then whatever you do with rectangles and diamonds within the process, it won’t work well.
Cases are no exception - one have to set up the architecture first. And I don’t believe that a business user without analytical mindset and not trained in solving such problems will do the job. And without that, there will be chaos instead of case management system.
2. Data architecture.
ACM advocates stress the critical importance of data constituing the case context. Arguably, for BPMS process is primary interest and data is secondary while for ACM it’s vice versa.
I do not agree with this - in my view, the process is a combination of the model visualized in a diagram, structured data (process table in the database) and unstructured documents (process folder in ECM) where all parts are equally important.
But anyway - they recommend first and foremost to determine the nomenclature and structure of the entities in your problem. Excuse me for asking, but who will do the job - a business user?
Once again: I don’t buy it! Data structures analysis and design has been and remains a task for trained professionals. Assign it to an amateur and you’ll get data bazaar instead of data base, for sure. Something like what they create with Excel.
3. Integration with enterprise systems.
Well, everyone seem to agree that this will require professionals.
So where did we come? To bureaucracy once again, this time the IT bureaucracy. It’s evil but inevitable eveil because the chaos is worse.
Concern 3: Two Process System?
Here is the question - how many process management systems do we need (assuming that cases are processes, too): two (BPMS and ACM) or one? And if one, how shall it be developed: by adding ACM functionality into BPMS or by solving all range of process problems with the ACM?
ACM proponents (well, at least some of them) position it as a separate system - they want to differentiate ACM from BPMS technology.
They argue that BPMS tries to “program” business but this is impossible in principle when dealing with unpredictable processes. Therefore BPMS is no good and we need a different system - ACM.
It reminds me something… got it: a new TV set commercial! “Just look at these bright colors and vivid images! Did you ever see something like this on your old TV?” - Of course I didn’t… But wait! Am I watching your commercial and see these bright colors and vivid images right on my old TV set?
Same here: of course, unpredictable processes can’t be programmed by a stupid linear workflow. ACM proposes more advanced way to program them, but still it’s programming. And who said that BPMS can execute only stupid linear worflows?
BPM allows to model much, much more than linear workflows. Citing Scott Francis -
“The BPM platforms that I’ve worked with are Turing Complete. Meaning, within the context of the BPM platform, I can “program” anything another software program can do.”
For example, one can model a state machine in BPMN which is presumably the most adequate representation of a case. Besides there are ad-hoc sub-processes that allow a user to choose which tasks to schedule for a particular process instance. The combination of a state machine and ad-hoc sub-processes serving transitions between the states produces something quite similar to the case.
Apart from that, stay away from micromanagement or unpredictability will hunt you everywhere.
Existing BPMS lack the ability to add a new task to the ad-hoc subprocess by one click (remember: it shouldn’t be more difficult than sending e-mail). But it seems to be fairly easy to implement. Not harder than BPMN transactions compensation, anyway.
And there is also “delegation” and “notes” functionality in the BPMS which help making a process less rigid, too.
Some ACM supporters believe that existing BPMS with their process diagrams are outdated - arguably, if ACM can manage unpredictable process then it’ll be able to cope with traditional processes for sure. But the majority seems to recognize that both management of traditional and unpredictable processes are vital.
Besides, there are processes that can be partially modelled but some other parts should be managed as cases. For example, a medical treatment is a typical case but specific test is a process that can be well-defined. This is the argument for a single system able to manage traditional predictable processes, cases and arbitrary combinations of both. And chances are that this system will be developed on the basis of existing BPMS.
Such ACM-enabled BPMS would provide some additional bonuses not mentioned above:
Bonus 1: BPM During All Stages of the Organization Lifecycle
Applicability of BPM is limited today even in regard to predictable processes: small companies simply can’t afford a business analyst and consequently BPM. This mines a future problem: with the company growth the process problems will pile up until falling down one day.
ACM-enabled BPMS would be a great solution to the problem: a small company or startup may work with cases only initially and then, as it grows, the organization structure develops and more clerks coming, a company will be able to transform seamlessly the patterns accumulated in cases into formally determined process diagram, optionally preserving the desired amount of unpredictability.
For the BPMS vendors it’s an opportunity to enter the market of small and medium-sized companies by offering a product falling into office automation category, not a heavy-weight enterprise platform as today. Support of cloud computing would additionally contributed to the success indeed.
Bonus 2: Artificial Intelligence
I do not trust that business users are willing and able to organize a library of template cases. I believe it’ll end with something similar to a bunch of Excel files. How many people are using templates in Microsoft Word, by the way? It’s a nice and usefull thing yet nobody cares.
More promising for me is the idea of implementing elements of artificial intelligence in ACM:
- To start small, a simple advisor can be implemented like the one at online bookstores saying “people buying this book also bought…”.
- More sophisticated implementation may take case data into account. For example a tech support case may suggest one tasks set or another depending on the service level of the current customer.
In essence, the system treats the whole set of case instances of a certain type as a mega-template.
Automatic analysis of the mega-template can be supplemented with manual ratings so that the user would receive not just a plain list of tasks that were performed at the similar situation but the list marked with icons saying e.g. which tasks are recommended.
Conclusion: Thank you!
ACM enthusiasts are doing the great job: they investigate the possibility of expanding the process management into previously inaccessible areas. Sincere thans for this!
Marketing considerations force them to differentiate from “close relatives” BPMS and ECM and to position ACM as an independent class of software. It seems to me that this is irrational both from technology and methodology perspective and it’s unlikely to succeed.
There was a similar story in IT history. Once relational databases have become mainstream a number of works appeared, calling further: post-relational database, semantic databases, non-first-normal-form databases, XML databases… They contained generally fair criticisms of certain aspects of relational database technology. But relational databases proved to have solid potential for evolution: missing functionalities were implemented one way or another, thereby putting alternatives into niche areas.
So here is my prediction for ACM: it won’t become a new paradigm but a new BPM feature that will expands its applicability significantly.
Cross-functional is a process involving several upper-level departments (or “functions”). From a process methodology perspective a BPM initiative should ultimately aim on such processes because handoffs between departments is usually the biggest source of problems and hence the greatest potential for improvement. Departmens use to rate their internal targets above the targets of the business as a whole as soon as hierarchical organizations reach certain size limit.
This idea ain’t new: “breaking down the walls between departments” is the re-engineering call of the early 90’s. An implementation proposed at that time - single radical transformation - wasn’t quite successful but it’s another story. Modern BPM got new ideas about how to reach it but the goal remains the same.
The «functional silo» metaphor is commonly used to illustrate the cross-functional problems. The analogy is following: after a hay silo is mounted one can only get a small portion of that wealth - the upper layer. Likewise, resources, information, knowledge and procedures in hierarchical companies are buried in the functional units - much of these asstes are not available to consumers from other areas and does not contribute effectively to the goals of the company as a whole.
A functional unit tends to come to the wrong view of what is “our business” and what’s not. For example it’s natural for accounting/finance to assume that accounting and reporting is their main business while invoicing is really someone else’s (e.g. sales) and for accounting core activities it’s a nuisance. Yet from a business standpoint the opposite is true: billing is part of the “Order to Cash” business process, most important in terms of value for the customer while accounting and reporting are auxiliary activities. We can’t avoid it because of the governement requirements and our own planning needs yet it does not create value and hence its cost should be minimized.
Accounting is just one example. New product development, building a commercial proposal, customer order fulfillment - there are lot of things critical to the client and hence for the business that can’t be assigned to a single business unit.
Cross-functional business processes are usually illustrated like this:
Fig. 1. Functions and cross-functional processes.
However the picture above produces a badly wrong idea of how to resolve issues located at the borders between departments. It leads to a vulgar idea of the business process as a simple sequence of steps: “do this - do that - proceed further - then stop.” Businesses does not work this way.
Let’s consider the “Order to Cash” process as an example. In case of production to order it’d contain the following steps: accept order - produce - deliver - obtain payment.
- Process begins when sales department receives a customer order.
- After processing the order sales transfers it to production.
- Production starts to fulfill the order.
- Manufactured goods are delivered to the customer.
- Finance department obtains the payment.
Fig. 2. «Order to Cash» cross-functional process, workflow version.
Imagine a manufacturing workshop being empty, dark and silent. Now the client’s order comes, the workshop manager switches the power on and everything starts running. Nosense? Sure. But the naive diagram above implies just this!
Now how it really works:
- Sales places customer’s order into production queue.
- Production planning starts periodically (e.g. daily), scans the orders queue and schedules production.
- Orders are processed one by one in accordance with the schedule and after each order is fulfilled the corresponding client order process is notified that the goods are ready for delivery.
Fig. 3. «Order to Cash» cross-functional process, BPM version.
We’ve got two processes here communicating via data (the orders database) and messages (order execution notice). It’s fundamentally impossible to implement it within a single pool (single process) because the “Purchase Order” and “Production” have different triggers: receipt of an order from a client and timer, respectively.
Same story with delivery and payment: they can hardly be implemented within “Purchase Order” pool. So technically there would be even more than two processes (pools).
Workflow, BPM, and multithreaded programming
As the example above shows, cross-functional processes can’t be implemented with a simple workflow: the boundaries between busines units can’t be ignored because they different units operate at different rhythms and utilize different routines. These boundaries can’t be eliminated simply by depicting the flow of work from one unit to another as shown in Fig. 2.
Technically, the cross-functional processes are implemented by inter-process patterns one of which is shown in Fig. 3. Getting back to the methodology, the picture shown in Fig. 1 should be drawn like this:
Fig. 4. Cross-functional process as a coordinator of functions.
The workflow only covers work within a single function. Once we go beyond it i.e once we aim at cross-functional processes and deal with handoffs between units, the interaction between workflows must be utilized.
Switching from workflow to inter-process communication means switching from single-threaded to multi-threaded programming.
Unfortunately in many cases it’s a tough barrier.
- Some people doesn’t see this barrier. They hit it but doesn’t realize what’s the problem really.
- Others instinctively bypass the barrier by implementing BPM pilot projects aiming at processes like “Vacation Request”. A pilot like this is going to be successful but does it have any value for business?
I believe this is the sources of most of the disappointment in BPM: those who narrow it down to the workflow end up with predictable failure.
Technically, multithreading is what distinguishes BPM from workflow. Remove the interaction between asynchronously executable processes via data, messages and signals and what you’ll get would be “workflow on steroids”, not BPM.
Unfortunately, this is the case with many software products marketed aggressively as BPMS. For me, the main BPMS criterion is the support of BPMN-style messages. There are other criteria indeed but this is the most useful at the moment. Everything else - graphical modeling, workflow engine, web portal, monitoring - is implemented ususally, better or worse, but many products totally miss inter-process communication. Most likely not because it’s that difficult but rather because no one has explained how important it is.
Yet saing “get used to the multithreaded programming of processes” is easier than following the advice. Complains about BPMN complexity are common: “who invented these damned 50 different BPMN events!”.
The name of complexity is business, not BPMN!
Whoever promises a simple solution to business issues, whether it’s BPM or something else - do not believe it. Business is a human competition by nature: smart people are competing for living better than others. Therefore business has been and will remain a complex matter.
The complexity of BPMN isn’t excessive, it’s adequate to the complexity of the business. Students of my BPMN training have no question about why there are so many events: no one is excessive. And by the way, note that BPMN 2.0 is practically no different from 1.x at workflow part - the standard evolves in supporting more sophisticated multithreaded programming: choreography, conversation.
The business can only be programmed as a multithreaded system.
BPM and the ACM
Here I deliberately step on the slippery ground because ACM (Advanced/Adaptive Case Management) fans may respond: “A-ha! We have always said that business can not be programmed!”
Maybe it can, maybe cannot … most likely, in some cases it’s possible but not in others.
They say the percentage of knowledge work vs. routine work is constantly growing. But exactly where is it growing? Mostly at US companies that offshore routine activities to Asia. A predictable observation for analysts located in US. But as soon as the amount of knowledge work grows at one place, the amount of routine work grows in another. And managing routine procedures running on the other side of the globe is the best task for BPM that one can imagine.
I would like to ask ACM enthuziasts that cricize BPM: are you sure you’re criticizing BPM and not wokflow? Aren’t the object of your criticism BPM projects either trying to solve business problems with workflow or having no business agenda at all?
If this is the case then the failure is quite predictable but it doesn’t mean that BPM points the wrong way, it just means the need to more thorough work.
ACM is a good thing indeed but only as an extension to BPM, not as a replacement. Besides ACM today is less mature than the BPM so those who make mistakes with BPM are likely to make even worse mistakes with ACM.
To be continued…
…with the major patterns of interprocess communication and a word of warining about the opposite extreme - excessive usage of interprocess communications. Stay tuned.
BPM conquers the new territory which is called in different ways: Dynamic Processes, Unstructured Processes, Knowledge Worker Processes, Barely Repeatable Processes, Case Management.
BPM now reached the maturity level where the management of repetitive and predictable processes has become a matter of technique. It grants reliable process execution by unreliable employees - low-paid, with low skills and low motivation. Such processes are common for state and semi-state organizations and also for businesses following an extensive path of development.
But only “very talented” individuals can believe that every process can be rigidly structured:
Leaving aside the extremes - fully structured and completely ad-hoc processes - there are two combinations: either a structured process launches the ad-hoc or vice versa.
- “A Little Help From a Friend” pattern: a structured process launches ad-hoc subprocess. An example: system integrator’s “request-to-order” process. Let’s assume that sales rep’s meeting with a client was positive meaning that he found ”pain points” - issues that the client will pay for if they were resolved by the integrator. The next step of the process is finding a solution. However, the client’s problems may vary at very wide range (note that integrator’s value is exactly his ability to solve a wide range of problems) starting from the simplest need of a boxed software to complex projects. In the latter case the process will follow a trajectory unknown in advance that may involve an architect, developer, sales manager, systems engineer, vendor’s tech support etc. Traditional BPMS can only represent this unpredictable subprocess as a single task (see “Process Antipattern: One Man Show“). This is a poor-man’s solution indeed because it isn’t visible who is addressing the issue at the moment, what progress has been made and what the current timeframe is.
- The opposite situation, the “Process Toolset” pattern: unpredictable process at the top launching well-formalized subprocesses. An example: a law firm having client’s case as the top-level process. It’s absolutely impossible to predict in what direction the case will turn next day, e.g. a new document may be submitted by the opposite party that will change radically both the case prospects and our plan for actions. Yet many of the actions initiated within the case are standard, making it possible to formalize each as a subprocess. They are mostly preparing applications or other documents for the court. Such subprocesses is executed by a dedicated specialist - a common resource not assigned to a specific case. From business perspective it’s interesting to monitor performance not only of the case as a whole but also of subprocesses and resources usage.
Going down from the top-level business processes (company’s value chain) to the lowest level (micromanagement) we must be prepared to encounter both structured and ad-hoc process. Support for the latter in today’s BPMS is far behind but this subject is widely discussed by researchers, analysts and vendors:
- The following estimate was made at Gartner’2009 conference: as much as 60% of an organization’s processes are unstructured – and probably also unmonitored, unmanaged, unknown and unruly. These 60% are like “average temperature by the clinic” but the “invisibility” of these processes can indeed be the major issue from business standpoint.
- “Tapping into Collective Knowledge Will Drive Unstructured Process Activity” - Jim Sinur predicts that organizations acceptance of collective knowledge, industry networks and even social networks will result in fundamental changes in BPM. His another post on the same subject: “White-collar and unstructured processes go together like cheese to wine“.
- The boom of social networks pushes the idea to borrow approaches evolved there for communication within dynamic processes - see the Workshop on BPM and social software at BPM conference in Ulm. For example, when confronted with a problem, I can publish the question on the corporate social network (”a help from a friend”). It’s visible to my “friends” including the project manager and team lead. The best answer gets a bonus.
- SAP shows how Google Wave collaboration technology can be used - not for process execution but for modeling. SAP Gravity is a BPMN modeler implemented within Google Wave. Taking into account that the ability to redesign a process on the fly is essential for dynamic process execution, SAP makes progress not only in process modeling and discovery but in the the execution too.
- Oracle talked about collaborative and dynamic BPM at Oracle OpenWorld’2009. They emphasized commitment to SCA that makes possible to combine different kinds of processes with business rules, analytics, etc. That’s no surprise taking into account that they have acquired about 50 companies in two years and hence face huge integration challanges.
- HandySoft, ActionBase and other vendors claim dynamic processes support in the latest versions of their products.
- The most authoritative industry experts gather to discuss dynamic processes in general and their support in BPMN.
So we can see a number of minds attacking the problem from different directions. Well the more alternative approaches, the better final solution should be.
Yet for BPMS vendors that may be a bloody battle. There is probably more BPM vendors than the market needs and now a new front opens for the competition: dynamic processes. It’s quite wide front if all aspects of dynamics are taken into account so I’m afraid not all vendors will be able to fight it in the current economic situation. But at the end of the day those who provided full support to dynamic processes will posess a competitive advantage clearly visible for the users.