When you get started in BPM, the first step invariably is documenting your current, or as-is, process. You can gather the facts from process participants and process owners in a variety of ways – in a group, putting yellow stickies on the wall, or in separate interviews. But eventually you face the challenge of reducing that collected knowledge into a structured, semantically precise yet intuitively understandable, diagram – a process model.

The majority of process “models” in the wild are simply Visio diagrams, applying shapes and lines as the individual modeler sees fit.

Introduction:  Seldom a hot topic now, quality was the holy grail for business fifteen to twenty years ago. At the time, the automotive industry was learning the hard way from Japan that buyers could recognize quality and appreciate it enough to make it a priority in choice-making. The lesson was largely framed through the lens of manufacturing and the concepts of quality control developed by Edwards Demming – a prophet embraced by the Japanese, ignored in America and, suddenly, as important at home as he was abroad.

BPM benefits such as enhanced operational efficiency and compliance derive largely from the way it breaks down routine office work into specific tasks performed in a prescribed order according to explicit rules. The process design assigns each task to some role or group, while administrators manage the mapping of individuals to those roles and groups at runtime. This allows the BPMS process engine to route tasks to users in the prescribed sequence and notify appropriate managers and supervisors when those tasks are overdue.