Development of a BI application. Moving from a business idea to formulation of the problem

. Development of BI applications and, in general, Business Intelligence are no longer new concepts for the market. Nevertheless, there is practically no literature of practical significance. This article is aimed at analyzing the author's practical experience with the generation of conclusions and specific advice for a novice business analyst to use in his work. Inexperienced professionals just starting their careers in BI can face a variety of challenges, especially when dealing with business customers and developers. Therefore, the article pays special attention to the description of research objects and their correct interaction with each other. It also provides a detailed analysis of the initial stages: from the customer's need to develop an application to setting clear detailed requirements for the contractor. The result of this work was the proposed methodology for step-by-step work and analysis of the difficulties that may be encountered on the way of the "newly minted" business analyst.


Introduction
Business Intelligence, or BI-systems, is a set of tools and technologies for collecting, analyzing and processing data. With the help of the created applications, you can set up convenient reporting and analyze information in different sections. BI applications are used in any industry and field of activity [1].
Application development begins with a business problem, the customer comes with his own "pain", which is often expressed in an incomprehensible wording. He himself does not fully understand what exactly he needs and what value the created product will bring in the end. If the BI-developer directly transfers these "requirements" to work, at best, the reporting will be implemented as it seemed to the specialist himself, at worst -the performer will completely refuse to perform an unclearly formulated task.
In order for the customer to ultimately remain satisfied and the application to bring accurate benefits to users, the analyst needs to do some serious work.
The purpose of this article is to identify the main stages of the business analysis process in projects for the development of BI applications. The objects of research are the development team, business customer of analytical reporting and business analyst. This topic is very relevant, because the market of BI systems is in the stage of active growth, businesses of any field and focus need to create high-quality, visualized analytics and automation of reporting based on the accumulated data. Many people face difficulties already at the stage of setting the problem -business and programmers communicate in completely different languages. At this point, the analyst performs an important function, systematizing, supplementing the information received, and translating it into detailed, clear requirements for development [2,3].
There are not so many books and articles written on the topic of business analysis, the field of business intelligence is now developing. Universities relatively recently began to graduate their students in the direction of "Business Informatics". Therefore, I believe that this topic has not been adequately covered. Based on the experience gained, you can draw your own conclusions and share real cases, examples and best practices.
Such material will help novice analysts in theory understand the specifics of work, make the right decisions and act in stages, in accordance with the proposed methodology.
The article consists of theoretical material taken from various authoritative sources, the author's practical experience and her own opinion on building a business analysis process within the framework of the developed application. Contents of the sections of the article: 1. A theoretical introduction: what are business intelligence and BI applications? 2. Description of the objects of research, their peculiarities of thinking and interaction with each other.
3. Formulation of the main stages of application development. 4. Detailing the initial stages: from the emergence of a business idea to the formulation of a problem. 5. Results of the step-by-step work and analysis of the difficulties that may arise.

