From Shadow IT to Business-managed IT: a qualitative comparative analysis to determine configurations for successful management of IT by business entities

A distinct case in the context of this study is understood as a concrete manifestation of SIT/BMIT (as defined in Sect. 2.2). The object of interest is, therefore, a distinct artifact or specifically an IT system with a high degree of responsibility for its components and tasks in a BU. This can include both overt (BMIT) and covert (SIT) instances. The calibration of this measure, that is, whether it is a positive case [1], is primarily based on the assessment of the interviewed participant (typically the CIO) who serves as a “key informant” (Kappelman et al. 2018; Kearns and Lederer 2003) and who is able to oversee the whole firm’s strategy and processes (Chun and Mooney 2009). In practice, it means that a case is coded Distinct [1] if the observed positive consequences (Kopper and Westner 2016a) outweigh the negative ones. This is the case if the participant predominantly associates positive attributes with the instance such as innovativeness (Behrens 2009; Rentrop and Zimmermann 2012), a good fit with users’ requirements (Behrens and Sedera 2004), efficiency gains (Röder et al. 2014), or the creation of a new revenue stream (Ferneley 2007). Other possibilities include increased flexibility and the ability to adapt in uncertain and competitive environments (Kretzer and Maedche 2014).

On the other hand, the measure is coded Distinct [0] if the participant primarily associates negative consequences with a case. This, for example, includes failed or problematic projects that led to financial losses or inefficiencies. Inefficiencies can also arise due to loss of synergies, loss of scale effects, or redundant systems (Györy et al. 2012; Kretzer and Maedche 2014). Other negative attributes can be associated with a lack of overall system quality, such as performance issues, operational issues, poor integration with other systems (Hetzenecker et al. 2012), or data security and data consistency risks (Györy et al. 2012; Kretzer and Maedche 2014; Silic and Back 2014).

In contrast to distinct cases, General cases describe organizational settings that represent multiple instances of SIT/BMIT sharing the same characteristics. This includes settings with IT governance models where BUs are involved to a significant degree, specifically federal models, as defined by Weill and Ross (2004). Such a model can, for example, define patterns in which infrastructure decisions are centralized, and business application decisions are made by the BUs (Andriole 2015; Winkler and Brown 2014b).

Similar to Distinct the value for General is primarily based on the assessment of the participant. A case is coded General [1] if it is predominantly associated with positive attributes. This includes settings that, for example, actively encourage joint initiatives between the IT department and the BUs that create new benefits for the entire organization (Silic et al. 2016). Specifically, this can mean a possibility for low-cost innovation and the ability to respond to changes in business conditions rapidly (Tambo and Bækgaard 2013). Altogether, the same positive and negative consequences already described for Distinct were used as indicators to code General [1] or [0] with the difference that they apply to multiple instances in a general setting.

The measure Approved describes if there is overarching consent about the legitimacy of distinct instances of systems managed by BUs or general IT task responsibilities on an organizational level (coded Approved [1]). This can have varying degrees of formality, for example, formal policies for SIT/BMIT or a clear definition of split IT task responsibilities. On a more general level, it specifies if the case is complying or not complying with management intentions (Alter 2014). Chua et al. (2014), for example, determined in their cases if central IT was consulted and if the instances were legitimized by the organization and the IT department. Zimmermann et al. (2016a) similarly have described requirements to consult the IT department for BMIT and the importance of maintaining transparency. A prerequisite for approval might also include the need to adhere to technological (for example, infrastructure), data (for example, data structures), and process (for example, security) standards (Dittes et al. 2015).

A case is coded Approved [0] if there is no organizational approval for the observed system or setting (Köffer et al. 2014). Such systems exist outside predefined structures that regulate and control IT work (Behrens 2009). This similarly covers un-enacted projects that have never been subject to an official evaluation process and exist without awareness by top management (Blichfeldt and Eskerod 2008; Buchwald et al. 2014b; Buchwald and Urbach 2012). Most obviously, a case is not approved if policies exist that would clearly define IT task responsibilities, but they are deliberately ignored or violated (Haag and Eckhardt 2017).

