Abstract
Due to today’s intense competition and rapid changes in the market, organizations must concentrate on their process management to improve their effectiveness to be able to respond quickly. Studies have shown that organizations are not necessarily even aware of the current primary function of technical management (TM) because their internal procedures are not currently modeled. This results in a lack of efficiency in terms of how businesses operate in organizations. This study aims to create internal procedure manuals for the technical support function of a case company and considers how to pinpoint areas for process improvement. Since TM is a part of the case company internally, it has not been able to update its internal procedure charts to reflect this, so cannot show its current roles in the surrounding organization. The methodology of this study is separated into two stages: modeling swim lane diagrams describing the existing state (as-is) of TM processes and then conducting semi-structured interviews with key stakeholders to ascertain their expectations and suggestions for change. Thematic analysis of the interview data and performing a comparison with the current procedure charts are used to determine whether or not TM’s procedures can be strengthened to better assist the surrounding organization. The study concludes that further actions are needed to clarify the role of TM in ways other than in the sub-process task level in the procedure charts of the case company. In addition, TM could conduct further analysis to optimize the case company’s business processes to achieve maximum benefit in the future.
Keywords
Introduction
Companies are currently doing everything they can to be competitive in light of the intense competition that exists today in the technology sector. Companies need to be adaptable and responsive to swift changes in the market in addition to being competitive in terms of product quality and cost.1,2 Organizations must concentrate on their business process management to improve their effectiveness in responding to the intense competition and rapid market changes.3,4 The American engineer Michael Hammer published an article titled “Reengineering Work: Don’t Automate, Obliterate” in the Harvard Business Review in 1990. 5 He believed that the way businesses currently operate is not adaptable enough to keep up with the rapid changes in technology and consumer needs. At the moment, businesses frequently automate and streamline their processes to improve corporate performance. To accelerate their procedures, they have replaced antiquated techniques with computers. Hammer believed that going deeper than simply speeding up current processes is the key to improving business process performance. Corporate Process Reengineering (BPR) was first introduced by Hammer as a way of producing significant improvements in corporate performance. 5
The phrase ‘using the power of modern information technology to radically redesign our business processes to achieve dramatic improvements in their performance’ is known as BPR. 5 Businesses have implemented business process reengineering to completely rethink their processes in order to increase their effectiveness ever since BPR was first introduced. Although active corporate performance improvement initiatives have the greatest of intentions, the results are not always ideal. Employees and internal departments of a business may find it challenging to adjust to a new organizational structure.3,6
Modelling internal processes in an organization is essential from the standpoint of efficiency so that everyone can have access to a set of rules to follow. When it is unclear, who needs to give what to whom, this creates unnecessary extra effort that takes time. When workers from various departments are unaware of who is in charge of a given task, they may end up doing two jobs at once. Double workload is bad enough, but it is worse when no one completes a task because they do not know who is assigned it. All operations can be described as task-level procedures, which reduce the danger of leaving an important task unfinished by making it simple to see who is responding to which task. Additionally, detailed procedure charts are useful for orienting and informing new team members about their roles.
The above discussion shows clearly that in organization there needs to be a clear pathway to define and execute all the business processes, especially in the technical management process. Due to inaccurate or incomplete definitions of the role and responsibilities of the TM process, the majority of stakeholders are unclear about its current role. The creation of illustrated procedure charts does not resolve all stakeholder uncertainty about technical management on its own. Additional steps are required to make clear the function of TM in ways other than at the level of sub-process tasks in procedure charts. The study examines TM procedures exactly as they are. As-is analysis entails recording the existing procedures, gathering ideas for improvements to these depicted processes through stakeholder interviews, and assessing the answers obtained by contrasting them with as-is procedure charts and findings from the literature. The TM process could also perform additional analysis to refine procedures and maximize the benefits to the surrounding organization. Based on this research agenda, the aim of this study is to set up technical management procedures that will best serve the organizations around them.
To demonstrate the identified aim, this study considers a case company, which is used to demonstrate the TM process clearly and to visualize its everyday processes. The organizational structure and duties have changed significantly in the case company over the last 10 years as a result of BPR operations. Technical Management (TM), an internal division of the case company, has not been able to update its internal procedure charts promptly, and is thus unable to show its current roles inside the organization. No one is aware of the precise procedures that make up the TM’s response, or even what its current primary function is in the organization. This is because the case company’s internal processes are not modelled. In line with the aim of the study, two research questions (RQs) are formulated as follows:
What is the status of the technical management processes in the case company?
How could the technical management processes be improved to support the surrounding organization better? The organization of this study is as follows: the research starts with an introductory section that describes the context of the investigation, the objective of the study, and the research questions. In the literature review section, related subjects such as process thinking and issues related to process development are presented. The method of the study is elaborated under study methodology section, while a description of the study company is presented in description of the case company section. All of the research findings, including technical management procedure charts and interview data, are included in results analysis section. The overall study impacts are explored in managerial implications section. The study is concluded along with future research directions in conclusion section.
Literature review
Process thinking
A process is described as “a set of interrelated activities designed to transform inputs into outputs" by Paula Berman.
7
As a result, each phenomenon in the universe having an input and an output is a process.
8
The choice to see some phenomena dynamically in terms of motion, activity, events, change, and transient evolution is known as “process thinking.” Put another way, process thinking is a philosophical stance that holds that the world’s ongoing evolution has an impact on all phenomena. Process thinking recognises that an independent phenomenon must also change in order to adapt to its ever-changing environment. Conventional thinking, on the other hand, interprets a phenomenon’s source and effect from a philosophical point of view.
9
Conventional wisdom According to philosophy, modifications to one phenomenon have an impact on its surroundings. The distinction between process thinking and traditional thinking is seen in Figure 1. Traditional thinking versus Process thinking.
10
Organisations have embraced the process thinking paradigm as a tactical move to maintain competitiveness in a world that is changing all the time. In order to increase company performance and effectiveness, organisations in the fiercely competitive technology sector of today must concentrate on ongoing organisational learning in a dynamic environment.11,12 By modifying their procedures, goods, and services to reflect the status of the environment at the time, organisations can use organisational learning to stay ahead of the market’s continuous change. Business practices are inherently influenced by customs, biases, and familiar ways of doing things, much like any other phenomena in the world. In many firms, employees just complete the tasks they are given as instructed without considering if doing so is the most effective course of action or even if the assignment itself is necessary. 13 By consciously choosing not to allow ingrained habits to dictate how to work in all types of businesses around the world, quality improvement and continuous improvement have been developed to address this issue. 14 Moreover, the objective of continuous improvement is to continually improve corporate performance and effectiveness by challenging the way things are currently done and changing these in response to the present environment. 15
Operational Excellence (OE) has become a common subject in businesses across all sectors in recent years. According to Mast et al. (2022), 16 the term “OE” refers to a company’s commitment to enhancing quality and performance at all organizational levels. Business process improvement has been emphasized as an element of OE in a variety of ways. It has been observed that it is more challenging to become aware of the ineffectiveness of business processes as compared to manufacturing process improvement. The business process, in contrast to the production process, frequently involves numerous departments, which causes horizontal problems. Due to the ease with which redundant steps in the production process may be recorded, it is more typical in business operations to waste time on activities that offer no value whatsoever for the client. 13
Business process management (BPM) and process improvement strategies focus more on making abrupt, dramatic changes to processes, whereas BPM focuses on stable, ongoing adjustments. 14 Nevertheless, there are many commonalities among all process improvement techniques. 3 Although BPM produces a number of functions and advantages for businesses, many clients continue to be unsure and unaware of the challenges involved in upgrading their present processes. 17
Expounding business processes
The procedure is a well-established method used in businesses to complete repetitive work.18,19 The sequential structure of the company’s process sets it apart from the company project; the former is a unique, not recurrent group of actions aimed at achieving a specific goal, while the latter is a cyclic and regular set of operations. 13 An input constitutes a thing that starts up the procedure operations within a business process. An input could be a client request, a time constraint, or a stakeholder desire. An output, on the other hand, is the result of a certain process and is the good or service that has to be provided to a client, either internal or external. A particular process has inputs and results in along with a certain number of interconnected tasks that must be finished in order to get the desired result. 20 Furthermore, the entire business may be viewed as a process, with the client as the input and the business as the output.18,21 The customer requests something from the business.
Three categories can be used to categorise processes: task, sub-process, and process levels. Order processing, billing, and the delivery process are a few instances of some of the most typical company procedures. Rather, sub-processes are all the smaller-scale procedures that must be finished in order to finish the primary procedures that were previously mentioned. Depending on how complicated a process is, it usually requires the completion of two or more subprocesses. 22 Instead, list all the tasks at the task level that must be completed in order to provide the desired result for the subprocess and, by extension, the main process. Analysing the process level reveals what the procedure accomplishes. In order to determine the structure of the process, the sub-process level is examined. When it’s necessary to understand how the work is done, task level analysis is performed. Sub-process level and task level differ only little, which makes it occasionally difficult to tell one from the other. The primary distinction between sub-process and task levels is that the former is typically carried out by a single individual, whilst sub-processes are typically carried out by multiple individuals or departments. 7
Technical management processes
In business, there are various technical functions such as research and development, management information systems, manufacturing engineering, and so on. It is a common practice in the business domain that the senior management expect to manage their internal operations strategically. 23 In particular, technical management processes need to be tailored to their particular contexts to make them more effective for the organization. 24 The technical management process needs its own, localized version in an organization, which is translated into measurable objectives to allow the function to continually assess its performance. The mission of the TM process is to communicate with other existing processes in an organization and to stay within budget. The TM process should contain goals that may direct resource decisions, assess how successfully it is carrying out its job, and align with the goals of and strategies of other functions. 25
Technical business processes are becoming increasingly prominent in achieving an effective overall business strategy that must be explicit and complementary to the business functions. 26 Technical functionalities in organizations need a way to benchmark not only their definitions but also their strategic management process. Organizational managers need to develop powerful conceptual frameworks for analysing functional strategies in research and development, manufacturing, product planning, finance, and marketing. 27 Thus far, there has been a lack of guidance for technical function managers. Despite many studies available in the literature, there has been no broadly accepted technical management process mapping. 28 This study tries fill this gap by defining various associated processes involved in technical management systems through a case study approach. It is believed that such a study will contribute substantially to the body of literature in the field.
The risks involved in the TM process can be seen on an individual level as much in terms of achieving positive consequences as avoiding negative ones. 29 However, the strategy in managing TM process risks should be more about avoiding negative consequences. 30 In general terms, managing risks can be made easier by keeping things simple. The associated risks can be reported tacitly rather than considering them more formally, which helps to shift the risks markedly towards a more holistic approach. In this way it is easier to manage the associated TM process risks. Additionally, a risk framework can also help in the decision-making process in managing TM process risks. In designing the framework, there is a need to consider several factors such as external drivers to risk management, organizational size, risk propensity, risk management practices, organizational performance, etc. 31
Business process reengineering
All out-of-date processes should be eliminated when reengineering business processes, and new processes should be created from scratch by employing creative ideas. It is best to disregard all unwritten rules governing the structure of the organization or processes. A new, more effective way of doing things should result from process reconstruction. 5 Since all sub-process levels are components of a company’s primary processes, significant process improvements can be made at these levels.6,13 This implies that internal departments within an organization can modify their internal processes to enhance their overall effectiveness and so improve the effectiveness of the entire organization. 1
An illustration of a BPR process flow is shown in Figure 2. The process starts with estimating the potential for BPR initiatives and analysing the current condition of processes. When individuals are enthusiastic about creating new and improved procedures rather than analysing current ones, firms frequently skip the analysis phase. However, the analysis step of business process re-engineering is a crucial stage that should never be skipped. This study focuses specifically on investigating, categorizing and assessing the current situation to give TM the best possible foundation for streamlining its procedures. BPR process model (Adapted from Roberts).
13
Businesses have used business process reengineering (BPR) since it was first introduced to completely rethink their processes to improve quality, outputs, costs, services, or speed. 13 Efforts to actively improve corporate performance are made with the greatest of intentions, but success is not always guaranteed. 4 Employees and internal departments may have a hard time adjusting to a new organizational structure. Additionally, it was noticed that BPR programs typically cease abruptly, and even when they did produce effects, they were only transient. Too ambitious goals that could not be met because of insufficient organizational resources that were overestimated during the planning phase were the root cause of the failure of BPR operations. 3 Failures in BPR initiatives decreased its desirability, which increased the need for more long-lasting process improvement methods.
Business process management
Business Process Management (BPM) takes a different tack in terms of processing improvement than Business Process Reengineering (BPR), which aims to achieve significant improvements for business processes. BPM is a complete process management approach that emphasizes endurance and patience instead of drastic reengineering efforts, making it a means for achieving company performance gradually. Companies have been shown to perform better when using BPM consistently from beginning to end. BPM ought to be viewed as a fundamental principle in businesses rather than something extra they may do to enhance their performance.3,32 For businesses to operate at their peak efficiency, business process management offers a variety of tools and strategies. Process mapping, process visualization, change management, benchmarking, and process and customer focus are some of these methods. 1 Swim lane diagrams, flow chart diagrams, and value stream mapping (VSM) can all be used to depict processes. Reengineering, Six Sigma, Lean, and Total Quality Management are a few examples of several BPM methodologies. These methods are all comparable to one another and were all modified from an earlier trend in the market. Every technique has a unique aspect that sets it apart from other approaches.3,32
Process improvement tools and techniques
Some of the tools used in business process management and reengineering are presented in this subsection. The research topic has been answered, and the tools have been chosen to develop technical management processes that will help the company in question. A process management method called as-is to-be analysis is used to assess the state of TM’s processes right now. Swim lane diagrams are used to model and record the state of technical management’s processes as-is as part of the as-is analysis.
As-is and to-be comparison
Business process reengineering includes a comparison of the current state and the desired state. 33 A method for analysing the present processes of a company or some of its departments is called as-is process analysis. The secret to finding chances for improvement and consequently optimizing processes to deliver the best advantage is to analyse the status of the processes as they currently stand. It would be difficult, or even impossible, to modify the processes without a detailed understanding of their current status. 13
Even if the potential for BPR actions has already been identified, an accurate as-is analysis needs to be carried out. It is not assured that people understand the existing situation as it is if the as-is analysis is not performed adequately. There is a significant chance that people’s perceptions of the current situation are inaccurate, and initiatives for re-engineering could go wrong. People may make the best re-engineering decisions and process improvements by completely comprehending the current scenario. Because of this, as-is analysis is a crucial foundation for process improvement. One must keep in mind, though, that becoming bogged down in the analysis process is a possibility.
One can proceed to figure out the future state-to-be processes after thoroughly researching, documenting, and analysing the as-is scenario. 34 One must first determine which procedures are essential for the firm before developing to-be processes. To-be analysis must be modified to suit the objectives of the case company, just like all other business process management or reengineering efforts and the as-is analysis. As a result of this study, the TM processes have undergone as-is analysis; now, TM must decide what kind of to-be analysis project they will perform for their processes in order to enhance them in actual use.
Swim lane diagrams
The swim lane diagram is a useful tool for illustrating cross-functional business processes involving multiple parties since it shows how the responsibilities within the process are allocated and which activities fall under the purview of each party’s response. 13 To depict very intricate and non-linear processes that are challenging to depict with conventional diagrams, such as value stream mapping, a swim lane diagram has been designed. 35 Swim lane diagrams are used to assess internal business processes as well as to model or build them.36,37 The swim lane diagram uses four key components to clearly and effectively depict the process. Swim lanes, forms, connectors, and phases constitute these four components. 38 The swim lane, which sets swim lane designs apart from other process diagrams, is the most important component. The swim lane is a bound region that is never permitted to have more than one responsible entity, group, or person.
Swim lane diagrams are therefore particularly useful for depicting cross-functional processes with a variety of stakeholders. Swim lanes are labelled “swim lane X” in the example in Figure 3 just to clarify what a swim lane is. The name of the accountable stakeholder is typically used to title swim lanes. A swim lane diagram is an excellent tool for displaying issues with interactions between several departments or individuals. The swim line diagram plays a crucial role in identifying the problems that arise in processes, but it does not solve them. Swim lane diagrams are used to represent processes, which allows all parties involved to collaborate on improving their shared processes.
35
An example of a swim lane diagram created with Microsoft Visio.
Study methodology
This study adopted a qualitative research method, where face-to-face interviews were conducted along with the use of tools such as swim lane diagram, business process reengineering (BPR), and business process management (BPM). According to Brodsky et al., 39 the qualitative research method takes a comprehensive approach to the study problem. Qualitative research was a logical choice because it is a preliminary investigation of the workings of TM. While normative research looks for a solution for how things should be in the future, nomothetical research investigates how things are right now. 40 Since the first research objective is nomothetical and the second research objective is normative, this thesis combines the two kinds of research.
To produce a credible research result, BPR and BPM tools and methodologies were used. In this research, as-is analysis was utilized to find solutions to the two research questions. The practical part of the research has been divided into the following three different sections to conduct the study efficiently, which align with the structure of as-is analysis: (1) Documentation: to creating as-is procedure charts of TM processes (2) Research study: to interview the relevant stakeholders (3) Analysis: to determine the improvement propositions for TM processes
In the documentation phase, the opinions of the case company’s process experts regarding the current processes of TM were collected, such as those of the general manager of TM and technical product management and technical quality management personnel. This data collection process consisted of six two-hour workshops. The collected data were used to represent the ‘as-is’ process status through using swim lane diagrams. The swim lane diagram approach was chosen because it best illustrates the domains of responsibility for a given process. The swim lane of TM was used to outline all the cross-functional process phases that were not included in the TM’s response.
List of interview questionnaires used for this study.
These five questions listed in Table 1 helped to accomplish the interview’s goals. We can understand the role of the stakeholders in Technical Management within the organisation, their expectations of Technical Management, and their suggestions for process improvement by having the stakeholders respond to these questions. Answers to questions 2-4 from the stakeholder interview are provided in the results section (Section 5). The answers to questions 2-4 provide crucial information for identifying potential areas for improvement in Technical Management processes. Since the purpose of the questions were to better understand the stakeholder’s position within the organisation and relationship with Technical Management. The answers to question 1 are not provided. The research goal, to identify areas, where Technical Management processes could use improvement, was not impacted by the stakeholder’s position within the organisation. The solutions are given in the form of a Table and text in Section 5. The most frequent responses to the questions are presented in Tables in descending order. This gives a clear picture of the topics that were brought up most frequently during the interview sessions. To provide readers with a clear understanding of the findings, free language is added to further explain the concepts presented in the Tables.
List of stakeholders and several interviewees from various departments of the case company.
To ensure the ability to provide the most thorough responses to the questionnaires, the interviews were conducted through Microsoft Teams. Face-to-face meetings would have been the most productive setting for the interviews; however, Microsoft Teams interviews were used because of COVID-19 constraints. Depending on how much was spoken during the interview, the time frame ranged from twenty minutes to an hour. All of the interviews took place in November and December of 2021. Depending on the interviewee’s mother tongue, the interview was conducted in either English or Finnish. With the interviewee’s permission, all the interviews were recorded, and the records were entered into the interview transcript on a subject-by-subject basis. Word-for-word accuracy was not required because the subject level of the investigation precluded it. The interview tapes were removed after transcripts had been written. Although the participants in the interview did not maintain their anonymity towards the interviewer, their anonymity was preserved afterwards. Only the department names and the responses from stakeholders were recorded and analysed.
In the analysis phase of the methodology, the interview results are analysed and compared to TM as-is procedure charts, making use of the interview results, candid feedback, and improvement recommendations. Only the interview responses were used to develop the themes in this study since they were sufficiently broad to be grouped under a single heading without diluting the significance of individual responses. In order to retain the significance of the interview responses that were meant to depict a particular process, there were no common themes among them. In order to rate the interview findings depending on how frequently they appeared in the interview replies, they were displayed as a table. By the end of the interview period, the areas where TM’s current procedures need to change could be identified.
Description of the case company
The case company is a market leader in the production of marketable sustainable technological solutions for the future. The case company’s research and development (R&D) unit houses a small department called Technical Management. The R&D division of the case company was established in response to the need for the research and development of new goods, technologies, and ideas in the relevant fields. Its strategic objective is to create the appropriate products, technology, and integrated solutions to establish the market’s most competitive offering. The primary area of focus for TM within the R&D unit is managing research and development activities to create collection of sophisticated technology products. To do this, TM is in charge of product-related maintenance and is responsible for providing technical support to a sizable number of internal stakeholders in performing their jobs. The stated objective of TM is to “develop, validate and maintain the company’s products with selected technologies to create added value to customers' business and environment”. 41
Technical Product Management (TPM) and Technical Quality Management (TQM) are the two teams that are responsible for TM. There are 22 employees overall at TM, including one general manager and two technical managers. 11 individuals with the titles of product engineer, technical expert, or technical manager are employed by TPM. Nine personnel in TQM are designated as technical managers or product improvement engineers. Technical product management (TPM) is the process of working with the products from sales support through to factory delivery. Throughout the development and delivery process, Technical Quality Management (TQM) responds to tasks relating to product quality as well as commissioning and field support. For a number of the company’s complex technology products, TM is responsible for all technical aspects from beginning to end.
TM has numerous internal processes because they are responsible for the technical end-to-end management of several complicated technological products used by the case companies. In actuality, TM provides the sales personnel with the most thorough analysis of the risks, additional work, additional lead time, and adaptability of the sought qualities. Technical Product Management (TPM) is in charge of the company’s sophisticated technology products from beginning to end from a technical perspective. The TPM team is in charge of providing the most recent technological viability for the required functionalities. For instance, TPM ascertains whether it is feasible to implement a special request that a customer made for the product.
The role of TPM is not to independently research all the features that are requested, but to gather all the necessary data by speaking with experts in the case of the company’s R&D group, and then determine whether or not the request is technically possible. TM reacts to configurator settings, IOS template upkeep and validation, and standard register choices. A tool called Configurator is used to manage new options and features following the agreed-upon Sales Release Plan, provide released options for usage by salespeople, and create Internal Order Specifications (IOS). To ensure that the products can be ordered from the factory following the sales contract, TM should ensure that everything is accurate in the configurator and that it contains all potential variations of the products. Similar to the configurator, IOS template maintenance responsibilities also apply to standard register options.
Results analysis
According to as-is analysis, this section explains all the study’s practical components: documenting the current TM procedures, conducting stakeholder interviews to ascertain their expectations of TM, and identifying potential areas for improvement for TM. The TM process charts as of right now are established in this area. Swim lane diagrams representing TM’s current processes are the output of this section. The potential bottlenecks, flaws, and vulnerabilities are also found and examined when procedures are documented.
Establishing technical management as-is procedure charts
The as-is procedure charts from TM are shown in this section. This section, which illustrates TM operations with swim lane diagrams, can be seen as an as-is analysis document section. These flowcharts represent all the inputs, actions, and results required to complete the process from TM’s point of view. To identify the roles of various tasks, each department in the case company that is involved in the process is depicted in its swim lane.
Figure 4 displays the TPM’s role in the NSR technical evaluation process. From Figure 4 shows that that TPM receives the non-standard request after it has already undergone a feasibility assessment. TPM reviews the new NSR information using the Salesforce application after receiving it through email. The NSR must be sent back to feasibility evaluation if the feasibility evaluation is ambiguous, lacking, or in any other way imperfect. After the feasibility assessment is finished, TPM can assess the NSR technically. In most cases, the TPM needs assistance from a few internal stakeholders because they are unable to analyse NSRs on their own. Depending on whether or not the NSR is technically possible after the technical examination is complete, the TPM product engineer will either accept or reject it. If the NSR is authorised, the Technical Manager of TPM must affirm if they concur with the product engineer or not and decide whether to approve the NSR. The NSR is sent to production’s evaluation using the Salesforce tool after receiving approval from the technical manager of TPM. Production will then automatically receive an email letting them know that they may now assess the NSR from their point of view. Non-standard request (NSR) technical evaluation procedure.
Figure 5 displays the function of the TPM in the Performance & Installation manual procedure. Figure 4 shows that technical writers are responding to the instructions from stakeholder 8, who currently has custody of the installation and performance manuals. Figure 4 also shows that TPM is responsible for the technical aspects of the products; thus they must respond to the technical input provided by the installation and performance guides. TPM must use the Polarion tool to communicate an update request to stakeholder 8 whenever they find an error in the documentation. The document will then be revised by stakeholder 8 following the TPM’s instructions. Additionally, any internal stakeholder who finds a mistake in the manual will seek an update from the manual’s owner. Performance and installation manuals procedure.
Figure 6 shows the functionality of the support for stakeholder 10. Figure 6 shows that stakeholder 10 frequently answered difficult technical question received from customers or stakeholder 13, or from sales. Figure 6, also shows that TPM might also require some further assistance in determining the solution, and they must get in touch with the relevant internal stakeholder in R&D for assistance via Polarion, email, or Teams. Stakeholder 10 support procedure.
Figure 6 depicts the quality and localisation process related to joint venture (JV) support, which can be broken down into two categories: quality and localisation, and projects sold by JV. Figure 7 shows that Joint Ventures and stakeholder 12 both ask Technical Product Management questions about quality and localisation because JV contacts TPM occasionally directly and stakeholder 12 occasionally. Stakeholder 12 will then refer the query to Technical Product Management if they are unable to respond to JV’s question. As a coordinator within the R&D department, TPM contacts the appropriate stakeholders when additional assistance is required and communicates the resolution to both stakeholder 12 and JV. JV support quality & localisation procedure.
Figure 8 depicts TM’s involvement in the sales project sold by JV. Figure 8 indicates that the procedure is otherwise comparable in terms of quality and localisation for JV sales initiatives, but stakeholder 10 serves as the intermediary between Technical Product Management and stakeholder 12. Stakeholder 10 is the first point of contact for JV and stakeholder 12 in sales initiatives, and they will ask questions of TPM. The sales support procedure chart and the internal process of TPM are comparable. JV support sales projects procedure.
Figure 9 displays TPM/compliance support. Figure 9 reveals that two distinct procedure charts have been created for compliance and certification assistance. TPM’s involvement in the compliance process is depicted in the first procedure chart, ‘Compliance support’ in Figure 8. TPM is the driving force behind the EN ISO 12100 product risk assessment compliance processes. Additionally, any other internal stakeholder may start the compliance procedure. The compliance process is initiated by the safety manager in response to a request from the TPM or any other internal stakeholder. Compliance support procedure.
Figure 10 displays the TPM/certification support, and it can be seen that the TPM typically takes the lead in the certification process, but any other internal stakeholder may also take the initiative. The initiative could be something like the requirement for an Engine International Air Pollution Prevention (EIAPP), product type approval, or a project line activity for research and development in the case company. TPM must schedule a kick-off meeting if EIAPP or similar type approval is required. The kick-off meeting will be scheduled if required, in which case TPM (or any other stakeholder with a requirement) must create an activity request for stakeholder 2, as shown in Figure 10. In any case, stakeholder 2 will schedule more meetings and carry on with the approval procedures. Certification support procedure.
Figure 11 shows the TPM/delivery project support of the case company, and it can be seen that the TPM plays a significant role in providing technical input for internal order specification (IOS) meetings in delivery projects. The customer delivery organisation publishes the first version of iOS following the sales contract after the client and seller have signed the agreement. The released IOS is announced to essential stakeholders via automated e-mail notification. Based on the published iOS, stakeholder 14 develops design requests, which are managed in the platform’s weekly order intake meeting. Following the meeting, the TPM assigned to that particular product checks the IOS from a technical standpoint and generates Polarion activity requests for the relevant parties. TPM gathers all the information required for the technical IOS meeting, which is organised by stakeholder 14 through the produced Polarion requests, as seen in Figure 11. Technical IOS meetings are scheduled up until the IOS is finished and error-free. Delivery management can then continue with their typical delivery project process after that. Delivery project support procedure.
Figure 12 shows TPM/configurator selections, and it can be seen that stakeholders 4, 7, 9, or 10 may provide an update that is required for the product configurator. Executing these configuration modifications causes TPM, which is in response to the configurator selections, to act. When TPM receives a change request, they assess it independently and engage with the appropriate parties. Figure 12 lists possible relevant parties that might be involved. When the evaluation is finished, TPM determines whether or not the configurator needs to be modified. TPM must notify the requester if the outcome does not update the configurator following the request. Stakeholder 8 is given by TPM the assignment of carrying out any updates to the configurator. The desired modifications will subsequently be made to the configurator by stakeholder 8, and the IOS template will also receive these modifications. Configurator selection procedure.
Conclusions about the as-is situation
It is clear from the result analysis that TM has a large number of internal processes. Several procedure charts were specifically designed for TPM to show their key internal procedures. The vast majority of TM’s procedure charts may be attributed to their role description, which states that they are responsible for the technical end-to-end management of the goods. They are expected to participate in a variety of activities to give technical assistance that enables other departments to carry out their duties since they have end-to-end technical accountability for the goods. Both TM and its stakeholders will benefit from having access to these illustrated procedure charts. These flow charts show the tasks that each TM is responsible for in each shared process with its stakeholders. Task-level procedure charts should resolve the current issues with ambiguity surrounding who is in charge of a certain task. When looking at the wider picture, these procedure charts will be beneficial for the entire organization because they will make operations run more smoothly and efficiently and Technical Management and their stakeholder departments will have clearly defined roles and responsibilities.
Interviews with TM stakeholders helped to clarify TM’s internal procedures. To acquire a cross-functional perspective of TM’s procedures, interviews were set up. The stakeholder interview feedback was utilised to assess the areas of TM that needed improvement. There are many stakeholders for TM because they are in charge of overseeing all technical documentation, product maintenance, and product care activities for several complex technology goods. Understanding the actions of TM’s internal stakeholders in the current organisation was one of the objectives of the interview. Since the organisational structure has evolved significantly over the last ten years, it is crucial to ensure that TM’s surrounding organisation is correctly understood before formulating suggestions for improving TM procedures. It is feasible to modify TM processes to fit the activities of the surrounding organisation when they are obvious. Discovering stakeholders’ expectations of TM and receiving suggestions for potential improvements to TM’s current procedures and method of operation were additional objectives.
Technical management’s role in the case company
Interview results for the second question.
Stakeholders’ expectations of technical management
Interview results for the third question.
Improvement ideas for technical management
Interview results for the fourth question.
Interview conclusions
After a few interviews, it became evident that all of the responses to questions 2-4 were very similar. During the second or third question, some of the interviewees impressed the interviewer with their suggestions for improvement or their goals. Because of this, the response analysis procedure took longer than anticipated. A better stipulation of the interview questions would have made it simpler for the interviewees to provide the desired answers. However, all of the interview questions received constructive and interesting responses from the TM’s stakeholders. The purpose of the interview sessions was to learn more about what stakeholders expect from TM and their ideas for improvement. The results were surprisingly thorough.
Identifying development areas in technical management processes
This part analyses and compares the as-is process charts to the stakeholder interview data to identify areas for process improvement in Technical Management.
Stakeholders interview analysis
The results from the stakeholder interviews supported the need for internal procedure charts as a model. Due to their inaccurate or incomplete representations of Technical Management’s current function and responsibilities, the majority of stakeholders did not understand it. Since TMs are involved in so many activities, it is understandable that their role may not be fully understood when internal processes were not modelled. The exhibited as-is technique charts untangle the majority of the stakeholder’s uncertainties, according to an analysis of the stakeholder interview data. However, other steps would be required, such as defining TM’s position as a technical tool responsible for goods. Determining how TM may enhance its procedures to create the best advantage for the surrounding business would also need a to-be analysis to be conducted.
Some interviewees expressed confusion about TM’s present position within the company. Concerns were raised by stakeholders over what it meant for Technical Management to own or be responsible for the goods’ technical aspects. The as-is procedure charts developed for this thesis will contribute to the practical clarification of TM’s duties. Stakeholders may quickly review all of the TM’s obligations via these procedure charts, which show the TM’s activities at the task level. Process-wise, TM’s duties have been elucidated to the greatest extent feasible. Because it is such an abstract description, technical responsibility and ownership role might be clearly specified in addition to having procedural charts outlining TM’s obligations in practise. The present position of TM is additionally referred to as a “suggester” since they lack sufficient power or capacity to make decisions. The organization’s purview should be widened to include greater accountability and technical management. TM cannot affect their job and obligations on their own.
Additionally, TM’s manager, communication, and technical assistance roles were all clearly depicted in the as-is process charts that were made. The aforementioned tasks are sufficiently concrete and clear to be explained just through procedure charts. When TM is portrayed as the initial point of contact in every circumstance, it is simple for all parties involved to adhere to the protocol, and requests from departments other than TM do not overwhelm the departments of the stakeholders. Additionally, TM’s communicator function should be tied to general external procedure charts so that all stakeholders are aware of who to contact in the event of an emergency. This also holds true for the other duties and the produced internal procedural charts. The basic main chart must be merged with all of the created procedure charts.
According to a stakeholder, it can be challenging to choose which TM employee to ask for assistance with particular problems. TM has previously established a documented contact person for various types of issues related to that problem. It seems that not all parties involved know about this paper. This suggests that either the stakeholder has not taken notice of the information provided by TM, or TM needs to do a better job of sharing information. One significant factor that needs to be considered in the next examination of TM procedures is the ten different stakeholders who stated that TM could enhance their information exchange. In order to better meet the demands of their stakeholders, TM could validate an active procedure for information sharing.
Managerial implications
Based on existing literature, it is noticed that there are only a limited number of studies explaining the usefulness of the various business processes and categorising them, especially TM processes.4,22 To manage business efficiently, there needs to be a clear framework to guide the business processes effectively. 18 In the case of the technical management process, a clear guideline is essential to overcome the process bottlenecks. This guideline helps to promote analysis of the current processes known as ‘as-is processes’ in organisations and to suggest ‘to-be processes’ as required to process updates. Additionally, process visualisation tools such as BPM, BPR, swim lane diagram, etc, are used to design and display all the essential blocks related to any specific process type.35,42–44 By constructing such process design, it is easier to be notified of any process abnormalities and take the necessary initiatives to improve those processes.
By identifying areas for improvement in TM’s procedures and recording them, this research study aimed to help TM and in particular to help the studied case company to improve the effectiveness and quality of its business. Overall, the findings demonstrate how much businesses can profit from just demonstrating the way things are now done. The issue of how to make sure that everyone in the firm knows the processes uniformly is likely to be a difficulty for large companies in particular. Additionally, managers should actively map and assess the current condition of their processes to ensure that things are done as effectively as possible in addition to establishing guidelines for how processes are set up. It is never too late to start implementing continuous business process management if a company has not done so already. Even if someone has known the process from memory for years, only by documenting the existing processes in the form of swim-lane diagrams can bottlenecks in the processes be identified. A useful tool for communicating with many stakeholders is to use a swim lane diagram to illustrate the process. 42
It was believed that TM would enhance communication and information sharing, as well as take general action more quickly and maintain all systems and documentation (IOS template, configurator, product parametrization document, standard register, and standard tools master list) current. It’s quite possible that TM presently has too many obligations or not enough resources to meet the expectations of every stakeholder. To-be analysis ought to be carried out in order to determine the most effective way to arrange TM operations. The responsibility of TM for upholding systems and documentation should be made clear in the to-be analysis. As soon as TM receives a request from the appropriate stakeholder or discovers a modification is necessary on their own, they are required to contribute the changes to the product documents and systems in the as-is procedure charts. It would probably be beneficial to have a more uniform and ongoing process for ensuring that systems and documentation are constantly updating.
Remarkably frequently, TM was mentioned as the proprietor of product manuals, responsible for maintaining their correctness, and responsible for their creation. A few stakeholders expressed their beliefs that TM is the true owner of these documents, while others expressed their goals about ownership. As with other internal stakeholders in the case company, TM’s role in the existing organisational structure is to respond by offering suggestions and enhancements to stakeholder 8, the owner of the product manuals. As-is procedure charts also provided a clear illustration of this duty. If TM’s duties in product manuals were to be increased, the organization’s purview should be adjusted. In light of the current organisational structure, people ought to think about the most practical and effective manner to manage the manual product process. TM cannot fulfil its obligations in the procedure by themselves.
When communicating with the stakeholders and their team members in the case company, it was noticed that Technical Management methods have been actively used since they were first illustrated. On the other hand, this research study is a good illustration of the wealth of useful information that a qualitative researcher can offer. Even though the condition of a business or team appears to be very steady, there may still be plenty of room for improvement. A complete perspective on the research question is provided by qualitative research, which is also a useful place to start when mapping out the processes and potential areas for improvement. Additionally, the findings of this study were considerably more thorough than anticipated, and they can inspire several other investigations to enter into the processes under consideration. It is believed that the outcomes from this study will be helpful for companies to analyse their existing processes and take the necessary initiatives to improve them further.
Conclusions and future research directions
The theoretical part of this study provided an introduction to the fundamentals of process thinking and business process management and reengineering as approaches for process improvement. Additionally, process tools and methodologies such as swim lane diagrams and an as-is to-be comparison were offered. In the practical section of the study, these instruments and techniques were used to assess the state of the Technical Management procedures. Three key steps made up the study’s practical part. To capture the existing condition of the processes of TM, the first step was to illustrate the as-is situation of these processes with swim lane diagrams. The second step involved speaking with some of the TM’s most important stakeholders to better understand their expectations of TM and their suggestions for improvement it. The analysis of the stakeholder interview data and comparison with existing procedure charts served as the third significant step in determining which aspects of the TM processes actually needed modification. Technical Management has failed to update its internal procedure charts in accordance with changes in the case company’s organisational structure during the last 10 years, so there were no procedure charts outlining the TM’s current processes. This led to uncertainty in daily work with various stakeholders because nobody was sure which tasks belonged to TM and which ones did not. The main goal of this study was to describe the technical management processes as they currently stand and identify potential areas for improvement by speaking with the stakeholders of nearby organisations.
The first research question in this study (What is the status of Technical Management processes in the case company?) was fully answered by using swim lane diagrams to depict the TM’s present processes. It was evident from the outcome of that phase that TM had a sizable number of internal processes. Because TM is responsible for all technical aspects of the case company’s complicated technological products, they are required to participate in a variety of activities involving these items. A total 20 TPM procedures were illustrated as a result of the first step of the practical part of the study.
The second research question of the study (How could Technical Management processes be improved to support the surrounding organisation better?) was addressed in steps two and three, when interviewing stakeholders about their expectations of and improvement ideas for Technical Management, and comparing the results for the illustrated swim lane diagrams. Stakeholder interviews, the second step of the practical part of the thesis, supported the need for internal procedure charts as a model. The majority of the stakeholders did not understand the TM’s current position because their definitions of its duties and responsibilities were incomplete or inaccurate. The thorough feedback that was given to TM during the interviews was the reason that they were successful. The primary source of information for identifying potential areas for improvement in TM’s current processes was feedback. The study examines Technical Management procedures as-is. As-is analysis entails capturing existing procedures in writing, identifying potential improvements to these procedures through stakeholder interviews, and analysing the interview results by contrasting them with existing procedure diagrams and research findings. The to-be analysis, actualising the suggested adjustments, or taking any other additional measures, are not included in the scope of TM, which consists of the processes examined in this study. The final procedure charts do not include any of the internal procedure charts from the other departments because they are deemed to be outside of their remit. To show how roles interact in particular processes, some of the activities of the TM stakeholders are presented in the procedure charts. All of the information obtained for the charts comes from the case company’s current state of affairs.
Study limitations
The time constraint was the biggest drawback of this research study. When examining the state of every internal processes under Technical Management, the research scope was broad. Because of this, the research focused on outlining the processes current state and identifying general areas for improvement. The time-consuming process of converting the results of the qualitative interviews into study-relevant data was the main bottleneck in this research study. The only feasible method for this type of detailed research study was a qualitative interview. The interviews produced remarkably comprehensive data for the research and were therefore worthwhile investing a lot of time on.
Further research
This study’s objectives were restricted to analysing TM’s processes in their current state. To implement the identified improvement areas in TM’s procedures, further research would be required. In the to-be analysis, one should evaluate the most important processes for TM’s processes and conduct a dynamic study of those processes. The most valuable outcomes for internal stakeholders or external clients come from critical processes. After identifying the crucial steps, drawings of the future state should be created without regard to resources like money or labour. The next phase in the study can involve either altering future procedures to fit the company’s current limits, or getting rid of process steps that do not bring any value for either internal or external customers. By performing a to-be analysis, TM would get the most out of its operations by optimising its procedures in real-world settings. All internal sub-procedure charts for TM should be joined to the organisation’s key processes in addition to performing a to-be analysis. This would guarantee that, regardless of whichever level’s procedure charts a person is looking at, their participation in the processes would be clear to them all. To achieve ongoing process improvement and maintain business performance and effectiveness, Technical Management should also incorporate the Business Process Management lifecycle into their everyday actions.
The outcomes of stakeholder interviews provided justification for the need to model internal procedure charts. Most stakeholders could not understand the existing role of Technical Management because their explanations of TM’s duties and responsibilities were incomplete or inaccurate. Given that TMs are involved in several activities, it makes sense that their role would not be fully understood in cases where internal processes were not modelled. Analysing the outcomes of the stakeholder interviews, it became evident that the majority of the stakeholders’ uncertainties were tangled in the illustrated as-is procedure charts. However, further work would be required, such as defining TM’s responsibilities as a technical product owner. To-be analysis would also be necessary to ascertain how TM may best optimise its procedures to yield the greatest advantage for the neighbouring organisation. Future to-be analyses should examine the following queries: • Is there another way to define the duties and responsibilities of TMs besides task-level process charts? • Should TM be given more power and responsibility in their capacity as the technical owner of products? • How can we make sure that TM communicates and shares information about the products in a methodical manner? • How can TM create a continuous and consistent process for updating systems and documents? • As the technical owner of products, should TM be more accountable for product manuals? • In order to enhance sales assistance, is it necessary for TM to compile and preserve a history of NSR requests? • How can TM processes be optimised to ensure that the scope of responsibilities is not excessive in relation to available resources?
Footnotes
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) received no financial support for the research, authorship, and/or publication of this article.