Materials and methods
This topic was chosen as part of the writing of the master's thesis. The research was carried out within the framework of studying the available theoretical material and supported by practical application on one of the projects. When writing the article, such methods as analysis of objects of research and synthesis of information obtained through analysis were applied. At the beginning of my work, I would like to define more precisely what BI and BI applications developed using this technology are. BI (Business Intelligence or Business Intelligence) is a set of IT technologies for collecting, storing and analyzing data that allows you to provide users with reliable analytics in a convenient format. Based on it, you can make effective decisions to manage the company's business processes [2,3].
At the moment there are several different BI platforms, but their architecture is not very different and is a process of obtaining data from various source systems, databases. They are accumulated and prepared in the DWH storage for subsequent loading into the developed BI application with visualizations necessary for users. The standard application necessarily reserves the ability to unload existing data from the system in Excel, PDF and other formats, for subsequent analysis and decision-making [4].
An example of how BI works is shown in Figure 1. 2 The development of the client side (or BI-application) will be discussed in this article. A BI application or dashboard is a system that represents analytical reporting in the form of charts, tables and reports, specially customized for the user for convenient operational and strategic analysis.
The main participants in the creation of dashboards are: the customer (representative from the business), the business analyst and the development team. Depending on the volume and complexity of the work, participants can also be a project manager, product owner, system analyst, tester, and others. Companies have adopted different approaches; often the same person can perform several functions. To simplify the understanding of the relationships in this article, the research objects will be considered the customer, analyst and developers.
Customer -a person interested in the performance of the contractor, the provision of services or the purchase of a product from the seller [5]. This is a person who has a need to solve a business problem. Sometimes he has a clear idea of how exactly it can be solved and even the approximate final result, with the help of what tools it can be implemented, he has accumulated the amount of necessary data and has an understanding in what aspects they need to be presented. It is even better if he understands the business value of the product being created.
But often the opposite happens: the customer does not know how to solve the problem that has arisen, does not understand the tools existing on the markets, does not understand where to get high-quality data and why he has developed an application in general. Customers are different, with everyone you need to be able to find a common language and, in the end, get something that has value for users, solves the customer's problem and brings specific benefits -for example, automates and facilitates the operational work of specialists.
A business analyst is a specialist who uses business analysis methods to study the needs of organizations in order to identify business problems and propose solutions [6]. Often he also performs the duties of testers and system analysts who are absent from the team. When looking for a specific definition of this profession, you often come across completely different descriptions of duties and requirements for a candidate.
Functionally located between the customer and the development team, a universal specialist-intermediary who understands the business area in which the customer is located and at the same time understands the language of programmers. A business analyst has knowledge both in the IT field, BI tools, and in the specific area in which the customer is immersed.
The analyst discusses the customer's problem with him, can suggest ways to solve it, assesses the feasibility of introducing a product, corrects and directs the creative flow of thoughts in the right direction. After meeting with the customer, he conducts a critical analysis, additionally searches for expert information and forms detailed requirements for development, if necessary, before transferring to work, he meets with the customer again and approves them [7]. The business analyst then submits the formulated task, detailed to the technical requirements, to specialists from the development team. After completing the development, he tests the result, most often gives it back for revision and demonstrates the corrected version to the customer. Also, the business analyst is responsible for documenting the requirements, helps to write the methodology, has the skills to promote the created product, and is generally responsible for creating and maintaining the functionality of the newly developed application.
The development team most often includes from 1 to 5 BI specialists. In large companies, programs are divided into many projects and usually no more than 2-3 programmers are required per project [8]. Of course, it depends on the amount of work and their timing.
The developers are the last link in this chain and it depends on them how quickly and efficiently the task will be completed. From a business analyst, they receive detailed requirements, if necessary, clarify some points, suggest what is technically possible to implement and what is not possible with limited tools. Experts necessarily evaluate the work that they have to do in terms of time (either in hours or in working days). They are obliged to withstand the announced deadline and, in case of force majeure, warn in advance that the execution time is increasing.
Developers should be interchangeable and, if necessary, a business analyst can redistribute tasks within a team to perform work more efficiently.
BI professionals will benefit from a creative approach to implementation so that they can also suggest their own solutions to the problem, suitable visualizations and a good layout on the sheet. It is important to remember that performers do not make the final decision and in a creative impulse you also need to be able to stop. First of all, you need to listen to the opinion of a business analyst who is completely immersed in the task and generally understands the ultimate goal and needs of the customer [9,10].
The chain of correct relationships at the stage of developing a BI application is shown in Figure 2.  Sometimes it happens that the customer directly sets the task to the developer (without an analyst, or if the analyst is not in the team at all), which is not the target method of setting and most often leads to misunderstanding, and as a result, affects the quality, timing and execution. The task is not completed or does not bring ultimate value to the consumer. As a result, resources, time and budget are wasted, but there is virtually no result.
Later in this article, a competent step-by-step process of transferring requirements will be considered so that the customer's idea is expressed in clear, specific development requirements.
I will briefly describe the main stages of developing a BI application [1][2][3][4]11,12]. 5. Creation of a dashboard and transfer to an analyst for testing; 6. Testing the MVP application, sending it for revision (not always, but most often), retesting; 7. Demonstration of the results to the customer, receipt of comments and, if necessary, another cycle "revision -testing -demonstration"; 8. Promotion of the finished product, assistance to users in mastering and transfer of the application to the service.
In this work, we will focus on the first 4 stages: the transition from a business idea to a problem statement [11,12].

