Keeping BPM Simple for Business Users: Power Users Beware

Abstract

This article is a thought experiment: Invent a simple business process modeling notation suitable for a workshop in which business analysts (BA’s) help business users chart their as-is and to-be processes. The experiment is no idle diversion. True, process languages abound today, and the last thing the world needs is another one. (Besides, Yet Another Workflow Language, or YAWL, has already been invented.) The motivation for the experiment is the goal of continuity in the software lifecycle for BPM projects; in particular, that the process deployed to production is the same model (by then fully developed and tested) as the one created during the initial requirements phase. The movement of this one model through the phases of the cycle is depicted in Figure 1. Figure 1. One Model for the BPM Lifecycle Getting to production requires getting things right in the prior phases. The very first phase (requirements gathering) will fail unless the model is based on an approach that business users can understand. The goal of the experiment is to invent a language that will resonate with business users but can also be used through the remainder of the lifecycle. The second part is the hardest. Will the model created during requirements be in good shape for use case definition, or will the BA need to redraw it in a different form? Will the architect, or design team, for that matter, be able to work with it, or will he or they need to adopt a more technical modeling approach? The goal is to avoid such a break in continuity. What Works in the Workshop In a workshop setting, modeling notation is merely a means to an end. The goal of the session is to talk as a group through processes: The users describe how their business works now and how it should work, the BA’s try to solicit and isolate firm requirements. The talk never stops. During the session, a BA sketches on a whiteboard a crude flowchart that captures the process flow emerging in the discussion. The diagram is, in a sense, yet another voice in the exchange, which the participants understand as plainly as each other’s words. The sketch is continually reworked; by the end of the meeting, it represents crudely the users’ notion of their process, and it gives the BA material to work with when drafting a more carefully constructed business use case document.

Cite this work

No public copy is stored for this record, so only the metadata is cited.

Stored only when both papers are in the corpus — 14 citations exist upstream.

Papers that cite the same references — the relational fallback while embeddings are still backfilling.