One of the things that Metastorm has released recently is a series of solution frameworks that they call “Process Pods”, which include prebuilt rules, dashboards, KPIs, and technical integrations in addition to prebuilt process models; however, they’re not truly productized in that they’re supported by the Professional Services group as if they were customized work.
The latest of these process pods is targeted at the financial services market, specifically new account opening: an area that often requires both electronic and paper-based data collection, background checks, new account creation, and updates to existing account and client records (Metastorm press release here). In addition to the process flows and rules of other process pods, this one also uses Metastorm Integration Manager product (which is, I believe, what the CommerceQuest acquisition turned into) to integrate the legacy applications (including CICS) that are typically used for client on-boarding tasks in financial services organizations. Although there will still need to be customization, the idea (as with most BPM frameworks) is that the time to deploy a productive, integrated solution will be greatly reduced.
I checked out their hour-long recorded demo of the New Account On-Boarding process pod (registration required, and didn’t seem to be Firefox-friendly). It’s pretty low-resolution and the audio is a bit sketchy, but you can get an idea of how a process would look as implemented with their NAO process pod, including the following features:
- CICS integration both for retrieving data and creating the new account on the legacy mainframe system.
- SharePoint portal integration, plus standard JSR168 portal integration into a Pluto portal; there are a number of portlets that can be embedded, such as a task to-do list, a watch list, a search form, and a form to create a new account (which presumably kicks off a new process instance).
- Email integration for alerting process participants.
- Data entry forms including links to data validation for things such as customer/account number, and enforcement of required fields.
- Checks for conditions such as specific countries of origin and amount of investment to trigger any anti-money laundering or other rules for further investigation.
- Identify verification to satisfy know-your-customer regulations, including checking against third-party blacklist checking services.
- Risk assessment checklist.
- Electronic signature and date-stamp at key points, such as completion of due diligence.
- Removing tabs from user interface at points in the process to limit access to information by certain user classes.
- Document attachments.
- After-the-fact batch reports.
- Dashboards with KPIs; these appear fairly rudimentary, but are actionable by allowing drill-down to the actual process instances.
- A third (!) separate business intelligence product that also produces reports and dashboards.
- Administrative functionality to allow control of many of the process parameters via table values, e.g., adding new questions to the risk questionnaire and indicating how each possible answer contributes to an overall score. There are some aspects of this with which I disagree, such as specifying parallel and serial process paths by creating table entries for each logical node in the process map, and assigning the order: this is the way that we used to do process maps before there were graphical process mapping tools.
One issue that I have with the demo is that it shows a finished product from a user point of view, without much of an indication (besides the administration table values) of how much effort is required to build this solution based on the NAO framework, or what is even customizable in the framework. For example, I suspect that some of the processes, rules and data fields in their standard process pod are US-specific, although they should be customizable with some additional help.
There are some things that they sell as features that look a bit clumsy, such as calling out to MS-Word for spell-checking within a note entered in a web form. Also, early in the demo, she shows the process model in ProVision, but not obvious that this maps directly to the Metastorm execution environment — I’ve seen some comments that indicate that it’s not so easy to pass models back and forth.
The demos a bit long, and an interactive demo is always better, but this does take you on a pretty thorough tour of what can be done with their process pod. And, I managed to get all the way through this blog post without a reference to pod people, invasion of the body snatchers, cocoon or many other great sci-fi usages of the word “pod”.
Sandy – I’ve seen and used this toolset. The power of something like this is the fact that by using the ProVision models as a base (which is, essentially what the process pods are) they now have a totally customizable set of models which integrate pretty seamlessly with the Metastorm BPM tool.
Whereas previously the BPM tool had no process modelling capability behind it (i.e. the models they used were designed fairly rigidly within the BPM tool itself) now with ProVision, the EA and BPA modelling capabilities are wide open. The key is the seamless (albeit one way) link between the ProVision models within Metastorm EA/BPA and the application generation part within Metastorm BPM. Apparently the next part is to make it seamless both ways and to integrate the look and feel of both sets of applications
I’ve only recently discovered your site and I’ve subscribed to the RSS feed. Well done and thank you!
Gary
http://process-cafe.blogspot.com
Gary, the real problem is likely to be that one-way trip from the modeler to the BPM execution environment: what happens when a model needs to change? Lack of round-tripping tends to make the processes in BPM much less agile, since the business analysts using the modeling tool are cut out of the loop once the first pass is executed.