Success factors for managing the SSBI challenges of the AQUIRE framework

ABSTRACT

Self-service business intelligence (SSBI) enables all users, including those with limited technical skills, to perform business intelligence (BI) tasks without the support of BI experts. SSBI reduces pressure on BI experts, gives more freedom to self-reliant users and speeds up decision-making. Recent research has illustrated how organisations experience numerous challenges when trying to obtain SSBI benefits. The AQUIRE framework organises 37 identified SSBI challenges in five categories: Access and use of data, Data Quality, User Independence, creating Reports and Education. SSBI literature does poorly address how these challenges can be tackled. This research study aimed to identify strategies on how to manage those 37 SSBI challenges. The performed case study includes 24 semi-structured interviews with respondents from two organisations which have been heavily involved in SSBI implementation. The results reveal how nine identified SSBI success factors are related to the 37 AQUIRE challenges and how they can be addressed over time.

KEYWORDS:

• Self service business intelligence
• success factors
• challenges
• SSBI
• education

Introduction

Self-service business intelligence (SSBI) aims at simplifying the application of Business Intelligence (BI) in organisations by enabling all users to access and use data to create content and conduct analysis by themselves (Alpar and Schulz, 2016; Kabakchieva et al., 2013). Business intelligence (BI) is an umbrella term that combines technology, managerial processes and products to organise data used by decision makers, ranging from strategic to operational levels within and organisation (Chaudhuri et al., 2011; Chee et al., 2009; Foley & Guillemette, 2010; Power, 2007; Williams & Williams, 2007). In traditional BI, a request-response scenario exists between casual users (employees, managers and executives who lack technical BI skills) and power users (IT department staff who have technical skills to set up, run and use BI). Casual users are not able to select and analyse data and create reports with appropriate data visualisations themselves. Power users serve casual users by producing custom-made reports for time-critical decisions and may assist again and again for realising small changes (such as altering the selected data or the type of visualisation). When the number of casual BI users and the volume of requests increase, a bottleneck arises in traditional BI since power users are not able to serve casual users in a time efficient manner (Alpar and Schulz, 2016; Imhoff & White, 2011; Yu et al., 2013). Self-service BI is a response to meet the bottleneck between the user groups (Alpar and Schulz, 2016; Analytics, 2015; Kabakchieva et al., 2013). SSBI is defined as ‘The facilities within the BI environment that enables BI users to become more self-reliant and less dependent of the IT organization. These facilities focus on four main objectives: easier access to source data for reporting and analysis, easier and improved support for data analysis features, faster deployment options such as appliances and cloud computing, and simpler, customizable, and collaborative end-user interfaces’ (Imhoff & White, 2011).

SSBI promises that all users can work in a self-reliant manner and are able to alter content as desired when making decisions without queuing and waiting for a new report (Alpar and Schulz, 2016; Kabakchieva et al., 2013). SSBI reduces the pressure on the IT department since power users do not have to serve casual users in creating reports. SSBI enables effective data-driven decision-making and increases organisational performance (Alpar and Schulz, 2016; Analytics, 2015; Imhoff & White, 2011).

Recent reports from 2017 and 2018, targeting Swedish organisations with more than 300 respondents, show that the interest in SSBI is increasing (Svahn & Ax, 2018; Svahn et al., 2017). Even though SSBI promises many benefits, the implementation rate of SSBI is still relatively low (Lennerholt et al., 2020a; Svahn et al., 2017; Svahn & Ax, 2018; Stodder, 2015; Analytics, 2015). Research has identified numerous challenges that may hamper SSBI implementation and use: difficulties to access and use data, poor data quality, users who are not self-reliant after all, barriers to create SSBI content and a lack of appropriate SSBI education (Daradkeh & Moh’d Al-Dwairi, 2017; Lennerholt & van Laere, 2019; Lennerholt et al., 2020a, 2020b, 2018; Passlick et al., 2020; Schlesinger & Rahman, 2016). Studies on how to manage such SSBI challenges are rare and lack detail (Daradkeh & Moh’d Al-Dwairi, 2017; Passlick et al., 2020; Paul et al., 2016).

This study presents nine success factors for managing SSBI challenges and discusses how they are related to identified SSBI challenges and how they can be applied them over time. For researchers, our results can serve as a research agenda to further explore the difficulties of managing challenges of SSBI implementation and use. For practitioners, the overview of challenges and success factors can increase awareness for potential hinders and provide guidance on how to overcome them.

Challenges of SSBI: the AQUIRE framework

When SSBI is interpreted or marketed as performing simple data-analytical tasks with easy-to-use tools, it might create the false impression that no challenges exist when implementing and using SSBI. Recent research shows that SSBI consists of numerous challenges (Daradkeh & Moh’d Al-Dwairi, 2017; Lennerholt & van Laere, 2019; Lennerholt et al., 2020a, 2020b, 2018; Schlesinger & Rahman, 2016; Weber, 2013). In order to present recently identified challenges of SSBI in a coherent way, the AQUIRE framework has been developed (Figure 1, Table 1 and appendix 1). The AQUIRE framework summarises 37 identified SSBI challenges (Table 1) within five areas of interest: Access and use of data, Data Quality, User Independence, creating Reports and Education (Figure 1).

Figure 1. The AQUIRE framework for organising SSBI challenges.

Table 1. SSBI challenges in the AQUIRE framework.

