Tag: BPM

Business Process; A Thing of Beauty

Written by Suzanne Jane Maxted on March 3, 2009. Posted in Articles.

The English romantic poet John Keats wrote in the poem Ode on a Grecian Urn ‘”Beauty is truth, truth beauty,” – that is all/Ye know on earth, and all ye need to know.’ This article proposes that, by recognising and reflecting on how a business behaves, we can find, cultivate and hone its beauty by clearly seeing the culture and behaviour that will make that business uniquely successful in its chosen field.

The previous articles in this series looked at seeking out good by setting the scene using a business context model, and at finding the truth within a business by understanding what real things exist and are true at any time of the day, however the business behaves, using a business domain model. This article looks at why we model the dynamics of a business and its people.

Unless we can see how the business behaves, it is very hard to understand it. It is therefore important that we can encapsulate what the business does so that we can refine and streamline its behaviour, reduce unnecessary complexity and focus on purifying its business offering. As an analogy, an athlete will develop a process to maximise performance, eliminating all unnecessary activity. There may be a small measure of uniqueness in the process depending on the physical and mental nature and build of the particular athlete, but most athletes will follow a similar process for their sport.

There are two main camps nowadays when choosing a notation for modelling business process. I like to use the Unified Modelling Language (UML) because my business customers tell me that it is easy to pick up and read and because it covers all the types of business modelling that I require (dynamic and static). The Business Process Modelling Notation (BPMN) covers only business behaviour (both notations are owned and managed by the Object Management Group). In addition, many government bodies and industry groups such as the United Nations, the World Customs Organisation and the Telemanagement Forum set standards and industry patterns using the UML.

There is another faction – those who describe the business without a notation – the textual modellers who have the genuine concern that their business people will not like or understand the standard notation.

I have only ever experienced positive feedback on the notation, willingness and enthusiasm from the business and an immediate understanding of a few simple symbols, but, it is our job to create and communicate understanding, not the notation’s job. The notation is simply a language with a ‘dictionary’ and some ‘grammar’ rules. It is our job to ask all the right questions in the workshop (remembering we should always model with the business), to apply logic to a number of jumbled verbal descriptions of what is going on and to label each model element in a meaningful way in order to communicate the understanding reached. Otherwise the business will not understand the result! It is the combination of analytical skill and of the UML notation which won the following accolade. Recently during a domain modelling session (please see the article “The Importance of Business Domain Modelling“), a fellow business analyst, new to the UML, told me that he had looked down to think about something, then had looked back up at the whiteboard and exclaimed to himself how well the entire discussion had been recorded in a matter of seconds.

Most business analysts are familiar with modelling the business process at some level. If we can answer the question “what happens next?” then we are dealing with a dynamic view of the world, i.e. depicting the behaviour and activity of the business area of interest. For example, the following (simplified) UML activity model of an outdated UK government business process to do with the international trade of food, specifies the business activity requiring automated support.

Note that a business process always has a starting point, a finishing point and directions on where to go when there are several paths to choose from. These are three of the most frequent review comments I make. Apply rigour and logic! For instance, I can only trade goods if a certificate was issued. Also note that the activity swimlanes (Goods Trader and Certification above) can be derived from the business context model (please see the article “The Business Context Model: As Good as it Gets“) by reusing the actors and business services or areas of interest already identified. The most frequent review comment I make is about the words used to name an activity. Each element in any model must be labelled in a meaningful way. I often see activities labelled like this – “Do Administration” or worse “Enter Data”. These have no meaningful business goal and therefore we cannot hope for good understanding.

Incidentally, it is useful to model at a higher level as we learn about the business; the business use case model is an ideal way to model disjointed business processes that do not logically flow one to another. For example, in international trade, we might identify the processes that are important to our piece of work in the following way, perhaps including a description (in a good modelling tool of course) before we model each process. They should be named to express an important result of value to the business or a major goal. We could even use the strategic business objective as the business use case name.

A business use case is also a useful container for business policies, business rules and constraints which can later be inherited by any software specified.