Organizational split [1] describes settings for which IT task responsibilities are split between the IT department and the BUs (Zimmermann et al. 2016a). As previously mentioned for the measure General, this is especially the case for a federated IT governance model (Andriole 2015; Weill and Ross 2004). In such a model it makes sense for the IT department to act as a repository of organizational-level requirements and coordinate them between BUs. This includes making sure that systems remain aligned with the overall enterprise vision and architecture. It can also play an active role by guiding BUs toward effective implementation, operational, and procurement practices. Specifically, it can structure the implementation or vendor-selection process because it tends to be more aware of the broader implementation issues (for example, proper testing) and has more experience selecting and negotiating with vendors. Other critical areas where the IT department may take an active role or at least educate the BUs about are security, privacy, regulatory, or continuity (service operation) issues (Chua and Storey 2016).

Organizational split is simply coded [0] if the case does not involve split IT task responsibilities at all, and the BU is acting solely on its own without even making use of the experience of the IT department or asking for advice.

Organizational split indicates an active involvement of the IT department but Technical split [1] means that it is only passively involved by providing infrastructure or tools on a technical level (Andriole 2015). While BUs concentrate on requirements, rapid application development, and deployment, IT departments are responsible for the “transportation architecture” or infrastructure (networks, servers, databases, platforms) (Brown and Magill 1994). On the most abstract level, platform systems are provided as a layer that remains stable, while the components built on top vary over time (Bygstad 2016). Platforms (and lower layers such as databases and servers) enforce uniformity and allow to exploit knowledge that is embedded in the technology. This enables increased agility and fosters self-organizing, loosely coupled teams (Krancher and Luther 2015). Krancher and Luther (2015) have described two different abstraction levels for platforms where deployment PaaS (dPaaS) aims at software developers, and model-driven PaaS (mPaaS) aims at technology-savvy end users. The latter are also known as low-code platforms and allow to build applications by simply modifying metadata, without necessarily having to write code.

Technical split is coded [0] if BUs use their own infrastructure not provided by the IT department, which can also be independently sourced from public cloud providers. This is, for example, the case with shadow sourcing, as described by Haag (2015).

A case is Specific [1] if the instance(s) it describes are very specific to a BU and its processes. Application specificity also means a higher level of customization to the individual BU’s needs (Behrens and Sedera 2004; Winkler and Brown 2014a). Zimmermann et al. (2017) found that when specificity is high, it is more efficient and faster to coordinate IT tasks within the BU because this omits costly and complex assignment procedures with the IT department (transaction costs). In contrast, non-specific tasks should be handled by the IT department because it, for example, can also consider reusability aspects or scale effects (Zimmermann et al. 2016a). A second aspect of the measure Specific is “scope of use” that defines the breadth to which an application is used within an organization, that is, if it is (or can potentially be) used only in one or multiple BUs (Fürstenau et al. 2016). Similar to specificity, Winkler and Brown (2014a) found that applications with a greater scope should be governed by the IT department due to the achievable scale effects.

Personalized spreadsheet-based applications would be an example for Specific [1] cases because they are specifically tailored by their creators for their needs and only cover a narrow scope of use (Fürstenau et al. 2016). They also allow flexibility to coordinate organizational and local requirements (Paulsson and Johansson 2013). However, also larger systems can be Specific [1] if they are limited to the requirements of a single BU. This, for example, applies to systems that are created for or offered to customers that are only served by one BU or systems that support the production processes of a single BU. In contrast to that, ERP systems, CRM systems, or more generally formal enterprise systems are not specific to a single BU and typically have a high scope of use (Huber et al. 2016). Cases that deal with such core systems are therefore coded with Specific [0].

Standalone refers to the degree of technical integration of a system. Bygstad (2016), for example, describes “Heavyweight IT” which represents fully integrated solutions that interact with the business logic and data access layers. In contrast to that, “Lightweight IT” describes non-invasive solutions that are usually initiated by users in cooperation with an external vendor. A lack of integration is commonly identified as one of the risks of SIT (Chua et al. 2014; Huber et al. 2016) which is caused by insufficient skills of conceptual IT development (Hetzenecker et al. 2012). Consequently, data integrity issues can arise (Silic and Back 2014). Fürstenau and Rothe (2014) therefore used “architectural embeddedness” to determine the criticality of a system. We similarly code Standalone [0] for systems with a high architectural embeddedness and vice versa.