SSBI challenges for Access and Use data
(1) Difficult to access data (2) Unaware of data sources (3) Difficult to make data available (4) Takes long time to request data access (5) Multiple data sources in different environments (6) Use correct data queries (7) Control of data integrity, security and distribution (8) Policies for data management and governance (9) Prepare data for visual analytics
SSBI challenges for Data Quality
(10) Faulty data exist when making decisions (11) Difficult to correct faulty data (12) Difficult to determine right level of quality (13) Difficult to define data (14) Low awareness of using faulty data
SSBI challenges for User Independence
Access and use data: (15) Difficult to know available data sources (16) Difficult to locate data (17) Difficult to use data (18) Difficult to use many different data sources (19) Support is required to add data Low user skills: (20) Limited competence level (21) Difficult to interpret report content (22) Limited general IT skills Difficult SSBI tools: (23) Difficult to use SSBI tools (24) Users create isolated solutions (25) Give the right tools to the right user
SSBI challenges for Creating Reports
Create and change content: (26) Difficult to create SSBI reports (27) Requires lots of time and manual work (28) Difficult to change content Assure quality: (29) Difficult to assure quality of reports (30) Redundant reports exist (31) No governance of SSBI reports (32) Unsupported tools are used
SSBI challenges for SSBI education
No formal education: (33) No formal educations are given (34) Users forget how to use SSBI (35) Not using SSBI after education Low interest in SSBI: (36) Users do not see the benefits of SSBI (37) Users have different technical backgrounds

Just like power users in BI, casual users in SSBI struggle with issues such as choosing data properly, using correct queries and combining and migrating data from different sources given unclear data definitions and inconsistent and contradictory data. Data access and use needs to be simplified with SSBI, but a poor implementation may create a new request-response relationship for data access. Instead of waiting for reports, casual users can end up waiting for data access. On the other hand, the IT department may be reluctant to give all user access to all data, as that may jeopardise data quality and report quality and because it may be overwhelming for casual users to navigate between and understand definitions of all kinds of data sources they might not need. SSBI users may, due to their limited data-analytical skills, have low awareness for data quality issues such as faulty, inaccurate or irrelevant data. The AQUIRE framework highlights the important distinction between the supply side of the data access and use problem (how data are defined and provided) and the consumption side (behaviour and skills of users and features of SSBI tools). SSBI users do not experience creating reports as ‘basic analytical tasks’ but perceive that creating SSBI reports takes a lot of time, a lot of manual work and witness that it might be tricky to change content. Users with difficulties to create SSBI reports can produce redundant or faulty reports, and when others reuse those reports, quality problems are unfolding. Besides data quality (well known from BI), report quality becomes an extra challenge in SSBI. Finally, education of users is underestimated when SSBI is marketed as an easier form of BI. Courses are often too introductory and SSBI users have difficulty in applying acquired skills in their daily work.

Whereas knowledge about the unique challenges of SSBI has grown in recent years, there is little understanding of what strategies are needed to manage the 37 SSBI challenges of the AQUIRE framework.

Success factors for managing SSBI challenges

Success factors are requirements to fulfil or strategies to apply in order to achieve a goal or mission fruitfully (Gaardboe & Svarre Jonasen, 2017). Table 2 summarises success factors for SSBI implementation currently acknowledged in the literature (Berndtsson et al., 2019; Daradkeh & Moh’d Al-Dwairi, 2017; Passlick et al., 2020; Paul et al., 2016).

Table 2. SSBI success factors.

Success factors for SSBI implementation and use	References
To have access to valid, accurate and reliable data Addressing data quality Perceived usefulness of SSBI Show the benefits of SSBI in education Educate on technical and non-technical elements of SSBI Users have experience with traditional BI Easy-to-use SSBI tools	(Berndtsson et al., 2019; Passlick et al., 2020; Daradkeh & Moh’d Al-Dwairi, 2017; Paul et al., 2016)

A commonly mentioned SSBI success factor is the ability to access valid, accurate and reliable data (Daradkeh & Moh’d Al-Dwairi, 2017; Passlick et al., 2020; Paul et al., 2016), although it is not explained in these studies how that could be realised. Another success factor influencing the effectiveness of SSBI is addressing data quality (Daradkeh & Moh’d Al-Dwairi, 2017; Passlick et al., 2020). Once data are of high quality, users will see the benefits in SSBI. Again, little information is given on how data quality can be guaranteed in a SSBI context, which differs from BI prerequisites. Perceived usefulness is another success factor (Daradkeh & Moh’d Al-Dwairi, 2017; Passlick et al., 2020). Berndtsson et al. (2019) argues that SSBI education could show users SSBI benefits by giving them examples they can relate to, which would contribute to perceived usefulness. Furthermore, Berndtsson et al. (2019) explain how education should address both non-technical skills (how to recognise what data to pick for certain decisions, how to recognise poor data quality) and technical skills (creating data definitions and cleaning data). Another success factor for SSBI is when users have previous experiences of working in traditional BI environments (Daradkeh & Moh’d Al-Dwairi, 2017; Passlick et al., 2020). Finally, if the SSBI tool is difficult to use or has a non-user-friendly interface, users tend to consider SSBI as not useful, which reduces motivation to use SSBI (Daradkeh & Moh’d Al-Dwairi, 2017; Passlick et al., 2020). Therefore, SSBI software developers should focus on developing tools that have a clear layout with an interface that is user-friendly and easy to use (Daradkeh & Moh’d Al-Dwairi, 2017; Passlick et al., 2020).

In contrast, research on BI success factors is more exhaustive. Gaardboe and Svarre Jonasen (2017) summarise 34 BI success factors based on an extensive literature study which included 444 articles. It is questionable whether BI success factors are applicable in an SSBI context. SSBI implementation challenges differ clearly from traditional BI implementation challenges (Lennerholt et al., 2020a). Consequently, BI success factors may at best serve as candidates for SSBI, but most likely they need to be adapted to the unique context of SSBI. Traditional BI still faces major implementation challenges (Gudfinnsson et al., 2015; Ni et al., 2019) despite exhaustive research on challenges and success factors for BI implementation (Gaardboe & Svarre Jonasen, 2017). Consequently, there is a need to increase understanding in the unique success factors for SSBI implementation.

In summary, research on SSBI success factors is still immature and descriptions of the few known SSBI success factors lack detail considering what exactly is meant or how practitioners should act to achieve them. The aim of this study is therefore to identify and more thoroughly describe SSBI success factors which are appropriate for managing the 37 SSBI challenges of the AQUIRE framework.

Research design

