When analyzing our customer base at NSI, which consists of end users throughout the Americas, we have become aware that business process management as a concept and technology frequently 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 serious BPM consultants, we will also must make sure that a current BPM implementation not only manages to satisfy a short term goal but also allows for future growth and process extensions and not merely 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.
A major difference between a BPM implementation and a business application is that it requires us and the customer to think, plan and budget ahead of BPMS and BPM services. The business application the customer in reality wants extends beyond typical BPMS elements, such as BPMN flowcharts, WYIWYG forms, process variables, SOA and basic reporting.
Enabling the end users with the business tools that they need now and –which we as business process experts know – that they will need in the near future, requires us to jointly create a solution architecture that will combine, with a BPMS at its core, elements of, but not limited to the following:
- WF/BPMN Process Flows.
- WYIWYG 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.
Failure to plan for these additional elements when thinking about what a pure player BPMS or an iBPMS will likely be able to deliver right out of the box, may cause false expectations by the end user of either of what products to choose, what budget to assign, or a to define a reasonable timeline for implementation.
The analysis of this likely set of technical elements required for business applications represents also a sound basis for designing a roadmap that enables leveraging 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 avoid the formulation of unrealistic requirements aimed at a specific BPMS.
Kay Winkler
Latest posts by Kay Winkler (see all)
- The BPM elements: Of Charts, Forms and Variables - May 2, 2016
- Green BPM - April 4, 2016
- Business Applications and BPM - January 4, 2016
IT channelization must be included in bpm data layer.