While some people think that specifying software requirements is the only aim of a business analyst, my view is that this activity should be regarded as a possible end goal depending on the findings of analysing the business. While the focus of this series is on business analysis, I will diverge a little to help refocus our attention on the business when we do step further into software specification i.e. to specify structured functional software requirements as system use cases (because a use case describes a single interaction between a user and a system that meets a goal of the user). There is misunderstanding about why we have use cases. Briefly, a system use case exists to partially or wholly automate and support a business activity in a business process. Therefore, we should not invent use cases from thin air. They should be derived. I have just read an article giving guidance on how to choose whether to model use cases or business process. I claim that we cannot know which use cases we need without studying the business process they are there to support. Otherwise, it’s like administering medicine without knowing what’s wrong with the patient.

How do we derive use cases? By studying the current behaviour of the business and improving it to a more desired state and then by looking at which activities we can enhance and support further. Please reference the Capability Maturity Model Integration [CMMI] which is an open framework for business process improvement describing five levels of business maturity: Level One is otherwise known as the ‘Beast’, and we might nickname Level Five as ‘Beauty‘. This begs the question – how do we know when we have found a system use case? The answer is when the goals of the business process are understood. What I mean is that we must model goal focused activities and those goals, once recognised, will guide us in informatively naming those activities in Verb + Noun format. When we understand the goal we have a system use case – possibly with the same name. If we don’t understand the goal of an activity, then we must look closer, like we do when showing a bee on a flower to a child – what is the bee doing and why? It may be that the activity identified is too ‘big’ or too ‘small’ and we need to ask many more questions.

Only by deriving use cases from a good logically thought out business activity model can we be sure that our software requirements analysis will be fit for purpose. How else would we know? By writing down the wish list of our business people, hoping that everyone can remember exactly what they said in the requirements meetings so that the 300 pages of free text that resulted are not subject to an endless round of revision? In addition, praying that the statements made can act, in a timely manner, as an accurate specification that really does meet the subset of business goals and objectives assigned to the piece of work from the overall business strategy?

Many business process modellers like to model in ‘layers’ and I am often asked how many layers one should model and what level of detail is required at each level. Some industry standards also model in layers, such as the Telemanagement Forum’s eTOM business process model. My preference is not to layer the business process, because I want the model to be public and exposed, say on my business owner’s wall, and I want the model to be useful as a focus for meetings and discussions. This means that it must fit on one page if printed! I have often seen four walls completely covered by a single layer process, or layers upon layers of business process never used again after the model is “completed” – incidentally the model can never be completed in my book. It is really a judgement for each modeller to make depending on their piece of work, but I prefer a single layer with exceptions modelled on further pages so that I can keep the main process on one page (“main” = what happens most of the time with exception activities shown to indicate when something goes wrong). This may mean that I must keep the goal of each activity quite ‘big’.

Of course, the best businesses are never complacent, always proactively striving for enduring beauty: measuring and optimising business objectives and activities; and visualising the business economics (cost, revenue, benefits). Therefore a model of the business process can never be complete – it is a snapshot of an ever evolving set of activities.

With a smoother running process, we can focus our attention on what really counts – the value chain; designing and pricing products and services. It can be a painful realisation when we know we must actively go looking for inefficiencies in our daily business life. After all, beauty is pain, so the saying goes.

Fill-in-the-blanks: A Process / Content Framework

Written by Terry Longo on February 15, 2008. Posted in Articles. 1 Comment on Fill-in-the-blanks: A Process / Content Framework

If you’ve read the previous entries in this blog, you have seen that we’ve been building up to something, and this new entry will hopefully bring us to our first conceptual plateau, upon which there is much more to build.

What we’ve done so far is to reorient our view of requirements and the BABOK, by going from this (based on BABOK 1.6):

to this (based on IIBA guidance on BABOK 2.0 direction and the concepts from the three previous blog entries):

Following the previous blog entry about content vs. process, we are naturally led to the above structure which manifests that distinction and also provides a framework within which we can indicate the appropriate methods, tools, techniques, and standards for the corresponding process phase, within the corresponding language domain.