This research follows an interpretative research strategy aiming at an in-depth understanding of success factors for managing SSBI challenges (Braa & Vidgen, 1999). A case study has been chosen as a research method for answering ‘how’ and ‘why’ questions related to the research aim by means of interviews (Braa & Vidgen, 1999; Yin, 2013). The focus is to collect rich and detailed accounts of how SSBI success factors are applied. The research adopts a socio-technical perspective by studying individuals who are using SSBI within an organisational context to perform their daily work.

Case and interview respondent selection

In order to obtain as rich and diverse accounts of SSBI success factor application as possible, case and interview respondent selection aimed at including organisations and employees with different backgrounds. The case study includes two organisations, a consultancy firm and one of their major clients, who both have a lot of experience with SSBI implementation and use. The client organisation provides first-hand experience of their own SSBI journey, while the consulting organisation contributes with experiences from managing SSBI challenges in over 200 SSBI implementation projects at a large variety of customers. Five SSBI consultants and seven client employees were selected as interview respondents. The client employees covered roles including vice-presidents, consultants, analysts, SSBI champions, BI developers, business improvements managers, strategists, business controllers, IT specialists, managers and end users. All respondents had on average 5 to 10 years of experiences with BI and SSBI.

Data collection

Data were collected during autumn 2020 via 24 semi-structured interviews conducted via phone. Each respondent participated in two interviews. The first interview aimed at identifying SSBI success factors and clarifying how they are related to one or more of the AQUIRE challenges. The follow-up interview aimed at filling in missed details or asking new questions for a deeper understanding. One example is that many respondents emphasised in their first interview that challenges should be managed in a certain sequence and that some success factors were relevant early and others later. Consequently, timing and sequence of success factors arose as an unexpected result. Each main interview was recorded, transcribed and validated by each respondent before the content was analysed. On average, each interview lasted one hour.

Data analysis

The qualitative analysis of transcripts applied open, axial and selective coding where the unit of analysis is to identify success factors (Wolfswinkel et al., 2013). First, open coding was used to identify a main set of success factors. Then, axial coding was used to identify sub-categories to visualise how the data portray the identified success factors. Finally, selective coding grouped segments of text that represent the identified categories. This is an iterative process that portrays each segment of text related to an identified success factor. The coding process was considered complete once no new success factors or related text segments were identified. The qualitative coding process was conducted manually using a word processor and colours to code each segment of text and its related success factors. A manual process can achieve a higher level of control compared to an automatic software tool. The result of the coding process consists of nine success factors. These were validated by respondents during the follow-up interviews.

Results

The analysis of the case study material revealed the following success factors:

1. Use pilot groups

2. Use champions

3. Identify user groups and their data needs

4. Allow end users to change faulty data

5. Create common data definitions

6. Serve ready-made standard reports

7. Let business govern SSBI content

8. Integrate IT in the business department

9. Educate users

In the remainder of this section, in-depth accounts from the case study analysis are presented that show what each SSBI success factor involves, how it addresses one or several SSBI challenges and how it builds upon earlier success factors or lays the foundation for subsequent ones. To provide the reader with a rough orientation before entering the detailed descriptions, Figure 2, Table 3 and Table 4 depict how the success factors are related to each other and the AQUIRE framework challenges in different ways. These relations will be further explained throughout the results section and summarised in the discussion and conclusion sections.

Figure 2. Success factors for managing the SSBI challenges.

Table 3. Sequential application of success factors.

Success Factors	A	Q	UI	R	E
Use pilot groups Use champions Educate users			x x		x x x
Identify user groups and their data needs Allow end users to change faulty data Educate users	x	x	x	x	x
Create common data definitions Serve ready-made standard reports Educate users	x x	x	x x	x	x
Let business govern SSBI content Integrate IT in the business department Educate users			x x	x x	x

Table 4. Changing nature of SSBI education over time.

Success Factors	Education Casual Users	Education Power Users
Use pilot groups Use champions	Increase SSBI interest
Identify user groups and their data needs Allow end users to change faulty data	Navigate SSBI tools Use available data sources Awareness of data quality
Create common data definitions Serve ready-made standard reports	Use standard reports Interpret and filter data	Define and clean data Create standard reports
Let business govern SSBI content Integrate the IT department with the business	Govern SSBI content Become self-reliant Create SSBI reports	Monitor SSBI governance Learn basic business tasks Support and coaching routines

Figure 2 visualises how the nine success factors relate to the categories of SSBI challenges in the AQUIRE framework.

Table 3 portrays how the success factors are applied sequentially and how they over time address different categories of challenges of the AQUIRE framework.

In Table 3, it becomes evident how Educate Users is an important success factor throughout all phases. In Table 4, it is illustrated how education changes content and addresses different user groups from phase to phase, emphasising that this single success factor changes nature and is applied differently over time during an SSBI implementation process.

Use pilot groups and champions to raise interest for SSBI bottom-up

Most respondents describe how the journey towards SSBI should start with small steps by using a pilot group. Individuals in the pilot group should have a positive attitude to SSBI and have necessary skills to demonstrate SSBI benefits. Many respondents emphasise that these pilot groups should be implemented before the organisation launches a major SSBI project that covers the entire organisation. First, the pilot group must be able to show top management and other users within the organisation what the SSBI initiative has to offer, by illustrating the benefits compared to old ways of working: ‘In order to succeed with SSBI, a pilot group is needed to show the benefits of SSBI. Otherwise, users tend to go back to old habits. The SSBI initiative should not be initiated by managers, instead users must see the benefits themselves in order to achieve an interest’. The pilot group is a means to create an interest among users, which provides fertile grounds for a major SSBI implementation within the entire organisation later on. This bottom-up approach is preferred over a top-down approach as, for example, a major project launch driven by top management. Another respondent confirms: ‘You cannot let top management within an organization initiate a SSBI initiative. The aim is to create a need amongst users. They should see the benefits of SSBI in order to obtain a desire to use SSBI. A pilot group is the only way to demonstrate the benefits of SSBI before a major SSBI project can be launched’. A pilot group can create a ripple effect, i.e. spreading the perceived benefits of SSBI among the workforce: ‘a pilot group is by far the most important factor to succeed. I can easily see users who are resistant to change and who question an initiative on beforehand. But once they start to see real work processes and the benefits SSBI offers, they become convinced’. In conclusion, our case study data clearly emphasise that a bottom-up approach with a pilot group is to be preferred over a leadership-led top-down implementation of SSBI.

