First Impression: BP Logix Process Director 3.0
- Published: August 26, 2013
- Written by Nathaniel Palmer
Recently the BPM.com team was provided with a comprehensive demonstration of the latest release, version 3.0, of Process Director from BP Logix. This was not a literal introduction, as we have had the opportunity to explore Process Director through prior briefings by BP Logix, as well as through working independently with two key customers. This has allowed us to understand both the potential value and the differentiating features offered by Process Director historically, as well as provide us with a unique appreciation of the critical milestones achieved with the V 3.0 release.
Some of the differentiating capabilities presented by Process Director include:
- Unique predictive BPM orientation with timeline and critical-path awareness, blending process management with project management.
- Flexible process architecture that supports both procedural automation and in-flight adaptation.
- The ability to combine both traditional sequence and control flow with time-based dependencies within the definition of workflows.
- Parallel cloud and on-premise deployment options using the same codebase.
- Tight integration and leverage of Microsoft infrastructure and environments including SharePoint.
- Persona-based workspaces and rich UI creation using a browser-based form designer.
- User-centric alerts and notifications that enable actionable, closed-loop communication with process participants about status and events, including predicted impact on pending deadlines and dependencies.
- Rich graphical reporting and report-writing capabilities allowing for building executive dashboards and defining KPIs.
- Integration with social media platforms such as (specifically) Twitter, enabling direct-to-customer process interaction, as well as event-listeners for launching processes in response to social network events.*
*The social media/platform integration is one of the milestones delivered in the 3.0 release. Related to this are other advances including: OAuth-enabled authentication allowing participation by users using Twitter, Facebook or Google account IDs, rather than having to be provisioned internally; cloud-based delivery which enables “outside the firewall” access and process initiation by customers and partners regardless of their device or platform; integration with a variety of third-party online services such as Dropbox, Google Apps, and Amazon SimpleDB which facilitate rich interaction to be embedded within the process.
These capabilities are combined to enable Process Director to extend notification of business events (also known as “signal awareness”) and the ability to act on these events to the furthest edge-points of the extended enterprise – engaging customers and partners as easily as departmental colleagues and internal stakeholders. This notion illustrates the defining capability and value offered by the emergent class of “Intelligent BPM” or “iBPM Suites”.
Intelligent BPM is not premised simply on “smart vs dumb” BPM, but rather intelligence in terms of visibility–the ability to extend interaction and awareness of process activity beyond the confines of the firewall and physical enterprise – and to safely interact both in the cloud and across social networks, where customer and partner interaction is most likely to occur. Yet perhaps the most critical aspect is time-based metrics. Specifically, the speed by which these signals are received, processed, and acted on. The real value of Intelligent BPM is the ability to create closed-loop communications with time-based dependencies, as explained below.
Intelligent BPM: Adding Time and Event Awareness to BPM
Widespread participation in social media now allows direct customer interaction at an unprecedented level. Now customers, partners and suppliers have the ability to not only receive notifications in near real-time, but also to broadcast their responses and opinions to the entire world. We are in an era today when an aberrant Tweet can, in a matter of minutes, cost shareholders millions of dollars and where the impact of mobile and social capabilities in enterprise systems, as well as external social networks, presents a very real consideration for business operations.
We have volumes of case studies that describe missteps and miscalculations with the personas of corporate brands across social networks. Preventing this is a clearly an imperative for any successful business in the socially connected world! Yet preventing or responding to PR disasters is merely table stakes. Leveraging social media for competitive advantage through greater responsiveness and effectiveness offers far more value than the governance of social media alone. Both pursuits, however, involve methods and metrics. The tighter/faster response loop, the greater the value derived from that business event – whether preventing a disaster or leveraging an opportunity.
Customer inquiries or complaints, partner requests, sales opportunities – all business events have an implicit half-life and utility curve, where the value offered by responding to an event diminishes over time. Clearly the faster the response, the greater the business value realized, yet this is inevitably based on a utility curve rather than a straight-line. If you submit a complaint and receive resolution a mere second or two later, your loyalty may have been won over forever, while a day later perhaps not, and two weeks later, forget it! Responding immediately is far more valuable than taking twice as long, and eventually that becomes too late to have any meaningful impact.
Understanding time-based value (and the corresponding loss of value) is an inherently intuitive notion, but putting this into a more quantitative context can be illustrated with metrics borrowed from the business analytics field, which splits into two distinct groups the inevitable delays or “latency” involved in each stage or set of steps which occur over the course of responding to an event:
- “Infrastructure Latency” or delay presented by the system in delivering notification of the event, and
- “Decision Latency” or the period of time between when the business event data is captured and when it is responded to.
For example, the delay between the time when a customer submits a complaint or tweets about a bad experience – until it is within an actionable, reporting framework is Infrastructure Latency. The time between when the event notification is received until the moment someone responds (first deciding then acting) is Decision Latency.
Time-based Value of Business Event Response
Using the basic model shown above, we see that the value of the response is greatest when it occurs closest to the moment of the event (customer complaint, etc.) and then diminishes over time. So while there may be more time spent in the decision, the greatest loss or otherwise potential capture of value happens with earlier notification, i.e., solving Infrastructure Latency. Despite this, however, BPM (e.g., pre-“Intelligent BPM”) and other automation technology have traditionally been applied to the second half of the equation, by automating or expediting decisions and responses. This may be perceived as the most obvious target as action here occurs over a longer span of time, yet as the model illustrates the potential value is a fraction of what be can realized by “moving up the curve.”
This distinction also highlights both the potential benefits and differentiation offered by the specific set of capabilities within Process Director 3.0, in particular related to cloud, social and mobile interaction cited earlier. Where there is a delay in notification and actionability, there is pressure to make decisions sooner rather than losing further value, yet paradoxically inevitably also value lost through poor decisions made in haste.
Therefore, the opportunity for process improvement (and thus generating greater business value) lies not only in receiving event notification, but in also providingactionable information to knowledge workers sooner. Achieving this comes in the form of having direct, closed-loop integration with the environments where the events occur, and allowing responses directly to and from social platforms such as Twitter, while maintaining the management and reporting benefits offered by the broader BPM environment. In other words, not simply leveraging Twitter for notification, or using BPM to manage ‘tweets’, but specifically to extend the reach of the managed process (visibility, interaction, and initiation) into the furthest edge-points of social networks and across the community customers, partners and suppliers.
Process Director 3.0 Twitter Interface
This notion of moving business processes into the social network arena as well as extending interaction through cloud and mobile platforms fits the evolving business model of today, where processes are no longer viewed as employee-only functions but reflect the reality that business occurs across a web of relationships involving customers, partners, and suppliers. Less the obvious but equally important , is the recognition that business processes that reflect how work is actually performed, cannot be entirely defined as preordained workflows, but need to adapt to the dynamic occurrence of events. We cannot define when a customer will call, when equipment will break, or the vast of array of more complex events that occur over the course of ‘normal’ business operations.
As discussed above and shown in the previous Time-based Value of Business Event Response illustration, the defining aspect of process improvement when responding to dynamic business events is not control, as with predefined workflows designed to enforce consistency of how work is performed, but rather it is time.
Businesses processes, specifically those performed by human beings rather than as automated scripts, consist of rules, dependencies, activities — and a time factor for both individual activities and for the process as a whole. In the traditional Gantt chart presentation of work, time is the constant point of focus. A critical path is consistently maintained and recalculated indicating expected time to completion. If an upstream activity takes more or less time to complete than previously projected, the impact of this is immediately known— and either the schedule or individual activities can be immediately adjusted.
With a traditional business process model, however, the concept of workflow – the very notion of the process itself and how work is performed – is understood in terms of the number of predefined steps or activities completed, without regard any particular notion of time. Yes, there may be discrete definitions of time as control measures, such as using a BPMN Timer Event, but that doesn’t translate to a critical path as with project management software as represented within a Gantt chart.
Hand any BPMN model to a Project Manager and ask them to show you where in the model they can determine whether project is on time. At best, they would not politely decline. Although you run the risk of worse reaction, as you would be asking them to do the impossible. Within any graph-based process definition, such as a BPMN diagram or any basic flowchart, there is effectively no means to identify whether a process is “on time” or on target relative to time based measures.
Although temporal extensions have been proposed for BPMN and XPDL (the industry standards for defining and storing process models) there is no explicit concept as time as process attribute. What this means is that while thresholds can be defined at the activity level (i.e., triggers based on a elapsed time of a given activity) there is no aggregate calculation of time. As a result, there are no specific temporal or time-based variables within the syntax of most BPM run-time environments.
Predecessor Model vs. Successor Model
Process Director is unique in the fact that the process design-time environment and the run-time syntax are comprised of two model orientations and run-time engines, within a single unified user environment. The first is a traditional graph-based process modeling and BPM engine. The second, however, presents an explicit work breakdown structure with precedence and time-based dependencies (i.e., the same representation as with a Gantt chart.) BP Logix positions these as the difference between a successor model (e.g., the sequence flow presented with a graph-based process model) and a predecessor model which presents the critical path of dependent conditions preceding each step, with time-based values for activity.
The predecessor model (shown below) and run-time environment presents a process timeline depicting dependent conditions (including predecessor activities or conditional rules such as “today is the first of the month” or “the VP has already approved this form), as well as the associated times or where applicable parallel activities. With a graph-structured flowchart, parallelism requires specific gateways to “split” and later “join” the workflow path. Because that model is depicting both control flow (i.e., who or what system has control of the process at that moment) as well as sequence flow (i.e., what happens before each process step or activity) it is necessary that these be defined in the process syntax. This includes defining whether it is a parallel gateway (i.e., where control flow splits and is later synchronized) or an exclusive “or” gateway (i.e., one path is taken based on the predefined criteria.)
With a successor model, parallelism is more naturally depicted by simply identifying whether an activity is dependent on the completion of another, or otherwise happens simultaneously. This avoids the complexity of splits and synchronization, but also provides for easier alignment with time-based measures. The result is a real-time calculation of the critical path, as well as deviations from planned versus actual, as shown below.
This model allows for uniquely predictive capability not possible, or certainly not practical, with graph-based process models. For example, by overlaying historic data with planned timing (as is the case below) the process model can immediately depict the predicted time to completion, as well as the highest-value for optimization. With a graph-based model, this would require multiple iterations of bottleneck analysis and what-if scenarios, but with the predecessor model it is immediately calculated as part of the critical path analysis.
Process Director 3.0 Process Timeline Predecessor Model
Where there are instances involving complex branching logic and if-then-else type rules, Process Director does support a graph-based model, as mentioned previously. Traditional process maps (as with the Process Director example shown below) are affective at showing the linkage between activities, but not the chronology of how work is performed. Thus one rarely (if ever) sees a flowchart used for project tracking, but of course will use a mapping of the visual flow to depict the “big picture” for work that is not as easily conveyed with a Gantt chart. In the same way, however, a very granular depiction of work quickly becomes difficult to comprehend, as a process model or flowchart lacks the inherent hierarchical collapsing and expansion inherent to a Gantt chart or the Process Timeline. For reasons, with Process Director the visual process map (flowchart) is typically saved for short process segments (e.g., a half dozen steps or less) or otherwise workflows which involve looping or iterative behavior, which visualize via a process model versus a Timeline.
Pr cess Director 3.0 Graph-based Process Model
Rules-Driven, Person-based User Environment
Process Director presents a distinctive User-Centric Design (UCD) metaphor with a responsive work environment able to adapt based on individual users’ roles, process state, and access device/platform. Combined with extensive reporting/dashboarding capabilities, contextual alerts/notifications and integration with third-party social media platforms, this allows Process Director to deliver a very rich user experience (UX) linked to business rules, roles, and individually defined preferences.
The Process Director framework includes a lightweight portal environment so that rich web applications can be built and deployed “out of the box.” Otherwise capabilities can be exposed as SharePoint WebParts or otherwise as web-based portlets. User authentication can done locally (i.e., as users defined within Process Director) but more notably can also use Active Directory or external LDAP services via standard protocols such as SAML, ADFS (Active Directory Federation Services), and OAuth. This enables single sign-on (SSO) within protected environments (e.g., “within the firewall”) as well as external social platforms, such as Twitter or Facebook as mentioned previously.
Typically, however, new processes are launched from within a form or in response to an event, such as new a ‘ticket’ submission, customer inquiry or a specific form submission such as a Purchase Order or Travel Request. Process Director offers both a complete form designer as well as an event listener within the process design palette. The event listener allows for the definition of triggers for launching a process or otherwise initiating a process-based activity, resulting essentially in any machine-based event. For example, an application receiving an email directly from a user or from a web page, a newly scanned document being added to a repository, or an application generated alert.
User interaction within the launched process can range from selecting a task from a task list, responding within a dynamic form, or otherwise responding to a direct alert. The forms designer allows for mirroring any existing environment, such as mimicking a literal paper form or otherwise following an e-form metaphor, as well as building a complete Rich Internet App (RIA) interface. In all cases, however, the presentation environment is driven by the underlying rules and context of the process.
Process Director 3.0 Rich User Interface
Environment and System Requirements
Process Director’s declarative, configuration-based (i.e., “codeless”) design-time environment allows all process definition and UI design to be performed within a standard Web browser. No client software or plug-ins are required, and Process Director can be accessed by any client browser (all leading browsers/client platforms are supported) including tablets and mobile devices
For on-premise deployment, Process Director eForm Builder requires just the .NET Framework 2.0 plus Microsoft Word 2003 or higher, and Process Director Server requires a standard Windows Server configuration:
- Microsoft Windows 2008, 2008 R2, 2012 Server
- Microsoft SQL Server 2005 or higher, Oracle 11g or higher
- .NET Framework 3.5
- 2 Ghz (or higher) CPU, minimum 2 GB memory, minimum of 500 MB hard drive space
Process Director 3.0 represents the emergent class of Intelligent BPM which is the result of combining rich user interaction and user-centric design capabilities with a dynamic and adaptable process architecture, as well as “any device, anywhere” access over cloud, mobile and social platforms.
For more information visit: http://www.bplogix.com/
Or contact via Email by Clicking Here