When analyzing our customer base at NSI, consisting of end users throughout the Americas, it can be noticed that business process management as a concept and technology usually plays only a secondary role in the minds of our customers. The main objectives of the principal stakeholders focus primarily on facilitating a turnkey solution that’s intuitive to use, fast, portable, scalable, and configurable and ultimately a tailor made business solution to the customers most immediate needs.

Of course, as a serious BPM consultant, we will also absolutely have to make sure that a current BPM implementation not only manages to satisfy a short term goal but similarly allows for future growth and process extensions as to not generate isolated application silos.

But mind you, business applications are what we end up producing all the time – not “merely” BPM solutions and process platforms.

Difference between business apps and BPM

A differentiation between a BPM implementation and a business application is in so far relevant that it is requiring us and the customer to think, plan and budget ahead of BPMS and BPM services. The business application the customer in reality demands, extends beyond typical BPMS elements such as BPMN flowcharts, WYSIWYG forms, process variables, SOA and basic reporting.

Facilitating the end users with the business tools that they need now and – from which we as business process experts know – that they will require in the near future, implores us to jointly create a solution architecture that likely will combine, with a BPMS at its core, elements of (not limited to):

• WF/BPMN Process Flows.
• WYSIWYG Forms that connect to the process flows.
• Server based forms (ASPX, JSP, PHP and such) that connect to the process flows but can be extended internally in the DMZ and WAN.
• Data dictionaries and variable libraries (to be universally reutilized).
• Macro Business Rules (programmed or designed within a BRE that connects to the processes).
• Edible Micro Business Rules (calculations, scorings, policies – usually programmed in Web Services and Stored Procedures).
• Process data repositories and Business data repositories (They are not the same. Whilst the first can be populated automatically with modern BPMS, the latter usually has to be custom made per business process application, gathering the individual business data on a form level).
• BI components, providing data cubes, dashboards, historical-, pattern- and predictive analyzes that combine both (above mentioned) data repositories.
• Mobile forms and process extensions (as adaptive web extensions or connected native Android and IOS apps that are capable of functioning in online and offline modus).
• DMS and ECM elements that assure an independent (from BPMS) document management and storage that can be used by other processes as well as process independent applications later on.

Failing to draft out these additional aspects to what a pure player BPMS or an iBPMS will likely be able to deliver right out of the box, may cause false expectations from the end user of either what products to choose, what budget or as to what timeline for an implementation to define.

Roadmap

The analysis of this probable set of technical elements required for desired business applications represents also a healthy base for designing a roadmap that also allows to leverage existing technologies that the end user may already have (even simple solutions such as existing integrations, pre-configured reporting services, CRM’s or ECM’s).  It also helps to avoid the formulation of unrealistic requirements aimed at a given BPMS.

Follow