This chapter concerns with the accessibility of Business Process Modelling tools (BPMo tools) and Business Process Modelling languages (BPMo languages). Therefore, the reader is introduced to accessibility first. The authors provide definitions, standards, and a status quo on accessibility. Afterwards, the chapter concerns business process management. The reader learns definitions for processes and advantages and disadvantages of modelling languages. The BPM section is closed with the selection of a proper modelling notation for the accessibility evaluation. In form of two separate analyses, the authors evaluate the accessibility of two BPM tools. The results and recommendations for actions are presented after each analysis.
TopIntroduction
Company’s output is based on a number of activities performed. To organize these activities a company has to identify its business processes and understand their interrelations. Therefore, business process management is a major driver for enterprises to promote a more efficient creation of value, as the analysis of internal processes occupies a centre stage (Weske, 2007). The origin of process management dates back to Henry Ford in 1903, when he organized and introduced the assembly-line work (Harmon, 2010). The first published paper, related to process management, was written by Frederic Winslow Taylor back in 1903, and was called Shop Management (Taylor, 1903). In 1911 he additionally published the first book attending process management, called Principles of scientific management (Taylor, 1911). Along with e.g. globalization, technological progress and the scarcity of resources during the second half of last century, enterprises’ business processes gained more importance and complexity. Hammer and Champy are known, as the modern era promoters for process management. Their publications in the early 1990s focused on business process reengineering (Hammer & Champy, 1993), to call attention to opportunities to adapt to new competitive landscapes. Since the mid-1990s enterprises try to support and optimize the operation of their business processes with information technology (IT) like enterprise resource planning (ERP) systems or customer relationship Management (CRM) systems (Jestin & Nelis, 2006). Therefore, the identification and understanding of business processes is a crucial factor for enterprises. To dominate such complex processes, detailed process documentation is inevitable. Process documentation provides necessary information for e.g. gap analyses or requirement specifications for IT-implementation (Baschab & Piot, 2007).
To ensure efficiency of business process documentation, specific software applications are applied.
As information technology today is strongly intermeshed with business processes, requirement specifications for IT-implementations obtain much more significance for enterprises’ prosperity. The on-going technological progress precipitates more valuable IT. This facilitates enterprises to offer more efficient and convenient processes to the customer. In contrast, process documentations become more complex and consume a higher amount of e.g. financial and human resources for its construction. Requirement specifications have to be more detailed and accurate to be viable by IT departments. This again requires more qualified personnel, as tasks / activities for process modelling increase.
Process modelling divisions tend to be frequently understaffed. The success of modelling projects depends on a few employees, who are deeply involved in additional projects and barely find capacities to generate or maintain the required specifications. In addition, process modelling can be a very complex and cross departmental task. Hence, the comprehension and acceptance of process modelling activities and process modelling results by the participants are regularly divergent. As a consequence, IT-projects often are terminated or delayed. In the worst case, incomplete, inaccurate or/and unintelligible specifications are delivered, which cause additional costs, occurring later in the engineering cycle.