No abstract

In this paper, we explore the need to improve systems awareness to support early-phase decision-making. This research uses the Norwegian energy industry as context. This industry deals with highly complex engineering systems that shall operate remotely for 25+ years. Through an in-depth study in a systems supplier company, we find that engineers are not sufficiently aware of the systems operational context and do not focus on the context in the early phase. We identified the lack of a holistic mindset and the challenge of balancing internal strategy and customers’ needs as the prevalent barriers. To support the concept evaluation, the subsea system suppliers need to raise systems awareness in the early phase. The study identifies four aspects that are important to consider when developing and implementing approaches to improve systems awareness in the early phase.

IntroductionSystems Engineering as a profession emerged from the telecommunications and space programs in the United States in the 1950s. Motivating this emergence was the need for these systems to be safe, reliable, robust, and able to handle unforeseen events. Practicing systems engineers wrote the earliest Systems Engineering literature (Chestnut, 1967;Goode & Machol, 1957), but it took nearly 20 years before academia began to offer explicit Systems Engineering educational opportunities and to produce textbooks. The subsequent literature has dealt not only with technological topics but also with the corresponding impacts on organizations that produce these complex systems.Thus, research on Systems Engineering is still an emerging field. One challenge is that Systems Engineering is context dependent: the practice is dependent on both the engineering domain as well as the organizations and its surroundings. Another challenge is that valuable tacit knowledge remains largely undocumented within the companies and industries. Specifically, research on Systems Engineering implementation and best practices within the oil and gas industry is scarce. This raises questions about how to make this knowledge explicit and how to best apply Systems Engineering in different settings.Systems Engineering master's students at the University of South-Eastern Norway (USN; tinyurl.com/y2e6h6za) are This article analyzes participatory action research conducted by Systems Engineering master's students embedded fifty percent in industrial companies for three years. The resulting papers authored by these students identify challenges and effective practices suitable for knowledge transfer between industry and academia. The analysis covers 181 completed master's projects, with a detailed analysis of 40 papers that have been published in international conferences and journals. The publication rate of about 23% shows that these students contribute actively to the body of Systems Engineering knowledge. This study analyzes master's projects at three levels -industrial problem and drivers; Systems Engineering methods; and research method feasibility -and provides valuable lessons learned by applying the industry-as-laboratory approach. Embedding students in industry has resulted in publications that do not suffer from the main challenges of participatory research such as delays, repeatability, and only action and not research. These insights are valuable both for industry and for academia in future work to enhance innovations.If you think competency is expensive, have you tried incompetency? ... In addition to getting good and motivated students, the company also gets working knowledge of the subject systems engineering. The company also benefits from assignments along the way, and the thesis is aimed at current issues in business. We have much to learn from these students.working with these questions to evaluate the effectiveness of the Systems Engineering body of knowledge in practice. To facilitate this process, USN -in close cooperation wi...

This article applies formal system engineering methods in early‐phase concept studies in the subsea oil and gas industry to identify early‐phase needs, and reduce late‐phase design changes. The oil industry is changing, demanding more cost efficient, flexible, and modularized systems. In order to improve their offering, suppliers within this industry are turning towards the systems engineering domain. To better understand the problem, we investigated the engineering processes at the supplier, went into details of technical project reports, and interviewed main stakeholders at the supplier. Based on our research we propose to adjust the early phase of the project execution process for the company, and adapt to a system engineering framework. At an early stage we recommend using unformal models to communicate decisions and to set up a foundation for applying more formal models in the later phases. A case study from field development illustrates the new process and methods. Some of these systems engineering methods have already been adopted in the company to improve the front‐end engineering studies.

This paper evaluates the use of architectural reasoning to explore the problem space in a system development project in the oil and gas industry. The suppliers in this industry have traditionally been tailor-making their systems for each delivery project. To improve the systems offering across the client and project portfolio, the suppliers must put more effort in the conceptual phase to explore the design space. Architectural reasoning is the process of transferring problem and solution know-how into a new systems architecture. In this paper we review literature on architectural reasoning in the conceptual phase, and on application in the oil and gas industry. To evaluate the use of architectural reasoning in the industry, we perform a case study in a subsea supplier company. From the case study, we are identifying a work-flow for architectural reasoning, utilizing the market needs, design, and domain knowledge to evolve the system. Evaluating the tools and working methods, we find that working in a multi-disciplinary team is key to support the reasoning process. We find that the team is utilizing the design and domain knowledge to improve the system architecture. However, the team lacks methods to make this knowledge explicit and to quantify the issues they are identifying.