A closely related strategy for SSBI success is to use champions who can create an interest for SSBI. Pilot groups and champions aim at overcoming resistance to change, both related to the AQUIRE challenge that users might have a low interest in SSBI. A champion of SSBI can create a positive impression and awareness for SSBI benefits: ‘A key to why we have succeeded with SSBI is the use of a champion. It is crucial to have someone who has a strong commitment and can show the benefits of SSBI to others’. The champion should be part of the pilot group of the SSBI implementation since they often have a genuine interest to succeed: ‘I have been involved with so many SSBI projects and can easily see if it will succeed or not. The use of a champion is key since they can drive the pilot group and talk fruitfully about SSBI. This is important to get other individuals on board. Otherwise, user resistance is a difficult challenge to overcome’. The results show the importance of using champions when starting the journey towards SSBI. The champion must have the technical and business skills needed to understand the entire chain of using SSBI, ranging from accessing data, creating reports and the analysis needed to make a decision: ‘An end user does not know the importance of using the right data since they are normally never accessing it themselves. But this is needed when enabling SSBI. A champion can easily be the person who shows how to use SSBI and who also talks about the importance of accessing the right data’. The results show that using champions is important and that the implementation of SSBI is more difficult without them.

Identify user groups and their need of data and allow them to change faulty data

To start addressing data access-related challenges of the AQUIRE framework, organisations need to understand what kind of decision users within a department normally are facing and what data are needed to support these decisions: ‘Step one is to think through what data sources that the users normally need. It is very important to understand which sources that are needed for a specific group of users. But it requires that you need to determine who these users are, what kind of decisions they make. Perhaps within a department of a work process’. Solving the data access challenges by releasing all data to all users within the organisation is not a fruitful strategy: ‘It is not easy to know when users need. Therefore, a quick solution is to release all data to everyone, which is not the right way’. Non-technical SSBI end users are not capable themselves of finding and selecting the appropriate data from all available data. Instead, data access for non-technical SSBI users should be simplified. When organisations distinguish different user groups and identify what data they need to make decisions, they can provide each user group with limited amounts of data that match their unique needs: ‘The first step should be to identify what data sources that are available and which of them are suitable for a typical role within the organization’. For example, data needs differ between users working in a sales department and someone working in the financial department. Champions, who understand the business benefits of SSBI and have technical knowledge about available data sources within the organisation, can assist user groups in identifying which data sources that are important for their typical decisions. When non-technical SSBI users only get access data relevant for their everyday decisions, they are better equipped to start performing more complex tasks that technical users did before, such as changing faulty data.

Then, the next success factor, allowing the end user to change faulty data, is related to the AQUIRE challenge of data quality. Typically, SSBI users who recognise faulty data are not allowed to modify it: ‘SSBI users in business departments are per definition not allowed to remove or alter content by themselves. It will not happen since IT departments are responsible for data governance’. It normally requires contact with power users within the IT department to change data, which is a time-consuming process that hinders the effectiveness of SSBI. The case study results highlight the importance of allowing end users to change faulty data themselves. Users should have permission and be trusted to alter content without support or surveillance from power users within the IT department: ‘Certain data that are critical and important and must be correct without errors. Customers with their invoices etc. require that data is correct. Users who identify faulty data need to be able to alter content right away. But this is not always the case for SSBI since other users from different departments have inserted data and the analyst in another department does not have permission to alter this content’. Business users should be able to change content right away. ‘If end users have accessed data and find faults, they should be allowed to change it. IT has already trusted the users to gain access, so why not give permission to change faults also?’ Respondents emphasise that it becomes easier to change content themselves when organisations have identified user groups and their data needs. The ultimate aim of SSBI is to permit business users to govern their own content. This is especially relevant in later phases when end users start to create reports by themselves. In the beginning of a SSBI implementation, permission to change faulty data could be given to more technically skilled end users within each user group. They can change faults faster for their colleagues compared to power users in the IT department. Gradually, more users can get permission to change data until eventually all business users can access, use and change data that are related to their user group as desired. To arrive at this final state, our case study respondents argue that more technically skilled end users already should receive permission to change faulty data early on in an SSBI implementation process.

Create common data definitions and serve ready-made standard reports

In order to enable non-technical users to become self-reliant when using SSBI (in accordance with one category of challenges in the AQUIRE framework), it is important to make sure that end users understand what the data actually represent. An organisation implementing SSBI needs to create common data definitions, so data sources are prepared in a way that non-technical users can utilise them.

For instance, data can consist of too short labels or really long names which are difficult to understand: ‘You need to describe what the data means. Their labels are often abbreviations or long names that are difficult to understand’. The same goes for data that are labelled differently but actually mean the same, which is challenging especially for a non-technical user. A common data definition that describes data sources that are normally used by a group of users facilitates the use of SSBI: ‘You have to describe the most central data sources and its content for a specific user group. You need a common approach for data definitions to make SSBI work efficiently’. Clear data definitions are an important prerequisite for enabling non-technical users to perform data analysis tasks in a proper way: ‘The largest part, probably 95%, of SSBI is to prepare data, to build common definitions that structure data. The remaining 5% is to let users use the data and to enable them to filter content the way they want’. Making sure that end users understand the data they use is an important prerequisite to avoid data quality problems later on: ‘The next step is to explain these central data sources and its content. I believe it is all about making data very clear, re-name data to make it more correct for the purpose being used within different reports. The focus is to remove all uncertainties within the data’. When users have access to limited amounts of data especially relevant for them and can easily understand data since there is a common data definition, some great steps have been taken towards SSBI success with regard to the AQUIRE challenges of data access and use.

