Skelta BPM.NET

A while back, I had an email from Phil Larson, who I have known since he was at Appian; he has spent the summer in India as an MBA internship. One thing led to another, he connected me up with Skelta, and I fostered India-Canada relationships by getting up early for an online demo with Sanjay Shah and Arvind Agarwal of Skelta. They’ve published a corporate presentation if you want to take a look.

They started by creating OEM workflow components that were embedded in other products, then built that out into a full-blown BPM suite, BPM.NET, while retaining a focus on componentized, embeddable pieces. They have significant penetration into the Indian business process outsourcing (BPO) market, both as the BPOs’ product offerings and for their own internal processes. Because of the OEM nature of their product, they also end up embedded in SaaS BPM implementations, although white-labeled so you may not know that they’re there. This is much more like the Fujitsu model – create BPM primarily for the OEM market, then launch as a direct BPMS product – and Skelta has leveraged this into business that includes OEM and full product sales as well as multi-tenanted hosted BPM. Even their browser-based process modeler can be embedded as a component in another application, not just the run-time UI components.

As you might guess from the product name, they have a strong Microsoft bias: there is significant integration with SharePoint and other Microsoft products to capture and act on events generated from those systems, plus adapters for SAP, PeopleSoft and Microsoft Dynamics. The number of integration services that they provide is quite extensive, and is likely what has made their product attractive to the BPOs to use as a base upon which to build applications. These are available directly from the process modeler: there is a palette of SharePoint activities built in, as well as BizTalk activities and other integration activities.

The process modeler includes the ability to set up data points that will be used as KPIs in reporting. Queue filtering and prioritization can be based on multiple factors so that process participants see only the work that they should be able to access, served to them in the correct order. Process models are consumed directly by the process engine without translation.

They include an AJAX forms designer for creating task user interfaces, including scripting to control contextual behavior: the view on the form (and therefore the visible/editable fields) can change depending on which step that the process is at. The main processing paradigm has a user requesting the next item at a particular process step from a shared queue, which moves it to their personal work list for working with that AJAX form; escalation can be based on the time that a work item spends in a shared queue before selection, or in a user’s work list. The user’s view can have some monitoring graphs built in, since these are all components that can be assembled into a web application. The user can view the process map for the current instance, including a history of the process to date.

There is not a full rules engine as part of the product: expressions and rules can be built into the forms and process definitions, or rules services can be integrated using web services, calling BizTalk rules, or writing the rules in .Net.

There’s a big focus on components used to monitor processes and their SLAs: this is critical for the BPO market, since their compensation is typically based on meeting SLAs, and they likely have penalty clauses associated with missing them so need to monitor them closely. There are other needs of BPO vendors that Skelta is seeking to address: the ability to embed white-labeled BPM within other applications; multi-tenancy software-as-a-service infrastructure; and, for the Indian BPO marketplace, the fact that Microsoft infrastructure is cheaper to build and maintain in India than a comparable Java infrastructure. In some ways, BPOs have needs similar to that of large enterprises, such as quickly-changing user requirements that can vary widely across the user base, and the need to simplify training and roll-out of the system.