For example, in the Software Development x Elicitation cell, we would typically find UML, prototyping, consideration of legacy systems, etc.; while in the Enterprise e-Learning Infrastructure x Elicitation cell, we might find multimedia complexity requirements analysis, consideration of training data privacy laws, task analysis, etc.

This view brings up some interesting questions about

Ownership of the process itself (process design, continual improvement, and governance)
Whether this view contributes to or hinders senior management’s ability to obtain a dashboard view of the benefits, costs, and risks related to current requirements management efforts
The potential benefit to the enterprise as a whole should this view be adopted by managers and individual contributors involved in managing or meeting requirements

We’ll tackle one of those in the next entry. Meanwhile, I, and I am certain your colleagues, would love to hear your comments.

Enterprise Analysis: Process or Content?

Written by Terry Longo on January 31, 2008. Posted in Articles.

In earlier posts, I have been reasoning that the IIBA and BABOK are on their way to defining a generally applicable framework for requirements management best practices, and that the BABOK 2.0 will be the first significant manifestation of the distinction between process (the requirements life cycle) and content (the nature, or domain, of the requirements being managed).

Viewing the requirements management life cycle in that way, however, requires us to scrutinize the way in which Enterprise Analysis (EA), as currently defined in the BABOK, fits in:

EA is content because it is carried out specifically in the domain of business planning and business strategy.
EA is process as well, because it is a crucial first step in the requirements life cycle.

The question becomes: is there an EA-like step in the requirements life cycle within other domains? Let’s explore this question by considering another domain, that of enterprise e-learning infrastructure and delivery (there are many other domains we could choose as well). From the business strategy point of view, this is a tactical and operational aspect of the enterprise. But from the e-learning director’s point of view, there is, of course, strategy involved, addressing questions about workforce trends, globalization of the enterprise, the presence of electronic performance support practices, learning-related data privacy, and many others.

So the e-learning director must:

Create and maintain the e-learning architecture
Conduct feasibility studies of e-learning infrastructure and delivery solutions
Determine the scope of e-learning infrastructure and delivery projects
Authorize the initiation of those projects
Interface with the project team to manage the projects’ value, track benefits, manage change and risk, etc.

Hmmmm. Looks a lot like BABOK’s Chapter 2: Enterprise Analysis. Which is the point being made. “Enterprise” is the content. “Analysis” is the process. An e-learning director reading BABOK Chapter 2, while pretending the title was “E-Learning Infrastructure and Delivery Analysis” would get some great guidance.

Requirements Management: Process vs. Content

Written by Terry Longo on January 14, 2008. Posted in Articles. 1 Comment on Requirements Management: Process vs. Content

In my most recent entry, I suggested that the BABOK 2.0 introduces the separation of process (planning, elicitation, documentation, analysis, verification/validation) from content (software development, etc.). And if you read that entry, you know I am of the opinion that this is a smart move on the part of the IIBA and the BABOK committee and authoring community.
Why? To put it simply: everyone does requirements management! And the process framework that will be represented by BABOK 2.0 will be valuable in many different disciplines.

For example, consider the practice of Instructional Design (ID): it too defines an approach that includes:
• Gathering (needs assessment, task analysis, workplace assessment)
• Analysis • Documentation (Student Performance Objectives)
• Solution identification (delivery mode, material selection, etc.)
• Management of requirements through the content development process
• Verification/validation of the content (Kirkpatrick levels 2-4, Kolb learning cycle, psychometric analysis of related exams).

This is not to say that the BABOK would become the reference body for ID itself – that subject area is sufficiently covered. Viewing the ID process through the BABOK lens, however, further strengthens the fundamental notion of the separation of the requirement from the solution.

You may have noticed Enterprise Analysis has not been mentioned yet – I hope you stay tuned to read my thoughts on how that fits in…..

Meanwhile, I encourage you to share with me, and your fellow readers, your thoughts on this thread as it develops more fully over the next few entries.

Business Process Modelling or Life without Use Cases

Written by Maria Murphy on September 27, 2007. Posted in Articles.