Practically speaking, Heavyweight IT, or generally core backend solutions such as ERP systems, database servers, or integration software (Bygstad 2016) are coded Standalone [0]. Because, for example, ERP systems integrate many different organizational functions (Behrens and Sedera 2004) and have increased requirements to security and resilience, the argument for a centralized ownership by the IT department gets stronger (Bygstad 2016). Most applications realistically require at least a minimum degree of integration. Cases are therefore coded Standalone [1] if the respective systems are either completely isolated (for example, certain proof of concepts, product IT, or spreadsheet-based applications) or have a low degree of integration with other systems through clearly defined interfaces or APIs.

To determine the value for Low-complexity, we primarily rely on the criteria for “size of SIT” as outlined by Rentrop and Zimmermann (2012). One of their sub-criteria is how professionally a system is operated and how qualified employees are for IT tasks. The level of complexity is, therefore, based on the ability to handle systems with an increasing size. Other criteria include the number of users, the type of components (hardware, software, or a combination of components), and the maturity of service processes around the system. Additional criteria are drawn from Chua et al. (2014), who have described “Lightweight IT” as simple applications on cheap technology. Examples include mobile apps or personal productivity tools such as self-developed spreadsheets (Fürstenau et al. 2016). Those are typically applications that are “on the edge” and do not cover core functions (Chua et al. 2014). Workarounds (or workaround systems) are also considered as small-scale actions with a low complexity (Huuskonen and Vakkari 2013) that can be handled by BUs themselves.

More complex systems (Low-complexity [0]) with a broad scope, however, require more involvement of the IT department because higher risks and costs are expected (Zimmermann et al. 2017). Required resources (cost and time) are therefore also an indicator, but it needs to be evaluated in the respective context. Chua et al. (2014), for example, have described a case where 50–70 thousand dollar is considered a “significant” amount, and we similarly consider cases to be complex if costs exceed 200 thousand dollars or even millions. Project runtimes beyond one year can also indicate high complexity. ERP systems, for example, are considered to have a high complexity (Behrens and Sedera 2004; Jones et al. 2004) as well as other backend and transaction systems such as database servers or production control systems. A higher degree of integration is also associated with higher complexity (Bygstad 2016). We consider product development (R&D) to be generally complex as well in comparison to the examples described for Low-complexity [1].

As for Low-complexity, we similarly draw on Rentrop and Zimmermann (2012) to determine the value for Low-risk. They used multiple sub-criteria to understand the relevance of a system. One of them is the strategic relevance for the company and another the criticality of the system. They have described that higher criticality also increases the risks and effects of erratic behaviors in areas such as IT security and compliance (Zimmermann et al. 2016a). Chua et al. (2014) have described examples of accepted SIT instances that do not cover critical areas, that is, they do not affect the core, regulated manufacturing business. Another example has been mentioned in form of spreadsheets that are indeed used in a highly regulated healthcare environment, but only for non-critical tasks that do not involve patient data. Zimmermann et al. (2016a) have argued that for systems with an acceptable risk level, it is justified to keep certain IT tasks in the BUs. Keeping critical tasks in the IT department can reduce the risk if, for example, professional software testing is performed or increased operational stability can be expected due to the usage of standardized infrastructure.

As previously mentioned, some of the most-cited risks of SIT are related to privacy, security, and compliance which often must be resolved by the IT department (Chua et al. 2014; Fürstenau et al. 2017). The risk value is therefore high (Low-risk [0]), especially, when the system is affected by regulatory requirements (Gozman and Willcocks 2015) such as in the healthcare sector (Chua et al. 2014) or the banking industry (Fürstenau et al. 2017). Another risk is business continuity which can lead to disruption of operations in the event of a fault (Chua and Storey 2016; Györy et al. 2012). The risk is therefore considered high if a system covers highly critical areas with high availability requirements. Zimmermann et al. (2017) have, therefore, argued that high-risk tasks should be allocated to the IT department. Risk can also be high for a project if there is a mismatch between the complexity and the skills of the parties involved.

Provisional is probably the most intuitive measure which indicates the temporality of a system. Workarounds or workaround systems are, for example, considered to be temporary (Provisional [1]) solutions until the obstacle disappears or a more complete fix for the system they cover is available (Alter 2014). Another example is prototypes that are not intended for long-term operation. Ebeling et al. (2013), for example, have described the decentral, iterative development of a shadow system to determine the requirements for a future core system. However, they have also recognized the system as a temporary solution until a proper, integrated system is available. Realistically, no system is built to last forever, but if the intention from the beginning is a limited foreseeable time of operation (for example, a single-use system for a project or a campaign that only lasts six months), the respective case is coded Provisional [1].

