Mapping Domain Characteristics Influencing Analytics Initiatives: The Example of Supply Chain Analytics

Purpose: Analytics research is increasingly divided by the domains in which Analytics is applied. Although the execution of Analytics initiatives is similar across domains and similar issues occur, current literature offers little understanding of whether the investigation of aspects such as success factors, barriers, and management of Analytics must be domain-specific. This article investigates characteristics of the execution of Analytics initiatives that are distinct within domains and can guide future research collaboration and focus. The research was conducted on the example of Logistics and Supply Chain Management and the respective domain-specific Analytics subfield of Supply Chain Analytics. The field of Logistics and Supply Chain Management was recognized as an early adopter of Analytics, but has fallen back to a midfield position in comparison to other domains. Design/methodology/approach: This research uses Grounded Theory based on 12 semi-structured interviews, creating a map of domain characteristics based of the paradigm scheme of Strauss and Corbin. Findings: The study identified a total of 34 characteristics of Analytics initiatives that distinguish domains in the execution of initiatives, which are mapped and explained. As a blueprint for further research, the domain specifics of Logistics and Supply Chain Management are presented and discussed. Originality/value: The results of this research should stimulate cross-domain research on Analytics issues and prompt further research on the identified characteristics for a broader understanding of their impact on Analytics initiatives. The study also describes the status quo in Analytics. Further, the results can help managers to control the environment of Analytics initiatives and design more successful initiatives.


Introduction
Previous research has lauded the potential of Analytics to have a tremendous impact on the world economy by changing the basis of competition and providing leading organizations with a competitive edge in operations improvements and new business models (Henke. Bughin, Chui, Manyika, Saleh, Wiseman & Sethupathy, 2016). This has attracted professionals and researchers alike, creating a variety of domain-specific subfields of Analytics. However, researchers usually do not work across domains (Holsapple, Lee-Post & Pakath, 2014), and, further, they do not usually explain how the specific characteristics of their domains alter the use of Analytics (e.g., Lai, Sun & Ren, 2018;Sanders, 2016;Wang, Gunasekaran, Ngai & Papadopoulos, 2016) One such subfield is Supply Chain Analytics (SCA) (Chae, Olson & Sheu, 2014;Sanders, 2016;Souza, 2014) or SCM Data Science (Waller & Fawcett, 2013), which concerns the application of Analytics in Logistics and Supply Chain Management (LSCM). Scholars have offered little explanation about differences in executing Analytics initiatives in LSCM as compared to other domains. While scholars have investigated the effects of Analytics on LSCM (Chae et al., 2014;Chavez, Yu, Jacobs & Feng, 2017), they do not elaborate on the domain-specific execution of Analytics initiatives. Meanwhile, LSCM research has called for education programs for data scientists specific to LSCM (Waller & Fawcett, 2013), but, while LSCM theory may help analysts to understand the context, the benefits to the understanding of a specific practical problem are unknown. In addition, scholars also call for the training of LSCM personnel in Analytics (Schoenherr & Speier-Pero, 2015), while Analytics research argues for the benefit of domain independent analysts collaborating with domain experts, such as in cross-functional teams, instead of creating designated analysts (Bose, 2009;Harris & Craig, 2011;Lavalle, Lesser, Shockley, Hopkins & Kruschwitz, 2011). Scholars present opportunities and challenges for Analytics in LSCM (Kache & Seuring, 2017;Sanders, 2016), while opportunities that do not impact LSCM processes and challenges are not described in terms of their domain specifics. Further, scholars have not presented evidence on whether challenges are domain-specific or cross-domain.
It is not the purpose of this research to call into question the advantages of domain-specific research on Analytics. Domain-specific research is advantageous for addressing use cases from a domain perspective. This is argued to be more meaningful and have increased impact in terms of Analytics solutions due to the incorporation of domain knowledge (Waller & Fawcett, 2013). However, goal-oriented exchange between domains with similar issues may create benefits in spillovers, as it does for collaborating business units within organizations (Grossman & Siegel, 2014). Collaboration across domains on domain-independent issues can provide benefits due to improved understanding of the issues, broader solution search, and direct domain-specific research towards issues with a critical demand for domain knowledge. However, there is no good basis for distinction, such as characteristics of Analytics initiatives displaying potentially differentiated effects and issues in different domains. Mapping these characteristics entails the potential to explain maturity and adoption differences in executing Analytics initiatives across the various domains. For instance, while LSCM displays an early adopter of Analytics (Davenport, 2009), this forward-thinking position did not permeate throughout the field, with a few organizations keeping up with implementing more advanced approaches (2017), but the field generally regarded as lagging concerning Analytics (Bange, Grosser & Janoschek, 2015;Thieullent, Colas, Buvat, KVJ & Bisht, 2016).
In summary, the literature differentiates among Analytics initiatives by domain, but with little necessity (Carillo, 2017) besides a more target-oriented addressing of an audience. Domains are advancing in different ways in applying Analytics, and this lacks a research explanation. A clearer understanding of the distinctions can direct domain-specific efforts towards critical domain-specific issues while stimulating cross-domain research and exchange on domain-independent issues. Thus, this research seeks to map the characteristics of Analytics initiatives, with the potential to differentiate among domains. As such, it responds to the call for more investigation of domain differences in Analytics (Cao, Duan & Li, 2015). In this effort, this research focuses on the domain of LSCM and the Analytics subfield of SCA. Considering MacInnis (2011), this work contributes by sketching and delimiting SCA. Consequently, the research question addressed is: What are the characteristics of Analytics initiatives, the execution of which set domains apart; and which specifications of these characteristics characterize the domain of LSCM?
This research concerns the increasing use of data to influence and transform businesses (Carillo, 2017), which is labeled as Analytics. The distinction between this and terms such as Data Science and Business Intelligence is vague, leading to some scholars constantly interchanging them (Agarwal & Dhar, 2014;Chen, Chiang & Storey, 2012;Larson & Chang, 2016;Song & Zhu, 2016). However, while Data Science is understood as "tools for Analytics" (2015), and Business Intelligence as being technology-focused (Larson & Chang, 2016), the managerial issues of both must be addressed as they also concern Analytics. For the purpose of this research, a distinction based on methods and technologies does not provide any value, although the distinction will be revisited later.
The remainder of the paper is organized as follows. Section 2 provides the theoretical background. Section 3 focuses on the methodology. In section 4, the resulting map of characteristics of Analytics initiatives is presented and discussed. Section 5 concludes this research and provides implications and limitations.

Theoretical Background
This article investigates the differences between Analytics initiatives that result from differences relating to the domain of application. Thus, this section presents theoretical considerations on the domain, its practical impact, and the incorporation of domain knowledge into Analytics.