Considering the AQUIRE challenges related to letting non-technical SSBI users create their own reports and alter report content by themselves, case study respondents argue to offer ready-made standard reports that are useful for a specific group of users: ‘An important step in the process towards SSBI is to create ready-made standard reports’. These standard reports should contain data that these users typically utilise when making decisions. Power users should focus on creating report templates that are based on typical data needs that exist for each identified user group. When casual users use such report templates, it minimises the risks of using wrong data or missing important data sources. The aim is to create reports that are easy to understand by non-technical users, so they are able to understand the content and can filter data to suit their needs when making decisions. When power users create standard reports, they should also focus on cleaning data as much as possible. Power users have the technical skills to identify and remove faulty data before they are used when creating reports: ‘If you create standard reports you have the ability to spend lots of time cleaning data in order to minimize problems of using faulty data later on. This should be done by power users within the IT department were the aim is to serve reports that are as clean as possible’.

Next, once casual users are becoming more matured and experienced using SSBI, they can become more self-reliant in creating reports by accessing and using data as desired: ‘Part of the beginning of SSBI is to create standard reports that are built on data that we have spent lots of time cleaning. When you have achieved great data sources and a data warehouse that consists of nice and structured data you can start to create and offer standard reports to these specific user groups. Once you achieve this, implementing and using SSBI is fulfilled, right?’ Another respondent (a power user) explains in a similar way: ‘We have started to serve ready-made standard reports, which is a great solution for users who have difficulties with data quality. We, who have knowledge about all data sources, can more easily eliminate faults on the source level before data is used in reports. This minimizes the risks for end users who could easily include faulty data otherwise. In the beginning of SSBI, these users should not create the reports all by themselves’.

Let business govern SSBI content and integrate IT in the business department

The responsibilities for governance of IT systems, architecture, data, etc. are one of the many core responsibilities of an IT department. It involves setting up rules on how the data sources and systems are used by its users within the organisation as a part of conventional IT security, data assurance and data quality. Unfortunately, when responsibility for data governance resides at the IT department, it complicates the implementation and use of SSBI with respect to the AQUIRE challenges of data quality. In SSBI, all users are supposed to be self-reliant when using BI, which includes the entire process of accessing and using data as desired. Governance in SSBI is not only related to data but also to reports, as illustrated in the following quote: ‘SSBI users create reports as they like, and it is common that colleagues create the exact same report. Within a couple of years, they realize that there are lots of redundant reports available. You have no idea which reports that are used anymore and the IT department do not dare to delete them’. The case study material includes a success factor that deals with this challenge and argues to let business users govern SSBI content themselves: ‘Users who have created the report should also be responsible to govern the content. They are the ones who understands the usefulness of the included data’. As already discussed with respect to allowing one to change faulty data, end users are experts within their business processes and are aware of the content they use. Different business units should appoint employees responsible for data analysis typically related to their specific business process, for example, purchase, sales, finance, etc. One respondent argues: ‘I recommend that there are people who own the analysis out in the business. Someone owns this purchase process. It becomes even better if some power users from IT meet the business. Like if there is a mix between power and casual users in the business’. Business users need to be responsible for the governance of SSBI content (i.e. data and reports) specific for their business processes. This is a next step building on earlier success factors: identify user groups and their information needs related to a specific business process and allow them to change faulty data. Consequently, business users should get full responsibility to govern content themselves, instead of letting the IT department govern content as they always did before. Business departments know best if SSBI reports are still useful or outdated.

The case study results suggest reconsidering the relation between the IT department and the business departments. Instead of acting as two separated islands where an IT department assists business departments, respondents describe a mixture of competences in business departments. When power users from the IT department are working closely together with casual users in business departments, the time-consuming request and response scenario will be eliminated: ‘You need to mix competences. You cannot have users at the IT department and the business sitting isolated by themselves. They need to be integrated with each other. We do this at some of our customers and they become more self-reliant and gain speed when using SSBI compared to others who do not mix users. It is an important new way of working’. Business departments who apply SSBI should consist of both power and casual users. When power users from IT are working more closely with business users, they are instantly available for answering questions, while they at the same time professionalise SSBI in the business departments: ‘We are working on a change with regard to the IT department. They need to loosen control and let the power users work with business more closely, becoming part of the business department. Power users we are working with are sitting with business users, working with information models and the standard reports that the business users are applying on a daily basis. These power users focus on growing the SSBI content within the business. They also become an operational support, which is useful when enabling SSBI’.

Educate different user groups and change education content over time

The case study results explain how SSBI requires education which initially should focus on the benefits of SSBI and the core functionalities on how to use SSBI on a daily basis (see, Table 4): ‘I focus a lot on educating users how to find real value in using the data. Thereafter I continue in different stages. But the main idea is to get something out from SSBI, real numbers, and to teach users how to use the basic functionalities of SSBI so they understand the functionalities of the tools. I also show them a lot of tips and tricks, how they can work with colors, diagrams and how to find deviations. Once these users learn the basics of SSBI, their interest grows’. This kind of education aims at creating an interest in SSBI in the early stages. Users also tend to learn more and more when they are using SSBI on a daily basis, especially when more skilled colleagues are working close to them (champions in pilot groups in the early phases and power users in their business units later on).

Instead of focusing on giving an overall SSBI education to everyone, our case study results emphasise that education should be targeting two different user groups. One type of education should target the more technically skilled users who are able to understand the back end of BI and how to access and use data. The other type of education should be designed for non-technical users, i.e. the casual business users who consume BI content: ‘We have a battery of pre-built reports. Our education focuses on two user groups. One tackles how to build these reports, which includes how to access and use data. This course is given to the more technically skilled users. The other part targets the non-skilled users who consume these reports. We focus on educating how to understand content in these reports, how to alter the content to analyze from different angles’. The education for technical users should focus more on the back end, which includes the access and use of data and the creation of reports. The education for non-technical users should focus on the SSBI tools itself and how to analyse content in reports, how to alter the content and to understand how to make decisions based on these reports: ‘We focus a lot to show the basics to all users in order to create an interest so they are able to work more self-reliant. We are satisfied when the non-technical users are able to understand the SSBI tool, the report and its content and has the ability to alter content to their desire. That is what SSBI is all about?’

Discussion

