I’ve been working today on a workflow system. Really, it’s just a simple test-client for my operational support service, but the perspective is a bit more interesting than that. As a workflow system, it provides as much freedom to the user as possible, to the point of even be able to execute “Read Facebook” for any process. That’s the scientific root of the name.
Let’s dive right in:
To the left is task management, in the middle is a log showing internals, and to the right is integrated operational support.
In the left field, we have two task lists, one comprising recommended tasks in order of preference and one listing tasks that are not recommended ordered alphabetically. Above the list of recommended tasks, we find two fields; one allows us to enter a new activity name and execute with no further ado. It will then be added to the task lists subsequently. We also have a field for changing the date (it is automatically kept up-to-date, but it is possible to log tasks in the past (for catching up) or ion the future (for testing). At the bottom, we have a button to close the current case.
In the center we just see the standard log in ProM. It shows whenever anything happens to the underlying workflow system.
To the right we see the integrated operational support client. At the top, we get to decide which provider we wish to use. We currently have the choice between the Drunken Monkey, which picks tasks at random and pretends to know stuff, and the Log XQuery Provider, which is slow but provides good recommendations for common cases. We currently see recommendations from the latter. The big empty area is intended to provide more details about the prediction leading to recommending the task at the top in the left side of the screen. Currently, it only shows the predicted value. At the bottom of the right field, we can enter our query. This is done similarly to in Declare, where we have pre-defined queries and can enter custom queries as well.
The main limitation right now is that we only mark when we complete tasks and not when we start them, nulling the requirement for a todo. Also, we do not have access to multiple concurrently running instances of this and perhaps also other processes. It is just a prototype with a quite specific goal, after all.
The data is from a real-life but small log. All events have code names due to some reason I was told but promptly forgot. We see that we optimize for shortest execution time, and are recommended to execute 01_HOOFD_010. According to the log, over 98% of the cases did that, so the recommender is not completely off.
I naturally know better than some retarded algorithm suggesting the same as what happened in 98% of the cases in real life, so I execute 01_HOOFD_065_2, and get this:
We get new recommendations and the log is updated. It is all very exciting. Being the adorable renegade, I decide to ignore any advise about doing things with moon-spoeak codes, and instead enter Facebook in the top-left field and hammer the Execute button. I get:
The Log XQuery Provider now gives up and we are left only with suggestions from the drunk monkey, but the task is executed, logged and added to the list of available tasks, as seen here:
This is all quite standard (except perhaps for the recommendations and the ability to enter completely random things). What is less standard is that this was all set up without a single formal model describing the underlying process. All was computed solely based on a log: the available tasks were found by traversing a historical log and the recommendations were given based on the log as well (as might be possible to guess given the Log XQuery Provider name). Here is the setup of the workflow system in ProM:
The idea is that in the future, the recommender will start learning from executions, adding new traces to the body of data used for recommendations. This means we can even start without as much as a log, which the I’d Rather Read Facebook Workflow System also supports:
Another next step is to mine real models instead of using just logs for recommendation. That way it should be possible to provide advice even for less common cases for which an exact match does not exist.