The Matter of Domain in Analytics
Domain refers to the context (Kenett, 2015), subject field (Holsapple et al., 2014), area (McAfee & Brynjolfsson, 2012), or business function (Bedeley, Ghoshal, Iyer & Bhadury, 2018;Carillo, 2017) in which Analytics is applied. Analytics can be applied to a variety of business processes and industries (Davenport & Harris, 2007) and no limitations as to which domains could use Analytics has been identified. This has resulted in an abundance of domain-specific subfields, including Marketing Analytics, Supply Chain Analytics, Financial Analytics, and more, while there is little exchange between these subfields (Holsapple et al., 2014).
Scholars' consideration of the domain's influence on executing Analytics initiatives has to date been more of a side note. However, the domain is the subject of data analysis and solution deployment, and its role in an Analytics initiative is essential, considering that the domain and its issues are the overall reason why the initiative exists. An initiative does not come out of the void and is assumed to be based on a business need or opportunity of a domain (Grossman & Siegel, 2014;Lavalle et al., 2011;Watson, 2014). The value Analytics can generate by providing solutions and insights is correspondingly related to the domain in which the insights and models/algorithms are deployed and applied (Gupta, 2014;Bedeley et al., 2018;Gupta & George, 2016). This essential link to the domain might be fragile if the domain representatives are not convinced Analytics will meet their needs. Thus, intensive communication and knowledge exchange and integration among analysts and domain representatives is necessary such that the domain will buy in and the solution deployment is not destined to fail (Dutta & Bose, 2015;Grossman & Siegel, 2014;Wixom, Yen & Relich, 2013). After all, the domain is typically the sponsor of an initiative (Grossman & Siegel, 2014), including the investment of time from domain experts (Viaene & Van den Bunder, 2011).
Besides purpose, sponsorship, and subject of deployment of Analytics solutions, the domain's knowledge also influences the search for insights. Section 2.3 discusses further details on incorporating domain knowledge into an Analytics initiative. This domain knowledge includes, among others, knowledge about an organization's mission, goals, objectives, and strategies; about organizational policies and plans; and an understanding of the potential impact of Analytics initiatives on organizational performance. Further, it includes knowledge enabling the interpretation of business problems and implementation of appropriate solutions (Ransbotham, Kiron & Prentice, 2015;Watson, 2014). Scholars argue for the criticality of this knowledge in the success (or rather meaningfulness) of Analytics initiatives (Chen et al., 2012;Debortoli, Müller & vom Brocke, 2014;Harris, Craig & Egan, 2010;Janssen, van der Voort & Wahyudi, 2017;Wixom et al., 2013).
In detail, domain knowledge provides guidance for the analytical process by determining subsequent steps and a course of action, identifying challenges, giving directions for decision points, and validating results (Ittoo, Nguyen & van den Bosch, 2016;McAfee & Brynjolfsson, 2012;Ransbotham et al., 2015;Viaene, 2013;Wixom et al., 2013). It enhances the identification of the most valuable opportunities and needs, or the best way to apply analytical skills to provide value to the organization (Grossman & Siegel, 2014;Harris et al., 2010;McAfee & Brynjolfsson, 2012). The understanding of the business problem can be improved by domain knowledge, as well as by understanding the assumptions behind business ideas and the objective behind applying Analytics (Chiang, Goes & Stohr, 2012;Viaene, 2013). Regarding data, domain knowledge leads to choosing the right data and data sources, better understanding of the data, as well as potential sources of measurement and collection inaccuracy of the data Kenett, 2015). It helps to make sense of the results of analyses and patterns found (Debortoli et al., 2014;Richards, 2016) and therefore can lead to the creation of more valuable models and solutions, and especially to avoid searching for insights new to the Analyst but already known to the domain expert Grossman & Siegel, 2014;Harris & Craig, 2011;Viaene, 2013). In relation to this, domain knowledge is indicated to improve Analysts' effectiveness and thus the fit of solution to problem (Carillo, 2017;Wixom et al., 2013), as well as their efficiency and engagement (Harris & Craig, 2011). Finally, domain knowledge improves communication of results Debortoli et al., 2014).
Of course, the domain is not the sole factor indicated to influence Analytics initiatives. Authors have also identified internal factors including company size (Cao et al., 2015;Davenport, Harris & Morison, 2010), the data-savviness of employees and a data-driven culture (Acito & Khatri, 2014;Carillo, 2017;Gupta & George, 2016;Ransbotham, Kiron & Prentice, 2016), executive support, prior successes, and available expertise (Acito & Khatri, 2014;Ransbotham et al., 2016). Another moderating factor is the fit of Analytics to organizational strategy, structure, and processes (Cao & Duan, 2017). This underlines that one Analytics approach of an organization cannot simply be transferred to another.

The Impact of Domain on Analytics
A study on Analytics in different business functions shows that some domains are more likely to be supported by Analytics than others. Domains that attract the most attention are finance, LSCM, strategy and business development, as well as sales and marketing (Lavalle et al., 2011). These domains are more experienced with statistical and quantitative techniques, are considered historically data-driven, and are expected to have a high payback (Acito & Khatri, 2014;Gupta, 2014;Kiron, Shockley, Kruschwitz, Finch & Haydock, 2012). This section investigates the impact of domains by considering objectives and challenges.
The objectives of collecting and analyzing data across domains differ and Analytics solutions cannot be transferred from one domain (or organization) to another with the expectation of similar results (Kambatla, Kollias, Kumar & Grama, 2014;Lavalle et al., 2011). This results from domains pursuing different business objectives, working differently, and having different issues. Considering different industries, domains differ in regulation, competitiveness, technological change, external standards, Analytics standards, time-sensitiveness, or their public importance (Acito & Khatri, 2014;Trieu, 2017). To exemplify, medicine and aviation aim to reduce the cognitive load of the decision maker in highly stressful environments, in which they have high information demands with inadequate time to sort out the most vital information beyond simple filtering or aggregation (Richards, 2016). Domains with less stressful environments but with requirements for broad oversight and real-time availability, such as retail and LSCM, pursue monitoring (Watson, 2014). In contrast, marketing or retail applications target the detection of changes in behavior -potentially presenting new opportunities with completely different time horizons (Shuradze & Wagner, 2016;Trieu, 2017). Another objective similar to marketing -capturing opinions -is pursued by politics. But while marketing requires insights for personalization, political candidates require insights guiding a collective political agenda to all voters (Gandomi & Haider, 2015;Shuradze & Wagner, 2016). Predicting behavior (e.g., demand) is an essential objective in LSCM and utilities, but also addresses subsequent objectives such as optimal resource allocation (Acito & Khatri, 2014;Watson, 2014). Insurance companies want to gain deeper understanding of why behavioral changes happen in order to prevent fraud (Watson, 2014). Finally, domains with high frequencies of recurring verbal and written interactions, such as tourism, aspire to automate these processes with Analytics (Gandomi & Haider, 2015).
Different domains also bring different challenges for Analytics. Considering the examples below, these challenges result from the complexity of implemented analytical methods or from internal and external organizational matters. Challenges closely linked to methods and techniques appear in complex analytical tasks like environmental studies, which demand the combination of spatio-temporal scaled inputs of satellite imagery, weather data, and terrestrial monitoring (Kambatla et al., 2014). Domains intending to understand the structure of social networks must consider dynamic evolution of connections between entities and dynamic interactions via these connections. Further challenges arise from methods that generate large volumes of data output during an analysis, requiring storage; for example, an astrophysical simulation (2014). Additionally, the costs of inaccuracy of the Analytics solutions differ, such that false positives (or rather false negatives) in diagnosis of a disease or fatal condition in healthcare have different impacts as compared to identification of customer preferences in marketing (Kambatla et al., 2014).
Technical challenges can be more frequent and relevant in domains with complex data integration needs. For example, in healthcare data is captured in heterogenic formats and collection is widely distributed over points-ofcare (Acito & Khatri, 2014;Kambatla et al., 2014). Further technical challenges from data, including data growth, data quality, or the degree of unstructured data (Chen et al., 2012;Kambatla et al., 2014), are, however, hard to connect to specific domain characteristics.
Organizational challenges concern domains working with person-related data. The challenges of securing privacy and subsequent data security are pressing in domains like healthcare, e-commerce, or e-government and can trigger ethical issues, which create the need to ethically justify the use of the data (Acito & Khatri, 2014;Chen et al., 2012;Kambatla et al., 2014). Further organizational challenges are the creation of data without any or adequate collection and storage, such as domains that do not store event logs, such as LSCM, or produce copious handwritten notes containing valuable information, such as healthcare (Chen et al., 2012). Special organizational challenges arise in business domains, since the increase of self-service Analytics creates the challenge of inadequate knowledge of users, leading to subverted effectiveness of the decisions made (Richards, 2016). In addition, business organizations tend to deploy several models and algorithms at once with different data sources, speed requirements, and structures, while models, algorithms, and their outputs are not integrated for consistency (Kambatla et al., 2014).
The differences in objectives and challenges across the domains affect various aspects of Analytics. The considerations above suggest that different domains have different requirements from Analytics, have different influences on organizational aspects of Analytics, and integrate Analytics differently into processes (Cao et al., 2015;Davenport et al., 2010;Janssen et al., 2017). Further, domains have different levels of spending on Analytics, while the organizational performance is also impacted differently (Cao et al., 2015;Trieu, 2017).
Considering the practical impact of domain characteristics, industry reports give appropriate insight and show substantial differences in the most frequent use cases, adoption rates, main challenges, and degree to which data-based business models may be potentially disruptive in different domains (Henke et al., 2016;Toonen, Kanthadai & Jones, 2016). Striking differences in tendencies for data-driven decision-making as opposed to intuition are also reported (Erwin, Heidkamp & Pols, 2016). However, reports show similarities in challenges and use cases also recur across domains (Bange, Bloemen, Derwisch, Fuchs, Grosser, Iffert, et al., 2017;Toonen et al., 2016).
To conclude, domains differ in objectives and challenges and further show different experiences with Analytics. As indicated, these differences result in and from altered organizational, technical, data-related, or methodological characteristics.

