Self-service business intelligence and analytics application scenarios: A taxonomy for differentiation

“A fundamental problem in many disciplines is the classification of objects of interest into taxonomies” (Nickerson et al. 2013, p. 336). Classification systems such as taxonomies, which are often referred to as typologies, help by structuring and organizing knowledge. Taxonomies uncover and classify objects based on common characteristics and explain their correlations to each other, which allows researchers to understand and analyze complex fields (Glass and Vessey 1995; Varshney et al. 2015; Nickerson et al. 2013; Miller and Roth 1994). Our goal is to create more structure with regard to the wide range of SSBIA application scenarios. Thus, the development of a taxonomy is suitable to improve our ability to differentiate among various SSBIA application scenarios. The design of our taxonomy is based on the methodology for the development of a taxonomy created by Nickerson et al. (2013), as this methodology provides a structured and scientifically sound process for the development of taxonomies. This methodology is an iterative process based on both existing theoretical foundations (conceptualization) and empirical evidence (empiricism). The dimensions thus obtained consist of mutually exclusive and collectively exhaustive characteristics. “Mutually exclusive” means that no object has two characteristics within one dimension, while “collectively exhaustive” means that each object has at least one characteristic in each dimension (Nickerson et al. 2013). Taken together, these two attributes of the taxonomy ensure that each object has exactly one single characteristic in each individual dimension. Starting with an analysis of the literature on SSBIA elements, the dimensions of the taxonomy are derived conceptually. Subsequently, related characteristics are identified by examining SSBIA tools empirically. After each iterative step, multiple ending conditions are checked. If the ending conditions do not entirely apply, a further iterative step is necessary. The ending conditions applied in this process were taken from Nickerson et al. (2013) (see Appendix 8.1). We also conducted a case study. The development of a taxonomy is derived from artifact development in design science research (Hevner et al. 2004; Nickerson et al. 2013). In design science research, evaluation and/or demonstration is an essential component of the research process. A framework for the evaluation of taxonomies has been developed by Szopinski et al. (2019). According to this framework, there are different ways in which a taxonomy can be evaluated. We follow this framework and evaluate our taxonomy using an “illustrative scenario” in Sect. 5 (Szopinski et al. 2019, p. 13). Our procedure is illustrated in Fig. 2.

In accordance with the suggestions of Nickerson et al. (2013), we base our meta-characteristic on the purpose of the taxonomy in line with our RQ. Therefore, we define our meta-characteristic as follows: the definition of SSBIA dimensions that can help differentiate among SSBIA application scenarios. We specify that the requirements of data science applications are considered to be SSBIA only if they can be realized in the context of analysis applications (Bani-Hani et al. 2019; Eckerson 2019). If the analyses are implemented completely in a programming language, e.g., in Python or R, we consider them to represent an IT implementation and thus no longer an SSBIA scenario. However, the partial use of programming language in analytical applications can constitute an SSBIA scenario, for example, if small snippets of code are used for the specific visualization of data. According to this definition, e.g., the work of a “citizen data scientist” belongs among SSBIA applications (Mullarkey et al. 2019).

The first iteration employs the conceptual-empirical approach of the process model (Nickerson et al. 2013). Possible dimensions that do not match the meta-features are discarded. Given the rapidly increasing number of potentially relevant scientific publications, not all of which add value to a literature review, it is important to identify the most relevant papers (vom Brocke et al. 2015). To identify the relevant literature, we followed the literature review guidelines suggested by Webster and Watson (2002) and vom Brocke et al. (2015).

The purpose of this study is to uncover the differentiating dimensions and characteristics of SSBIA. Consequently, based on this framework, many areas of SSBIA could be considered, leading to our broad characteristic search string “Self-Service Business Intelligence” OR “Self-Service Analytics” OR “Self-Service Business Analytics”. Using this search string, the literature search engines and databases ScienceDirect, AiSeL, and Google Scholar were searched systematically, resulting in 46 relevant papers. We conducted a forward (3 papers), backward (4 papers), and a related article search (1 paper), to find additional literature based on the key papers previously identified. The key papers are Alpar and Schulz (2016), Bani-Hani et al. (2017, 2019), Burke et al. (2016), Eckerson (2009, 2012, 2014, 2019), Halper (2017), Imhoff and White (2011), and Lennerholt et al. (2018). These steps allowed us to complete our list, resulting in a total of 54 relevant papers. In addition, we searched the publication lists of the authors Bani-Hani and Eckerson for additional relevant articles. An overview of the overall and final results of these search methods is provided in the table in Appendix 8.2.