In all other cases, systems are not provisional (Provisional [0]). This is, for example, the case for systems that cover stable BU processes, for IT products developed for customers, or for core systems such as ERP or CRM. For those non-temporary systems, there are higher requirements on architectural standards, integration, and stability to ensure efficient long-term operation. They should, therefore, be in the responsibility of the IT department (Bygstad 2016). However, applying the logic of transaction costs, it would be too expensive for temporary solutions to adhere to the same standards because the investment cannot pay off in the long term (Zimmermann et al. 2017). They are, therefore, candidates for being managed by the BUs themselves.

Cases are Ambiguous [1] if they deal with uncertainty, that is, systems for which the requirements are initially unclear (Zimmermann et al. 2016a). Similar to the concept of Bimodal IT (Horlach et al. 2017) or Lightweight IT (Bygstad 2016), this describes experimental and agile environments with short development cycles and possibly short product life cycles. It especially covers exploratory projects that may have intangible and difficult to quantify benefits (Chua and Storey 2016). Zimmermann et al. (2017) have described that BUs engage in IT development to try new ideas that have unclear requirements. It can be justified to have responsibility for those instances in the BUs because involving the IT department would require extensive and inflexible coordination efforts that slow down the process. IT departments also may not want to spend resources on a properly designed and integrated system until the BU is certain of its future usage (Zimmermann et al. 2016b).

However, systems for which the above descriptions do not apply are Ambiguous [0]. This especially applies to systems that are focused on stability and efficiency, for example, backend and transactional systems (Bygstad 2016; Horlach et al. 2017) or more generally systems with clear requirements.

This configuration where all conditions have a value of [1] is not only part of S1-A, but also S1-B and S1-C. Furthermore, it is backed by the highest number of cases. This is consistent with the theoretical foundations previously described which indicate that all four conditions contribute to the outcome Positive.

Four of the cases are dealing with general governance settings. In P07-A for example, BUs are allowed to build their own solutions as long as their initiatives are approved in the architecture board. Approval is given if the system is not touching any core processes, only affecting isolated areas (involved applications and infrastructure are very local), and if the requirements are still unclear. For such cases the participant recognized cost benefits because they require an agile approach with a low process and coordination overhead. For P01-C the same conditions apply, but the participant more critically mentioned that BMIT is inevitable and therefore rules and conditions must be defined under which it is acceptable. For P13-B and P15-C the conditions were described in a similar form as the other two.

Another category is represented by local Proof of Concept (PoC) solutions. In P16-C (similarly also P23-C), PoCs are created locally and (if successful and if required) properly rebuilt afterwards centrally to be able to scale the solutions. Those initiatives are embedded in a central governance with clear responsibilities. Security requirements still need to be considered (for example, that central infrastructure needs to be used), but fewer restrictions exist for the development itself because the teams should be able to move fast and to explore technical options. PoCs are also less critical because often it is not clear if there is a business case for the respective area, and they remain temporary solutions. Still, there are basic documentation, and support/continuity requirements, and the IT department supports with vendor selection. In P29-A, business-managed PoCs are also seen as a way for agile exploration, which makes them more efficient than formal projects with large process overhead. Know-how is created by experimenting with simple tools and, for example, by building spreadsheet-based prototypes that are at some point rebuilt together with the IT department when they reach a critical size. However, even before that, the IT department is available to support with complex tasks.

Reporting related cases form the third category of this configuration. In P05-B certain users are given read-only access to a central database. They can write SQL queries themselves to be able to quickly adapt to their changing local requirements and use self-developed spreadsheet-based tools to analyze/process the data and build reports. If an interface is required to transfer data back into the database, the IT department needs to be involved to retain data consistency. P16-A similarly provides a possibility for self-service reporting/analysis and allows advanced data analysts to build their own reports using a web-based Business Intelligence suite. P26-B was planning a data warehouse (DWH) self-service platform at the time of the interview.

A rather unusual case was described in P12-A where the IT department hired an external office automation expert that worked directly with the BUs to build local solutions together. The expert facilitated to efficiently cover local, initially unclear requirements that would otherwise have low priority in large system developments.

The high number of cases for this configuration shows that, as the solution highlights, it is sufficient for Aligned and Local to be true for the outcome Positive, but not necessarily Simple and Volatile. More complex, stable instances can, therefore, also lead to a positive outcome as long as they are Aligned and Local.