Modes of Incorporating Domain Knowledge in Analytics Initiatives
Two aspects are explored regarding the incorporation of domain knowledge into Analytics initiatives: the domain knowledge holder and the interaction of analysts with the domain.
Considering the knowledge holder, some researchers have argued for the necessity of analysts holding domain knowledge and being proficient in numerical disciplines specific to the domain in which they work (Chen et al., 2012;Debortoli et al., 2014;Grossman & Siegel, 2014;Harris & Craig, 2011). Supposedly, this is key to successful analysts who are able to communicate with the domain representatives. The skills-set of the ultimate breed of analyst, the data scientist, usually includes domain knowledge (Carillo, 2017;Debortoli et al., 2014) as part of portraying a jack-of-all-trades approach. In the contrasting second mode, the domain knowledge holder is a domain expert, supporting analysts to understand data, patterns, results, and their implications because analysts lack the appropriate knowledge (Ittoo et al., 2016;Janssen et al., 2017;Richards, 2016;Watson, 2014). This promotes cross-functional teams in which key personnel from different functions represent the needs of their respective functions and communicate progress and results to the team (Bose, 2009;Dutta & Bose, 2015;Rothberg & Erickson, 2017). A hybrid version of these two modes argues for analysts to receive the domain knowledge on the fly during an initiative. They take part in the data collection, get a sense of variations, visit premises, and have focused conversations to gain a comprehensive and holistic view, as well as creating conditions for cooperative work on the solution with domain experts (Kenett, 2015;Viaene, 2013). This hybrid model counters issues of lack of communication from experts on important domain features, as they take them for granted, but they nevertheless require scrutiny from analysts.
Regarding interaction, two idiosyncratic modes have been identified. The first mode is the centralization of analysts in a separate unit as center of excellence that deploys analysts into domains on demand (Debortoli et al., 2014;Grossman & Siegel, 2014;Lavalle et al., 2011). An advantage of this mode is that an organization's Analytics expertise is shared in this unit, including governance, tools, methods, and specialized expertise, creating a more consistent level of effectiveness across domains (Kiron et al., 2012;Lavalle et al., 2011). This is especially useful for predefined questions that recur across domains (Debortoli et al., 2014). However, it creates distance between analysts and domains and potentially reduces analysts' understanding about specific domains and awareness of their needs (Grossman & Siegel, 2014), and is vulnerable to organizational politics (Kiron et al., 2012). In contrast, the organization of analysts can be domain-specific and decentralized (Carillo, 2017;Grossman & Siegel, 2014;Wedel & Kannan, 2016;Wixom et al., 2013). The popularity of this approach can be observed in the richness of domain-specific job postings (Carillo, 2017;Debortoli et al., 2014). When the need for Analytics is initially recognized, closeness is desired, and this mode creates close collaboration between analysts and domain representatives, leads to tailored solutions to domain requirements, and provides analysts with freedom to explore and experiment (Grossman & Siegel, 2014;Kiron et al., 2012;Lavalle et al., 2011). However, this siloed approach ignores the commonalities of tasks across domains, which would allow exchange with potential benefits, eliminate the need for tailored solutions, and save resources. It can result in skills gaps, isolated expertise, and a lack of leadership to harness and develop analysts, resulting in domains being left behind (Carillo, 2017;Grossman & Siegel, 2014;Wixom et al., 2013). It delays the development of broad expertise across the organization with the flexibility to respond quickly to emerging issues without excessive overhead (Wedel & Kannan, 2016). Wedel and Kannan (2016) name Netflix as an example for pursuing a fully centralized Analytics approach and AT&T as contrasting example for an organization pursuing a fully decentralized approach.
Two further, distinct hybrid modes are discussed below, while a multitude of gradations is imaginable. First, analysts can be rotated through several domains by assignment, exposing them to several domains and facilitating their interaction with key stakeholders (Harris & Craig, 2011;Harris et al., 2010;Wixom et al., 2013). That way, analysts are more aware of the organization's main activities, challenges, and processes and can develop greater understanding of the organization overall including strategy and value creation potential from Analytics solutions . Thereby, the fit to strategy is indicated as a distinguishing factor between low and high performers (Cao & Duan, 2017). Rotation further creates exchange between domains and stimulates the adoption of Analytics across domains (Lavalle et al., 2011). The rotation can be reciprocal, such as domain experts being deployed to Analytics functions as support as well (Wixom et al., 2013). The second hybrid organizes analysts by deploying some Analysts in domains and keeping some centralized (Debortoli et al., 2014;Grossman & Siegel, 2014;Watson, 2014). This hybrid accounts both for problems that can be addressed by generalists and for business problems that require highly specialized analysts, who should be strongly familiar with the domain (Debortoli et al., 2014;Grossman & Siegel, 2014). Examples may be problems without predefined solutions or of an experimental nature that might include innovative technologies and concepts. E & J Gallo winery has been mentioned to take the rotational approach, while Zalando uses embedded (in the domain) and central Analytics teams Luetke Schelhowe, 2017). Google has even been mentioned to follow either approach, which indicates them not to be mutually exclusive (Harris & Craig, 2011;Wedel & Kannan, 2016).

Methodology
This research aims to explore the characteristics of Analytics initiatives that set domains apart on the example of the LSCM domain. This objective requires a research design based on empirical data. Since extant research about these individual aspects is limited and largely incidental in the existing literature, this research is exploratory in nature. Thus, a Grounded Theory approach has been chosen using semi-structured interviews for data collection (Manuj & Pohlen, 2012;Strauss & Corbin, 1998).
Grounded Theory combined with semi-structured interviews has previously been used in LSCM research to map phenomena and develop distinctions. Grounded Theory has been employed to map themes and properties of enhanced communication that have explanatory value for differences in business performance in the employee-to-employee relationships between supply chain organizations (2012); categories of benefits of supply chain clusters have been identified, with detailed reasoning for the distinctions made (Rivera, Gligor & Sheffi, 2016); and definitions of supply chain complexity and supply chain decision-making complexity have been designed, and antecedents, moderators, outcomes, and interrelations identified (Manuj & Sahin, 2011). To summarize, Grounded Theory generates depth and understanding of research topics in LSCM when little is known about the research subject and, as a result, is suitable for this research.

Sample and Data Collection
Initially, experts on SCA were contacted for interviews, but these experts expressed their concern about their inability to make statements about differences of LSCM as compared to other domains, since their experience is limited to a single domain. Consequently, experts with experience in executing Analytics initiatives in different domains were sought by approaching "Data Analytics Companies" (Beer, 2018). Specifically, experts in these organizations were contacted and asked about their experience with different domains and their experience with LSCM. Experts who signaled knowledgeability about LSCM and several other domains were invited for interviews. For this purpose, a list of top solution vendors and integrators for Analytics was extracted from market reports. A list of 110 "Data Analytics Companies" was compiled and participants from managerial and senior positions were chosen for establishing contact. An initial sample of interviewees was sought based on experience, job title, profile, and willingness to participate. Subsequently, theoretical sampling was used in accordance with the Grounded Theory approach (Manuj & Pohlen, 2012;Mello & Flint, 2009;Strauss & Corbin, 1998). Thus, the choice of experts contacted was determined by the theory emerging from analysis of the interviews already conducted. As the theory emerged, interviewees were recruited with the objective of further developing understanding in certain aspects. Therefore, personal and company profiles were taken into consideration, while job title and experience requirements were relaxed. Later interview requests targeted more technology-focused organizations as well as experts in Prescriptive Analytics topics. Eventually, 13 interviewees were recruited, resulting in twelve interviews including one interview with two interviewees. For reasons of anonymity, positions and organizations are presented as follows: • Positions: Head of Analytics (2), Director Analytics (3)

