[Design of JBoss jBPM] - Re: Analytical and operational dashboards
by tom.baeyens＠jboss.com
Another approach to KPI could be identify a special set of variables. Suppose that an Order process has an order variables which is a hibernate Order entity. Then in that entity, there is a field retributionCost. Then in the process, we could copy that field into a KPI variable field at indicated places in the process.
The benefit is that our console then has a generic way to diplay and work with key performance indicators.
Another type of KPI is time measurements. E.g: How much time is there between the quote approval and the closing of the deal. Therefor we need to be able to store the start en end times of the process execution at specific places indicated by the process developer in the process definition. Also super-states could serve for this purpose.
Another variation would be to put probes on transitions. One probe could initialize a KPI variable to true and multiple other probes could turn it off. Then you can count for all the process executions that past the first probe, how many of them did not pass a second probe. This might be used to get statistical data on the % that each transition out of a decision is taken.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185293#4185293
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185293
15 years, 6 months
[Design of JBoss jBPM] - Re: Analytical and operational dashboards
by heiko.braun＠jboss.com
anonymous wrote :
| Are there any plans to support business indicators (KPIs)?
|
If they get too domain specific, no. At least not in the beginning. A good dashboard is always customized to the users needs. I am talking about is information the can be derived from default BPM terms, because we are not offering a lot of customization in the beginning. Don't underestimate it though. People have the capabilities to read "between the lines". What you described with order example, can be derived from non domain specific figures as well. IMO "outstanding orders" can be as well expressed as a particular derivation or exception in the process execution without being to much tight to that particular domain.
The goal should be that people with specific knowledge are able to "recognize" patterns that put them in alert state or at least raise their interest.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185240#4185240
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185240
15 years, 6 months
[Design of JBoss jBPM] - Re: Analytical and operational dashboards
by kukeltje
A low level API is indeed not interesting enough certainly not in relation to the amount of work it will take. What (imo) is interesting though is getting access to outcome of the queries and to the images. The company I work(ed) for want's to show this data in the webapp of the specific application for several reasons:
- marketing wise (look and feel)
- authorization wise (often already implemented in that app, implementing it also in the/a/one of the consoles is double (or more) work
- functionality wise (they can decide what to show, what not etc.) Give labels a name etc (see also response below)
anonymous wrote :
| Are there any plans to support business indicators (KPIs)? Because people usually don't really reason about "the number of process instances", more about "outstanding orders",
|
Since this is very process specific, (labels), information from processdefinitions (process name, task name etc.) can (should?) be used to overcome this.
>From my (not very broad, but still) experience, the time to complete an order (one specific I assume you mean here) is only partly interesting. It is combinations of data that tells a manager how to act.
Some small examples:
- number of open orders goes up, average of the duration of handling an (from the moment is is really being acted upon) stays the same, then the conclusion is that there are more orders coming in then can be handled. 'Downdrilling' is not needed
- If the number of open goes up, but the average also goes up and the average of a processdef. (including stdv) also goes up, then there most likely is a bottleneck in an external actor (system or human) being used. Downdrilling to the individual times of nodes is interesting then to see which task/node/... is causing the problem and downdrilling to get detailed info of e.g. this tasknode can be needed, e.g. is on human always slower than others, is a generic system always slow, or is it related to data!. The latter may sound strange, but we've had an issue where a fraud system required a licenseplate number to be passed to it where the customers told us they did not want a check on validity (e.g. is the combination of characters a probably existing one). So many users used '000000' for that in specific circumstances that the system became slow when searching for possible fraudulent actions with this license plate number).
To me, these are 'fairly simple' to implement when using e.g. Pentaho and these are operational. Thresholds are needed to be able to have a clean/empty dashboard when everything is within configured thresholds. The tresholds themselves can come from analytical data
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185054#4185054
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185054
15 years, 6 months
