Reading time: 5 min
In an organization, regarding the judgment of an introduced data warehouse (or an ongoing data warehouse implementation), we can recognize general and individual aspects affecting the organizational level.
General considerations permeate the entire organizational structure, from the initial phase of a data warehouse project to the entire lifecycle of the project.
Aspects that affect one organizational level generally apply to a certain stage of the project and although their impact may extend to other organizational units, they actually influence the attitude of a smaller, well-defined part of the organization.
General aspects of data warehouse judgment
Size of development
The size of the implementation and further development cycles plays an extremely important role in the judgment of the data warehouse project. During a shorter but usable development cycle, the costs and time requirements of the project can be planned more accurately, thus avoiding the negative opinion of the top management due to possible slippages and additional costs. The human resource needs of the project are also easier to assess, in addition to providing a foreseeable amount of extra tasks for the participants, thus avoiding overload. It also provides a solution that can be used in a relatively short time for end users, with a shorter learning cycle.
Separation of team and technology
The data warehouse technology introduced or planned to be implemented and the team performance that manages it are closely related. As a result, it is difficult to separate the two from an external perspective, and a technology that provides a perfect solution to a given problem can lead to a deterioration in the overall assessment of the project in the absence of a competent team. In the evaluation of the project, it is worthwhile to separate the two as much as possible, in order to accurately identify possible problem areas.
The prevalence of current technology and visualization trends can have an impact on the judgment of the data warehouse within the entire organization. An example of this is the rise of cloud-based solutions, which are not feasible for all profiles due to technical or security factors. However, this is not necessarily the case for all participants involved, so data warehouses using non-cloud-based technology can simply be labeled “obsolete”.
The impact of internal communication on judgment starts at the intop management level and then spreads to the entire organization. If the data warehouse is used on the management’s instructions, but colleagues are reluctant to use it or do not see its benefits, forcing it will lead to further deterioration in judgment. Another example is the data warehouse reporting time reducing effect. Colleagues who have dealt with this for a significant length of their working time may find that the data warehouse takes up their duties and may fear dismissal. This can be handled by internal communication.
Data warehousing judgment at different levels of the organization
Top management level
At the top of the organizational hierarchy, the factors that affect the assessment of a project in general, appear. If the project is not delivered according to the proposed schedule, performance delays can also paint a negative picture of the data warehouse project. Also, the ratio of the costs incurred (development and operation) to the benefits achieved by the project has a significant influencing factor. Determining the cost/benefit ratio in the case of data warehouse development is not a self-evident task, as we can realize benefits not only from the reduction of resource demand but also from the lack of wrong business decisions made based on erroneous data. The transparency of the reports prepared with the system is a much more project-specific influencing factor. The wider the visualization toolbox of our system, the more likely we are to discover relationships that can serve as a basis for a potential business benefit decision. In addition to the possibilities of the visualization layer, trust in the authenticity of the displayed data is essential. The level of validity of KPIs determines the extent to which business decision-makers dare to base on the results extracted from the data warehouse. Due to everyday use and the effects generated by the changing market environment, new business opportunities and needs may appear in the organization’s operations. If the data warehouse has the potential for improvement to fulfill these new needs, its assessment can be much more positive.
Operator and support level
At the middle level of the hierarchy, operational tasks, such as the frequency/severity/source of errors, play a more prominent role in the judgment. In the event of frequent or severe failures, significant labor input is required to operate at the expected level, a significant part of which is reported by end-users. This imposes an additional administrative load on the group in addition to error correction work. Talking about the source of the errors, it is worth mentioning the errors that occur in the core system, as the data warehouse works with the existing features of these systems. And users attribute the errors to the system in which they were detected. Moving away from the top management level, the question of accountability arises. As a result of more thorough and consistent analyses, the results may paint a more negative picture of expected indicators. This, in turn, could result in the accountability of colleagues who have been reporting so far. If comprehensive and thorough documentation of the data warehouse project is prepared from the beginning of the project, the elimination of possible errors is a significantly less burden on the operator team, not to mention the additional manpower required to replace the missing parts of the documentation. Therefore, the quality of documentation is a significant factor in judging a data warehouse. The degree to which key players are involved determines the level at which the data warehouse can fulfill users’ needs. The known but unfulfilled expectations of key players during the project could be an additional supporting burden for the operations team, which could be avoided at the planning stage by involving these users. The basic transaction systems operating in an organization may change during certain business decisions. In this case, the operation of the data warehouse must be adapted to the changes in order to achieve accurate results. The higher the adaptive potential of the system, the less work is needed to adapt the data warehouse to the changes.
End users are the ones who experience first-hand the efficiency of the data warehouse. With proper operation and implementation, the days spent making complex reports are reduced to hours, depending on the measure of automation achieved, and the time freed up can be devoted to new tasks or perhaps more thorough implementation. Accountability also appears at this level, as the new system may shed light on the flaws of the previous methodology, which may have consequences depending on the severity of the problem. End users do not see the technical details of the data warehouse, so for them, the end-user experience is the biggest influencing factor. The wide range of available visualization tools, user-friendly interface, short loading time makes the time spent working with reporting more pleasant and efficient, thus giving a positive assessment to the data warehouse project as well. Even with the most user-friendly systems, issues may arise during use. If the company has the right training materials and an internal support team, the user can get help in a relatively short time, and so continue their work. For colleagues who have deeper IT knowledge, it can be a lot easier to work with if the services provided by the data warehouse include a sandbox option. Individual queries and information retrieval must always take place in well-controlled environments, otherwise shadow-BI can develop within the company, violating the data warehouse principle that it is “the single source of truth”.
István Balázs – Junior DWH developer
Richárd Pertics – Business Analyst