1. Introduction
I4.0 is presented as a promising set of integrated digital technologies to improve production performance significantly and bring manufacturing into the digital age [
1]. A core capability of these I4.0 technologies, when combined, is to institute a level of intelligence to production lines by monitoring and eventually controlling physical machines [
1,
2,
3]. By adopting I4.0 technologies, the manufactures can develop their production setup to potentially become both more effective and flexible in producing highly customized products on a large scale while still staying competitive regarding high productivity and continuously lowering costs per produced unit [
4].
Therefore, manufacturers have invested many resources into acquiring these new I4.0 technologies to develop their productions system to be more flexible and productive [
5]. However, when investing heavily in I4.0 technologies, the capital investment gets tied to the production machinery, and the depreciation cost of these investments is often quite irreversible and possesses low variability. Therefore, such investment poses financial risk if the technology is not successfully utilized [
6]. To ensure full capitalization of manufactures’ I4.0 technology investments, the literature suggests implementation in conjunction with process excellence methodologies like Lean Management (LM) [
7,
8,
9].
However, most extant literature exploring how I4.0 and LM can elevate production performance focuses on how to enhance the technical tools and methods of LM [
7]. Only focusing on the technical side of linking I4.0 and LM imposes a significant risk that the implementation of I4.0 technologies will become stranded in a fledgling state. Many I4.0 implementations will, as such, not be able to fulfill the very ambitious and novel performance standards reported in discussions of I4.0, just as it has happened with many LM efforts [
10,
11,
12]. This amounts to a call for a strengthened focus on the non-technical aspects like learning organization (LO) practices and behaviors when manufacturers adopt I4.0 technologies in conjunction with LM for improving production performance [
7,
13,
14]. Conceptually, LM can, from the extant literature, be understood from both a technical perspective and a non-technical perspective. The technical LM perspective is related to technologies and tools like pull-systems, Kanban, and value stream mapping [
7]. The non-technical perspective is related to human and cognitive elements like learning, collaboration, and leadership [
15]. Analogously, we can understand I4.0 from both a technical and non-technical perspective. For I4.0, the technological perspective is the most prevalent in the extant literature and is related to technologies like real-time data, Internet-of-things, and autonomous robots [
1,
13]. However, non-technological perspectives of I4.0 are also on the rise and are related to learning, people development, and managerial aspects [
13]. They are also similar to the non-technological aspects of LM. From an explanatory point of view, this study perceives LO practices and behaviors as underlying and overlapping factors in linking and mediating I4.0 and LM, as illustrated in
Figure 1.
The research area exploring the intersection between I4.0 and LM from an LO perspective is scarce beyond the existing explanatory literature [
7]. Tortorella et al. [
13] have, for example, empirically investigated the association between LO and the adoption of I4.0, and Tortorella and Fogliatto [
15] have done the same between LO and LM, but only quantitively. The aim of this paper is, therefore, first to follow-up on Buer et al.’s [
7] call for additional empirical research on how to link I4.0 and LM. Subsequently, it is to follow-up on recent survey-based research to examine more profoundly and to validate the positive effects that come from focusing on LO when adopting I4.0 in conjunction with LM [
13,
15].
A logical first step for many manufacturers, when embarking on a transformation towards the digitalization of their production system, is to acquire I4.0 technologies that provide real-time data to help monitor and improve the performance of machines and production lines [
16]. This paper examines, as an in-depth field study, the implementation, commissioning, and utilization of a real-time operational data capturing system, based on OEE (Overall Equipment Effectiveness) data, at a LM-intensive Danish manufacture. In the wake of implementing the real-time operational data capturing system, the manufacturer had, after six months, experienced no significant increase in production performance. The first author observed that the manufacturer had not advanced their existing LM work routines after implementation. They continued to practice reactive management-initiated problem solving of production issues, weekly, based on historical operational data.
The scientific issue behind this real-life problem is the underlying non-technocentric variables of why the manufacture was not able to enable its organization to both explore and exploit real-time operational data systems. A central element with this scientific issue is related to real-time data in a manufacturing context. The commission of real-time data comes with new opportunities but also challenges for manufactures. Real-time data has the potential to both significantly reduce the time spent identifying and correcting operational issues like unplanned machine stops and, through predictive maintenance, prevent operational issues happening in the first place [
1]. The significant challenges are non-technical and associated with the multifaceted change process of shifting leaders and employees from working reactively to proactively. In a manufacturing context, this challenge is related to adding new learning routines and work practices on the shop floor. This study, therefore, proposes the following research question: What are the barriers for operators to utilize real-time operational data in improving production performance in conjunction with lean management, from a learning organization perspective?
To answer the research question, the paper will first review the relevant literature linking I4.0 and LM with concepts and practices related to LO. The methods section uses an applied case study research approach, based on a variety of in-depth qualitative data, like interviews, observations, and archival data gathered from different sources at the case company. Subsequently, we triangulate and analyze this data and outline a set of barriers related to LO for utilizing real-time operational data to improve production performance. We use these findings in the discussion and conclusion section to elaborate on how to link LM and I4.0 from a LO perspective, by outlining the elements that can prevent manufactures from utilizing real-time operational data in conjunction with LM to improve production performance.
1.1. Literature Review
1.1.1. Linking LM and I4.0 Using a Learning Organization Perspective
The literature explains LM implementations most unsuccessfully, with an imbalanced technical focus on applying LM tools to improve processes, over the LO aspects of LM [
12,
14,
17,
18,
19]. In this regard, all organizations need to learn how to continuously improve processes and develop how they adopt and utilize new technology daily, to achieve the organization’s strategic objectives while leaders and employees are simultaneously developed [
20,
21].
We, therefore, base this study on Edmondson and Moingeon’s [
22] (p.28) definition of LO practices as the process by which an organization’s members actively use data to guide behavior in such a way as to promote the ongoing adaptation of the organization. The presence of real-time data will not necessarily lead to better performance if the organization is not able to transform the data into valuable actions or adjust existing process standards and daily work routines to utilize the new technology. Likewise, developing new digital versions of LM tools will not make a significant impact if not utilized as a part of learning processes within a LO.
We found positive associations between LM and LO among several authors in the operation management literature. These studies can be divided into studies highlighting learning systems and learning environments as associating concepts between LM and LO, e.g., [
23,
24,
25]. Other authors focus more specifically on problem-solving practices as associating concepts, e.g., [
26,
27].
To advance this study’s objective of empirically exploring how to link LM and I4.0 from an LO perspective, as opposed to the prevalent focus on technical aspects found in extant literature [
7,
28], we consolidated a comparison between the technical domain of both LM and I4.0 and how they are linked associated through the LO domain in
Table 1.
1.1.2. Second-Order Problem Solving
A critical LO capability for any organization applying LM and aiming to utilize I4.0 is the organization’s capability to improve performance by adopting scientific problem-solving practices [
21,
33,
35,
36]. Essential to scientific problem-solving practices is Plan, Do, Check, Act (PDCA), a generic learning model for defining a problem, identifying the underlying causes, developing and testing countermeasures, and instituting new standards and work routines [
37,
38]. In many cases, problem solving is understood only as a technical process improvement practice, without surfacing the underlying LO aspects [
14,
27]. The practice of instructing operators, from a technical point of view, on how to follow a set of predefined steps in problem solving and analytical tools, but neglecting the learning and cognitive aspects, has led to many failed attempts at LM and building LO able to effectively improve performance [
38,
39,
40].
In both theory and practice, scientific problem-solving practices are closely related to LO practices [
26,
27,
31]. They share the underlying learning and cognitive process of defining deviation from the desired state, identifying the root-causes of the current deviation, and subsequently implementing a set of potential countermeasures to close the deviation and reach the desired state [
21,
41]. An organization’s ability to perform second-order problem solving daily is central to changing or adjusting its day-to-day work routines to respond to changes in the production processes, which eventually leads to improved performance [
22,
36,
42].
The consequences of ignoring the LO side of problem-solving practices often lead to a problem-solving behavior pattern, characterized as overcoming the immediate obstacle, assuming what the problem is, short term-fixes, and ignoring the underlying root causes. Tucker et al. [
36] observed this kind of problem-solving behavior pattern among hospital staff, and Worley and Doolen [
42] had similar experiences from observing a lean transformation. From an LO perspective, we can define the latter form of problem-solving behavior as first-order problem solving instead of second-order problem solving [
36,
43]. Second-order problem solving is a cognitive approach that focuses on identifying underlying root-causes. Identification of root causes happens through investigating current work routines and practicing in-depth questioning to identify the underlying root-causes preventing an organization from obtaining a specific goal [
36,
38,
41,
43].
A potential of adopting I4.0 technology is that it can display operation performance data in real-time and automatically generate performance analyses [
1]. Nevertheless, like any analog-generated data, automatically generated analyses based on real-time data still requires an underlying second-order problem-solving process. I4.0 technologies can help operators with automated signals and alerts when deviations occur. However, the operators still need, for example, to apply second-order problem solving to define the performance gap that needs to be closed, as well as identifying the underlying root causes and specific countermeasures to close the gap. The latter also requires a structured approach to experimentation. Real-time data, utilized in conjunction with second-order problem-solving practices, has the potential to considerably reduce the time it takes from when a problem is perceived to when it is solved [
44]. Firstly, real-time data can immediately indicate when there is a deviation from the desired state. Then, the digitally captured data can assist the problem solver in both defining the magnitude of the gap and provide data for root cause analysis. Lastly, real-time data can provide instant feedback when experimenting with potential countermeasures.
1.1.3. Enabling Formalization
Manufacturers cannot expect operators to automatically embrace new daily work routines of engaging in second-order problem-solving efforts and utilizing the presence of real-time data to remove root-causes. According to Adler and Borys [
29], it requires an enabling formalization of work routines, e.g., how to handle deviations and how to utilize real-time data. Manufacturers need to ensure that operators perceive new digital technologies as something that enables them to improve their processes in their daily work. There exist two types of formalization: coercive and enabling [
29]. If the formalization of work routines is coercive, operators will perceive the purpose of new digital technologies as a way for management to ensure compliance of rules and procedures by controlling their work. The underlying logic behind the coercive formalization is that experts and leaders can design optimal work standards for operators to follow. However, the consequences of coercive formalization are that that operator separates themselves from their workplace and becomes alienated instead of becoming committed to daily improvements and problem solving [
29,
45].
Conversely, when the formalization of new work routines is enabling, they are designed to support operators in performing their daily tasks and assists them when deviations from regular operation occur. Enabling formalization of work routines embodies LO practices and dialogue between the operators, specialists, and management, which celebrates problems as an opportunity to learn and to improve performance together [
21,
46]. When formalization is enabling, there also exists a high degree of mutual trust between different layers of hierarchy, where the operators do not fear reprimands in case of mistakes.
1.1.4. Supportive Learning Environments and Learning Processes
A linking characteristic between enabling formalization and LO is the presence of a supportive learning environment consisting of supporting leaders, contextual training, and adequate time to reflect and experiment [
20,
29,
31,
32]. According to Garvin et al. [
31], a supportive learning environment constitutes an environment where operators feel safe disagreeing with others. They can, for example, freely ask naive questions, own up to mistakes, and present minority viewpoints, along with having the time to reflect, explore new ideas, conduct experiments, and share knowledge. This understanding is supported by Marsick and Watkins [
32], who also mention that, in a supportive learning environment, learning is an integrated part of the operator’s daily work. When learning is an integrated part of daily work routines, it becomes natural for operators to develop and improve processes together with co-workers, including the ability to express their views and the capacity to listen to and inquire about the views of others [
45].
A supportive learning environment also accompanies internal and global transparency by consisting of both high- and low-technology systems to capture and share learning across departments, while helping operators to see how their work is affecting the rest of the organization [
29,
32].
1.1.5. Leadership That Supports Learning
A supportive learning environment with formalized learning processes is strongly influenced by the behaviors of its leaders [
19,
31,
32]. A supportive leader acts on a basic underlying assumption that she is not the one who adds value to the produced products. It is the operators on the shop floor who create the value. The type of leadership behavior required to enable operators to increase the value created for the manufacturer’s customers is described in both the existing LO literature [
31,
32] and the LM literature [
19,
20,
23,
38].
One of the central principles for a leader when growing a LO with strong second-order problem-solving abilities is to foster a learning environment with a focus on both striving towards perfection and not blaming operators when failures occur. A leader must embrace failure as an opportunity for improvement and learning by enabling, developing, and empowering operators in second-order problem solving to identify and eradicate root-causes [
20,
31,
32,
43]. A fundamental practice of leaders in a LO is to develop their operators using the principle of ‘going to Gemba’. ‘Going to Gemba’ means that the leaders go to the place where the organization creates its value, e.g., the shop floor, to understand the current situation and, through coaching and mentoring, supports and develops operators in their problem-solving efforts towards the desired state of operation [
19,
20,
23,
43].
3. Results
3.1. The Utilization of Real-Time Operational Data Requires Operator-Initiated Problem Solving
Before implementing the real-time operational data gathering system, OEE data was registered manually on paper by the operators. These data were then collected by the local lean responsible weekly and reported to management. According to the local lean responsible, it was rare that the data were analyzed and used: “I print all the numbers every Monday, but nothing happens, and we have no time to go down and analyze the numbers”.
There also seemed to be a widespread basic underlying assumption among the operators that their role is not to engage actively in problem solving but ‘only’ to generate ideas for problem solving or improvements, then let maintenance handle them. During a focus group interview with the operators, one expressed this basic underlying assumption, saying: "It is easy to generate ideas, but there is nobody to execute them."
The same behavior and basic underlying assumption were also apparent in terms of machine maintenance. They used manually gathered OEE data to prioritize which production lines and machines the maintenance department should focus on fixing at a bi-weekly meeting. However, despite management ambition to conduct preventive maintenance, repairs were mainly carried out when equipment caused unplanned downtime. One of the operators explained this reactive approach to maintenance like this: "We do not work much with preventive maintenance. We do not have the time, and we just call the maintenance department when the machines break down".
It was the presence of this reactive, firefighting behavior to problem solving and maintenance that the leaders in the case company were seeking to change with the implementation of the real-time operational data gathering system. However, six months after its implementation, the case company could ascertain no significant change in behavior or improvement in performance. The operators confirmed the lack of changed behavior during a focus group interview: "We do not use the data from the real-time data gathering system since it is not our system, it is maintenance’s, so they can see what they need to fix." Another indicator supporting the fact that the operators had not altered their daily work practice to utilize the real-time operational data was when the operational gathering system had been out of order for over a week. The operators knew that the system had stopped working but did not escalate the problem. It was a project engineer who discovered and corrected it.
Despite the presence of operational data in real-time, the procedure for utilizing the operational data was the same as before implementation. The local lean responsible still gathered the OEE data weekly to submit a report to the management. They also still conducted prioritization meetings between the production department leader, the local lean responsible, and the maintenance department on a bi-weekly basis.
3.2. First-Order Problem Solving PrevalentAapproach to Reducing Unplanned Machine Downtime
Before implementing the real-time operational gathering system, applying second-order problem solving was not a widespread capability among operators. Problem solving based on PDCA was only conducted occasionally in cases of critical quality issues. In these cases, the quality department performed the problem solving.
As illustrated in
Figure 2, the prevalent problem-solving behavior observed among operators and maintenance specialists can be characterized as overcoming the immediate obstacle, assuming what the problem is, short term-fixes, and ignoring the underlying root cause. If the short-term fixes do not result in resuming regular operation, then the maintenance department will be contacted to re-start the machine. This observation was supported by a leader who explained: "We are often saying that we really need to get to the bottom of this and identify the root causes, but we do not."
It is important that operators begin to start acting on real-time operational data, but more important still is that they do this by applying daily second-order problem-solving based on PDCA, as depicted in
Figure 2. The operators were familiar with several of the LM problem-solving tools and methods introduced by the global lean department. However, our observations revealed that the operators only performed first-order problem solving [
36]. Due to the underlying basic assumption among operators that it is not their responsibility to identify the root causes preventing machines from running could explain why first-order problem solving is the prevalent practice when handling unplanned machine stops. "We are only doing firefighting," as one of the operators explained.
As Tucker et al. [
36] observed among nurses, there also seemed to be a prevalent heroic attitude among the maintenance specialists. When machines break down, they often come and "save the day" by fixing the machine. This behavior fuels a psychological gratification, which maintains the observed first-order problem-solving behaviors. "We honor the firefighters," one of the leaders reasoned in an interview.
Shortly after implementing the real-time operational data system, the maintenance department initiated a set of 11 specific fixes. From observing the implementation of these 11 fixes, we identified two clear examples of first-order problem solving. Firstly, the 11 fixes were initiated at the same time without any specification of what gap or deviation in performance they intended to close. The maintenance department was, therefore, not able to evaluate if the fixes had worked and, eventually, which of the fixes worked the best. Investigating the effects of the fixes revealed that they had not improved performance significantly. Secondly, according to the operators, the fixes were not initiated based on OEE data. The operators explained that the initiated fixes had been on their wish list for a long time, and now management had approved them due to renewed attention on their production lines’ performance as a result of the real-time operational data gathering system implementation.
3.3. Real-Time Data System Perceived as Coercive
Our findings identified that the new real-time operational data gathering system implementation was carried out by experts and specialists from the support functions. Despite their intention, the specialists had not involved the operators in identifying the best real-time operational data gathering system and how to implement it. Before implementation, the operators only participated in an introduction to the system delivered by the technology supplier. After the implementation, the operators only received training in the technical use of the system. Once the functionality of the system was up and running, the experts and specialists from the support functions were off to the next project, and the employees were left alone to ensure utilization of the new real-time operational data gathering system to improve performance.
This coercive formalization approach to implementing the new real-time operational data gathering system adopted by the support functions specialist had several consequences contributing to unsuccessful implementation [
29]. Firstly, it maintained the operators in the existing first-order problem-solving approach, as depicted in
Figure 2, where they were not cooperating with others in conducting the analysis and making decisions on how to improve or fix the machines they were operating: “After the implementation, I still gather data once a week and type it in, and the only change is that I now can get them from the system instead”. Secondly, it strengthened the underlying assumption that it is only the support functions experts and specialists who can identify and implement new technology. “Only ideas of implementing new technology from the engineers get implemented”, one of the operators responded. Thirdly, the operators ended up perceiving that the new real-time operational data gathering system was imposing constraints on their work by adding new tasks in terms of interacting with the system. This perception was clouding the intention for the system to enable operators to reveal opportunities for improvement and problem-solving.
Despite the opposite intention behind implementing the real-time operational data gathering system, the operators did not perceive that the feedback received from the system was useful to them in their efforts to improve production performance. Instead, they believed that the new real-time operational data gathering system was only put in place to help management and maintenance get a better understanding of the production lines’ performance: "We do not need the new system to tell us what is wrong with the machines."
For the operators to utilize the new real-time data gathering system to improve performance, it is also vital to ensure a practice of problem-solving and continuous improvement across departmental siloes. However, the expected outcome of the implementation of the system also failed to appear in this regard. "I expected closer integration between maintenance and production after the system implementation, but it did not happen," the maintenance supervisor explained. One of the operators supported the leader: "We still do not work much together across the factory. If we all helped each other, things would be better ".
3.4. Poor Learning Environment and Learning Processes
At first glance, one would expect the existence of a supportive learning environment at the place of manufacture, since operators articulate the presence of psychological safety [
58]. Operators feel they can speak up about what is on their mind. We observed several meetings supporting the notation that employees can speak freely. At one meeting, an operator complained about the planning department to his leader while the head of planning was present in the room. Our findings did furthermore not indicate a culture where the operators are reprimanded for failures and therefore try to hide them.
However, a supportive learning environment consists of more than psychological safety. A central element is allocating time to experiment and reflect on how to improve work routines in conjunction with new technology [
31,
59]. Our data analysis revealed that operators felt that there was no time allocated to engage in improving work routines: "We do not have time to make improvements; after 11 hours on the job, I just want to go home". The operators explained the lack of time available to develop new work routines as a result of high workload. "We start up a lot but do not finish much. We want to do everything at the same time," one of the leaders responded.
Another critical element of a supportive learning environment and learning processes is conducting experiments in a structured way [
43]. Despite management’s willingness to experiment with new technologies, the execution of experiments could also be characterized as first-order problem-solving. A contributing factor was difficulties in defining a concrete deviation or gap from the desired state, e.g., it was observed that a perceived solution was often defined as the goal itself instead of a means to achieving a specific performance improvement goal. When this was the case, it was difficult to subsequently follow-up and reflect on the learning from an experiment and evaluate the effects [
43].
3.5. Leaders Not Demonstrating Support for Learning
Based on the interviews and observations, a gap between leaders’ espoused theory and theory-in-use emerged [
60]. The leaders had the following perception of their leadership behavior. One stated: “leadership is for me to listen to the employees and identify what needs to be done for them to do their best and be a success”. “Another leader explained”, “My job is to help and coach the employees to improve performance and reach our strategic goals”. Furthermore, a third leader replied, “As a leader, I must be visible and give the employees feedback”. This perception is in sharp contrast to how the operators experience their leaders. “I feel that the leaders do not listen to us. I would like them to exhibit more interest in our work”, as one operator explained. Another operator felt that: “It is often difficult to get hold of my leader. They only come when the KPIs (Key performance indicators) are in red, and then they expect us to fix it”.
Perceptions of the leader’s current presence and support held the operators also indicate a behavioral gap related to the principle of ‘going to Gemba’. According to the operators, the leaders are rarely observed going to the shop floor to understand the current situation and mentoring or coaching the operators in solving problems or conducting improvements [
20].
Even though the leaders’ espoused theories of commitment to developing their employees, they instead exhibited a prevalent behavioral script of first-order problem solving. As operators, they handle their leadership and operational problems with short term fixes [
41]. It was, for example, observed that the leaders handle imminent production challenges by shuffling operators around as opposed to proactively enabling and empowering them to initiate second-order problem solving and address the underlying root causes within the operational system. An observed and explaining factor behind this predominant behavior is the primary focus on short-term and urgent matters. As one of the leaders reflected: “We always feel that we are behind. I would like to get in front of things and be proactive instead of just firefighting”.
Another observed behavioral script among the leaders, which prevents the operators from engaging in second-order problem solving, is the preference of setting the destination as a fixed goal or the implementation of a solution as opposed to a direction. This behavior reflects habits of giving the answers to what the operators should do to fix a problem instead of asking questions that fuel reflection, learning, and development among operators. It was, for example, observed in an operation status meeting that the highest-ranking leader only asked six open-ended questions but came with 64 orders and evaluating remarks during the meeting.
4. Discussion
The identified themes constitute the groundwork for the conceptual model depicted in
Figure 3. Based on empirical findings and observations from studying the case company’s implementation, commissioning, and utilization of their new real-time gathering system, we propose the conceptual model illustrated in
Figure 3. The study implies, from a LO perspective, that for operators to utilize real-time operational data and harvest the benefits of significantly reducing the time spent identifying and correcting operational issues like unplanned machine stops in order to prevent operational issues from happening, manufactures need to overcome a set of related barriers.
4.1. No Utilizing of Real-Time Data to Improve Production Performance if Operators Do Not Initiate Problem Solving
Our empirical findings indicate that, despite knowledge of LM tools and methods to perform problem solving and training with the real-time operational data gathering system, the operators did not adopt new routines and work practices to improve performance proactively. Our findings indicate that if manufacturers intend to move towards proactive operator-initiated problem solving, the technical implementation of real-time operational data gathering technology is not enough. Applying a solely technical focus on implementing new technology will not in itself enable operators to initiate problem solving and utilize real-time operational data. Manufactures must firstly, together with the operators, institute new routines and work procedures; thus, it is the operator’s responsibility to initiate problem solving daily when deviations from planned operations occur. Otherwise, the benefits of having real-time data available are not achievable.
4.2. Lack of Second-Order Problem-Solving Abilities Among Operators Prevents Them from Utilizing Real-Time Data
Our findings support the notion that the lack of second-order problem solving abilities among operators, including a structured approach to learning, experimentation, and reflections, is one of the explaining factors preventing the utilization of real-time operational data. Only practicing first-order problem solving prevents the organization from engaging in the deeper thinking required to practice second-order problem solving. It also prevents them from adjusting their day-to-day work routines so that, once formalized in an enabling way, they can utilize real-time operational data [
29,
42]. I4.0 technologies cannot replace human cognitive processed related to the operators’ reflection and imagination when identifying root causes behind production problems and countermeasures for resolutions and improvements [
1]. We can, therefore, also conclude that operator-initiated problem solving entails both developing and empowering the operators to perform daily second-order problem solving [
36].
4.3. A Coercive Perception of Real-Time Data Systems Among Operators Prevents Them from Initiating Problem Solving Based on Real-Time Data
An explaining factor of why the operators did not utilize the new real-time operational data system was that they perceived it as coercive and a system serving management and support functions as opposed to enabling them to, e.g., more effectively handle unplanned production stops and eventually prevent them [
29]. Despite the opposite intention of implementing the real-time operational data gathering system, the operators do not perceive that the feedback received from the system is useful for them in their efforts to improve production performance [
46]. Instead, they feel that they must perform additional non-value-adding work procedures to accommodate management and the maintenance department in getting a better understanding of the production lines’ performance.
4.4. Poor Supportive Learning Environments and Learning Processes Disseminate a Coercive Formalization of Real-time Operational Data Utilization and Hinder Developing Operators’ Second-Order Problem-Solving Capabilities
Despite a high level of psychological safety, the operators are not sufficiently engaged and empowered to find out how to utilize real-time operational data. If the current learning environment was supportive, the operators would be involved as active participants during the implementation and commissioning of the real-time operational data system. Management and specialists would have facilitated the operators in finding the best practices when it came to using the new system and integrating it into their daily practices [
29,
31].
Our findings reveal that the presence of a poor supportive learning environment and learning processes upholds first-order problem-solving behaviors of quickly fixing problems in the case of unplanned stops. The current learning environment is preventing the operators from being proactive in eliminating unplanned stops instead of expecting the maintenance department and management to act. An explaining factor is that there is no allocated time or structured approach to learning, experimentation, and reflection, in addition to deviations not being embraced as learning opportunities by leaders and operators.
Furthermore, training in the new system was not contextual. Marsick and Watkins [
32] confirm the importance of contextual training. They point out that it is essential that learning is an integrated part of the operator’s daily work, which includes the ability to solve problems together with co-workers. Developing and empowering the operators to perform daily second-order problem solving must, therefore, be facilitated by the presence of a supportive learning environment and processes [
31,
32].
4.5. Lack of Leadership Supporting Learning Disseminates Poor Supportive Learning Environments and Processes
The leaders’ behaviors are essential in establishing a supportive learning environment and learning processes, where, for example, the operators are enabled to utilize real-time operational data to improve production performance [
19,
31]. Our empirical findings indicate a gap between the leaders’ espoused theories of how they aspire to enable, develop, and empower the operators and the theory-in-use [
17,
39]. The gaps identified from the empirical findings and observations were, e.g., related to the leaders’ inadequate practice of being present, ‘going to Gemba’, asking questions instead of telling, and coaching and mentoring practices towards the operators. Similarly, as the operators must solve specific operational problems by conducting second-order problem solving, the leaders also must perform second-order problem solving. The difference is that the leaders focus on a higher-level problem of how to develop a supportive learning environment and learning processes instead. We observed no sign of committing to the daily development of operators during their problem-solving and improvement activities [
19].
4.6. Initial Example from Explicitly Addressing the Identified Barriers
After being presented with the findings from the analysis, the manufacture decided to engage with the first author in an action-learning experiment that addresses the identified barriers. The action-learning experiment consists of two action-learning interventions. In the first action-learning intervention, two department managers, together with their factory manager, were selected to undergo intensive training in second-order problem solving [
38] and problem-solving coaching [
44]. During this action-learning intervention, the managers solved a concrete problem by coaching each other, supervised by the first author. Subsequently, in the second action-learning intervention, each department manager selected two groups of operators to work on a concrete operational problem concerning production lines where real-time data were available. For four weeks, the department manager would coach and support the operators in solving the selected problems. Simultaneously, the factory manager would coach the department managers on their effort to support the operators. Based on initial anecdotes, operational data and observations, one department improved performance by 10% on one of their production lines during the second action-learning intervention by conducting second-order problem solving and utilizing the new real-time operational data systems.
5. Conclusions
Our scientific contribution is firstly to identify specific non-technological barriers that prevent manufactures from enabling their organization to explore and exploit real-time operational data from a LO perspective. We attain this by proposing a conceptual model (
Figure 3) based on the theoretical notions of second-order problem solving [
36], enabling formalization [
29], fostering a supportive learning environment, and processes [
31,
32] and leadership that supports learning [
19,
31]. The cross-fertilizing of these theoretical notions within the conceptual model helps us to understand what it requires to implement new learning routines and work practices on the manufacturing shop floor and utilize real-time operational data proactively. Secondly, our finding suggests that effective implementation and commissioning of Industry 4.0 technologies, like real-time operational data, requires the existence of an LM environment. However, this does not only mean a technocentric LM environment where organizational members have been introduced and trained in LM tools and methods, but an LM environment conjoined with a supportive learning environment and supportive leadership. Thirdly, the study adds to recent survey-based research by getting behind statistical numbers and understanding how LM and I4.0 are empirically associated through the non-technical lens of LO in a manufacturing context.
The practical implications derived from this study suggest that manufacturers cannot rely on a solely technological focus when implementing I4.0 technologies and linking them with existing or new LM capabilities. For manufactures to ensure a successful return of investment from acquiring new I4.0 technologies, they need to balance both technical and non-technical perspectives. New technology does not automatically bring about desired changes to operators’ behaviors that result in them utilizing these technologies just by implementing them. Despite the best designs and intentions, manufactures must also consider how to advance their second-order problem-solving abilities. The study, therefore, advises manufacturers to develop their leaders’ ability to grow a supportive learning environment and implement learning practices, ensuring that, as new data generating I4.0 technology gets implemented, underlying work routines and practices are formalized in an enabling way.
A limitation of this in-depth single case study is its generalizability. This single case study is limited to the specific context of the utilization of real-time operational data in a manufacturing setting in Denmark and, therefore, is not able to extrapolate any statistical generalization for other contexts [
50]. The analytical generalizability of the study is based on solid theories of why manufacturers are not able to utilize real-time data and how to link LM and I4.0 from the non-technical perspective of LO. Therefore, further research should validate the conceptual model from this study statistically across different manufacturing organizations for different markets and locations. Additionally, future research should examine how manufacturers can overcome the identified barriers, e.g., examine the effect that developing leaders’ ability to grow a supportive learning environment and the effect that learning processes have on formalizing underlying work routines in an enabling way when utilizing new I4.0 technologies in an LM environment.