The largest category of cases for this configuration is represented by product IT or more general R&D. The respective participants explained a general split of IT tasks and responsibilities, such as for P02-A. They described so-called “commercial IT” that is centrally governed, controlled, and supported by the IT department. This includes general infrastructure (e.g., workstations, network) and transactional or core systems (e.g., ERP, business warehouse). From a process perspective, the IT department is also responsible for central coordination of material management and production planning. However, so-called “shop floor IT” (management of CNC machines, systems at the production lines, and grapplers) is managed in the BUs. They are also responsible for “product IT”, which is the development and maintenance of IT products or software in tangible products for customers. The participant also explained a specific project in P02-B for the development of a customer IT system where the IT department “would have only been an obstacle if it were involved”. In P23-A, the participant similarly differentiated between “product IT” (including workflows in production facilities, production control, etc.) which is managed in the BU and “business IT” (ERP, DWH, etc.) which is managed by the central IT department. The interfaces and responsibilities between the two are clearly defined. In P19-A, the participant emphasized that the task split should be commonly agreed to and documented but recognized that it is difficult to draw the line. They described “commodity systems” such as infrastructure (up to the integration layer), finance applications, or HR systems that should be run centrally by the IT department. In contrast to that, customer services, or generally systems that can provide a competitive advantage (which are a differentiation factor) can be managed by BUs. One reason for that is that usually no efficiencies or economies of scale can be gained by consolidating such systems centrally. In P24-A, a mostly centralized setup is described but R&D for IT products is still done in a separate unit. In P15-A, a product IT project is described where the BU and the IT department are working closely together.

Another category for this configuration is represented by larger local business systems. In P23-B, flexible frameworks are centrally provided in an “Application Service Provider Model” that can be customized by ecommerce teams for local country-specific requirements. In another example (P23-D) a BU created a new system for a locally specific customer process. The frontend was developed locally and with the help of the IT department integrated into the standard, centralized fulfillment backend through an interface. The BU also worked together with the central IT security officer to fulfill the required standards. The participant highlighted that the BU was able to move very fast and successful in this setting and that their IT department would not have had the resources or priorities to fulfill this requirement.

Two cases describe general governance settings with a split IT responsibility model. In P04-A, BMIT is “business as usual” because the company is structured rather decentral with hundreds of organizational units. BUs are responsible for product IT and locally specific systems. The central IT department provides shared IT services and is responsible for workplace IT, infrastructure (until the database layer in the technology stack), and overarching applications. The participant for P17-A similarly differentiated between “cross-section procedures” for which their department is responsible and “specialized procedures” for which the individual units are responsible. The latter are required to use the IT department’s IT infrastructure until the database layer for their applications. The IT department for example also offers a voting platform that can be customized by local regions.

This configuration is also part of S1-B and is represented by cases dealing with smaller local business systems. P06-C describes a small pricing engine that was developed and is maintained by some traders in the BU of a commercial banking company. They are working with an external vendor and are in close alignment with the IT department. Additionally, they adhere to commonly agreed processes, use development tools and secure infrastructure provided by the IT department, and work together with IT for testing and go-live. In P21-A, BUs are responsible for specialized, specific, small (non-core) tools for which they have the required knowledge and IT skills (e.g., VBA or Matlab). Some access controls are in place and they must coordinate requirements between teams. P16-D describes areas such as local (country-specific) customer interfaces, smaller local ecommerce systems, and local helpdesks which are decentralized.

P27-A deals with a general organizational setting for new ventures. For that, units (or startups) within the organization are formed to explore new business models. They consist of agile, integrated teams that can act relatively freely and detached from organization-wide systems and processes. The participant notes that they, for example, are not required to use the central ERP system in the beginning so that they are not dragged down in speed and able to concentrate on the development of the new business. Still, their decisions need to be reviewed by an overarching governance board, and the IT department has veto rights on IT architecture decisions. New systems must, for example, not have a (negative) impact on centrally controlled systems. This configuration is, therefore, comparable to the PoC category explained before but deals with settings that are more complex.

This configuration has already been illustrated for S1-A, is also explained by S1-C and covers general governance settings that allow local BUs to build simple, volatile solutions, as well as local PoCs and adaptive reporting solutions.

As already illustrated for S1-A, this configuration represents smaller, local business systems.

