A well-conducted business analysis is the first step to successful completion of the project. How to make the entire process understandable? In my daily work I use UML and BPMN diagrams for this purpose. Diagrams in business process modelling are more often used by business users as well. In today’s article, we will see how to design the process. This will help us find the answer to a seemingly simple question: “What is the point of the project?”
What is the point of the project?
When creating an analysis for a project, it is necessary to describe in one place, in a clear, legible and unambiguous way, what the project’s goal is. Theoretically, there’s nothing simpler – the scope of the project and the list of desirable functionalities have been determined during a series of business workshops. We have notes from meetings, photographic documentation of flipchart descriptions… It seems that all we need to do is to put everything together and send the document to the client for approval. But suddenly, while reading the document, it turns out that everyone had a different understanding of the meeting. This is because everyone attends the meeting with their own specific goal and focuses on achieving it. A tight project schedule usually does not allow enough time for assumptions to be turned upside down, a team of developers is waiting ready to start programming and you need to make decisions. How to avoid such situations in the project?
It very often turns out – not only in IT projects – that it is necessary to take a number of factors into consideration while making decisions. There are an increasing number of questions like: “Should I choose this direction or go in another direction?” or “What if…?” In addition, the greater the time pressure, the higher the risk that we will omit key information. In such situations, methods based on decision trees, which are also used successfully by business users, are helpful. When it comes to business processes, UML and BPMN diagrams, used by business analysts on a daily basis, allow us to specify the process flow and its results in particular cases. This way, it is possible to create a few versions of the process and thereby show various process flow possibilities.
Specifying if the result of the proposed process fulfills the business need after implementation.
Using optimal solutions.
Avoiding technical debt.
Why is it worth taking advantage of the assistance of a business analyst? I often explain it this way: we do not start building a home unless we have a project. This is the same as creating an information system without thinking about what it’s really going to be for. This is probably the essence of a business analyst’s work.
Approaches to conducting analysis are different depending on the organization. However, there is a set of good practices that will work in any company. I have not yet come across a case in which it would be standard to use all diagrams. A good practice in implementing projects is to set conventions and documentation standards. The most desirable way is going from user requirements to the scope of implementation within a particular system (or several systems, system modules); i.e. for the internal systems of a given company, the following path can be used:
business requirements >> system requirements >> use cases with scenario description
Use cases are great for determining the scope of the project. They also allow you to specify functionalities (and share responsibilities) between individual departments or teams. The diagram below shows the scope of the system: “Data transfer in .xml format”, and the creation of a statement of fees. There is also information on which department uses a given function that is outside the system and how responsibilities are divided. In the case of large systems, here we can indicate business departments which have reported functional requirements (meaning they are our stakeholders). Finally, after writing the software for functionality, users of this department will be able to accept the task.
For systems where the end-customer is external, we can refer to the designed screens:
business requirements >> user screens >> business processes >> sequence diagrams
In this case, the role of the analyst is to focus on how to properly (consistently, unambiguously and legibly) translate the business requirements and screens which have been drawn up into actions to be undertaken in the system. Business Process Modelling Notation (BPMN) is my favourite tool at this stage of the project. I use it to draw and describe the process as follows:
conditions for entering the process,
range of data displayed on individual screens,
all branches of the process.
Such a diagram helps to illustrate the entire process flow. I use it during workshops with business representatives in order to confirm requirements. Understanding the process on the basis of a diagram does not require knowledge of methodology and is highly intuitive. According to the methodology:
rectangles are actions performed in the system or at the user’s request,
rhombuses are processes branching into separate flows,
circles are events that affect the process (e.g. different types of errors).
We can see that something is happening in terms of the rectangles. The rhombuses separate the two arrows, and I start and finish process modelling with circles. Thanks to this diagram, you can see not only the positive path of the process, but also moments at which an error may occur (e.g. while systems communicate).
Sample process below:
The process of purchasing online
Intuitive readability and lack of details is both an advantage and a disadvantage of this diagram, because it does not give any specific information.
Once the business process is determined, we meet with analysts or developers to specify the details. In most cases during projects we do not build a system from scratch, but add new functionalities that should be adjusted to the existing system logic. A sequence diagram is helpful in outlining details. We describe in detail which systems take part in the process, and provide the names for APIs and the way to evoke them. This is the target diagram of the project that can be used as technical documentation for the system.
A business analyst’s work means continuously building an understanding between project teams and business. It is worth using proven tools for this purpose, which UML and BPMN diagrams that I described above undoubtedly are. In my daily work, they allow me to find a common language for project and business teams. Thanks to this, both business analysts, developers and clients have no doubt what the point of the project is.
She has been working in the area of business and system analysis for 8 years now, mainly in the financial industry. Supports banks, leasing and insurance companies. As part of implemented projects, invariably searches for a logic and sense. In priviate life, she doesn't run.
Would you like to learn more about the possibilities of cooperation? Do you have a question? Write to us!