, (Senior) Manager Analytics (3), Consultant
Analytics (2), Solution Architect Analytics (3); • Organization: Solution Vendors (5), Solution and Service Vendors (2), Consultancy (1), Solution Vendor and Consultancy (2), Integrator (1), Service Vendor and Consultancy (1). Figure 1 summarizes the years of experience distributed across the interviewees, as well as the interview duration. Interviews were conducted via telephone and VoIP conference systems. During the interviews, handwritten notes were taken for the purpose of recording and guiding the interview. The interviews were audio-recorded if permission from the interviewees was granted. Audio-records were transcribed and deleted afterwards.
Following the recommendations for Grounded Theory (Strauss & Corbin, 1998), interviews were started with "grand tour" open-ended questions (McCracken, 1988). First, interviewees were asked about their understanding of the terms "Analytics" and "Data Science". Second, they were openly asked about the differences of Analytics initiatives executed in LSCM compared to other domains. Subsequently, the open questions were extended by focused questions. To provide a systematic examination of the interviewees' experience and knowledge, interviews were structured on "cause categories" provided from the Ishikawa diagram -a tool for identifying causes. Eight cause categories were used in this approach (2016). The original generic cause categories were adjusted to Analytics by referencing the cause categories to more specific topics from Analytics. This approach was used to provide a systematic and broad focus on differences to discuss with the interviewees. The categories were as follows: People (users and domain experts), Methods (analytical and initiative management), Machines (hardware and software), Material (data), Measurement (metrics of success, objectives), Environment (partners and external data), Management (organizational management), and Maintenance (solution maintenance).

Figure 1. (left) Duration of Interviews with Experts, (right) Experts Experience in Analytics
Interviewees reported the differences among domains in executing Analytics initiatives to be nuances. However, these nuances corresponded to the characteristics this study aspired to identify. Thus, the characteristics, or rather phenomena (1998), and how they influence Analytics initiatives were mapped, as presented in section 4.
Interviewees elucidated the nuances, as they perceived them, based on Analytics initiatives they had contributed to. The systematic semi-structured interviews identified three forms of characteristics: (1) interviewees presented distinguishing characteristics of LSCM from other domains, (2) interviewees explained characteristics with differentiation potential through examples that distinguish other domains and commented that LSCM does not differ from the majority of domains, (3) interviewees explained distinguishing characteristics that were previously different in domains, but not currently. The latter was primarily influenced by the current hype-level of Analytics causing changes in the characteristics across domains.

Data Coding and Analysis
Data were analyzed in accordance with the guidelines of Grounded Theory as described by Strauss and Corbin (1998). In the first step of the analysis of interview transcripts, open coding was performed following each interview with the intention of incorporating new aspects into the subsequent interviews. In the open coding, the interviews were conceptualized on a sentence-by-sentence basis by labeling them with short explanatory phrases or terms. Similar statements were given the same label. The labels, and the concepts they represent, were used to identify "categories" in subsequent steps, which reflect phenomena such as events, conditions, or actions/interactions. After twelve interviews, theoretical saturation was attained such that incremental interviews were not expected to yield additional information. The analysis was performed using the ATLAS.ti software and resulted in 90 labels. After all interviews had been conducted, following Strauss and Corbin (1998), the labels were reevaluated to discover the categories. Thus, the concepts were grouped under higher order categories with an improved ability to explain or predict phenomena. For this purpose, a category-by-category comparison was conducted. Resulting higher order categories were subsequently given names with explanatory value and these categories were developed into phenomena by using the interview chunks to derive explanations describing the phenomena and delineating them from other phenomena. These steps eventually resulted in 34 categories.
In the second phase of axial coding, links between categories were systematically developed by using the paradigm scheme and its components (Strauss & Corbin, 1998). The paradigm scheme components recommended by the Grounded Theory guidelines are conditions, actions/interactions, and consequences, as illustrated in Figure 2.
Conditions are divided into causal conditions, which influence other phenomena; contextual conditions, which have their source in causal conditions and create circumstances or problems to which persons respond through actions; and intervening conditions, which mitigate or alter the impact of causal conditions and must be responded to by actions. Actions represent strategies devised to manage or respond to a phenomenon such as causal conditions. Consequences are outcomes or results of actions.
In the final phase of selective coding, categories and components were integrated and refined (Strauss & Corbin, 1998). Thereby, more detailed and comprehensive explanations on phenomena were derived by revising them to indicate connections to other phenomena according to the data. Appropriate to this purpose, the components from axial coding were split such that connections could be revised to represent the links in accordance with the data to form a well-developed map of the characteristics of Analytics initiatives that potentially set domains apart.

Trustworthiness
Following previous studies using Grounded Theory in LSCM research (Gligor & Autry, 2012;Manuj & Sahin, 2011) and studies reviewing Grounded Theory approaches (Denk, Kaufmann & Carter, 2012;Manuj & Pohlen, 2012), multiple criteria for trustworthiness were collected. These criteria are credited to the Straussian School of Grounded Theory, which was followed closely in this research. The following criteria were addressed: (1) Credibility was addressed by providing a summary of the phenomena with descriptions and links to the participants for feedback and reflection; (2) Transferability was ensured by applying theoretical sampling; (3) Dependability was addressed by following the guidelines of Strauss and Corbin for Grounded Theory (Strauss & Corbin, 1998) and McCracken for interview design (McCracken, 1988); (4) Confirmability was addressed by a technique using an altered form of bracketing (Kvale, 1983) as described by Manuj and Sahin (2011), which requires the authors to write down the essential points known about the research subject. The pre-existing knowledge was afterwards compared to the results. Phenomena that overlapped in pre-existing knowledge descriptions and results were reviewed for their existence in the transcripts. (5) Integrity was established by maintaining anonymity of the interviewees; (6) Fit was ensured by the methods for credibility and dependability; (7) Understanding was also addressed by the summary provided to interviewees and the process of feeding back to and reflecting with them; (8) Control was given to interviewees, who had some control through directing the interview to topics they perceived as important; (9) Generality was aspired to with the length of the interviews and use of open questions, and the subsequent systematic structure that intended to cover as many areas as possible.

Results and Discussion
This section explores the results by presenting the characteristics of Analytics initiatives differentiating domains, with specific reference to LSCM.

The Map of Characteristics of Analytics Initiatives Differentiating Domains
The characteristics derived from the data analysis have been mapped according to the paradigm scheme of Strauss and Corbin (1998). Due to substantial differences among the characteristics allocated to components, the components were further segmented. This resulted in eleven sub-components with 32 characteristics of Analytics initiatives that differentiated among domains. A twelfth component was created describing the concept of Analytics, which is independent of the domains. The components and their characteristics, which are explained in the upcoming section, are illustrated in Figure 3.

