[tom.baeyens]

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.

[camunda]

Open Orders: 20
But just
<processdefinition name>: 20

Add support for super-states (<processdefinition / super state name>) and I think you can satisfy a lot of the requirements already with the generic solution...

To what Tom said: Yes, very good ideas! I think these are the right directions!

Something somehow similar I had in mind with the simulation, see http://www.camunda.com/jbpm_simulation/jbpm_simulation_language_draft.html:

<scenario name = "slow invoice payment">
...
<business-figure name = "missed discount"
type = "costs"
automatic-calculation = "none|process-start|process-end"
handler = "org.jbpm.sim.tutorial.TutorialBusinessFigureCalculator " />
<business-figure name = "missed discount"
type = "costs"
automatic-calculation = "none|process-start|process-end"
expression = "#{order.discountForFastPayment}" />
...
</ scenario >

Basically this would be a cool improvement and the same logic could/should be used in BAM/BPR (BP-Reporting) as in BPS (BP-Simulation).

I don't remember exactly if I had implemented the "Business figures" already or if it was just a sketched idea, I think it was the latter ;-) But I can have a look at this later...

Greeting from the jBPM training in Stuttgart
Bernd

[tom.baeyens]

Let's get jBPM 4.0.0 out asap so that we can actually start working on those nice ideas :-)

[camunda]

+1!

[kukeltje]

@Tom,

Your first example might pull in to many domain data into the processvariables. The same is partly true for the 'missed discount' in Bernds' example. You should not have to take this into account while running/executing the process. The BI software (Sorry Heiko ;-)) should be able to (and e.g. Pentaho is to get that data from multiple datasources. Missed discount can vary per customer, heck even per 'special order', and in some cases there even might be penalties etc... Leave that data where it belongs... in the domain model.

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.

This is almost exactely how SeeWhy uses it. Personally I do like it, but do not like to have to model those things in. Makes it look ugly (at least in the source) and if I forgot something, I do not have the data afterwards. BEA (in to of their former BPM 'solutions') had a cooperation with a company that just knew the domain model of the engine and every x seconds did a select from the database, read the new log records since the last time (know from that specific record) and updated the metrics. Somehow, that just feels better

To bad I never had the time to try out Pentaho (tried SeeWhy) to get a detailed impression.

@Bernd,
Including those figures in the simulation is nice for generic analysis but did you also use these with slowing down e.g. one of the actors in a pool that should act on a node?

[kukeltje]

Personally I do like it,

above was about the product generically and not how it has to be used

[tom.baeyens]

"kukeltje" wrote:
The BI software (Sorry Heiko ;-)) should be able to (and e.g. Pentaho is to get that data from multiple datasources. Missed discount can vary per customer, heck even per 'special order', and in some cases there even might be penalties etc... Leave that data where it belongs... in the domain model.

yes, you are right. the special variable was not a good idea. instead the same principle of associating generic KPI values should be added to the jBPM BI database.

"kukeltje" wrote:
Personally I do like it, but do not like to have to model those things in. Makes it look ugly. BEA ... every x seconds did a select from the database, ... and updated the metrics. Somehow, that just feels better

the logs that are generated by default will already enable a log of PKI metrics without modelling them explicitely in the process. But for some, you need to generate extra data. Or e.g. extract the right information from the users domain model in order to get the KPI's into a generic scheme and display them without coding a custom query that spans over jBPM and user tables.

[camunda]

I think jBPM BI should be a mixture:

- Some "probe" mechanism like Tom mentioned on transitions as somehow implemented by SeeWhy (but maybe less verbose for Ronald ;-))

- Some BestPratcises / Basic working examples for PEntaho integrations, especially a basic cube layout and an Kettle ETL process for the jBPM log data

- Some BPR reports for existing log data for generic performance indicators (process runtimes, task instance wait and run times, ...). This is what I think Heiko is working on at the moment, right?

- Some KPI descriptions like I mentioned earlier. Even if this may be a lot of domain data information, I think if the process processes this domain data anyway, it is not such a bad idea to calculate KPI's already out of that and send better business events to BAM (like SeeWhy does).

[kukeltje]

Or e.g. extract the right information from the users domain model in order to get the KPI's into a generic scheme and display them without coding a custom query that spans over jBPM and user tables.

How would you like to extract them without coding a custom query? Providing a java/webservice api in your application to retrieve the data? P

"camunda" wrote:

- Some "probe" mechanism like Tom mentioned on transitions as somehow implemented by SeeWhy (but maybe less verbose for Ronald ;-))

Hey... I'm profesionally lazy :-)

"camunda" wrote:

- Some BestPratcises / Basic working examples for PEntaho integrations, especially a basic cube layout and an Kettle ETL process for the jBPM log data

+1 (is +10 allowed to?) Maybe they are interested in helping out? Joint effort?

"camunda" wrote:

- Some BPR reports for existing log data for generic performance indicators (process runtimes, task instance wait and run times, ...). This is what I think Heiko is working on at the moment, right?

My impression to

"camunda" wrote:

- Some KPI descriptions like I mentioned earlier. Even if this may be a lot of domain data information, I think if the process processes this domain data anyway, it is not such a bad idea to calculate KPI's already out of that and send better business events to BAM (like SeeWhy does).

This would be the last on my list (priority wise)

[heiko.braun]

- Some BPR reports for existing log data for generic performance indicators (process runtimes, task instance wait and run times, ...). This is what I think Heiko is working on at the moment, right?

Yes I am working on integrating BIRT with gwt-console-server. We would like to ship out of the box reports on the data available, but allow users to plugin customized reports (including domain data), which could then be selected from within the console.

BIRT basically works on data sources and has a lot of report design tools available, which should overcome our limitation of not knowing the detailed report requirements upfront. Users should be able to create custom report templates including data form the jbpm datasource and custom, domain specific ones ones.

[heiko.braun]

So, to conclude: Wee chose is integration with a report toolset instead of making up something on our own, which doesn't reflect the diverse requirements anyway.

[kukeltje]

Cool... good choice....

[heiko.braun]

... are still interested in 3rd party integration, Roland?

[kukeltje]

For the dashboard maybe... things I've seen in Pentaho etc look cool. Not sure how complex that is for integrating it:

http://wiki.pentaho.com/display/COM/Community+Dashboard+Framework

Birt is already 3rd party right ;-) But if you mean doing some work, yes, but there is no 'free time left'. I have no paid projects yet where customers want this functionality. Heck, I have no paid jBPM projects at all. Paid yes, but different topics