In short, all terms in BPM are misunderstood. This misunderstanding objectively appears due to mixing enterprise contexts.
Being in the center of enterprise architecture and processes, BPM objectively appeals to versatile groups and enterprise divisions. Each of these groups has very specific terminology and vision of every model and term, which it routinely uses. It is hopeless and counterproductive to convince every given group to think in terms of a different group. However, all groups still share a single model describing given organization. How to resolve this contradiction?
Since a singular enterprise model objectively exists (even if not explicitly expressed) and different groups of users work with it in their own ways, we can deduce that every group of users utilizes individual projection of the entire model. Multiple projections of the same model or process can be written in different notations, use different modeling methodologies, have non-similar visual symbols and appearances on diagrams but still consistently express valid projections on the single model behind. EPC, BPMN, UML, XPDL and whatever more notations can well coexist and complement each other.
This situation explains crucial role, which play process repositories and master data management for a successful BPM implementation. Well configured process repository serves as a single point of truth and implicitly translates aggregated enterprise model into projections and terms understood by each group of stakeholders.
Single BPM terminology cannot be achieved similarly to a single world language. Just on the contrary, a mission of BPM is to maintain versatility of terminologies, which are comfortable for each user group, similarly to maintenance of all world’s cultures and individualities. In this situation, well established model translation services acquire same crucial role as automatic translators of natural languages.
Please somebody knowing a word in Japanese comment on how well Google did with translation.
Leave A Comment