The backing of the management
In the previous article various triggers for planning automated company reporting were mentioned and expectations that we encounter time and again in our own data project as well as in customer projects. These can either come from employees, e.g. those who regularly spend a lot of time reporting to management. Or from management directly, e.g. because the latest figures should be available at all times.
The necessary regulations for setting up a database and its use in the company require at least the Involvement of the managementand, even better, the active promotion of the necessary activities. Especially in the area of Data governance strategic decisions have to be made which must be embedded in the overall corporate strategy and which often conflict with other processes or objectives. In addition, the personnel and financial costs involved are not insignificant, so that also backed by the budget is necessary.
What do we want to know? Gathering requirements and asking the right questions
The collection of requirements can be started from different sides: Top down or bottom up.
If you now consider the top-down approach with the use cases, you can start from these questions in the case of existing, manually created reports and begin the collection of requirements from the user or technical perspective.
Even with tried-and-tested reports, it makes sense to think about each question and structure the requirements independently of tools and presentation. A report can contain several use cases, not least for a summarized overview of all KPIs at the highest aggregation level.
For all Use Cases at least the following questions should be answered:
|
In our internal data project Data Hub existing manual reports were taken as a jumping-off point and the question of how successful the projects are financially was addressed first. For us as a service provider, the projects are the produced good, so this is a very central question for many further analyses. The first step was to start, Analyze completed projects and the KPIs project revenue, return on investment, internal and external costs. At a later stage, further KPIs which were also applied to ongoing projects with linear extrapolation. With increasing knowledge of the influences and indicators, KPIs were also developed based on these, which depict the success of project activities in the company.
Figure 1: Top-down or bottom-up data strategy; source: own illustration: https://staging.blog.doubleslash.de/mit-predictive-maintenance-den-business-value-maximieren/
From the question to the data offer
It is often already clear in the use cases/questions, Which data sources come into question for the answer. In larger companies in particular, however, it is often the case that a potential data pool has to be searched for at great expense and a connection is lengthy due to numerous processes. The preparatory measures often involve considerable effort before the first data extract can even be viewed. A great deal of effort can be saved when preparing data, which sources can be made available for several use cases with little adaptation.
In our case, the initial question about the financial success of the projects is based on data from two systems: the contractually agreed prices and framework conditions, such as the term with the customer on the one hand and the hours booked by the project staff and other expenses within the scope of the project on the other. This meant that two systems were already involved at this point and their data had to be linked. The two systems were not introduced at the same time and therefore had different time spans of historical data. The Effort to transfer legacy data from the previously replaced systemexceeded the benefits by far and was therefore explicitly excluded. The historical data goes back as far as the more recent of the two systems was introduced in the company.
Globally standardized KPIs were also used for the questions developed for and by us, which did not have to be defined specifically and are sometimes used for external reporting in a comparable form, such as the equity ratio or EBIT (earnings before interest and tax).
As Stakeholders of the initial use case for the success of the project was seen as the management circle and the team leaders. The authorizations were not further subdivided there. However, it was decided at the start of the data project that no employee-related data would be evaluated.
From a data supply perspective, we had at least these two systems with multiple data sets. If we were to start from this user-oriented perspective, we would begin by examining the technical and functional quality and ask ourselves the question, to which technical issues the data can be made available or linked can. If the main goal is for many users to use data sources provided in self-service, this perspective should not be neglected.
The top-down approach is often predominantbecause there are stakeholders who need to answer questions and therefore look for answers in data and demand them. In addition, the stakeholder's focus is on the technical quality requirements.
Conclusion
Decisive for the success of a data project is the Backing from the management. In our data project, there were initially requirements for existing reports and everything else developed based on initial experience. If for each report the Questions about use cases and stakeholders clarified This has the advantage that questions can be summarized by structuring them, if necessary, thus reducing redundancy. For the right questions, you can either top down or bottom up proceed.
It is not uncommon for the The structuring described above only after the use of the data has already begun This is the case when consolidation is used to (re)introduce a technical structure into the growing number of data sources. A structure can undergo changes for various reasons, but must apply consistently to the entire database in order to ensure reliable quality and traceability. For rather unpopular but necessary processes of Data governance it is essential to think about use cases and their stakeholders and possible authorizations.