Results
Before the first phase begins, the business analyst should prepare for the meeting with the customer. There are situations when a business analyst is not at all immersed in the required business area and does not know the customer. In this case, the preparation time increases. The analyst needs to dive into the topic on his own, look for information about the specifics of the subject area in open sources and try to analyze the result, having previously answered such questions: What is this business about? What processes are carried out in this company? What goals (at different levels: tactical, strategic, etc.) do the company / leaders of this company set for themselves?
How is this business measured? What Key Performance Indicators (KPIs) are there? What data has already been accumulated in the company? On which source systems are the integrations stored and configured?
What are the features and needs of future business users of the application? What is the pain (main problem) of the customer that he wants to close by developing a dashboard?
What value will the created product bring? The answers to these questions will help to conduct the first meeting better. First, the customer will be pleasantly surprised and it will become easier to tune in to "one wave", to understand each other. Secondly, a trained specialist already at the first meeting will be able to make his proposals, give his vision "from the outside" and speak "to the point".
There is also another story: the business analyst and the customer know each other before the first meeting, moreover, they work together and both are immersed in the field of activity, the specifics and more or less understand the value of the application being created, the necessary data and what is the basic need of the customer. In this case, the preparation takes much less time and most of the issues are discussed already at the meeting [13,14].
The first meeting is usually very productive, and the main pool of information is transferred there. The business analyst must find out the answers to the questions that I gave earlier and, if there is time, discuss the details, deadlines, fix the agreements (various methods are used: from recording a MEMO of a meeting in writing to fixing a meeting on a dictaphone/video). Sometimes the customer prepares poorly for the meeting (or rather does not prepare at all), he is not ready to answer some questions -in such cases, additional meetings are held to clarify the details and more time is spent. But this is the area of responsibility of a business representative -in his interests, so that the product is implemented in the shortest possible time and with the best quality.
While writing this article, the second stage I highlighted is the conduct of critical analysis. The order of these stages can be adjusted depending on the specifics of the situation in which the objects of research are located. So, for example, the second stage could be carried out before the first or canceled altogether. This also happens: there is no time for development at all and the customer sets a deadline: "it was necessary yesterday," which is quite common. In this case, you need to prioritize: loss of quality or loss of time, it is necessary to immediately notify the customer and fix the agreements, in order to avoid unpleasant questions and misunderstandings when demonstrating the final result.
If you have time, it is worth doing a critical analysis. The business analyst further investigates the customer, reads literature in open sources, works with experts, and holds other meetings with stakeholders. It is worth conducting an in-depth interview with future users, this will also save you from a big mistake: creating an application without a special purpose, without customer orientation, without value and, accordingly, without an actual result.
Based on the information received from the customer and through all other channels, the business analyst generates conclusions. If necessary and if there is time, he discusses them with the customer who has the necessary competencies and can expertly assess the correctness.
The third stage is the formation of the final business requirements for their development, approval and documentation together with the customer. This is a very important stage that cannot be neglected even in the absence of free time -agreements recorded in any form will help in resolving controversial situations later, and will also help to fix all the details. It will be easier for business analysts to create a development task for them and check them point by point after completion.
Business requirements can be fixed in any format -whichever is more convenient for both parties. Sometimes all requirements are spelled out in e-mails, sometimes they are recorded on paper, or they are stored in a convenient common place -in a public directory (for example, in Word format) or in a system like Confluence. In some companies, a specific TT is written, which must be signed by stakeholders.
It would seem that this document can already be transferred to the work of the developers of the BI application, but here it is important not to skip the fourth stage: reformulating the business requirements into technical detailed requirements for the executor. If you give it to programmers in the form of business requirements, thinking about saving time, the opposite effect will happen -time will be lost a little later, when the specialist starts asking clarifying questions on each of the points, not understanding the business turns of speech. And this is the best case. At worst, the developer will do the work as he understands, applying all his creative vision and at the end we will get a result that will need to be completely redone. This will take much more time [1][2][3][4]15].
Business requirements need to be decomposed down to subtasks, each of which is written in a language understandable to a technician, indicating where the data comes from, in what context and with what visualization it needs to be presented. When developing an application from scratch, the layout of graphs on sheets, the required schedule for dashboard updates, and many other details are also discussed. It is best to set the task orally, having said not only the detailed requirements for each schedule, but also the business sense, to partially immerse the contractor in the customer's "pain" so that the work is done efficiently, and the specialist is focused on the overall result, understands what value he will bring with his work.
After the meeting, the business analyst necessarily describes the created TT in writing and sends it to the developer/puts the document in the public domain. Thanks to the fixed clear requirements, it is easier for a specialist to carry out the work (all tasks are at hand), and the analyst, upon completion, can be tested according to the list. Also, this document will allow you to avoid possible controversial issues, because all agreements are fixed.
After the meeting with the transfer of requirements, the developer analyzes the received task and announces the deadline for its completion. This information is also recorded and, if necessary, transmitted to the customer. Then the product is created in the framework of the previously described 5-8 stages.
The first four stages are fundamental, it is very important to complete them without missing seemingly unimportant moments, because they can ultimately strongly affect the result and affect either the quality of the work performed, or the timing of its completion. In general, each company has a different approach to developing BI applications, depending on the working conditions, well-established methods and rules adopted in the team. But if it seems to you that the "rules of the game" are not entirely optimized, then they need to be changed -most often this is welcomed in large companies, especially if the effectiveness of the new approach is proved in practice [1][2][3][4]16].