Both cases for this configuration deal with management of cloud-based CRM workflows. In P11-A, BUs are empowered to create reports, dashboards, and workflows in a Salesforce CRM system. They are coached and supported by professionals to retain a consistent data model and organization-wide workflows. The participant explains this as a form of “business DevOps” that allows to be agile and to have 12 releases per month in comparison to 2–3 per year for the on-premise SAP environment which is managed by the IT department. Interestingly, the system emerged as a shadow instance and was then legitimized, improved, and properly integrated with other systems with the help of the IT department. Another participant was setting up a similar arrangement in P06-A at the time of the interview. In a new cloud-based CRM, which consolidates multiple older ones, BUs take over maintenance and further development/design of the system. This should allow them to employ more agile procedures without heavy project processes and to solve challenges closer to the users who best understand their own needs. In this setting, the IT department is still responsible for large system changes, integration with other systems (e.g., email server), vendor/contract management, security, and retains budget control. The largest BU with the most complex requirements takes over coordination of different local requirements to enable synergies and to retain overarching workflow consistency. The participant noted that with cloud technologies the borders between IT and business blur because there is less technical knowledge necessary to operate them. Without having to maintain a datacenter or on-premise infrastructure, there are also fewer continuity risks.

It is interesting to note that these two cases are the exceptions that were responsible for the condition Local being only almost always necessary. The question arises why in these two cases locality was not needed. As argued above, this might be due to the way cloud technologies are operated. An essential part of IT responsibility does not enter the organization at all as it is taken over by an external cloud provider who handles the infrastructure/technology for a broad range of clients so that handling it all over one organization without having to limit it to local reach is usually no challenge from the provider perspective. Thus, the need for locality is exempted as there is a third party outside the respective organization handling most of the issues of global use. Additionally, this outside party, the provider, is specifically interested in handling or running its technology over a wide range of organizations and contexts in a standardized manner. Looking at these exceptions from the NCA perspective reveals that these are cases Dul (2015) calls “substitutes”. In these cases, there are mechanisms that substitute or compensate the need for locality, which is the reason why locality is not needed in these cases.

No cases were observed for this possible configuration in solution S1-B which is a result of limited diversity in the data. However, three of the four conditions are present (Aligned, Simple, Volatile) that contribute to the outcome Positive based on theoretical foundations, and there is also no negative case with the same configuration. A hypothetical example in this category could be represented by a simple event management tool that is developed or sourced by a BU to organize a Christmas party and re-used all over the organization due to its usefulness. If such a case had existed, it again would have been contradicting that Local is a necessary condition (in the NCA). But as argued for 1010 where the need for locality can be compensated for even in the absence of volatility, here we assume that a system with a very short-term use and without operational relevance for the core business (as in the hypothetical example) may yield the outcome Positive in spite of global use. Again, this hints at locality being a condition that can be compensated for in specific constellations.

This configuration was already illustrated for S1-A and is also explained by S1-B. To recap, it covers general governance settings that allow local BUs to build simple, volatile solutions, as well as local PoCs and adaptive reporting solutions.

P01-A describes the only case that is part of a solution leading to the outcome Positive which is not Aligned.² It deals with a system required by a BU for a large customer project. Initially, the BU asked for a proposal from the IT department to implement the system. However, the BU deemed it to be too expensive and the implementation time too long. Only after three months, the IT department realized that the BU was already working with a standard solution they had procured externally by themselves in the meantime without alignment. It turned out that a simple, temporary cloud solution with an app frontend on tablets was sufficient for the BU to fulfill their temporary requirements during the project duration. The solution was not integrated with the internal systems and required some additional manual steps, but it was sufficient. One of the reasons for the mismatch of expectations between BU and IT department was that the IT department based their proposal on the assumption of building a customized application with full integration into the core ERP system. While the participant assumes that the IT department could have helped if the alignment and communication with the BU would have been better, they recognized it as a positive example for IT managed in the BU under these conditions (Local, Simple, Volatile).

