Blog: KWKeirstead's Blog
KPPs and BPM
You are probably familiar with KPIs (Key Performance Indicators), but this article is about KPPs (Key Process Points).
KPPs are wait-state auto-commit steps along BPM pathways.
They have predecessors and successors like all other BPM steps. They become current when the last of their immediate predecessors has been committed and their immediate successors become current at the time KPPs commit.
The performing resource is “System” and KPPs post to user System’s InTray.
KPPs have Forms, same as all other BPM steps, with, in the case of KPP steps, a mandatory form rule that reads data and “fires” when the rule evaluates to TRUE.
For performance reasons, it is important that each KPP have a cycle timer so that the form rule is evaluated at reasonable times along the process timeline (i.e. every hour, every day, once a week).
KPPs are becoming more and more important as BPM processes depend on data external to their run-time Case Management platforms.
They typically require a generic data exchanger so that data pulled from local and remote applications and systems to the data exchanger or data posted to the exchanger can be mapped to data element names that the Case Management platforms recognizes. Most organizations use pull protocol with some of their data trading partners and use push protocol with other of their data trading partners.
OK, so if we have KPPs waiting for incoming data, why don’t we have KPPs waiting to output data for push to local and remote systems and applications or for pull by local and remote systems and applications.
The reason is this data management task is handled by the data exchanger. For pull, the subscriber can decide the frequency of pickup and, for push, again, the subscriber can work out a push strategy that suits the subscriber.
If you don’t have/use KPPs, your BPMs is an island and you are basically working with a model of a process as opposed to a real-life mirror of a process.
Leave a Comment
You must be logged in to post a comment.