Discussion
What difficulties can arise in the early stages of development? There can be many of them, because the work is carried out with the interaction of several people. Each person has his own opinion, his own competencies, his own characteristics and it can be difficult to find an approach to everyone. Sometimes conflicts and disagreements may arise, here it is important to come to a constructive discussion and remember that you are all going towards one goal, it remains to agree on ways to achieve it.
Difficulties in working with a customer: incompetence in some issues, lack of a true desire to achieve a high-quality result, lack of understanding of the value of the product being created, and sometimes the goal of development, interpersonal conflicts.
You can first try to solve these problems on your own -spend a little more time in the first stages in order to clearly define the customer's task. If necessary, on particularly difficult issues, it makes sense to involve colleagues -for example, your immediate supervisor, who can look at the situation "from above" and give the necessary advice on getting out of it.
Difficulties in working with developers: unwillingness to complete work, systematic failure to meet deadlines, too creative approach to work, or vice versa, lack of creative thinking, constant arguments and misunderstandings.
Here you also need to first try to negotiate with a person on your own, find an approach to him, pay attention to yourself -maybe you need to change something in your way of interaction, find out from the developer what he lacks for comfortable work. If the situation E3S Web of Conferences 284, 04009 (2021)

TPACEE-2021
https://doi.org/10.1051/e3sconf/202128404009 seems insoluble, you should not neglect to turn to him or your line manager for help or advice. There are no unsolvable situations.
Difficulties in understanding the details of the customer's business area and, as a result, the inability to generate their own proposals and sometimes even formulate clear requirements for their detailing.
If there are problems with understanding the task and goals of the customer, there is nothing wrong with asking him for an additional meeting and discussing the issues that have arisen. At the same time, you should definitely study open sources on your own, ask for help from colleagues in explaining what is not clear. This situation cannot be ignored, if the business analyst does not understand the problem, then this will affect the final result. Let me draw an analogy with playing a broken phone, where a business analyst sits in the middle and does not hear / misunderstand the requirements and transfers them to work in a limited / incorrect way. Therefore, it is very important to fully understand everything related to the development of each specific application.

Conclusions
In conclusion, I would like to note that the development of BI applications is a promising and interesting direction. Modern business is already unthinkable without such tools to support management decisions.
These business analyst principles and development stages are simple enough, but by adhering to them, we manage to create interesting solutions that benefit our customers.