-
1. Re: Process Inference
Hi Julio!
Comments inline
Julio Faerman wrote:
Hello colleagues,
When i am working in BPM projects, it is very common to have some or all of this problems:
- The organization does not know the [whole] process
What do you mean by does not know the whole process? They can start with simple models and improve them over the time
- The organization knows the process, but does not know how to model, deploy or maintain it
The IT Deparment + The Business Analyst will need to coordinate the whole process lifecycle maintaince
- The organization knows how to model, but the process is too complex, full of special cases and exceptions
That's why Drools and jBPM are together. You can model simple process and let the Rules deal with exceptions
- The organization is improving the process faster than software can keep up
The idea of having processes and rules is to provide a declarative way to improve the software to be up to date to the business requirements.
And other related issues i think you may also have found. Then i wonder...
What if we modeled the software so that the process engine could relate the system state and events to user actions?
This could be possible, but your description is too generic to even think in a particular case.
Given some time, the process could be infered from this data and the engine automatically take the actions it has enough confidence (possibly undoable) or ask the user otherwise.
Now this sounds to probabilistic stuff.. you can do the same with rules and fuzzy logic, but once again, you will probably need to be focused to a particular case. At that point you will need to measure if creating complex rules and mechanisms to auto update your system is more efficient that let the users change the rules and processes by themselves.
Would this be any good in your organization, or is it just another bad idea?
Cheers
-
2. Re: Process Inference
The case am thinking is document flow.
Take a organization with *many* kinds of documents, each of which with its own rules, processes, data and actors (humans and systems, internal and external).
This would a good case for inference, as the ammount of actions upon documents is quite restricted (forward / delegate, return, copy, archive, enrich, ...), and the modeling of all processes is quite hard.
Note that the modeling and inference can actually be complementary and yes, that would require some machine learning and the probabilistc stuff
BTW, sorry to polute as this is not jbpm-specific, just thought it would be a good place to assess the idea.
-
3. Re: Process Inference
Julio, right now we don't have any machine learning algorithm associated with the Process engine, but the whole idea is more than interesting. If you are going to spend time reasearching about this, I suggest you that try to contrast the learning process with the process of business users writing rules. As you mention, the company may have tons of documents, but there are always experts that can define how each of those documents are handled. If you have access to those experts and teach them how to write rules, the system doesn't need to learn anything. But in any way I'm descarting the machine learning stuff, I've always wanted to contribute with something like that, but I never had time to reasearch in that direction.
Cheers
-
4. Re: Process Inference
Thanks for your input Mauricio!
I am not inquiring about jbpm, just wondering if this idea of process inference in the engine would be "good to have" (for others beside me) or if it would be just "waste of time".
-
5. Re: Process Inference
I think there are different approaches to solving your problem. Note that some of these are still experimental and might not solve exactly what you're looking for, but they might at least do something in the same area.
The best researched one is probably "process mining". This is the idea of deriving a process from various information sources, typically some form of logs that describe real-life cases (history logs), so those cases can be used to automatically create a process based on that, which can then be used for future execution. The downside is that the generated process itself typically isn't that flexible (so it might be difficult to deviate).
Ad-hoc processes allow you to specify "recommendations" when executing (a part of) a process, and the user can then select which recommendations to execute, possibly add new tasks that are not part of the process yet, etc. This typically works well with then using this information (deviations and selected recommendation) to improve the process based on this info.
Incomplete processes are processes that don't contain all the logic yet, but where parts are left unspecified, and only at runtime will be decided what to execute.
Pure Adaptive Case Management (ACM) tries to tackle cases where there is no process upfront, people can just create cases and execute these. It is my opinion that these are not a different kind of processes however, but that these are just one extreme of processes and that your suggestion is probably something in between. The main idea is that a user has full flexibility here, and doesn't need a (full) business process to do his work, but that for example recommendations might be generated based on the current state of the case.
We always try to work towards supporting some of these more advanced cases in jBPM already. For example, we do support ad-hoc (sub-)processes and by offering users the ability to combine processes with rules and event processing, at almost every level, we believe these paradigms combined can also allow you to define a lot more flexible yet smart processes. Integrating for example a neural network to support the reasoning would be more experimental, we haven't considered this yet at this on its own probably is a big, specialized research area. But if anyone is willing to give it a try, let us know, and we'll try to help out where we can !
Kris
-
6. Re: Process Inference
Thanks *a lot* Kris, looking into the things you mentioned and learning a great deal from it.