I recently became involved in a project that has been ongoing for the last 18 months. In that time, a lot of documentation had been developed and over 80 use cases have been written. The problem is, that despite this activity, the system development has not progressed and the project is facing a fast approaching deadline. The team is now trying to develop requirements specifications, prototype and build-of-the system all at the same time. Big Challenge!

I am working in an agile environment where there is rapid change and the business needs are evolving, and this needs to be managed. As we know Requirements are never really complete until the project is finished, as the needs of the business will inevitably change over the life of the project’s development.

In this instance, the project manager does not like use cases and has decided that a process orientation modelling approach is required to meet the deadline. The approach is to develop business process maps from the user pathways, document the information flows, develop prototypes and then build the system. Use cases are “banned” and process mapping is the key focus for business analysis and the BA team.

As a BA, use cases have been the main way to capture functional requirements for a system, so at first I was a little perplexed. I thought to myself, “if we don’t have documented requirements specifications (via use cases or an alternate method), then how will the developers know what to build, how will the clients know we have the requirements right and what requirements will we test the system against?” Will process maps be enough?

Anyway, I started to map my processes and sub processes for the system. The rest of the BA team and I are working side-by-side with the information architects and developers and, as each process map is delivered, a prototype is built and shown to the client area. Sign off and development begins (all within a week!). It’s a hectic schedule but it seems to be working.

The business maps are slowly uncovering the business requirements and are a key communication tool for the project team and business area to discuss the “current” and “future state” requirements for the system. The process documentation is highlighting the inputs, outputs and document flows for the system and, importantly, the client understands this type of documentation and is therefore able to quickly sign-off on the processes. The project is now gaining some traction and we are progressing well along our time-lines, and meeting the deliverable for each stage of development.

When I discussed this Case Study with a colleague of mine, he commented that this points to an oft overlooked element for requirements- that of communication. The requirements specifications task is not just about documenting the requirements it is also about communicating them and, as business analysts, we need to be flexible around the vehicles we use to communicate. We should not push the communication vehicle we are comfortable with, rather we should ensure that the requirements are accurately communicated via a vehicle that our clients are comfortable with. This requires flexibility.

The real key to our success in navigating this agile environment has been teamwork and collaboration between the development, analyst and business teams. Without this interaction, between members, our project would not be progressing well. Communication is so important and as an agile analyst, I believe this capability is a core skill in an agile environment.

I must admit that when I look at the node map for the business processes and sub processes, it does look strangely like a use case “context diagram” and the documentation does indeed specify the functional requirements but as long as we don’t format these documents as “use cases”, the project manager is happy. For me, I guess these documents are not exactly use cases, however “a rose by any other name would smell as sweet.”

Adrian Marchis from Modern Analyst commented on my recent blog about Business Process Modelling and agreed that a “use case shows the steps (or process) that an actor employs in order to accomplish a goal” and, therefore, “process vs. use case is just a name”. He suggested that in reality the details of a use case can be documented as either a use case or as an activity diagram or process flow. He noted that although clients may like the process flow format for its visual properties, it does have one drawback and that is that process flows may not offer the same level of detail found when using use case specifications.

Business process modelling may be a different take on documentation of system requirements for the team, but the client area is happy and, so far, the developers are comfortable with the level of requirements specifications contained in the process maps and associated documentation.

Maria Murphy is a business manager and information and communications specialist. She has over 10 years senior management experience within the medical/pharmaceutical industry, not-for-profit organisations and government. She has a reputation for innovation, managing change, driving strategy implementation and successfully delivering programs. She has extensive experience in the management of large federal government contracts, project management of large scale ICT business system reviews, development of requirements, systems planning and change management. Maria is currently a consultant with SMS Management and Technology. She is the Regional Lead for a Business Analysis at SMS and provides advice to her colleagues on developing requirements specifications for appropriate IT systems to support clients’ programs and initiatives.

Maria is on the Board of WIC (Women in Information and Communication), is a member of the International Institute of Business Analysis (IIBA), Australian Institute of Company Directors (AICD), The Australian Computer Society (ACS) and The Australian Business Analysis Association (ABAA). She can be reached at [email protected]