The Concept of Analytics
Two domain-independent characteristics were identified, which describe the interviewees' conceptualization of Analytics and the distinct roles and attributes of analysts.
The term "degrees of Analytics" hints at the degrees of business intelligence described by Davenport and Harris (2007) and addresses different levels of complexity of analytical methods. However, they represent contemporary complexity levels, which are subject to change over time. Analytics has been recognized as the most complex "degree" of analytical methods, building on the overall concept of Business Intelligence applied twelve years prior (Davenport & Harris, 2007). However, in this study, the interviewees recognized Analytics as an overall term, with Business Intelligence as its least complex degree, Analytics, in a second function for the term, as a label for the moderate degree, and Data Science as the most complex degree of analytical methods. In the introduction, the terms were expressed as being hard to distinguish, and interviewees explained this as somewhat artificially created. The methods and technologies constantly evolve, but distinct labels advertised as innovations help to draw attention to the topic. This attention helps to either market evolved analytical concepts to more mature organizations for new use cases or present interesting opportunities to organizations less experienced in Analytics.
As a result, this can lead to confusion, but helps to increase the popularity of analytical methods. In regard to this, a label similar to "cognitive intelligence", a term invented to describe the business version of artificial intelligence (Maissin, Van Der Elst, Griedlich, Mouton & Van Der Poorten, 2016), might be a plausible candidate for the next label. In short, Business Intelligence is currently understood as comprising methods of manual and experience-or intuition-driven analysis of structured data, mostly from data warehouses, vulnerable to human bias and with less advanced methods. Analytics is understood as comprising more advanced methods with structured data, resulting in model-and algorithm-driven insight relying on human intuition and experience to a lesser degree. Data Science was understood by interviewees to refer to the most complex and advanced analytical methods (machine learning, advanced statistics), supposedly minimizing human bias and applied to unstructured data as well, often with a more experimental and proof-of-concept focus as opposed to driving business decision making.
Four Analytics roles were extracted, which are postulated to exist in parallel in an organization. First, business users use embedded analytical functions from the software accessible to them. Second, controllers aggregate and group data and numbers and must assure correctness of data for the purpose of reporting to higher management as well as legal authorities. Third, business analysts are business function-specific analysts familiar with some advanced methods for structured data in terms of purpose and application with the intent of producing consumable insights for management or other non-analysts. Fourth, data scientists are application developers with a full range of knowledge about the methods and tools at hand, from simple methods in graphical user interfaces to advanced methods applied "at the command line", who have deep technical and analytical knowledge and skills, and try to stay up to date on methods. Their jack-of-all-trades-image was rejected in the interviews and they were generally criticized for their tendency to produce results that are non-consumable for non-analysts, to develop applications that are not scalable, to reinvent existing concepts, and that do not address business needs.