This configuration covers the development of permanent/non-volatile critical core systems for which the BU was not aligned with the IT department. P01-B describes the failed development of a large system for a core business process. The BU head decided to do the implementation by oneself together with an external vendor without aligning with the IT department first. They anticipated lower costs, had a strained relationship with the IT department, and wanted to avoid tedious discussions about guidelines, security, or integration. The project was paid with business budget instead of IT budget and ultimately failed after 1 ½ years with a loss of several million euros. The system ended up with poor quality (documentation, modularization lacking) and poor integration/interfaces with other systems. At this point, the IT department was involved to save the system and it required an additional year to fix the shortcomings. Despite the initial anticipation of cost savings by the BU head, the participant estimated that it would have been more than 50% cheaper if the IT department had been involved from the beginning. In P12-B a BU similarly implemented a new CRM system together with an external provider without aligning with the IT department. It was heavily customized and grew very complex. Ultimately, the effort was stopped and restarted. After that, the BU still worked together directly with the vendor, but the IT department took over vendor management and quality assurance of the project. In P15-B, a BU had the necessary budget and IT competencies to start implementing a core manufacturing execution system for the company without first aligning with the IT department (the relationship between the two was strained). The IT department was only involved at a very late stage and seen as a fulfillment provider instead of a partner. Due to inefficiencies caused by unclear responsibilities with an external provider and deficits in the solution design, the participant perceived it as a negative case. For P06-B the participant mentioned a central risk controlling system with many dependencies on other systems that was created by a BU without IT alignment. Here, they saw the risks (continuity, regulations, inefficiencies, etc.) outweighing the potential benefits.

This configuration contains four cases that can best be described as unofficial, non-specific, small, permanent solutions. The first one (P03-C) revolves around a solution for managing company goals which was procured independently without any involvement of the IT department. The requirements were not specific to the BU and did not involve any specific know-how the BU could contribute. The independently selected vendor turned out to be unqualified and system quality was poor (usability and performance problems due to missing non-functional requirements). The BU initially wanted to avoid having to align with the IT department due to a perceived high effort of doing so. In P13-A, a small external provider worked directly with multiple BUs to implement small solutions. The BUs enjoyed its services because their unsolved issues were covered fast and cheap. However, the initiatives were not aligned with the IT department and created high follow up costs due to faulty system integrations and poor security concepts. The provider was then integrated into the IT department so that architectural impact analyses and quality control are possible. In P14-A, a doctor implemented a planning software in cooperation with a school project, but operational issues were ignored and remained unsolved. P03-B deals with non-standard devices that are not supported and pose a security risk (for example, smartphones or unsecured gateways connected to the internet).

This configuration (as described before) is shared with S0-A and includes unofficial, non-specific, small, and permanent solutions.

Three cases which caused continuity issues are representative for this configuration. These cases can best be described as unofficial, local, small, and permanent solutions. In P16-B, an employee developed a solution for a local business process. They managed to integrate it with a database but did not align with the IT department. Over time, the local BU’s processes became dependent on the solution. After the employee left, they demanded money for continued support and even included a time lock in the application before leaving. In another case in the same organization, an employee unexpectedly died and left behind an unsupported, undocumented application they had built. P26-A represents a similar case where the author of an application left the company and it stopped working after some time. Because there was no source code available, no documentation, no versioning, or any professional development standards, it was necessary to completely rebuild the solution. For P18-A the participant denounced inefficient, hard to support and hard to secure Excel and Tableau reports that are created by BUs themselves for long-term solutions instead of requesting proper reports from the IT department.

This configuration is represented by two cases which can be best characterized as unofficial, local, complex or high-risk, permanent applications and one outlier case which was considered Positive by the participant. P18-B describes a critical application built with MS Access in a BU over years. The underlying technology was inadequate for the complex requirements and the solution, for example, did not support concurrent users and created data consistency issues. It took a high financial investment to properly rebuild the solution with the help of the IT department. In P05-A management accountants were using spreadsheets without permission instead of the officially mandated SAP system for calculations and were feeding inconsistent data back into the system. They were also not asking the IT department for help when changes to the SAP system was needed. This created a high level of operational and financial risks before the issue was addressed.

P03-A describes a one-year project for the development of a database extension. The solution had clear requirements and covered a critical business process, but the IT department was only shown the finished solution before hearing about the requirements. The solution had some operational issues, and integration with other systems was lacking (which the IT department planned to fix later), but the participant recognized it as a relatively well-made, positive example in the end. This case is, therefore, responsible for this configuration not being part of any solution because it has an outcome of [1] instead of [0] with the same conditions. It is also one of the two cases in the NCA that are responsible for Aligned being an almost always necessary condition instead of an always necessary one. Thus, P03-A is a contradictory case in several respects and an outlier in both analyses.