Based on the SSBI architecture developed by Passlick et al. (2017), which indicates the relationships between new self-service elements and traditional BI components, we used the five themes of “Data Modeling”, “Data Presentation and Analysis”, “Users”, “Data Governance”, and “Architectural Elements” as our first criteria to sort and classify the literature identified. “Data Modeling” describes the tools, components, and techniques that are necessary to transform the data so that it can be analyzed in subsequent steps. The “Data Presentation and Analysis” topic focuses on these further analyses. Tools and techniques that present and visualize data are outlined. The “Users” topic specifies the user groups that can be found in an SSBIA environment. “Data governance” summarizes the guidelines governing, e.g., data quality or data protection. Under the theme of “Architecture Elements”, we summarize the components that support SSBIA from a technical or organizational perspective.

To obtain a scientifically valid basis for classifying SSBIA applications, we identified the initial dimensions based on the literature review presented in Table 1. Drawing on the aforementioned SSBIA architecture developed by Passlick et al. (2017), we structured the dimensions of the taxonomy in line with the literature review, resulting in a preliminary taxonomy including a total of eight dimensions. A description of the dimensions follows in Sect. 4, and definitions of the different dimensions can be found in Appendix 8.3. As shown in Appendix 8.1, several end conditions were not met due to the purely conceptual-empirical approach previously employed.