Causal Conditions
Causal conditions represent sets of characteristics influencing other characteristics and conditions that explain why persons, or organizations, respond as they do (Strauss & Corbin, 1998). From the interviews, three sets have been identified: extra-organizational causal conditions, intra-organizational causal conditions, and conditions influencing Analytics processes in an organization and, subsequently, the Analytics initiatives (intra-processual causal condition).
The first characteristic of extra-organizational causal conditions is the mentioned patterns of development of data Analytics terms, leading to a new taxonomy about "every 5-7 years or so". The new and unheard-of concepts usually highlight aspects that were already used to a lesser degree in previous iterations. These changes mobilize new groups to use Analytics or existing user groups to identify new use case domains differently. Second, as infamously represented by the Gartner hype-cycle, technologies and concepts undergo cycles of temporary publicity, leading to changing hype-levels of Analytics. This results in an eruption of projects to create benefits from data in a sort of "gold rush atmosphere", with exaggerated expectations on profitability and ease of applying Analytics. At the time of this study, organizations are eager to create Analytics subsidiaries (e.g., Data Labs, Data Factories) with high top management attention but likely to perish quickly if they fail. This kind of adoption based on the momentum of other adopters and success stories is termed bandwagon behavior, which can lead to a mindless adoption, as opposed to one that is mindful and thus wary and appropriate to the organization (Fiol & O'Connor, 2003;Swanson & Ramiller, 2004), with domains displaying this behavior to different degrees. Third, interviewees described the rather abstract phenomenon of external pain points that create different stimuli to interest and need for Analytics in different domains. This characteristic was retained as a vivo code (Strauss & Corbin, 1998) to express the recurring inability of interviewees to explain it more tangibly. This pain point could be something like competitive pressure, reducing environmental impact, changing regulations, or customers demanding Analytics solutions. Fourth, a specifically mentioned external stimulus to use Analytics is regulations. The regulatory demand to report various aspects of organizational operations and actions is a strong motivation to deploy Analytics, especially if future prognoses are demanded, such as for the banking domain to avoid market crashes and monetary devaluation.
For intra-organizational causal conditions, one characteristic with different impacts in different domains is the data-driven culture, which is assumed to have a plethora of effects on the application of Analytics in organizations, as discussed by scholars (Holsapple et al., 2014;Kiron et al., 2012;McAfee & Brynjolfsson, 2012). This culture positively influences the cooperation of users and experts within Analytics initiatives, and acceptance and use of the Analytics solution, but requires appropriate change management. Otherwise, users show unwillingness to participate or devalue solutions ("this is a one-time effect", "data have been flawed and antiquated"). Another characteristic of this causal condition is prior knowledge on Analytics. This prior knowledge paves the way for the application of Analytics, collaborative initiatives, and the use cases that can be addressed. However, interviewees highlighted background knowledge as being less important than interest and willingness to achieve a successful improvement of processes using Analytics. Nevertheless, this motivation is often dependent on knowledge.
Finally, the causal conditions above influence the intra-processual causal condition, represented by the characteristic of state of progress of Analytics. This characteristic refers to maturity, advancement of use cases, and adoption rate, which differ across domains.

Context Conditions
Context conditions describe conditions originating in causal conditions and creating circumstances and issues for Analytics initiatives to which people respond to through actions and interactions (Strauss & Corbin, 1998). In contrast, intervening conditions moderate the effect of causal conditions. The identified context conditions have been grouped into conditions concerning organizational processes and conditions concerning the application of Analytics.
Regarding organizational context conditions, the first identified characteristic is budget to execute Analytics initiatives, which might be an additional allocation, reallocated from IT, or not allocated at all. Its allocation can be goal oriented to create innovations or "halfhearted" by hiring "some Data Scientists" due to hype, without any ideas for use cases. In contrast to the varied behavior of different domains in the past, organizations across domains are currently allocating budgets into Analytics in surprising magnitudes, previously unseen by the interviewees, while organizations without financial means wait for technology providers to develop applicable solutions. Second, long-term value from Analytics requires strategic Top Management support, as discussed by previous scholars (Davenport & Harris, 2007). Interviewees explained that both IT and business units can easily lack strategic vision, with the former prioritizing technical specifications and standardization over functionality and displaying protectionism, and the latter being stuck in its daily business or concerned about increased workload. Top management support is required to establish a goal-oriented course of action with Analytics, encourage change, and create visibility of the value of Analytics -a value that is recognized differently across domains. As an interviewee described: "If nobody recognizes the value of an initiative, it will not have success".
Concerning application context conditions, it must be recognized that Analytics has low standalone self-purpose and requires a problem-solving approach to address business problems or cases -"something with a user story behind" -at the core of initiatives, as scholars have emphasized (Herden & Bunzel, 2018). The problem needs to be clearly defined and its solution promise valuable returns, whether for data aggregation of reports or for strategic enterprise-wide analytics initiatives. Interviewees expressed that this business problem is more relevant than superior algorithms or models, with timely available solutions "put on the road" being more valuable than superior, but non-deployable or delayed, algorithms. This problem-solving approach proliferates with increasing experience with Analytics but organizations across domains are still performing Analytics initiatives without a problem. These are unlikely to address business needs, instead resulting in abandoned pilots, undeployed solutions, or missing users for deployed solutions. A second characteristic and a strategy to ensure addressing a business problem is to give business users means to apply Analytics by themselves -so-called self-service Analytics. However, this requires users' ability to apply quantitative methods, while access to data and tools must be provided. Only some domains are putting this to the test. Third, due to the promised value from data and the technological ease of data collection, organizations across domains are experiencing a data abundance, leveling out the varying data access situation in the past. This does not imply access to all the data required for their initiatives. Organizations collect and store data without a specific purpose, hoping to harvest the value at a later point in time, while the number of data sources increases constantly, and collection is becoming cheaper. Consequently, they try to harvest value from data forcefully while contradicting the problem-solving approach -with sporadic success.

Intervening Conditions
Intervening conditions mitigate or alter the impact of causal conditions on Analytics initiatives, and must be responded to by actions (Strauss & Corbin, 1998). They contrast with context conditions, which are triggered by causal conditions. The identified intervening conditions were grouped into organizational conditions, conditions concerning the process of executing Analytics initiatives, and conditions concerning the required technologies.
The first organizational intervening condition, mostly recognized as specific to the LSCM domain, is the crossing of functional boundaries. The characteristic describes data being collected, stored, and owned by partners, with Analytics solutions requiring to be deployed across boundaries to these partners as well. However, boundaries can already exist in the same organization between business functions, which are rarely crossed in some domains. A closely linked second characteristic is data ownership issues. This, as opposed to the previous characteristic, considers data owners with no business relationship, but which possess relevant data. Data collected by a third party or using the technology of a third party is often owned by that third party, resulting in additional agreements. These are increasingly used in some domains as source of revenue: "most data owners have recognized the revenue potential by now", and increase the cost of Analytics initiatives. Unwillingness of this third party can further prevent access to data necessary for an initiative. This issue is impeding organizations across all domains, but interviewees suggested that organizations could accept Analytics solutions from data owners instead, while saving resources by buying (decision-ready) insights. Third, the characteristic of data security issues is usually a major concern in domains with highly sensitive data, necessary to protect the privacy of individuals. This induces steps to limit access to data or to anonymize them, complicating their use in analytical methods and demanding additional infrastructure in the form of hardware and software to increase protection against unauthorized access.
The category of application (processual) intervening conditions is the largest. The first characteristic, that interviewees unanimously agreed to be the main and most tangible differentiator of domains, is the inherent Analytics use cases. This is self-evident, since the business tasks, processes, objectives, roles, people filling the roles, their knowledge, and their vocabulary are different. Thus, metrics, data, and requirements of Analytics solutions are different, resulting in various use cases inherent to every domain. However, some use cases recur in numerous domains. Second, interviewees unanimously agreed upon the lack of domain inherent Analytics processes and methods. Analytics is characterized by transferability to any domain. This includes the process of executing initiatives, process management techniques and, in particular, the "very transferable" analytical methods. However, choice of and adjustments to a method are dependent on the specific use case, resulting in some methods being used more often in certain domains. Third, while in some cases there is an abundance of data, as explained above, for certain problems and use cases, a shortage of data can occur in some domains, since not everything interesting is currently collected or collectable. The required data collection technology may not exist or is not available for a reasonable resource commitment. Thus, the development of a technology or a reduction in its price can spontaneously enable a range of organizations to execute certain initiatives, such as with the internet-of-things (IoT) sensor data discussed below. Fourth, and closely linked to data shortage, are data quality issues, which have been identified as cross-domain issues (Hazen, Weigel, Ezell, Boehmke & Bradley, 2017) but to varying degrees in different domains. They result from false entries, missing entries, conflicting entries, and unstandardized data entries and prevent integrated analysis and more complex Analytics initiatives, which can even occur in the same organization. Hence, resources are redirected from Analytics initiatives to initiatives to integrate data. Fifth, as discussed above, for complex analytical approaches, several data sources must usually be combined -crossing organizational boundaries, business units, or process steps, leading to issues with heterogeneity of data as a characteristic. Even comparable processes may entail different machines or different people in charge of processes and, thus, create differences in data (e.g., data collection frequency, data availability, data structure, or data granularity). As a result, integration binds resources that would otherwise be used for insight generation in some domains. Sixth, a contemporary stimulus for adopting Analytics is the use of external data, due to wide applicability and increased availability. As one interviewee explained: "as of now, using external data is common sense", and most domains use them for improved results (e.g., for LSCM, data on infrastructure, weather, traffic, natural disasters, political conditions, and regional customer characteristics and preferences). Finally, the use of mobile sensor data has increased due to advances in their technology and especially integrability and remote data access ability. This characteristic is becoming quite relevant in some domains in particular, resultingly distinguishing it from other domains, due to IoT sensor devices that transmit data via GSM or other mobile signals. These sensors create access to new kinds of mobile data (e.g., ambience, vibration, brightness, sound level, movement, image-based condition, position), while data become available in higher granularity and frequency.
Concerning application (technical) intervening conditions, some domains experience issues in these conditions that increase the impact of the issues discussed in previous categories. The first technological characteristic altering an organization's ability to apply Analytics is an integrated systems landscape, which enhances Analytics if present and obstructs it otherwise. The replacement of outdated systems, which lack the performance of modern systems, can be too great a risk for an organization dependent on these systems' functionalities and worrying about losing them. System landscapes grow organically and so do their data structures, resulting in established organizations losing overview of their systems in terms of functionality and operating method as well as in inappropriate or missing updates to the systems. Once deliberately deployed, tailored, and task-specific systems lack scalability and integrability in the context of today's systems landscapes and, nowadays, the effort of orchestrating these systems is challenging and resource consuming. Start-ups and younger organizations are usually spared from these challenges but most organizations in established domains need to cope with them and must redesign their systems landscape. A second prominent characteristic that creates challenges for organizations in the execution of Analytics initiatives is standards for data exchange. Internal data exchange standards are adapted from legacy systems in the systems landscape or overturned and compromised by merger and acquisition. Externally, some domains have developed standards for certain data exchange processes such as the EDI (Electronic Data Interchange) standard, but these are usually barely sufficient for Analytics requirements. However, the currently used interface landscape created to enable data exchange is argued by interviewees to be sufficient for current needs and the development of a standard would lack a necessary authority, with the result that scholars' demands for a common shared understanding on the definition of standards and interfaces (Kache & Seuring, 2017) might not be met any time soon.

Actions
Actions represent strategies devised to manage, handle, carry out, or respond to conditions (Strauss & Corbin, 1998). Thus, the analytical actions identified in this study are initiated or altered by the various identified causal, context, and intervening conditions. Analytical actions are distinguished as initiatives that represent the use cases of analytical methods and actions related to the lifecycle of Analytics initiatives.
In accordance with a widely recognized perspective, the analytical actions in initiatives are distinguished as Descriptive, Predictive, or Prescriptive (e.g., Holsapple et al., 2014;Souza, 2014;Wang et al. 2016), which were explained by interviewees to represent complexity levels, but only to a limited extent. Initiatives usually demand a combination of different approaches that employ both (relatively) simple and complex methods. Regarding the first approach of Descriptive Analytics, the methods are predominantly less analytically complex, with rule-based data aggregation analysis. However, they can become technically complex when several heterogeneous data sources are required to become integrated. Currently, interviewees experience high demand for such initiatives from organizations in some domains, attempting to create "a single version of truth" of their complex operations in similarly complex organizational structures, which are no longer manageable by intuition and require data-driven decisions and control. The created insight -embodied in reports, key performance indicators, and dashboards -is usually post-operational and provides transparency and visibility of the status of the daily business, mismatches of results to expectations, weak spots, benchmarks for different decisions, and needs for actions -without necessarily specifying which actions. Nonetheless, it was credited as a "good entry level Analytics approach" by the interviewees, creating meaningful insight, nonetheless. The second characteristic, or rather approach, is Predictive Analytics, which is currently broadly requested across domains, while some domains took time to catch on. Famous due to demand forecasting, Predictive Analytics provides use cases for most domains, while it is deployed in cases of higher or lower analytical complexity. Third, Prescriptive Analytics mostly consists of the application of optimization methods. While more complex optimization use cases are concentrated in a few domains, the methods are generally used in most domains. Further, the methods are sometimes applied to simpler, repetitive problems and as such provided as features within software tools without further individualization, leaving potential for improvement.
Regarding the lifecycle actions, the identified characteristics concern the benefits of analytics initiatives in the short and long term, and issues in these characteristics can eradicate any productive activities in the previous steps of the initiative. First, a major current issue in many domains is the operationalization, the so-called deployment, of Analytics solutions. There is a shift towards providing more Analytics solutions directly into operational processes to improve decision-making at the operational level instead of the managerial level only. The insights are used faster and the users at that level work naturally with those insights since they are based on their tasks and decisions. Further, they are incentivized to collect and insert data more carefully because they get better insights or better processes in return. However, this phase is prone to be underestimated in the planning of the initiative, and challenges, overlooked user requirements, and the heavy resource consumption can result in abandoned pilots. Second and similar, the subsequent maintenance of the developed Analytics solutions, such as algorithms and models, is supposed to ensure correctness, adaption to the process, persistence of accuracy, or adjustment to new patterns in newer data. As scholars have indicated, this requires continuous monitoring and evaluation of even proven useful analytics solution (Leventhal, 2015). However, while users are familiar with updates for software, maintenance of Analytics solutions is alien to some domains that lack maturity in Analytics.

(Aimed) Consequences
Finally, consequences are the outcomes of actions and therefore the outcomes of the investigated Analytics initiatives. Corresponding to the research method, the consequences below refer to intentions and aims.
The first and foremost aimed consequence is the characteristic of achieving the financial objective, whereby short-term costs savings and revenue increases must be distinguished. Analytics tends to provide direct benefits (improving processes, increasing revenue), which induce indirect monetary payoffs in terms of cost savings. An initiative must be cost effective in this indirect way, since it involves an investment that is supposed to create an output valued higher than its input, like any other investment. The financial objective, which is pursued in some domains, stands outside of this cost-effectiveness and refers to direct cost savings and increased revenue. However, interviewees usually addressed non-monetary objectives. Second, one non-monetary objective is the accuracy objective, referring to the need for high accuracy of Analytics solutions due to criticality of business processes. Criticality can result from domain-specifics such as possible harm (e.g., pharma, aeronautics), adherence to laws (e.g., taxes), or costs of inaccurate decisions (e.g., consumption of low margins in retail). Consequently, users must communicate reasonable requirements on the accuracy, since it influences the dimensions of Analytics initiatives. Third, another non-monetary objective is the efficiency objective, regarding identifying and eradicating process inefficiencies. This may concern the identification of sources of lost time, insufficient quality, or waste, and creation of monitoring solutions that support control of these inefficiencies.

Specifics of the LSCM Domain
LSCM shows several differences in the mapped characteristics in all components except context conditions, which are discussed below. This implies benefits from domain-specific research with extensive domain knowledge on the issues. However, the majority of characteristics, not discussed below, represent characteristics of Analytics initiatives that allow cross-domain research for improved approaches or to create measures to overcome barriers.

Specifics in Causal Conditions
Interviewees attested a certain scarcity of pain points in LSCM, leading to low perceived external pressure to use Analytics as compared to other domains. Organizations in LSCM are usually driven by the internal need to handle and control the daily business and operations -motivating the use of Analytics if this control is perceived as unsatisfactory. Customers may create an indirect stimulus by demanding more efficient services, but few customer requirements specifically demand Analytics and, in particular, few were reported to demand Analytics solutions that necessitate Analytics maturity, that is, those beyond market-available solutions.
Considering regulation in particular, LSCM was also reported to be subject to fewer and less complex regulations, but still has to report things like journey times of drivers or compliance to customs, taxation, or customer requirements. Interviewees speculated that environmental regulations will potentially increase the use of Analytics in LSCM, but the current influence of regulations on the state of adoption of Analytics in LSCM is low in comparison to other domains.
Interviewees reported perceiving LSCM as more directed towards an intuition-driven culture as opposed to a data-driven culture, which was, however, described in aspects comparable to a lock-in effect for solutions. LSCM was an early adopter of analytical methods in certain processes and these solutions are trusted, with hesitance to use other, allegedly more advanced, methods. Thus, the culture is less data-driven relative to newer Analytics approaches and the issue is one of change management.
Respondents experienced personnel in LSCM, relative to other domains, as less imaginative in the use of data, having a comparatively lower degree of experience in working with data, and with a higher need for explanation -having less prior knowledge. Considering the range of activities in LSCM, the domain has an apparent demand for a workforce without a requirement for formal education in statistics or higher mathematics, while members of this workforce, on the condition of showing satisfactory performance and due to their "shop floor experience" (Rivera et al., 2016), can rise to management positions. However, people in LSCM are perceived as interested in (and proud of) improving their processes and finding solutions for their problems, leading to the flexibility to test several solutions with a hands-on mentality. Interviewees observed two outcomes of this: if a solution has been found to which people have become accustomed, they are harder to convince to change course. Otherwise, they are open to new solution attempts, including Analytics, but the problem to be solved is resultingly intense.
Regarding the state of progress, LSCM is perceived to occupy a stable midfield position. In contrast, other domains are perceived as more volatile -sometimes leading, sometimes trailing. Respondents reported they were currently executing Analytics initiatives in LSCM that they had executed decades ago in domains such as banking and telecommunications. This current state was understood to be caused by previously lacking data and technology that are now available, giving LSCM a momentous opportunity to catch up with some organizations already exploiting that potential. However, this potential requires industry interest or identification of pain points to exploit.

Specifics in Intervening Conditions
In accordance with the foundational idea of LSCM of creating a conjunction between different actors to transform raw material and distribute resulting products to consumers, LSCM organizations have a substantial number of links to customers, suppliers, service providers, other business units, and other partners. Thus, LSCM constantly crosses internal and external functional boundaries in its physical processes and would greatly benefit from implementing Analytics initiatives in a more natural way compared to other domains (e.g., new business models between wearable technology providers and insurance organizations). However, issues arise from data collection or distribution of Analytics solutions that cross functional boundaries. First, due to global distribution of partners and organizational distance, a different need for collecting or exchanging data is perceived, or the resulting transparency is feared as a loss of power and influence, even in the same organization. Second, cultures differ in attitudes towards collecting and exchanging data. Third, technological infrastructure and systems differ, complicating data exchange. The organizational distance increases further with requests for data exchange cascading to organizations with indirect business relationships (partners of partners). In reverse, insights from Analytics solutions might be necessary for partners, leading to deployment across functional boundaries. This increases the scalability and adaptability requirements of the solution, which increases development time and reduces the interest of solution sponsors unwilling to pay for benefits outside their area of responsibility. Lastly, due to limited contract duration, exchange of partners, and changing customer preferences, the supply chain network is in constant motion such that cross functional Analytics may have a short durability.
In contrast, interviewees did not observe demanding requirements in terms of data security in LSCM, since for most use cases organizational assets and processes are analyzed, as opposed to individuals. Of course, customer preferences analyzed for demand prediction entail privacy concerns, but such concerns are far more regular in other domains.
This study further specifically inquired about data quality issues, since scholars indicated the considerable impact of human data collection errors (Wang, Caron, Vanthienen, Huang & Guo, 2014). This was confirmed by some interviewees but was evaluated as a minor component of the data quality issue, with its effect comparable to any other domain. Further, data collection is increasingly becoming automated such that this impact will be eliminated in the long run.
As a consequence of the crossing of organizational boundaries, also natural to LSCM is heterogeneity of data coming from diverse business functions and partners. In LSCM, this binds resources for creating interfaces such that interfaces are created with partners considered to have reasonable importance and longer expected partnership lifetime. Put differently, the effort is not invested for every partner, hindering potentially interesting initiatives.
Finally, LSCM is a favorable candidate to use mobile sensor data and has an affinity for using it from mobile assets (e.g., ships, trucks, airplanes, trains, elevators, manufacturing machines) and shipments (e.g., containers, packages, work-in-process). This innovative technology represents a paradigm shift in LSCM from collecting event-based data at stationary points to constant monitoring, which provides value by reduced reaction time on incidents. The integration of IoT data is complex and creates large effort in wide-scale implementations but is already technologically manageable. Hence, organizations are still pioneering with the technology, such as a few LSCM organizations that have started to monitor and control their (ideally) permanently moving goods and assets, such as in real-time status visualization. However, organizations struggle with initiatives to extract higher forms of insights and few attempt more complex use cases as ETA-Prognosis, (dynamic) route optimization, and incident-based product allocation or product reordering. Other domains certainly have use cases for this technology, which are, however, less apparent -one interviewee suggested insurance use cases with insurance-owned sensors in private homes detecting unusual behavior (e.g., fire, burglary).

Specifics in Actions
Since it is strongly related to the use cases, LSCM shows clear domain-specifics in the differentiating characteristics.
Regarding descriptive Analytics, LSCM shows an above-average demand for aggregated data from widely dispersed data sources, including IoT, in real time such that operational processes can be fine-tuned and adjusted based on the most appropriate decision for even complex issues, if necessary. LSCM operations have been streamlined and usually include few buffers, which demand precise real-time data to react to short term incidents and changes. As a result, current Descriptive Analytics problems in LSCM display high technical complexity, while some have remaining aspired-to solutions, but have not achieved them.
Regarding Predictive Analytics, LSCM was indicated to trail behind other domains. While scholars (Waller & Fawcett, 2013) have emphasized the potential of use cases such as forecasting of demand, delivery time, or customer behavior, interviewees barely experienced these use cases from LSCM. They observed that these use cases are either on the long-term agenda due to missing data or are inputs for Prescriptive Analytics, whereby the development focus is on the Prescriptive part while accepting of standard solutions for the Predictive part (e.g., predictive maintenance of assets focused on resource efficient repairs scheduled into operations).
With regard to Prescriptive Analytics, interviewees perceived an extraordinary position for LSCM, since there is a natural association between Prescriptive Analytics methods and LSCM optimization problems, which "are so beautifully tangible". LSCM has complex planning problems of goods and assets to be allocated or moved through the network set against its capacities. However, it was also observed that these problems are sometimes solved with standard features of certain software, but these solutions are not further individualized and leave high potential for improvement. Interviewees described further aspects of complexity. First, LSCM is eager to exploit Prescriptive Analytics solutions for identification of alternatives and evaluate the impact of what-if scenarios to develop superior reactions in advance, including dynamic adjustment of operations that were already initiated according to the previously optimal solutions, to situational changes with as little effort as possible. Second, LSCM problems tend to be more complex due to the characteristics of problems and numerous restrictions, which additionally change along the supply chain. As scholars noted, the idea of holistically optimized efficient networks leads to optimization problems in LSCM getting very large very fast (Blackburn, Kallrath & Klosterhalfen, 2015).
Considering the maintenance of Analytics solutions, some domains experience an extensive need for adjustment and verification due to fast degrading model quality or high impact of small degradations. In contrast, domains like LSCM requiring high effort for data collection or deployment of updates tend to maintain solutions less frequently.
Interviewees perceived LSCM to have low need for maintenance, favoring the complete replacement of solutions in the long run.

Specifics in Consequences
Interviewees indicated lower demand regarding accuracy from LSCM. They observed that certain decision-making processes are often well supported by tendencies. LSCM was observed to focus particularly on the efficiency objective, which overlaps with the extensive development of tools to increase efficiency (e.g., lean, continuous improvement). Respondents emphasized that results from Analytics solutions in LSCM usually lead to decisions on physical operations, the resource consumption of which is presumed to be minimized.

Conclusion and Directions for Further Research
Research on Analytics is often limited to one domain, while it is a transferable tool that can benefit from cross-domain development efforts. To identify promising aspects of Analytics for collaborative research, it is necessary to identify the characteristics that set domain-specific and independent issues apart, but the research community has not yet provided this. This study has investigated these characteristics and identified the specifics of the LSCM domain based on Grounded Theory. The derived map displays a theoretical model of characteristics that potentially and currently differentiate domains, or may have done so in the past. This map displays antecedents that influence the procedures for and success of Analytics initiatives, and can guide Analysts and managers for prioritization of issues.

Theoretical Implications
Relating to the purpose of this research, the main contributions is the diagnosis of characteristics of Analytics initiatives, their connections -their mapping -and their use to differentiate LSCM from other domains executing Analytics initiatives. The map provided by this research distinguishes the characteristics in different conditions, actions, and consequences. The mapping of characteristics provides explanatory value for differences in Analytics initiatives' success and performance far beyond the Analytics method and approaches themselves.
This research adds to the limited literature on the effect of the domain on Analytics initiatives and provides an extensive overview of effects contributing to implementation, success, and users' attitude towards it, therefore enabling an initiative to be characterized. These characteristics can be used for further quantitative research on issues relating to Analytics.
Concerning the LSCM literature, the theoretical model emerging from this research provides antecedents of Supply Chain Analytics. It emphasizes the potential of the LSCM domain to advance in Analytics due to recent technological progress, enabling further use cases which should be supported and monitored by research efforts. In particular, research is needed on the exploitation of IoT data and the individualization of Prescriptive Analytics solutions. For both, research is required to simplify the adoption of the results for organizations. Further research is required to facilitate change management towards more advanced analytical methods and presentation of benefits from Analytics.
This study also highlights that organizations are coping with issues far from the considerations of current research. Easily stated recommendations to advance in Analytics, such as by standardization and investment in IT, pose major challenges for organizations with implications and issues unconsidered by research. Thus, this study, by highlighting the complexity of Analytics as embodied in the variety of mapped characteristics, cautions researchers not to bypass practitioners' needs.
To conclude, this study provides a novel approach to understand the execution and success of Analytics initiatives and provides a multitude of new areas demanding deeper investigation and further research. Thus, this research makes a valuable contribution to the LSCM and Analytics literature.

Managerial Implications
This research has accumulated a vast number of recommended actions and behaviors for managers executing Analytics initiatives. Before starting an initiative, managers should identify technical and organizational challenges and prerequisites on the map of characteristics to avoid later issues. Managers should further avoid hype-triggered initiatives but rather create well thought out initiatives comprising of valuable problems to be solved, a potential user meaningfully contributing to the solution's development, a sense of the user story for the solution providing implications for the deployment, and consideration of maintenance needs for long-term performance persistence.
To gain the users' help, trust, and willingness to use the solution, managers must create visibility of the initiative's value. Users must make sure to state the degree of accuracy required or quality of solutions in order to induce the right effort. Based on the map of characteristics provided by this research, managers can grasp the big picture for an initiative and understand success factors, potential hazards, and key areas to monitor such that corrective actions can be taken.
While these implications are directed towards the manager executing the initiative, there are characteristics which are hard for him to reach and get information about. Thus, any member of an initiative's project team is encouraged to be aware of characteristics on the map and to point out potential fallacies. This emphasizes the necessity of domain knowledge in Analytics initiatives and the requirement to assure knowledge exchange between Analytics and domain experts.
In addition, this research brings attention to the complexity of Analytics, which cannot be mastered by "hiring some data scientists". Further, while Analytics initiatives require short organizational distance between Analytics experts and application domains of solutions, they may not require collection of all data from partners if Analytics solutions can be collected instead. Collaboration of this kind, and the sharing of the organization's own Analytics results with partners, might induce benefits such as the partners recognizing the value of sharing such information.
Finally, challenges and issues reappear across domains since many organizations are currently working on similar topics. Managers might consider innovation collaborations and mutual assistance on Analytics across domains with non-competing organizations, which can also generate new use cases. In particular, LSCM managers should explore collaborative use cases beyond operational efficiency, which could facilitate new business models and new sources of revenue.

Future Research and Limitations
This research provides potential for future research to validate the model -the map of characteristics -with quantitative methods to obtain more accurate insights on the domains' conditions. In accordance to that, other domains could be investigated regarding the specifications of their characteristics.
Further research demands arise from the specific characteristics. For example, the need for accuracy in Analytics models and algorithms and factors influencing this need could be studied further for break-even points of investment versus utility. This research could help managers to make better decisions by avoiding seeking too high accuracy without utility from it but with immense resource consumption, or the reverse, too little accuracy, with serious consequences. Further, if hype and pain points lead to budget release in larger organizations, research is needed on how to support organizations with limited budgets, such as small and medium sized organizations. If these organizations perish due to their limited investment potential, competition is permanently altered. Additional research potential lies in overcoming barriers such as reluctance to change to a data-driven culture, non-integrated IT landscape, or unwillingness for data exchange between partners.
Further, this research has limitations. The deployed method of semi-structured interviews results in the theoretical model being subject to the individual experiences of the interviewees and the initiatives they individually conducted and took part in. While this study was controlled according to perception of saturation and its results should thus be generalizable, a larger sample size could allow stronger conclusions. The diversity of interviewees could further be increased in two ways. First, the study included interviewees from Germany and the USA. While the characteristics are expected to be similar globally, interviewees from more countries could become involved. Second, this study intentionally covers an informed outside view on several domains by inquiring among Data Analytics Companies, but in doing so excludes the domain insight view, which experts were reluctant to share due to their inability to compare their domain to others.

Declaration of Conflicting Interests
The author declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding
The author received no financial support for the research, authorship, and/or publication of this article.