Hello, is there any best practice how to use Cost Revenue Enhancements in BPM v9.2?
Hello
Is anybody use this additional variables?
Could you describe how to best use it for reporting purposes? Why it is stored both in eEvent and eFolder?
I too am puzzled by these additions to ProcessContext. IMO these additional fields break the semantics of ProcessContext (or in the old world eFolder), i.e. ProcessContext contains information that is relevant and common to all processes regardless of what they do.
I agree with Greg, how about some explanation about this 'enhancement'?
I agree it lacks documentation, but it is failry easy to work out by playing with it. During an action you can set the TotalCost, TotalRevenue and TotalWork variables. What is interesting is that when you do this, it puts the value in the eFolder table, and it puts the difference between this and the previous value in the eEvent table.
It is a bit like the 'eEntryTime' value in the eEvent table in that it calculates the difference in Revenue, Cost and Work time per action, although the eEntryTime value only allowed you to make the calculation yourself (time between stages), whereas this calculates for you.
Frankly I would have preferred it completely the other way around, in that I record the Revenue, Cost or WorkTime per action and it keeps a running tab of the total, but this works just as well, albeit a bit less intuitively to my mind. I also imagine I'll find a way to abuse it before long!
We have exactly this conmstruct in our Client Inception and Case Management solutions, and it is nice to see a siliar concept being incorporated into the system itself. I imagine it is there as part of the Case Managemnt direction the product appears to be directed at.
I haven't used it yet myself since it is brand new, but I too am suprised to hear that you set the totals and not the individual values. I would have preferred the latter, but I'm sure they had a good reason.
I can tell you the rational. It was simply to improve the metrics available to be reported on. I do not agree that this breaks the semantics because every process has some cost, revenue, and work associated to it whether it is direct or indirect.
Jerome, thanks for the explanation, much appreciated.
In terms of reading these values the way it has been implemented seems correct to me but I agree that it makes no sense to have to set the totals. This just means that the designer has to do the work that the engine will eventually un-pick. What would be better is to be able to set the cost for the action, say Action.Cost and let the engine manage the totals.
I'm with you and Rob on that, but having said that, I can see why it might have been done this way. Now you have three editable values, and all you actually have to to is add to them.
The other way you would need three editable and three read-only values (for the action and total respectively). That makes it somewhat more cumbersome to manage and document.
Does that make sense?