Subsequently, we employed an empirical-to-conceptual approach. For this purpose, we analyzed SSBIA tools. To identify possible tools, we used Gartner’s Magic Quadrant Report (2019), the “BI Products List” drawn from the website “BI-Survey.com”, the Google search engine using the search strings (“Self-Service Analytics” OR “Self-Service Data Mining” OR “Self-Service Data Preparation” OR “Self-Service Intelligence”, and our own knowledge of this field. We found 49 software products that were labeled SSBIA tools. The table in Appendix 8.4 provides an overview of this process. After identifying the SSBIA tools, we checked the website for each tool to verify that the tools could be used to perform SSBIA in accordance with our definition. Two tools were dropped because they did not support SSBIA. This process led to the final sample size of 47 SSBIA tools, which can be seen in Appendix 8.5. The companies developing the tools ranged from mid-sized companies, such as Phocas, to large corporations, such as Microsoft. To analyze the 47 tools thus found, we examined each company's website (websites, online interviews, and videos), product sheets, case studies, and white papers.

Based on this examination of the SSBIA tools, we performed the next five iterations of the process model developed by Nickerson et al. (2013) until we finally fulfilled all ending conditions. In the second and third iterations, we examined a sample of 10 randomly selected SSBIA tools each, from which we derived suitable features pertaining to the dimensions obtained in the first iteration. Furthermore, very similar characteristics that were referred to by different terms were combined into one overall characteristic. In the fourth iteration, we examined a larger random sample of the 15 remaining SSBIA tools to confirm whether the dimensions and characteristics identified during the first three iterations were sufficiently stable, i.e., whether a sufficient number of characteristics had been found and whether they had been reasonably selected. We added additional characteristics and altered the structures of four dimensions from flat to hierarchal. Due to minor additions and changes, the final criteria of the taxonomy were not met.

At this point, the development of the taxonomy, which was mainly based on the analysis of SSBIA tools, was formally completed. However, certain important SSBIA aspects are difficult to analyze by reference to empirical data. For example, data governance continues to be discussed in the literature as an important element of SSBIA. Whether SSBIA application scenarios can be differentiated based on data governance remains unclear. The different aspects of data governance are very difficult or even impossible to identify. For this reason, we also conducted a case study. Based on this case study, it can be determined whether different SSBIA applications emerge depending on, e.g., the data governance. In this case study, we investigated the SSBIA application scenarios that are available or planned. Therefore, we identified which SSBIA tool is used and why and how it is used. Several informal, unstructured interviews were conducted with different employees of the case study company, taking into account the guidance provided by Yin (2009). These employees had different roles, including executive positions, BI managers and BI users from the business departments.

The company under investigation is active in the field of engineering and manufacturing, its headquarters is located in Germany. With approximately 4000 employees worldwide, it is considered to be a medium-sized company. The company is thus large enough that it features quite different SSBIA applications. In the context of this study, we examined only BI tools that include SSBIA components.

The company's BI architecture is based on a core data warehouse (DW), which mainly processes data from the enterprise resource planning (ERP) system. To facilitate access to the DW data, different departments use different, predefined queries. The DW data is often processed using Excel. A web front-end is available for this purpose (“SAP BEx Web Analyzer”), which allows to filter data, analyze it by different dimensions and download it in the desired form. In addition, a plug-in for Excel is available (“SAP Analysis for Microsoft Office”) to facilitate direct access to queries. This plug-in is increasingly used by financial analysts since some of them are very well trained in Excel and can employ the plug-in efficiently. Furthermore, users experience sufficient freedom in these scenarios to create ad hoc analyses quickly.

To simplify access to the data further and facilitate more efficient interaction, selected applications are created by the IT department on the “Jedox” platform. The results are web-based dashboards with, in part, very extensive functions for different business areas. For the sales department, some kind of data mart is developed, which is supplied with data from the core DW. In this context, the data modeling is done by the IT department, while small dashboard modifications are implemented by selected power users in the sales department.

One novelty is the requirement for different departments to introduce an additional tool for SSBIA application scenarios. From the perspectives of these departments, the existing tools are somewhat too inflexible (web-based applications), there are no up-to-date visualizations (“Microsoft Excel”), and the tools do not offer interfaces for complex algorithms (sales reporting). “Microsoft Power BI” is discussed in this context as a possible all-round SSBIA tool that can meet these requirements. However, while examining the tool concretely, it became clear that other challenges also arise. For example, when using the tool in the cloud, the role and authorization management implemented in the core DW is bypassed because the data is accessed by a technical user. Permissions can also be bypassed using “Microsoft Excel” worksheets, but the extent of this issue is different. With regard to particularly sensitive data, downloads to “Microsoft Excel” are prohibited. This situation highlights the fact that SSBIA application scenarios can also be differentiated based on the sensitivity of the data. While less critical data can be analyzed group-wide using any tool without major difficulties, access to sensitive data is restricted. With regard to sensitive data, it is necessary to ensure throughout the SSBIA analysis process that the only persons who have access are those who are authorized to do so. Under certain circumstances, these requirements can lead to a situation in which a certain SSBIA tool cannot be used.

Another question that arises when discussing “Microsoft Power BI” pertains to the task of ensuring that correct information is displayed in the applications. This problem applies to SSBIA in general. Data provided by IT are usually tested extensively; thus, their correctness can be assumed. When using queries of the core DW, the sales DW, and the web-based dashboards, the information is reliable, as the modeling is conducted by IT. When using “Microsoft Power BI”, data reliability depends on the application scenario. It is possible that the data modeling is largely performed by the business department, in which case data quality is not necessarily guaranteed. The likely data quality depends largely on the complexity of the modeling, the possible transformations, and the completeness of the data.

Our case study shows how SSBIA application scenarios are discussed in the context of a concrete company. The dimensions thus described are also included in this discussion. The next step is to evaluate the usefulness of the taxonomy in further detail.

We evaluate the developed taxonomy based on the framework developed by Szopinski et al. (2019). For this purpose, we have chosen to employ a quantitative approach and the “illustrative scenario” methodology. More precisely, we have applied “a taxonomy to real-world objects”. As described by Szopinski et al. (2019, p. 11), this method of evaluation is appropriate because it “allows researchers to evaluate their practical applicability and usefulness for classifying, differentiating, and comparing objects […] as well as to evaluate their robustness, utility, efficacy, stability, and completeness”. In this evaluation, our primary purpose is to investigate whether the developed taxonomy is useful with respect to achieving the goal of differentiating SSBIA applications. Accordingly, we assign all examined SSBIA tools to the characteristics we discovered and conduct a cluster analysis based on this process. This approach allows us to answer the questions of “how?” and “what?” included in the Szopinski et al. (2019) framework. The question of “who?” is answered by reference to the fact that we, as the authors, conduct the evaluation. We have experience with the domain and the method, have academic backgrounds and have been involved in the process of taxonomy development. The cluster analysis should indicate that meaningful clusters ultimately emerge, which differentiate themselves based on the dimensions we discovered. Furthermore, we qualitatively examine the extent to which the archetypes resulting from the clusters represent a plausible form of an SSBIA application. If these archetypes can be discussed profitably, it is indicated that the taxonomy is successful in the task of differentiating among SSBIA applications.

The assignment of the SSBIA tools to the particular characteristics of our taxonomy was performed by one author following the guidelines proposed by Yin (2009). Approximately 10% of the tools were analyzed by a second author to ensure a consistent understanding of the definitions. In dimensions for which the assignment of the SSBIA tools to characteristics was not obvious, assignment criteria for the tools were developed. These criteria can be found in Appendix 8.3.

Following a literature review, an analysis of SSBIA tools and a case study, we developed a taxonomy for SSBIA application scenarios using the development process developed by Nickerson et al. (2013). This taxonomy consists of eight dimensions featuring a total of 31 characteristics. The four dimensions of BI analytics activities, data management requirements, development collaboration, and access type consist of hierarchical levels, as the characteristics in each dimension build on each other. Accordingly, the characteristic of a higher level also includes the lower levels. The other three dimensions, i.e., user roles, user skills, and nature of the analysis, do not possess such a hierarchy.

We split the initial “user” perspective into the two dimensions of user role (Imhoff and White 2011; Eckerson 2014) and user skill (Eckerson 2011; Alpar et al. 2016). This distinct allows us to adopt a more granular perspective on users, as user roles are mainly task-dependent and user skill are mainly person dependent. The first dimension, user role, distinguishes among the SSBIA application scenarios based on three user types, namely, information consumer, information producer and information collaborator, which have different tasks in the SSBIA process (Eckerson 2011; Alpar et al. 2016). The information collaborator user role focuses on unique tasks such as providing guidance and advice to other SSBIA users but can appear in combination with other user roles with respect to a particular person, as the three user types are task-dependent. The next dimension distinguishes users based on their skills. Skills include statistics, coding, data management, visualization and discovery, and reporting skills (Cosic et al. 2012). The next dimension differentiates BI analytical activities (Alpar and Schulz 2016). With regard to pure self-service data-preparation tools, the first characteristic, i.e., no analytical activity (none), applies. On the other hand, there may be application scenarios in which very extensive analytical activities are performed, such as the performance of more complex analyses using clustering algorithms or regressions. Such extensive analysis activities represent the highest level of activity in this dimension. This third dimension is hierarchical, which indicates that the last characteristic also contains the previous characteristics. For example, report creation and visualization contain access and the use of reports. In the fourth dimension, the requirements for data management in the SSBIA case are distinguished (Cosic et al. 2012). In this context, it is possible that a finished data model that can be used directly (first characteristic) already exists but also that very extensive adjustments are necessary, such as data cleansing and enrichment. This situation is the highest hierarchical level associated with its dimension, as the process of removing inconsistencies and errors in the data can take place only after the extract, transform, and load (ETL) process is complete. The next dimension addresses the importance of collaboration among users in the development of SSBIA applications. SSBIA can support such collaboration by providing comment or rating functions on dashboards, e.g., as in Alpar et al. (2015). The manner in which the final SSBIA application is accessed is addressed in the sixth dimension. If a finished application is to be used on mobile devices, e.g., this use case must also be taken into account during the process of development. This additional requirement can also increase the associated complexity further. However, the complexity also depends on the tools used. The next dimension describes what actually drives the SSBIA analysis or report in question (Schulz et al. 2015). The purpose of this process may be to answer an ad hoc question or to develop a regular report. It is also conceivable that the purpose is to conduct experiments by reference to a data set to determine whether it contains relevant information. The characteristic of all-rounder describes application scenarios in which several of the other characteristics apply.

The final taxonomy is shown in Table 2, and a detailed definition of each characteristic is given in Appendix 8.3. In addition, the dimensions in which the characteristics are structured hierarchically are marked. In the final column, the sources of the particular dimensions are listed.

To evaluate the taxonomy, all SSBIA tools examined were assigned to their respective characteristics. Figure 3 shows the frequency with which the characteristics were assigned to particular dimensions.

In terms of the user roles dimension, it is apparent that the vast majority of SSBIA tools address both information consumers and information producers. The information collaborator type is not addressed by any tool as the sole characteristic. Eleven percent of the tools focus only on information producers. Basic + standard is addressed by more than half of the SSBIA tools with respect to the user skills dimension. Thirty percent of the tools additionally include the advanced skill. Few tools (13%) do not address the lowest level of skills (basic). In the dimension of BI analytics activities, approximately half of the tools are designed for report creation and data visualization. Thirty-eight percent of the tools offer additional advanced analytics capabilities. At least the integration of existing data sources is supported by all SSBIA tools in terms of the dimension requirements for data management. However, approximately 90% of the tools also support further activities. We also identified full support for data cleansing and enhancing in 47% of the tools.

Only approximately 11% of the tools do not support any form of collaboration in development. The majority (72%) of the tools support the individualization of other people's reports. A small percentage (together approx. 17%) of the tools also offer comment or rating functions. Most tools support access via mobile devices (51%). Approximately 21% even enable natural language chat, while 28% offer information access only via desktop. With regard to the final dimension investigated, i.e., the nature of the analysis, the ad hoc characteristic dominates, accounting for 53% of the tools, while 28% of the tools try to function as all-rounders. Significantly fewer (17%) tools address standard reporting, and 2% of the tools do not have any reporting function because they focus on data preparation.

The assignment of the examined SSBIA tools to the characteristics of our taxonomy described previously was used as the foundation of our cluster analysis. By means of this cluster analysis, we identified typical SSBIA tools that are offered on the market. These typical forms are also known as archetypes. The analysis indicates that the developed taxonomy can differentiate the tools well. In addition, we can obtain insights into the SSBIA application scenarios that are observed by SSBIA tool vendors because they focus their tools on these application scenarios.

To conduct the cluster analysis, we first applied the Ward (1963) algorithm to the collected data set. The Ward (1963) algorithm has the advantage of being a hierarchical partitioning algorithm. In contrast to the k-means algorithm, it is unnecessary to specify the number of clusters to be formed in advance. On the other hand, the clusters formed using k-means are often better. For this reason, a combination of hierarchical and nonhierarchical algorithms is recommended (Balijepally et al. 2011). To apply the Ward (1963) algorithm, we used the Sokal and Michener (1958) matching coefficient to calculate distances. After execution, the result can be visualized using a dendrogram. This dendrogram is shown in Fig. 4, which displays the SSBIA tools that we analyzed.

All tools are connected by different branches. In this context, if a connection is long, it indicates great differences in the assigned characteristics. The height of the branching gives an impression of how many different groups are included in the data set as well as the strength of that inclusion. At a height of approximately 3, we can see three groups, which could be a suitable cluster number. These three groups are also marked by thicker boxes. However, four clusters would also be conceivable because this junction is at a similar height. The fourth branch is at a height of approximately 2.8, so we continue by using three and four as possible cluster amounts. Two groups would also be conceivable, but if three or four groups already lead to plausible results, these three or four groups are preferable, since the archetypes thus become more differentiated. The data set in this constellation is too small to accommodate more than four groups. Although several measures can calculate the optimal number of clusters, several studies have shown that these measures lead to such different results that a qualitative assessment is more appropriate for our study (Gimpel et al. 2018; Janssen et al. 2020). Accordingly, we analyzed the distribution of the characteristics when separated into three and four groups in further detail. If the study were to be divided into four groups, no plausible groups could be identified. No clear differences could be identified between two of the four groups. We thus concluded that a division into three groups leads to plausible results. The distribution in the case of a separation into three groups is shown in Table 3.

We have assigned each group a label that reflects its essential characteristics. Thereby we refer to the groups or archetypes as all-rounder with advanced analytics (A), simple ad hoc application scenarios (B), and tools used by information producers (C). In the all-rounder with advanced analytics archetype, all user skills are typically covered by the analyzed SSBIA tools. All analytics and data management activities are typically possible. Most tools support the individualization of other people's reports. Frequently, mobile BI applications can be realized, but many tools of this archetype already include a natural language chat. All kinds of analyses are supported.

In the archetype simple ad hoc application scenarios, the basic + standard user skill is supported. In rare application scenarios, other skills are also supported. No advanced analytics functions are offered, and data management is limited to the integration of new data sources. The individualization of other people's reports is supported as a form of collaboration, and analyses can usually be accessed via mobile devices. The tools associated with this archetype very often focus on ad hoc analyses.

The user role information producer is the focus of the archetype tools used by information producers. Standard + advanced is often addressed as a user skill. The skill basic is therefore rarely included. Either no analytical activities or advanced analytics are enabled. Most such tools support data management with data cleansing and enhancing. Collaboration is frequently not supported. Access to all tools is possible only via desktop. Above all, standard reporting is addressed in this archetype. Table 4 summarizes the archetypes thus found.