Why Use Business Process Modeling?
Organizations use Business Process Modeling (BP Modeling) in order to visually document, understand, and improve their processes. A part of Business Process Management (BPM), BP Modeling has been used as an organizational tool to map out what is (or “as-is”) as a baseline and to determine the future (or “to-be”) with any improvements assimilated. BP Modeling visually represents all of the connecting activities, events, and resources of the process of a product or service to make it more efficient. BP Modeling often combines the disciplines of process mapping, process discovery, process simulation, process analysis, and process improvement. Within a Business Process Reengineering (BPR) event, BP Modeling is used to illuminate what processes are already in use, and to represent new processes. Some of the other reasons to use BP Modeling are as follows:
- To create visual models of processes - Word-driven documentation is often not sufficient for employees to understand the way a process is performed. Backing it up with visual representations helps provide a comprehensive picture.
- Align operations - With any new business strategy, keeping processes consistent after a change requires figuring out how to stay within the overall organizational strategy. Analyses are also performed to identify bottlenecks and inefficiencies, and enable process agility.
- Improve process communication - Communication is the key to all of the following tasks: formalizing existing processes (that were once informal knowledge), making consistent processes, eliminating guesswork with business rules, handling exceptions, providing regulatory compliance, ensuring business people are in charge, and supporting new initiatives (such as Lean Six Sigma).
- Improve operational efficiency - Modeling processes promotes optimization by allowing simulation and illustrating needed improvements. This reduces cycle time and promotes better resource utilization.
- Gain competitive advantage - A process is better overall when it is constantly refined and aligned with its business’ strategies. This efficiency places the company in a forward-leaning position to be better than the competition.
See how Smartsheet can help you be more effective
Watch the demo to see how you can more effectively manage your team, projects, and processes with real-time work management in Smartsheet.
Business Process Modeling in Software Development
Software development is a risky field. Twenty years ago, the 1995 CHAOS report by the Standish Group reported that 90 percent of software projects fail. Today that numbers are lower, but still reflect that there is work to be done. In the 2015 report by the same group, the rate of success for software development projects was still only 29 percent. The group’s recommendations to improve these numbers over the years have ebbed and flowed with new trends, but one main recommendation holds: communicate with all of the stakeholders, especially the end users, since end users are those who end up defining the requirements in the first place. Experts recommend developing clear models with understandable notation early on in projects in order to validate the requirements of the software. BP Modeling allows software engineers to negotiate with stakeholders to determine the system that needs to be built, based on what is optimal for both groups.
Most BP models have been developed as part of existing enterprise architectures, which shows that the intent during development is that the end user is represented. However, these models have been done from a number of different perspectives including functional, behavioral, organizational, and informational. Experts agree that the combination of these perspectives in process design is the best method.
- The functional perspective shows what process elements are being performed and what information is relevant to them.
- The behavioral (or dynamic) perspective demonstrates the sequence of interaction and how process elements are performed.
- The organizational perspective shows by whom and where the elements of a process are performed.
- The informational perspective represents the origin of information that is produced or analyzed.
Business Process Modeling Languages in Software Business Process Modeling
All of the existing business processing model languages come from different facets of scientific tradition, and have been built to suit one perspective or another. There is significant overlap in the languages, but there are four broad categories of business process modeling languages.
- Traditional process modeling languages: From the management information system (MIS) tradition of information engineering, these languages are meant to be understood and are not typically formal. These include IDEF, Petri Nets, EPC, Role-Activity Diagrams, REA, and BPML.
- Workflow modeling languages: These scripting languages are for describing workflows for a workflow management system (WfMS). These very formal languages include Workflow Process Description Language (WPDL), and proposed interchange formats (PIF, PSL).
- Process integration languages: These languages are for the purpose of integrating between enterprises, and capture different levels of the semantics in processes. These include RosettaNet, ebXML, and BPEL4WS.
- Object-oriented languages: Meant to be understood by both IT and domain experts, these languages represent the software domain. Most of the object-oriented modeling takes into consideration the functional, behavioral, and informational perspectives.
Hafedh Mili et al recommends that teams should use a core language for modeling, and then use different parts that suit the process from other languages. In this field, it appears that experts agree that even the languages should be driven by the tasks.
How to Approach a Business Process Modeling Project
Choosing an approach to BP Modeling is just as essential as performing it. The approach, based upon the actual task itself, is not a one-size-fits-all affair. Some classifications should be made before a project is undertaken. According to Bider, professionals should consider three factors: the actual business processes, the characteristics of the modeling environment, and the intended use of the model. These three factors may be broken down into specific business considerations.
- The business processes – Businesses should consider their active and passive participants, how closely they are meeting their operational goals, how closely the process interacts with its environment, and the nature and orderliness of the process flow.
- The characteristics of the modeling environment - For the modeling environment, businesses should consider the maturity of their existing processes and whether or not there are personnel available that understand the very formal notation.
- The intended use of the model - Businesses should consider their objectives for designing models and what basis they are using to create models. For example, they could be trying to improve the current processes, providing analysis or reengineering, or building a new computer system.
Since there is no universal approach to BP Modeling, experts recommend considering all of the unique business factors. Some pros recommend a specified formal approach that gathers all of the information before choosing tools, while others recommend specific tools that have worked for them in the past. Two of our experts make their recommendations below.
According to Dani Peleva, Managing Director of Local Fame Ltd:
Workflows and Business Service Oriented Approach (BSOA)
Some experts consider BP modeling for software development to be a before and after prospect that revolves around the introduction of web services. Before the development of the web, the main approach for developing processes was workflows. In the workflow approach, the business processes are pre-determined. The most suitable languages are Business Process Execution Language (BPEL) and Flow Definition Language (FDL). The workflow approach was criticized as not being very flexible in a modern environment.
After the development of web services, the approach for BP Modeling for software development became more focused and identified as the Business Service Oriented Approach (BSOA). Process modeling is based upon the flexible composition of business services. The approach can be tailored to address what the designer’s goals and requirements are in architecture development by using building blocks. Services carry out small tasks, such as data development, or simple service procedures. Taken all together, BSOA makes an extremely reusable system that can be fixed and regularly upgraded. This approach is credited as being Agile, and applicable to many different types of organizations.
Different Ways to Model Business Processes
Between all of the standards and standardized languages, some professionals think that the creativity in designing processes is being leached out. Alternative approaches can restore some of that creativity. Some of the most popular techniques that can stand-alone or even complement more formal approaches are the following:
- Flow Chart Technique
- Data Flow Diagrams—Yourdon’s technique
- Role-Activity Diagrams (RAD)
- Role-Interaction Diagrams (RID)
- Gantt Chart
- Integrated Definition for Function Modelling (IDEF)
- Colored Petri-nets (CPN)
- Object Oriented Methods (OO)
- Workflow Technique
- Business Process Modeling Notation (BPMN)
- UML Activity Diagram
- Transformational Process Models
- Hierarchical Process Models
Process Mapping vs. Process Modeling
Process mapping is a high-level review of an organization as a single entity with interconnecting parts. The flow of business processes through the organization is reviewed to clarify who does what, how processes are performed, and by what standard they are judged. In process modeling, professionals are more focused on how efficient the processes are, using business and economic best practices. Although both depict the processes graphically, process modeling is a deeper dive into the relationships that produce the services and outcomes.
Framework for the Modeling and Evaluation of Software Processes (FMESP)
One of the complicated issues that came from developing standardized business processes is the notion that their efficacy must be determined. In other words, how successful are business processes? FMESP comes in as a set of metrics to evaluate conceptual models of business processes: what they do and what they do not do. FMESP measures the structural complexity of software process models and then the activities, roles, and work products. This framework is intended to give businesses objective information about the maintainability of their models.
Develop Good Business Process Models
How does a professional get started on a BP Model? One of the common approaches advocates picking a problem, selecting the method, and then solving the problem. Keeping it simple ensures that everything relevant is in the model and everything in the model is relevant.
Other professional tips include:
- Ensure that you know who will be your resources. Develop lists of tasks, people, and the time required to complete the model.
- Conduct your interviews in the order the roles appear on the process model.
- Document. Document. Document.
- Recheck all of your symbols, ensure there is a key, and follow each step to ensure that the path takes you either back or ahead.
- Know your desired outcome ahead of time.
- Figure out your start and end points.
- Get ahold of the documents and forms ahead of time that are part of the process.
- Use templates whenever you can.
According to Steve Wallis, Co-Founder/Analyst/Consultant at ASK MATT, Foundation for the Advancement of Social Theory (FAST) - Theory for a better world:
Image Source: Steve Wallis
Oh, if only life were so easy – and so predictable, however, it is not. Therefore, we looked for a slightly different approach to business process modeling. Calling it Strategic Knowledge Mapping (SKM), we focus on the transformational aspects of modeling. Rather than modeling what is happening on the “surface” level (e.g. Research gives information to manufacturing), we encourage our clients to see what changes occur at all of the interconnected steps of the process. From our research and experience, we have developed two easy techniques for developing good models.
First, in order to understand a transformation in a model, there must be more than one arrow pointing towards each box. For example, if we are talking about making pastries, the process of creation requires raw material (flour, eggs, sugar, chocolate, etc.) and equipment (oven, racks, mixers, etc.) and cooks (with some level of expertise). Therefore, in order to better understand the transformation, we create a model showing how each of those ‘inputs’ combines to create the transformed ‘output.’ To some, that may seem obvious. However, here is the hidden insight (ex: chocolate filling): If you have a model where there is only one arrow pointing towards something, that lack of additional arrows indicates a gap in the model. For managing the process, you are missing an alternative path.
The second tip for making effective models is to understand each arrow as being ‘causal.’ This is one of the great bits of ‘forgotten knowledge’ in the world of business. Causality is the essence of scientific understanding. To understand the transformational process, and business processes in general, it is not enough to simply say, ‘The cook mixes the ingredients and makes the cakes.’ A good manager understands that having more raw materials, more equipment, and more expertise will cause the transformation into a marketable product (or service). And, for managing that process, there may be some tradeoffs between them (a really good expert might be able to stretch the raw material a bit), but each stream is required to create the end product. Without raw materials, I will not have a pastry with my coffee!”
Business Process Model and Notation (BPMN)
BPMN was developed by the Business Process Management Initiative (BPMI) as an open-industry standard, and is now maintained by the Object Management Group (OMG). No software or consulting company owns it. It is a graphical notation for creating process models, similar to flowcharts, that is used and understood industry-wide. Many software tools support BPMN. However, the meaning of the shapes and symbols are independent of those tools, and those meanings are precise. BPMN is a core part of Business Process Management (BPM), an initiative of enterprise architecture. The version of BPMN that is currently in use is v2.0, last updated in 2011. Professionals may become certified in BPMN v2.0 through the OMG exam process. The OMG also offers guides that show how the notation is broken down into the groups of events, activities, flows, data, artifacts, etc. Elements are categorized into four major groups that are referred to as flow objects, connecting objects, swimlanes, and artifacts.
The intent of BPMN is that technical users and business users may be able to understand a common diagrammatic language. BPMN is based upon a flowchart technique similar to one developed from the Unified Modeling Language (UML), and is able to be mapped directly to Business Process Execution Language (BPEL), an XML-based language that is used to define enterprise business services within web services.
Critique of BPMN
Industry opinion varies on the use of BPMN for BP Modeling. Critics argues that BPMN is much more complex and advanced than it needs to be for stakeholders who may not be very close to the actual process. Further, with so many symbols it is easy to make mistakes, defeating the purpose of its use.
Proponents of BPMN say that most professionals only use a handful of symbols - making the knowledge of obscure symbols unnecessary. Some international companies require BPMN’s consistency, especially when languages may be varied. Understanding the processes with a standardized notation is less of a challenge.
Other Types of Notations and diagrams
In 2012, Cristina Venera performed a study of two popular notation languages, BPMN and UML Activity Diagram (UML AD). Among professionals and the literature, she found that both languages are equally easy to understand by stakeholders interested in BP Modeling, and that they in fact both provided similar solutions. However, the difference was that BPMN is able to be mapped to (WS)BPEL, whereas UML AD is not able to be automatically mapped to any BPEL.
Other types of notations include Event Driven Process Chain (EPC), workflow diagrams, and mind maps. EPC is most often used for higher-level business processes, consists of five elements and rules, and always starts with and ends with an event. There are rules in between: “OR,”“AND,” or “XOR” represented as graphical connectors.
Workflow diagrams illustrate stages and relationships between all parts of a business. In workflow diagrams, there is no set of agreed upon (standard) symbols. It is more difficult to compare models done across an organization, but does allow more freedom for creativity.
Mind maps are the least restrictive of any of the techniques listed here. Although they are generally hierarchical, they can be done by hand on a napkin in a pub, if necessary. Mind maps are a way to show relationships around a single concept as well as any associations. They are free-flowing and allow for maximum creativity.
Source: Jennifer Frith
What to Look for in Business Process Modeling Software
From all of the expert opinions and research, there does not appear to be one tool that will fit all of an organization’s forever needs. The major requirements that are recommended for a tool or a suite of tools are that they are fast (to learn) and inexpensive. The BPMN homepage lists 74 BPMN compliant tools. If BPMN compliance is a requirement, then the search is already narrowed. Otherwise, users should specify their objectives and requirements, which tools satisfy their requirements, what are the most significant criteria, and what the potential tools could be for use. Then, TEST. Finding the right tool may be a process, but it will not be a regrettable one.
According to Norbert Nogrady, Managing Director & Co-owner of JCM Ltd: firstname.lastname@example.org, Twitter: @kgordos
- Management appointed the IT department to find a tool for business process management (workflow) that fit the IT requirements.
- Management-level leaders with BPR engineers created their respective processes
- Process diagrams had been created using various tools.
- Processes were then transferred to the IT department, so that they could evaluate if the processes fit the workflow system of their choice.
- After a number of iterations – most usually resulting in compromises regarding the processes – the IT department started programming the processes into the workflow system.
- The processes were implemented in the organization, with the immediate need to re-engineer many of them.
- Points two through six have been repeated for a long time until a somewhat acceptable set of business processes were created.
As it is clear from the above, BPR this way was not easy, but instead very time and resource consuming. In addition, I realized very soon that departments should create their own processes, instead of iterating with IT; therefore, a number of process compromises could be avoided. In addition, it took a really long time to implement the created processes into the workflow system by programming. Both of these issues bothered me to the level that I started to look for a solution that fits the usual IT requirements and fully supports my BPR activities.”
After much trial and error Nogrady finally found a solution that worked for him. After his successful search, he suggests looking for a workflow system that has an integrated process and workflow editor tool with a graphic interface, hence making process programming obsolete. The advantage is that once a process has been created in the graphic workflow editor, it only takes a click of a button to have it run in the workflow system immediately. Therefore, all departments can create their own business processes, without the need for programming. Going this route means there are a little to no compromises in the workflows and most importantly, a lot of time and resources could be spared this way. Finally, a good solution will make testing the processes take much less time and effort. In this manner, if a process could use some improvement, anyone in the department can have their suggestions, and if the department leader approved it, the modified process should be able to run in the workflow system in a couple hours.
The Future of Business Process Modeling
One critical area of concern for the future of BP Modeling includes how modeling approaches could be standardized. Many businesses are moving to a more Agile platform, and BP Modeling does not necessarily go hand-in-hand with Agile processes. A modeling approach may only be considered Agile for some types of processes, according to a recent study by Nancy Alexopoulou.
As Ian Gotts, Founder and CEO at Elements.cloud and columnist at Digital Business also notes, “There are big issues in the BP Modeling space. BPM, automation and workflow software vendors have hijacked BPM, so that the B in BPM has disappeared. Modeling has come to mean defining workflows by IT for IT. However, process visualization (business process modeling) is valuable for end users. They use the business process diagrams to agree on how work is done. That then gives the behind-the-scenes IT perspective. Nevertheless, trying to use the BPMN notation as a model for everyone is difficult to achieve; with so many symbols it looks convoluted, and business people are quickly dis-engaged and wondering why they are doing this.
Learn more about Business Process Modeling
Interested in learning more about BP Modeling and how to implement it at your company? The following are lists of resources for further reading that can help.
Books and eBooks
- Analysis, Automation & Adoption for #AwesomeAdmins - Free UPN software handbook
- A Pragmatic Guide to Business Process Modelling, by John Holt
- Essential Business Process Modeling, by Michael Havey
- Business Process Modeling, Simulation and Design, Second Edition, by Manuel Laguna and John Marklund
- Strategic Knowledge Mapping For Improved Policy and Strategic Planning, by Steven E. Wallis & Bernadette Wright.
- Strategic Knowledge Mapping: The Co-Creation of Useful Knowledge, by Steven E. Wallis & Bernadette Wright.
- A List of Free Business Process Modelling Software
- Comparison of Business Process Modeling Notation tools
- Market Guide for Enterprise Business Process Analysis - from Gartner
Other Types of Diagrams
How Smartsheet Can Help Improve Business Processes
Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change.
The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.
When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.