Whereas recent research has identified numerous challenges for SSBI implementation (Table 1), research on SSBI success factors is limited (Table 2). Also, SSBI success factors in the literature lack detail considering what exactly is meant or how practitioners should act to achieve them. In contrast, the rich descriptions of the nine SSBI challenges identified in this study provide clues on how each of them is related to different categories of challenges in the AQUIRE framework,and how they sequentially build upon each other. For example, Table 3 summarises how different SSBI success factors first address user education and user independence and later on tackle data access and data quality challenges. Also, it is visualised and explained how early SSBI success factors such as champions and identifying user groups and their data needs become prerequisites for later SSBI success factors such as changing faulty data or letting business departments govern their own SSBI content. In summary, the research contribution is a rich account of how nine SSBI success factors tackle the challenges of the AQUIRE framework.

At first glance, the SSBI challenges in the AQUIRE framework and the nine identified SSBI success factors listed in Table 3 might be misinterpreted as resembling typical BI challenges and BI success factors (i.e. data access, data quality, user education and championing). Whereas SSBI challenges and BI challenges are labelled the same, they may be rather different in nature (Lennerholt et al., 2020a). The same holds for SSBI and BI success factors. The challenge of data access for a power user in traditional BI is different from the challenge of data access for non-technical end users in SSBI. Similarly, creating data definitions amongst power users in traditional BI is different from creating data definitions so non-technical end users can utilise data in a self-reliant way in SSBI. A project leader champion in BI contributes in a different way than the suggested pilot group champion in SSBI. In the remainder of this discussion section, it is highlighted how the SSBI success factors identified in this study differ from known SSBI success factors and typical BI success factors.

Champions push pilot groups

Whereas SSBI literature does not acknowledge championing as a SSBI success factor (Table 2), BI literature often mentions the importance of using ‘a project leader and champion’ when implementing traditional BI (Montero & Lind, 2021; Mosavi & Santos, 2021; Tsoy & Staples, 2020). In BI, this success factor focuses mainly upon the operational management of the BI implementation project itself and how to achieve implementation success. The role of project leaders as champions involves pushing the project forwards, by recruiting team members who can contribute to reaching success and by coordinating their tasks.

According to this case study, championing is important for implementing and using SSBI as well, but in a different form. The case study results suggest that we did not start the journey towards SSBI in a large project implementation format. Instead, the focus is to use small pilot groups to show the benefits that SSBI offers. The use of champions contributes to success by highlighting the benefits of SSBI and by motivating employees to actually prefer the use of SSBI over old ways of working with BI. Champions in SSBI are coaches who support employees in developing interest in SSBI and acquiring SSBI skills. In contrast, champions in BI are project leaders managing the implementation project.

SSBI cannot succeed without differentiated education

Berndtsson et al. (2019) highlight the need to train SSBI users in technical and non-technical skills. Even in the BI literature, ‘Education and user training’ is frequently mentioned as a success factor (Montero & Lind, 2021; Mosavi & Santos, 2021; Tsoy & Staples, 2020). SSBI is typically marketed as simplifying the usage of BI and many organisations believe that education is not needed since they already educated and trained employees in BI (Lennerholt et al., 2020a, 2020b, 2018). Respondents in this case study argue that education definitely is needed in SSBI implementation. Initially, it should focus on casual users and demonstrate the benefits of SSBI. Later, it should target different audiences: technical power users and non-technical casual users. Education for power users should focus more on the back end of SSBI and on understanding analysis and decision-making in business departments. Casual users need to learn to use the front-end of SSBI and should become more aware of data quality and how they can correct faulty date themselves.

Whereas the BI literature also acknowledges that power users and casual users have different training needs (Deng & Chi, 2012), recommendations of how that impacts the content of BI training programmes are typically rather vague, for example, ‘those system use problem patterns should be addressed by a training curriculum on an ongoing basis so as to develop training programs that “click” with the users’ (Deng & Chi, 2012, page 317). In contrast, our findings elaborate the suggestions of Berndtsson et al. (2019) in more detail and describe what kind of training power users and casual users need in different phases of an SSBI implementation.

Focus on bottom up user interest before top management support

SSBI literature does not recognise ‘Top management support’ as a SSBI success factor (Table 2), while it is commonly mentioned as an important success factor for BI implementation (Montero & Lind, 2021; Mosavi & Santos, 2021; Tsoy & Staples, 2020). In BI, executives and leaders within an organisation must be strongly involved in the BI project in order to succeed. According to the case study results, the opposite holds for SSBI. Top management should not be included from the start when implementing SSBI. Instead, smaller pilot groups and champions should operate without any connection to a major SSBI project. This is emphasised many times during the case study interviews where employees repeatedly highlight the importance not to use top management support from start. It becomes too difficult for all employees to embrace SSBI in general terms since they already use traditional BI on a daily basis. Instead, employees need to understand the benefits SSBI offers before top management is involved and launches a major SSBI implementation project. SSBI should be built on a foundation where employees already are convinced of the benefits that SSBI offers before an organisation-wide implementation is rolled out.

Data and report governance is a business responsibility

The ability to access valid, accurate and reliable data and the need to address data quality are SSBI success factors, which already are acknowledged in the literature (Daradkeh & Moh’d Al-Dwairi, 2017; Passlick et al., 2020). Existing SSBI literature does, however, not explain how to actually realise this.

In BI, the responsibility for data sources and BI content lies with the IT department and its power users (Berndtsson et al., 2019; Daradkeh & Moh’d Al-Dwairi, 2017; Passlick et al., 2020; Paul et al., 2016). They are in charge of serving BI content and make sure that data sources are up to date and valid. When casual users identify faults in BI, they need to contact power users for corrections, which is a time-consuming process. The case study results suggest that the efficiency of SSBI increases when business users are allowed to change faulty data and govern SSBI content and data themselves. Correspondently, the relation between the IT department and the business changes. The aim is to build business departments where power and casual users mix competences, which eliminates the request response scenario between the business units and the IT department. The case study organisations discuss examples where power users who normally worked within the IT department now are integrated in the business departments and working there part time as an SSBI end user.

Limitations and future research

