One of the most important elements of every Business Analyst’s toolkit is process modeling, which is also significant activity for Business Process Management professionals.
For BPM market BPMN is now the standard for modeling processes. But is it also the case for BA’s?
To find out what are the best practices, I asked some of the best BA and BPMN experts in the world a simple question:
“Why, when and how should business analysts use BPMN?”
I got 19 responses from the experts and their answers are awesome.
The post is pretty long, so I have added navigation to make your life easier:
Abidemi Stephanie Famuyide
Now, let’s dive into the answers.
Jonathan Babcock is a Senior Manager at Jabian Consulting, an Atlanta based management and IT consultancy. His areas of expertise include business analysis, process optimization, and solution delivery methodology.
Prior to joining Jabian, Jonathan worked in several different solution delivery roles in both Fortune 500 wholesale and retail distribution company, and a “Big 4” consulting company.
His passions include helping organizations to improve their solution delivery capabilities, and individuals to reach the next step in their personal progression.
From a business analyst’s perspective, creating visual process models, whether in basic flowchart form or a formalized notation such as BPMN, is valuable in helping to contextualize and visualize a process so stakeholders – both business and technical – can refine and understand it together.
Generally, I use basic flowcharts to capture process flows because my audience is more familiar with them and there is less of a learning curve.
However, in environments where process automation capabilities are leveraged, the value of BPMN increases significantly, as it enables stakeholders not only to understand the process together, but, with relatively little technical effort, to simulate and test proposed process flows to validate rules and results and troubleshoot before actual coding takes place, resulting in a more reliable finished product.
Joy Beatty is a Vice President at Seilevel, a professional services company whose mission is to define software that customers love to use. The Seilevel team provides business analyst and product management services for F1000 companies across the US. They also help companies modify their approach to software requirements to be more effective, so IT projects deliver their intended business value. Joy implements new methodologies and best practices that improve requirements elicitation and modeling. She advises customers as they build business analysis centers of excellence. Joy has provided training to thousands of business analysts and is CBAP and PMI-PBA certified.
She co-authored Visual Models for Software Requirements, with Anthony Chen from Seilevel, and Software Requirements, 3rd Edition with famed Karl Wiegers.
BPMN is a very powerful modeling language for modeling very complex business processes; and with that, it is often too powerful for most of what a BA does. So when I teach BAs to model business processes, I point them to a process model that uses simpler syntax. Arguably, it’s really just a subset of BPMN’s syntax, so maybe they are still using BPMN at some level. I think it’s important for BAs to understand the basics about how and when to model business processes, and a select few will benefit from learning the full richness of BPMN.
There are a variety of scenarios when a BA should use a business process model:
1. Working with business stakeholders to understand or describe how they do their job – they are such an easy model for business stakeholders to understand (and sometimes create), so it’s my go-to choice for that type of work.
2. Showing the sequence of when things happen – many models show relationships between pieces of information, but process flows are the best way to show the order that things need to occur.
3. Showing the current state (as-is) and future state (to-be) of the business process – this would be impossible to do well in words, so we suggest you create the as-is, then update it in a new copy for the to-be flow.
4. Showing the order in which systems interactions occur – this is a variant of a business process called a system flow, where the swimlanes are actually systems instead of people and the steps are steps within systems.
Teresa has 20 years of experience working in IT as a business analyst and software tester. She started The Analyst Coach, LLC in 2010 with the goal to help individuals and businesses increase IT project success through effective business analysis. Teresa’s organization is an IIBA endorsed Education Provider and has provided training for hundreds of business analyst employees, consultants, and contractors.
The Analyst Coach also provides analysis training to IT sales teams and BA informational training to staffing firm recruiters. Teresa can be reached at Teresa@theanalystcoach.net or 1-866-968-6657.
If you are going to do define how processes should be executed, then BPMN is a great way to do that. Because BPMN is a standard for doing just that, if you are consistent in using BPMN, your stakeholders will have a better understanding of the diagrams you produce.
Just like anything else, if you aren’t consistent, the stakeholders will have difficulties understanding and may blame BPMN for those issues when in fact it’s the preparer of the diagrams that’s to blame for the confusion.
I have heard complaints that BPMN is complex and hard to understand, but if you use the following criteria it will go a long way in alleviating some of that complexity:
1. Limit the number of symbols you use
2. Review your diagrams with stakeholders instead of just sending it to them to review on their own
3. Include a legend that explains the symbols
Your goal should never be to use as many different symbols as you can. You are not trying to show your BPMN prowess, your goal is to show (in the simplest way possible using the right symbols to help the stakeholders have a clear visual representation of what is happening) how a process should be executed.
Do not send the diagrams to them electronically and tell them to just let you know if they have questions. Walk them through it; help ensure they understand the diagrams.
Including a legend at the bottom of your diagram will help explain the symbols and the meaning behind them.
Just like any other new standard, process, tool, etc., BPMN may seem overwhelming in the beginning but if you’ll keep these things in mind you’ll find that it can be very beneficial to your projects.
Steve Blais, PMP, has over 43 years’ experience in business analysis, project management, and software development. He provides consulting services to companies developing business analysis processes. He is on the committee for the IIBA’s BABOK Guide 3.0. He is the author of Business Analysis: Best Practices for Success.
BPMN is an excellent diagramming tool for business analysts to use to model the problem domain. Because of its emphasis on the business processes rather than the computer systems the notation helps the business analyst integrate the computer based technical solution with the overall business processes, something that is often forgotten in the rush to develop the software. Documenting the business processes feeding the computer system being changed and consuming the results of the computer system helps the business stakeholders and the solution team understand the context in which the computer system works, and better understand the scope of the business problem being solved.
With 14+ years experience in the Business Analyst role with several companies, Brad Botz is the creator of the Business Analyst Academy – businessanalystacademy.com.
He has been known to, occasionally, write articles for ModernAnalyst.com
In my opinion, the decision to use BPMN is a fairly easy choice. It is a well established modeling technique with strong tool support. BPMN is fairly easy to learn with tons of information available in books or online.
A business analyst should consider using BPMN anytime there isn’t an existing process modeling notation or models are needed that are more descriptive and technically accurate (As opposed to simple Visio models, for example). I find BPMN specifically beneficial when transitioning a process from physical (paper, forms, etc…) to a more automated solution (web, app, etc…).
The BA should keep in mind that end users may not easily understand BPMN without some education, which may not be an option. However, more technical people, used to modeling in general, will likely appreciate BPMN as being more descriptive of the actual process.
Laura Brandenburg, CBAP is an internationally recognized leader known for helping mid-career professionals start business analysis careers. Laura brings more than a decade of experience as a full-time business analyst, consultant, and hiring manager to help you find transferable business analysis skills, expand your business analysis experience, and start your business analysis career with confidence. Find her at www.bridging-the-gap.com.
In my experience, there are only 3 good reasons for using BPMN notation.
1. You find yourself stuck using the handful of most commonly used workflow diagram elements to represent a concept.
2. Your organization requires you to use it.
3. You are applying for a job you are otherwise qualified for that requires knowledge of or experience with BPMN notation.
Excerpt from “3 (and only 3) Reasons to Use BPMN (Business Process Modeling Notation)” quoted by permission of Laura Brandenburg. Read the full article on: http://www.bridging-the-gap.com/bpmn-business-process-modeling-notation/
Jump to the top
Kathy Claycomb brings nearly 20 years of IT experience to the classroom. She has participated in all phases of application development across a wide variety of platforms, and has used numerous methodologies to analyze, design and implement systems. Kathy holds a Bachelor of Science in Business and has worked in transportation, training, and software development organizations.
Kathy’s first love is teaching, and throughout her career she has always managed to spend a portion of her time instructing. She has an engaging, highly interactive teaching style that ensures students leave the course with a thorough grasp of the material. Her students consistently praise her teaching abilities and her talent for drawing on her personal experience to enhance their learning.
* BPMN is more business-friendly than ANSI or other flowchart notations
* Additional symbols in BPMN allow things like time-related events, looping or repeating processes, and information exchanges to be shown easily.
* BPMN is particularly good at representing conditional activities. It has several styles of “gateways” that are not available in other notation standards.
* As with flowcharts in general, BPMN can be used at many points in the project lifecycle. Early on, it can be used to understand your As-Is state. As the project progresses, a To-Be model can be developed.
* Early models will likely be high-level views of the process. Later models will typically have an increasing level of detail.
* BPMN and other flowcharts are used when it’s important to understand the steps that are necessary to accomplish something, the order in which those steps need to be done, and who is responsible for doing the work.
* BPMN is designed to be developed in “levels” or “layers”. Ideally, each “level” fits on a page and contains no more than about 10-15 process steps. You can then drill down into additional details as needed.
* A good rule of thumb for when you’ve got enough detail: Stop when everyone in your intended audience understands the process step without additional elaboration.
* The “process pool” and “external lane” concepts in BPMN encourage modelers to focus on the portions of a process that are in scope. Steps that are outside the scope of the current project are typically not shown.
* There are many tools available for developing BPMN models, ranging from stencils in drawing programs like Visio to specialized BPMN tools that are designed to support code generation.
* Unless you are using a specialized tool designed to generate code, worry less about the details of the notation standard and more about capturing the process in a way that the business will understand. With BPMN, it’s easy to get distracted by things like the style of border that goes around an event, or whether an envelope should be black or white.
Alexandra Cordes is the author and founder of The Business Analyst’s Toolkit and an ICT Business Analyst with over fifteen years of experience in a diverse range of business domains. Alexandra’s biggest driver as a business analyst is to deliver results that are highly attuned to the unique nature of each business problem and are correctly aligned with business strategy.
BPMN (Business Process Model and Notation) is a standard notation for business process modelling. BPMN specifies an agreed set of symbols for process modelling. This has a major advantage as it creates a consistent way to compare models and communicate with various stakeholders across an organisation.
Unlike unstructured approaches to documenting processes, BPMN provides a number of elements that you can use to model more complex business process patterns – consistently. This allows you to produce detailed requirements, which improves the level of information available to solve problems and explore options for identifying a solution.
Like any model or document that you produce, delivering value to your audience is the key. How you deliver that value occurs through a variety of mechanisms, but it includes your models. Your primary aim as a business analyst is to communicate clearly and accurately to your intended audience.
You can produce models following the BPMN specification to the letter. However, if your stakeholders cannot interpret and visualise the process or solution you’re describing, your models are ineffective. They will contain significantly less value than the models that don’t follow good practice but successfully expresses the intended message.
In effect, your models must clearly communicate to your audience.
I use BPMN in my daily work because it provides me with a consistent way to model and communicate with my stakeholders. However, I try not to get carried away with elitism in any of my business analysis techniques as – most of the time – it doesn’t serve my audience. It’s about striking that balance between producing good models using BPMN, and expressing requirements to my stakeholders in a language that they can understand.
Abidemi Stephanie Famuyide
Abidemi Stephanie Famuyide, CBAP specializes in business process management, requirements management, designing systems suited to users’ requirements and IT Project Management.
Her experience cuts across project management, database analysis, user support, business analysis and business process management. She holds a distinction in Analysis, Design & Management of Information Systems (Now known as MSc Management, Information Systems and Innovation) from the London School of Economics and Political Science.
In our team, we use BPMN to:
1. Standardise how processes are represented. Even though these diagrams are not currently created with the intention of executing them directly in a BPMN Engine (An executable process model can be implemented directly by a process engine), the day the company decides to make a move in that direction, we won’t have to start from scratch. Our process diagrams are however, tightly integrated with requirements specification and form the basis for the technical design of business applications. Workflow notations are necessary to indicate the sequence of process steps (BPMN is only one example).
2. Convey meaning. The latest version, BPMN 2.0.2, provides 100+ different symbols. I have never had difficulty finding the right modelling notation to use for conveying the right meaning of process flows.
3. Model to an increased and more accurate level of precision, e.g. displaying different types of events.
Excerpt from “Why Should Business Analysts Use BPMN?” quoted by permission of Stephanie Famuyide. Read the full article on: http://businessanalystlearnings.com/blog/2015/9/25/why-should-business-analysts-use-bpmn
Jump to the top
Jakob Freund is a co-CEO of Camunda, author of ‘Real-Life BPMN’ and a regular speaker at conferences such as bpmNEXT. He is in the BPM space for more than 10 years now. Jakob’s absolute passion is the big picture of scaling up business models by well-defined and automated business processes, using BPMN as the common language for Business and IT.
BPMN is the right tool if you want to describe business processes that have a certain amount of predictability (or should become more predictable as a result of your process improvement project). If you really know BPMN, you can create process diagrams that are easy to read and directly executable in a BPMN process engine. That is not a wish or promise, but reality.
However, BPMN is not the best way to go if we are looking at less structured activities, also known as cases. If it’s about case management, look at standards like CMMN. Again, you can model and execute your activities, and you can combine those models with BPMN models in order to implement a business process in an end-to-end fashion.
Finally, keep in mind that business rules should not be reflected as a combination of BPMN gateways and conditional flows. That’s what decision tables are for. Yet again, they can be maintained by business analysts, and executed by an engine – a decision engine, that is compliant with the DMN standard.
All three standards are from OMG, and combining them makes obviously a lot of sense.
Doug Goldberg is a Senior Business Analyst in the Dallas, TX, USA market. He has 15 years experience as an analyst in application development for financial, health care and technology companies. He has also programmed Java/J2EE for a period of time.
Additionally, Doug is an avid business analyst mentor both online and in-person, a facilitator for CBAP study groups, an active guest blogger, and the current VP of Professional Development for the Dallas Chapter of the IIBA.
I find that BPMN is a powerful visual modeling tool and concise language to convey structured concepts. It provides a consistent understood approach to documenting.
Like anything else, though, the practitioner must be mindful of the intended audience. While the value of BPMN is high, it’s utilization with an audience not prepared to understand the notation will result in lost work effort. This is unfortunately a very common occurrence as teams seek to work in rapid fashion with less focus on documentation and traditional methods of delivery.
Don Hussey serves as Managing Director for Seventh Morning, a leading provider of business analysis training and advisory services.
Prior to founding Seventh Morning, Mr. Hussey was Senior Vice President of Global Internet Strategy for a global financial institution. In this role, he drove online strategy for the private bank, oversaw all business analysis and project management for the bank’s online channel, and overhauled the way these functions were run.
Before this role, Mr. Hussey was a star Project Manager/Business Analyst with a top investment bank. Earlier in his career, Mr. Hussey held various roles in sales and sales management, client service, operations, and technology. He currently resides in Washington, DC.
BPMN is often the best modeling notation for business processes, simply put. It provides more rigor and insight than simple flow charts. It is more understandable (to non-techies) than UML Activity diagrams and better suited to process analysis and design. Also, if you’re going to be working with Business Process Modeling software packages, they tend to favor BPMN over the other notations.
All Business Analysts should be conversant in BPMN. I recommend analysts use BPMN whenever they’re working on projects that deal with processes of intermediate complexity or higher. There are some circumstances when BPMN isn’t suitable, however. If your audience is primarily technical, UML is a medium they already have depth in. On the opposite end of the spectrum, if your audience is model-phobic, simple high-level flow charts will be better suited.
Others will speak to BPMN mechanics in depth, but my best advice is that you use it often. Invest a couple hours up front in understanding the basics, and then create models for every process you come across. You’ll quickly become an expert.
Paul Mulvey is a sought-after business analyst, instructor, coach, CBAP with 20+ years of analysis experience.
Often-requested instructor and presenter, able to engage audience and students in order to transform a company’s business analysis discipline. Transforms by understanding root cause and business pain points and providing cost-effective solutions to address them. Business Domains include CRM, Sales, Pricing, Revenue Management, Logistics, and Management. In addition to authoring “Business Analysis for Dummies“, volunteers with industry organizations such as Greater Atlanta Chapter of IIBA, BABOK V3 writing committee, as well as treasurer of the West Forsyth Band Boosters
Two quick advantages come to mind when asked this question:
1. BPMN is built as a top-down modeling approach, so the deeper into the weeds you get in the process, the deeper you can model it. The advantage is this is the use of partitions (or “swimlanes”) to show exactly who or what is performing the process. With the assignment of roles or systems to each lane, your audience can quickly see the party performing the work. I have even taken this swimlane model down to the level or individual modules in a system performing the tasks.
2. The second big advantage is the use of the data icon. Business Analysts can use this to quickly note where a task requires data, and what kind of data. It doesn’t need to be completely detailed out to the individual data elements or data types in the model, but only to the extent to show data is required for a decision. For example, an approval process for a vacation request often requires knowledge of the employee’s vacation history and available vacation days. Seeing these data icons in the model is a great reminder to talk about all the information the process needs.
Alex Papworth is the founder of Business Analyst Mentor. He is a business analyst who has worked in IT for over twenty years and a former President of IIBA UK.
Alex is passionate about the BA community and their collective power – this is why he has built BA Mentor to tap into this network with the specific goal of accelerating the professional development of ALL BA’s.
Business analysts should use BPMN because process models are the simplest, most effective and widely accepted form of visualising requirements. They should use BPMN as it is a widely recognised standard that ensures consistency (other standards are available!).
BPMN can be used throughout the business analysis effort from the outset when we tend to work at a high level, conceptual view through to the end when detail becomes paramount. It is most valuable at the detailed stage when precision is critical. At the conceptual stage, it is often more useful to produce a simplified linear process where it is more important that it is easy to understand.
BPMN models would be produced before, during and after requirements workshops or interviews. In the early stages, the workshops would be designed to produce a draft model. Later workshops would review and modify the BPMN models until they are ultimately approved.
Obviously these meetings should also produce the usual artefacts such as requirement documents (or user stories) and should use other supporting models such as prototypes.
Tobias Rausch is the Product Manager at BOC Group for the ADONIS Business Process Management Toolkit as part of BOC’s Management Office suite. Previously Tobias has been working for the BOC offices in Austria and Ireland and his role as a Senior Consultant offered him the opportunity to manage and be part of (large-scale) projects in different industries. His main fields of expertise are in introducing and implementing BPM in organisations, approaches for process-driven requirements definition and software development and in risk management scenarios.
He co-authored the chapter “BPMN for Business Professionals: Making BPMN 2.0 Fit for Full Business Use” in “BPMN 2.0 Handbook Second Edition“.
Addressing the “Why”, and knowing that one should not answer a question with another question, I’ll do it nevertheless by saying “Why not?” In plain and at its very heart BPMN is just a modelling notation and therefore a valid mean for process modelling and flow charting (like any other notation).
There are some obvious advantages for doing so, such as that many students will have learned BPMN at university, publicly available literature and courses and there some aspects of the model and notation you might find helpful in your BPM projects.
The “When” is probably the most difficult part to answer. On the one hand there is an obvious benefit using BPMN for projects with a clear goal to “execute” the processes within process execution / workflow engines. That is where BPMN is coming from and the main focus of the BPMN specification. Often business analysts will be involved in such projects to reflect the business’ needs, but in general the processes will be quite technical and designed by IT (and not readable for persons from the business).
On the other hand BPMN can be used for simple flow charting with a reduced set of classes. “Pure” BPMN however will not address any requirements a business analyst and business people will have going beyond the simple “flow charting exercise”, as it does not contain any concepts needed for proper documentation of business, quality, risk and further typical BPM and/or IMS (Integrated Management System) scenarios.
This leads us to the “How”: naturally this can have many flavors, but I’d like to recommend what I have seen important to make it work practically: Firstly select what you really need from the BPMN notation for use with business people (both in terms of designers/contributors and end consumers) and then use it consistently. Typically you will see that many concepts provided in BPMN will not be needed for business process modelling (attached events, 85% of activity and event markers, complex Gateways …). In our tools we address this by offering pre-defined “BPMN light” modes for users. Secondly use an approach where BPMN is not an isolated method for flow charting, but integrated into the BPMS and extended with concepts for business users and analysts. We have called this making “BPMN fit for business” (more info on this approach can be found in the BPMN Handbook).
Finally using BPMN should be supported by a tool not only to support modelling and manage the information and changes efficiently, but the right tool will also provide support in syntax checks, model validation, translation, governance, business analysis and publication to end consumers.
So: Why not now, with a consistent approach, necessary extension for business and supported by the right tool!
Adrian Reed is a true advocate of the analysis profession. In his day job, he acts as Principal Consultant and Director at Blackmetric Business Solutions where he provides business analysis consultancy and training solutions to a range of clients in varying industries. Adrian is President of the UK chapter of the IIBA and he speaks internationally on topics relating to business analysis and business change. You can read Adrian’s blog at http://www.adrianreed.co.uk and follow him on Twitter at http://twitter.com/UKAdrianReed.
This is an interesting question! Taking a step back, as business analysts we should of course focus on the problem being solved, rather than jumping straight to the solution. This is a tension that we manage on every project that we work with. We should take the same considered approach to the techniques we use. Rather than asking “Why, when and how should we use BPMN” we should instead ask “What is the best tool for this particular situation, context and stakeholder community on this project”. It is very easy to immediately revert to a ‘favourite’ technique — which is something I am sure we are all guilty of!
Having said this, there is no doubt that BPMN is a useful standard. One of the core benefits, I believe, that BPMN and other structured modelling techniques provide, is the ability to use a common notation. This ensures that everyone–from our users, to our sponsors, to our developers, have a common view of the problem. Of course, we may choose to ‘abstract away’ detail when giving a high-level view to our sponsor, but the beauty of a model is that the detail is still there if they need it. In fact, creating different views of our models is crucial–else we will end up drowning people in the detail. So, if we find ourselves in an environment where it is necessary to communicate very precise nuances of a process accurately, BPMN would be a good candidate. Particularly if the stakeholders have an existing understanding of the notation, or if there is time to bring them up to speed.
The beauty of the BA profession is that we have a whole range of tools available to us. BPMN and process modelling more generally are very useful tools to have in our tool-box.
David Saboe is an accomplished leader and Agile Coach with extensive experience in business analysis, project leadership, operations management, and business transformation within the financial services industry. Over 15 years experience in leading technical and process reengineering projects from concept to closure while managing geographically diverse teams for Fortune 500 and Global 100 companies.
David is on a mission to elevate the role of the business analyst, which he does through his podcast, Mastering Business Analysis. He helps business analysts and agile teams achieve their full potential.
Whenever I’m asked why or when to use a technique, I reflect on the expected outcome. Using an approach such as Business Process Model and Notation (BPMN) certainly results in output (the process model/diagram), but what value is the organization expecting to achieve from that output versus another approach such as flowcharts?
If the expected outcome is to create a shared understanding of the process, the extensive graphical notation used in the BPMN standard is far from intuitive for most business stakeholders. If we use only a subset of the notation, why not use another technique? BPMN usually falls short if your goal is to create a shared understanding unless your stakeholders fully comprehend the full notation.
Even if the organizational standard is BPMN and your diagram is expected to be combined with other process models, think about the expected outcome and whether or not BPMN is the best technique to meet that outcome.
When does using BPMN result in a valuable outcome? BPMN has the greatest value if you will use the model to run simulations – either of the current process to identify inefficiencies or resource needs or to perform “what if” analysis of process changes. If you use a tool that allows you to import and create models using BPMN and run simulations to learn what works in a safe environment, that’s an outcome that (potentially) using BPMN can achieve. Some tools even allow you to build executable applications from BPMN diagrams.
The best use case for spending time using BPMN is if you want to run simulations or build working software from your BPMN diagram.
Bruce Silver is an independent industry analyst and consultant focused on business process management, also founder and principal of BPMessentials.com, the leading provider of BPM training and certification.
In 2009 Bruce got involved with drafting the BPMN 2.0 specification in OMG, and wrote a book, BPMN Method & Style, which is now in second edition. Together with Nathaniel Palmer he hosts an exciting annual event, bpmNEXT, focused on the next generation of BPM-related technology.
BA’s should learn BPMN because, unlike traditional flowcharts, the meaning of the process logic is independent of the tool used to create it and the modeler’s private conventions.
That means BPMN diagrams communicate to those beyond the modeler’s immediate project team members. BA’s and developers are not forced to use the same tool… a huge benefit on its own. The same modeling language communicates both to business and technical users. But these benefits have a price: while BPMN adopts the basic look of flowcharts, to use it you need to learn the semantics and rules. And to use it most effectively you also need to learn additional rules – like Method and Style – that ensure that the meaning is clear from the printed diagrams.
If you try to learn it from the spec (don’t try it!) or a “dictionary” of the shapes and symbols, it would seem too complicated. But trying to learn English by reading the OED would lead to the same conclusion.
When BA’s (and more importantly, process improvement consultants) say “BPMN is too complicated,” they are really saying the following:
* “I’ve been doing flowcharting for 25 years and I don’t want to learn anything new.”
* “I don’t like using software tools; I want to keep putting stickies on the whiteboard.”
* “I am happy to capture process details in a long text document that nobody reads. For me, the process diagram is just a sketch to give a hint of that detail.” Translation: “I don’t believe in model-driven requirements.”
Emrah Yayici contributes to IIBA® (International Institute of Business Analysis) as a chapter president. He is the author of the best-selling Business Analysis Methodology Book, Business Analyst’s Mentor Book, and UX Design and Usability Mentor Book.
He is one of the managing partners of UXservices, BA-Works and Keytorc. He started his career as a technology and management consultant at Arthur Andersen and Accenture. Afterward he led global enterprise transformation projects at Beko-Grundig Electronics.
During his career he has managed multinational and cross-functional project teams in banking, insurance, telecommunications, media, consumer electronics, IT industries, and startups.
He also contributed to UXPA (User Experience Professionals Association) as a member and ISTQB® (International Software Testing Board) as a former international board member. He is now sharing his experience about business analysis, business development, entrepreneurship, product development, customer experience design, UX design, usability, and quality assurance by publishing articles and books, leading training sessions, and speaking at conferences.
“What appear to us as motions of the sun arise not from its motion but from the motion of the earth and our sphere, with which we revolve about the sun like any other planet.” – Copernicus.
After the acceptance of Copernicus’s theory, people perceived the sun as the center of the planets in the solar system. This was a paradigm shift in the mindset of human beings who used to envision the earth as the center of the universe throughout history.
In recent years a similar change has also occurred in IT business.
Previously the legacy systems at companies didn’t have an open architecture. It was not easy to update them or add new components. Although these systems were highly reliable, they allowed limited changes. Most of the business unit requests could not be fulfilled due to technical constraints. As a result business was mostly driven by IT.
However, due to fierce competition and dynamic business environments in every industry, business units focused on differentiating their products and services by fully benefiting from technology. They became more demanding of IT departments. This fact increased the need for more flexible IT systems, which led to the advent of new software development approaches like object-oriented programming and SOA (service-oriented architectures). Software started to be developed with an open architecture of integrated components. This new way of software development brought more flexibility to IT systems, which meant more tolerance to fulfill business requests.
In this new approach, the most important success factor became achieving seamless orchestration of integrated system components. This required utilization of modeling techniques like BPMN as a major part of the software analysis and design profession. This factor increased the strategic importance of business and system analysis in parallel.
- BPMN is getting more and more popular
- It gives you a standard way of communication between e.g. business and IT users that ensures consistency (as opposed to e.g. flowcharts)
- As with every tool you should think whether it fits your purpose. In this case – does your way of modeling work with the intended audience.
- Don’t get discouraged by the number of available symbols. In practice you will need only rather small subset unless you plan to automate your processes.
8 Comments for “BPMN for Business Analysts – why, when and how”
BPMN for Business Analysts – best practices from 19 experts | Business Process Management – Software, Methods and Practical Tipssays:
[…] Read more on bpmtips.com […]
We do use BPMN here, however, our business clients seem to like Event Process Chain Diagrams (EPCs) done in ARIS much better. They are easier to read, and the color boxes provide visual cues that BPMN doesn’t do as well. I find large, complex BPMN diagrams very hard to follow – they tend to look like spaghetti. However, I do agree that using a small subset of symbols is better, and it keeps the models simpler and more consumable.
karl walter keirsteadsays:
It would be interesting to know what percentage of BPM processes are documented/built by Business Analysts.
Surely not existing processes (you might as well interview the process owners)?
It’s probably for new processes that do not yet exist and therefore have no process owners (at least yet).
It follows BAs should be able to use whatever notation/languages they like.
But, once they have mapped their process, the acceptance criteria should be 1) that the map can be compiled with one click and rolled out to a run-time environment AND 2) automatically converted to some flowgraph environment that process owners can master for improvement and maintenance purposes, otherwise the BAs have their customers on a slippery slope.
End user’s don’t want to be in the position they are with lawyers where you have to go to the lawyer to write up an agreement and then each time you need to read it you have to go back to the lawyer.
Thanks for good article.
Can you explain on how you’re able to use same BPMN process model by BA to capture business needs and mapping to IT systems and their interfaces?
This is a good question 🙂 If your model does not need to be discussed with less technical users you can use the features of showing and hiding certain aspects of the model content depending on the selected view (feature present e.g. in ADONIS:Community Edition). But very often models created with business users need to be extended in order to make them executable, so you have two models.
Good article thanks. I am facing a problem to model a business process where is it very important what happens in a specific period in time, the first part of the process happens in the first year, the second part in 3 moths of the second year etc. I cannot find any good example explaining how to represent this situation. Can you or any of your guests help me with some explanation?
karl walter keirsteadsays:
Short of using Critical Path Method, you can build a BPM process where you have a particular sequence (what has to be completed in the 1st year) and you will see a countdown to the last step in that sequence.
Followed by a “must start by” that is 12 months from the start of your 1st year sequence (in case you finish early on the year 1 sequence).
As for making sure the year 2 sequence takes no longer than 3 months once it starts, same protocol (i.e. an end step alarm at 3 months).
I prefer EPC models to BPMN unless the goal is create code through instantiation. They have more visual clues, and look less like spaghetti when they get complicated. For BPMN, I agree that using a subset of the symbols (keep it simple), and taking time to review the models with the client is of utmost importance. Remember, if the model isn’t useable by the business or client, then it was a waste of time.