BPM capabilities have gone through a radical transformation as a result of Case and Dynamic Case Management (DCM) concepts. The Case type concepts were intended to help people wrap their heads around the business applicability of BPM which was desperately needed since “core BPM” is often considered to be nothing more than another development type language. The natural outcome has been millions of transient (short, specific, temporary) BPM transactions; such as order processing, back ground checks, cases and escalations. The key question is how does one get past each of these BPM records from being simple transactions?
If you are familiar with the intersect of BPM, Case, DCM, Content, Agile, system and data federation– skip down. If you’re not, here’s a little background.
- Case and Dynamic Case Management placed BPM in language of the common user – made it tangible, understandable and configurable. They include pre-built capabilities such as escalations, dynamic assignments, deadline calculations, etc., essentially creating functional “building blocks” that simplify application construction.
- Core BPM stitches these functional blocks together. You can rapidly change or restructure them – facilitating agile thinking, enablement and managing them through completion. The functional blocks are typically accessible to both core BPM and Case. This capability library is used to build horizontal utilities and vertical specific applications – delivering on the intended business enablement mission.
- Process Orchestration is a key mandate of BPM; pulling together multiple human steps, departments, systems and data into an end-to-end, orchestrated and managed set of activities. The real core BPM value is the in place utilization of ERP type data – i.e. read, written, reported on from the system that owns the data – this includes systems like SAP, store management, inventory, asset management, contract systems, content management, etc.
- Now add digital transformation as it has significantly increased the demand for “content” (files, documents, media files, blogs, etc) to become a pivotal and contextually relevant part of the process. This must happen without replicating the content, instead maximizing the media, files and content in place with capabilities such as media editing, document creation, etc.
If you skipped down, here’s where you can rejoin…
All of these concepts – BPM, Case, DCM, etc. – have been driven by traditional process and procedural type thinking (step 1, step 2, step 3) – call this waterfall, agile, sprints, process definition, or application design. It is the power of these concepts that made it phenomenally simple for the lay-business user to construct personalized use cases, apps, processes and systems with no concern about BPM, Case or DCM. The glitch is that it also has resulted in isolated transient [BPM] transactions that cannot be tied to other business directives, objectives, or outcomes without a significant amount of “Master Data Management” type effort to glue information together that should not ever have been created in isolation.
This transaction isolation is the result of limited inter-project collaboration despite everyone having great intentions. There is not much BPM can do to drive human dynamics here – people will build within their domain, confines and areas of control. People will follow natural behavior and protect themselves, teams and budgets – no type of BPM technology introduced will change this. What we can do is benefit from this behavior, give people the tools to do what they want to do within the individual projects.
This challenge will continue to get more significant as BPM becomes more and more simple and closer to the hands of the “Citizen User”. The next major hurdle for BPM is to facilitate the “Citizen User” while ensuring that silo construction efforts become enterprise, business relevant capabilities – and allow companies to look at transactions within context of the revenue and operational demands and expectations.
The most logical path to facilitate relevancy is to allow the business to understand the assets, documents, buildings, constructions sites, etc – the “stuff” that drive processes and revenue. This “stuff” can be anything – from a contract to a building to a truck fleet to computer hardware. These items typically exist in a company for long periods of time, up to decades and end up being persistent records (records that hang around and are usable and relevant for extended periods of time).
Take an oil rig for example, it is persistent within BPM and there are several processes that it drives. From drilling to ordering to construction to auditing to oil pumping to helicopter flights to staffing, etc. Plus, an oil rig has a lot related “stuff” such as pumping stations, contracts, helicopters etc. Each of these have their own individual lifecycle with processes attached to those elements
BPM must bring those transient and persistent transactions together with content – in the manner and pace at which a business thinks and executes. This means configuring and building an enterprise application, asset and organizational change framework without any formal project around it. This means that all of the “stuff” and the related processes can be glued together and can systematically and progressively become an orchestrated BPM solution without breaking agility – by multiple, isolated, non-collaborative projects.
The ability to create persistent BPM records surrounded by transient records that drive revenue and operations transcends BPM today. Instead of trying to construct all permutations of step 1, step 2, step 3 so that the process is managed, the persistent record (aka the oil rig) can be the center of the multiple processes. This allows for an oil rig to be defined as it is used. Once the oil rig record (or the idea of the oil rig) has been initiated (to any initial level of initial maturity) one can start mapping processes and procedures around it using BPM, Case or DCM concepts. Now, you are able to construct the progressive and relevant activities around “stuff” that drives the business. You can create linkages with contextually relevant content while evolving the maturity and sourcing of information. This allows for clear business definition of the “stuff” that impacts the business – including information hosted in external systems.
OpenText call this approach Information-Driven Design. The “stuff” or persistent records are called entities. Entities have lifecycles and associated tasks. It is the objective to place the power of agile, rapid, isolated capabilities, corporately leveraged, contextually relevant configurability in the hands of the “Citizen User”.
We are excited about this approach and how it can deliver greater BPM success for our customers. Come to the Process Suite booth at Enterprise World for a peek at current abilities – and make sure you schedule time to get to the Innovation booth to have a look at what’s coming.