SSBI success factors in this case study differ from those for implementation of traditional BI. SSBI implementation and use requires new ways of thinking, as indicated by the 37 SSBI challenges in the AQUIRE framework and the nine SSBI success factors identified in this study. Research on SSBI success factors is still limited, as witnessed in Table 2. Consequently, a suggestion for future research is to conduct more studies for identifying and understanding additional SSBI challenges and SSBI success factors. Another suggested research focus is to follow different organisations and investigate how they work with the AQUIRE framework and the suggested success factors. Some success factors could be more difficult to implement compared to others, and organisations may tackle SSBI challenges differently. An interesting investigation would be to understand why.

Finally, an unexpected result of this study was the observation that success factors preferably can be applied in a certain sequence, addressing certain SSBI challenges first and others later (see, Table 3). The sequence should be understood as a map with possible routes and areas, rather than a fixed path. How the journey unfolds, and whether some phases are more or less relevant and can be addressed shortly or more intensively, may differ from organisation to organisation. A deeper understanding of how the sequential application of SSBI success factors may vary depending on contextual circumstances would be another interesting research avenue.

Conclusion

The implementation and use of SSBI brings numerous challenges. The AQUIRE framework organises 37 identified SSBI challenges in five categories: Access and use of data, Data Quality, User Independence, creating SSBI Reports and SSBI Education (see Table 1 and appendix 1). The aim of this research was to identify success factors for managing SSBI challenges. The conducted case study reveals nine SSBI success factors:

1. Use pilot groups

2. Use champions

3. Identify user groups and their need of data

4. Allow end users to change faulty data

5. Create a common data definition

6. Serve ready-made standard reports

7. Let business govern SSBI content

8. Integrate the IT department with the business

9. Educate users

The qualitative analysis of 24 case study interviews did also explain how these nine SSBI success factors are related to the 37 SSBI challenges of the AQUIRE framework (Figure 2) and how they can be applied in a logical order throughout an SSBI implementation process (Table 3).

According to these findings, organisations should start their SSBI journey by setting up a small pilot group consisting of experts who speak warm about SSBI and who have the competences needed to set up and run SSBI. The purpose is to show the benefits of SSBI by demonstrating examples that users can relate to and compare with previous ways of working in traditional BI systems. SSBI champions need to be available close to casual users. Casual users in need of support can turn to champions and get quick answers, rather than ending up in a time-consuming request and response relationship with a central IT department. SSBI education should initially focus on showing SSBI benefits and explain basic SSBI tasks. Pilot groups, champions and early SBBI education have one common goal: increase interest in SSBI bottom up.

While creating interest bottom up, pilot groups and champions can identify different user groups and their data needs. Gradually, casual users can be introduced to data sets valuable for their decisions (rather than all available data) and made aware of data quality challenges. Casual users can step-by-step get a larger responsibility to autonomously correct faulty data, while power users develop data definitions and ready-made standard reports for these user group-specific data sets. Data quality becomes a shared interest. Through clear data definitions and standard reports, data become more structured and easier to access and the risk for mistakes is lowered. Simultaneously, casual users start to contribute to data cleaning from their perspective. Champions support casual users in their growing independency. SSBI education should start to target the user groups differently, where technically skilled users learn more how to use the back end of SSBI, while the non-technically skilled users learn to use the front end.

Finally, the SSBI implementation can further evolve by eventually letting end users govern their own SSBI content (data sets and reports commonly used for their decision-making). Governance is typically a responsibility of the IT department in traditional BI systems, but in SSBI, end users within business departments should take responsibility of structuring data sets and deleting outdated reports. The case study results also highlight that decentralised governance requires a new kind of relationship between the IT department and business units. Business units need a mixture of competences, where power users and casual users work closely together, for instance, by letting power users work part time in business as a SSBI end user. SSBI education should again change content by assisting casual users to address governance of their own data and their own reports and by educating power users on the business context of analytics and decision-making.

Organisations aiming to implement SSBI can be better prepared if they take stock of the 37 SSBI challenges of the AQUIRE framework they may face and carefully plan for the application of the nine success factors discussed in this article. Researchers who investigate these SSBI implementation processes can use AQUIRE as a research agenda and contribute to enriched knowledge about SSBI challenges and SSBI success factors.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Additional information

Funding

This research was supported by Grant [2016-3046] of the Swedish Civil Contingencies Agency

Appendix 1:

Short description of all SSBI challenges in the AQUIRE framework

SSBI challenges for Access and Use data

• (1) Difficult to access data: It is not obvious how to access and use data since users find it difficult to determine what the data mean or how the can be used. It can take weeks and months to get access, but the entire idea with SSBI is to enable users to access and use data on the fly.

• (2) Unaware of data sources: Users of SSBI do not find it obvious what data sources are available. Many data sources are still unknown, especially for casual users.

• (3) Difficult to make data available: It is important to determine what data sources should be available to a specific user. The results show the difficulty in determining user privileges to access data freely.

• (4) Takes long time to request data access: Many users must request data access, and it can take a long time before they receive an answer. This creates frustration since users believe they can access data in a self-reliant manner on the fly.

• (5) Multiple data sources in different environments: The process to combine data does often require technical skills that casual users do not possess.

• (6) Use correct data queries: It is important to use correct data queries to join the sources properly. Even the smallest mistake, e.g. improper joins between tables or using incorrect attributes, can lead to serious faults that affect decision-making negatively.

• (7) Control of data integrity, security and distribution: Many users are still using ad hoc solutions to perform analytics and decision-making. This may lead to inconsistent data that impact security and quality, especially when users distribute the content to other colleges.

• (8) Policies for data management and governance: Many users are still using ad-hoc solutions to perform analytics and decision-making. This may lead to inconsistent data that impacts security and quality, especially when users distribute the content to other colleges.

• (9) Prepare data for visual analytics: Users of SSBI need to create their own story by using data that visualise the content in an easy self-reliant manner. It is important that conclusions when making decisions are easily tracked back to the data used in a story telling manner.

SSBI challenges for Data Quality

• (10) Faulty data exist when making decisions: It is important to achieve a sufficient level of data quality to increase the possibility to make adequate decisions. It is not obvious what level of data quality is needed when implementing SSBI.

• (11) Difficult to correct faulty data: Once faulty data are identified which is mainly due to a lacking data owner who normally corrects the errors and the fact that end users of SSBI normally are not allowed to change data.

• (12) Difficult to determine right level of quality: Users of SSBI are having trouble to determine the accuracy, freshness, completeness, reliability of data, etc. These are important factors that users must be aware of when selecting data.

• (13) Difficult to define data: Users of SSBI find it difficult to select and use data since there is no common definition of data available, which makes it difficult to understand what the data mean and consist of. Similar data from different sources may be labelled differently, or equally labelled data may have different meaning.

• (14) Low awareness of using faulty data: Users of SSBI are not always aware of the data they use when making decisions. Important details are sometimes missing when decisions are made.

SSBI challenges for User Independence

Access and use data

• (15) Difficult to know available data sources: If users do not understand whether important data are available or not, it may hamper them to analyse the best relevant content for decision-making.

• (16) Difficult to locate data: SSBI users who know that data are available face problems to determine where it is located. They experience problems with whom to contact to gain access, which is a time-consuming process.

• (17) Difficult to use data: Users must understand the content of the data and when to join and not to join data. Otherwise, it will lead to wrong conclusions which affect decision-making negatively.

• (18) Difficult to use many different data sources: Power users have the technical skills to join data correctly. Now, casual users have to do this themselves, and if done wrong, decision-making may be based on incorrect data.

• (19) Support is required to add data: SSBI users still need support from the IT department to add missing data when making decision.

Low user skills

• (20) Limited competence level: Many casual users lack the right level of competence to use SSBI. They are unable to perform SSBI tasks themselves.

• (21) Difficult to interpret report content: Users find it difficult to interpret content in SSBI reports. There are many different data definitions which are named differently in different systems.

• (22) Limited general IT skills: Users of SSBI lack general IT skills that affect SSBI negatively.

Difficult SSBI tools

• (23) Difficult to use SSBI tools: Causal users are having difficulties to understand and use SSBI tools. It is more than just a threshold for learning new software, even if they have well-developed IT skills.

• (24) Users create isolated solutions: Once SSBI is difficult to use, users start building their own isolated solutions. Excel is commonly used as a traditional BI tool which users feel comfortable using.

• (25) Give the right tools to the right user: Different users have different skills and needs compared to others. Organisations believe that SSBI tools are of a ‘one-size fits all’ character due to its believed simplicity of using SSBI tools compared to traditional BI tools.

SSBI challenges for Creating Reports

Create and change content

• (26) Difficult to create SSBI reports: Many users find it difficult to create SSBI reports. They can hardly create their own reports from data prepared by a power user.

• (27) Requires lots of time and manual work: Creating SSBI reports requires lots of manual work. The software tools cannot automatically create SSBI reports but requires troublesome manual work, especially when many users are involved in the creation.

• (28) Difficult to change content: Even experienced organisations working with SSBI for many years are facing the challenge to change content. It is common that users want more content in their report once they realise what the SSBI tool can do, which is difficult to fulfil.

Assure quality

• (29) Difficult to assure quality of reports: When all users are able to create reports, the number of created reports increases. Users are prone to believe that content is of high quality since someone else already created the report and approved its quality.

• (30) Redundant reports exist: Users are not aware of the available reports. Instead of analysing existing reports, duplicates are created even though they already exist.

• (31) No governance of SSBI reports: It is difficult to govern SSBI reports, especially when users are customising existing reports. There is no clear responsibility who owns the SSBI report.

• (32) Unsupported tools are used: It is common that users are working with their own ad hoc tools, which may cause software problems. If someone creates a report consisting of content which is created by these tools, they often fail since they are unable to handle all data efficiently.

SSBI challenges for SSBI education

No formal education

• (33) No formal educations are given: Organisations do not organise formal education as part of SSBI implementation.

• (34) Users forget how to use SSBI: Organisations arrange informal education focused on sharing experiences on how to use SSBI. Users who were able to work with SSBI tend to forget and ask for support.

• (35) Not using SSBI after education: Some users testify that they are not using SSBI after their education even though they were enthusiastic about SSBI.

Low interest in SSBI

• (36) Users do not see the benefits of SSBI: Respondents illustrate how users fail to see how SSBI can help in their daily work. Users tend to reverse back to their old routines.

• (37) Users have different technical backgrounds: Users have very different technical backgrounds and some find it difficult to adopt to standardised SSBI tools.

Success Factors for Managing the SSBI Challenges of the AQUIRE Framework

Christian Lennerholt, Joeri van Laere and Eva Söderström School of informatics, University of Skövde, Skövde, Sweden. Christian Lennerholt is a Ph.D. student in Informatics at the University of Skövde, Sweden. He holds a M.Sc. in Information Systems from the University of Skövde where he teaches in courses like database systems, programming and business intelligence. Christian's research focuses on self-service business intelligence. He has published at international conferences such as ECIS and HICSS and in journals such as IJBIR and TDWI BI Journal.

Joeri van Laere is an Assistant Professor at the University of Skövde, Sweden. He holds a Ph.D. in Information Systems from the Delft University of Technology, the Netherlands. Joeri performs research at the interface of organisation science, communication science and information systems. His research interests include business intelligence, crisis management, situation awareness, gaming-simulation, organisational change and distributed work. He has published at several international conferences such as ECIS, HICSS and ISCRAM and in journals including the European Journal of Information Systems and the Journal of Contingencies and Crisis Management.

Eva Söderström is an Associate Professor at the University of Skövde, Sweden. She holds a PhD in Computer Science from Stockholm University, Sweden. Eva’s research focus is primarily on digitalisation and reducing the digital divide for groups of people risking digital exclusion. Other research interests include standardisation and information security, with an emphasis on the administrative and organisational side. She has published in several international fora, such as ECIS, HICSS, CAiSE and EGOV, and in journals including IJHCQA, GIQ, JSIT and JISS.