Anniina Syrjälä Establishing Technical Management processes to support the surrounding organization Vaasa 2022 School of Technology and Innovations Master’s Thesis Industrial Systems Analytics 2 UNIVERSITY OF VAASA School of Technology and Innovations Author: Anniina Syrjälä Title of the Thesis: Establishing Technical Management processes to support the sur- rounding organization Degree: Master of Science in Technology Subject: Industrial Systems Analytics Supervisor: Ahm Shamsuzzoha, Turo Kuoppala, Kai Lehtonen Year: 2022 Pages: 88 ABSTRACT: This thesis is written for a case company’s Research and Development organization. The aim of the thesis is to establish internal procedure charts for the case company’s technical support function and identify improvement areas in their internal processes. Due to various Business Process Re-engineering activities in the case company during the last ten years, organization structure and responsibilities have been changed a lot. Technical Man- agement, as an internal department of the case company, hasn’t managed to update their in- ternal procedures charts accordingly, and therefore they lack procedure charts to illustrate their current responsibilities as part of the surrounding organization. Because Technical Manage- ment’s internal processes are not modelled, no one knows exactly which processes are in TM’s response or what even is their main role in the organization nowadays. This leads to inefficiency in business performance. The methodology of this research study can be divided in two steps. The first step of the study is to model swim lane diagrams about the current situation (as-is) of Technical Management processes and the second step is to hold semi-structured interviews for Technical Management’s key stakeholders who are actively co-operating with Technical Management, to understand their expectations and improvement ideas. The interview results are analysed thematically and compared to as-is procedure charts to find out whether Technical Management’s processes can be improved to support the surrounding organization better or not. Stakeholder interviews were successful because Technical Management received huge amount of significant feedback. The interview results justify the fact that internal procedure charts were necessary to model. The current role of Technical Management is not clear for most of the stake- holders, because their descriptions of Technical Management role and responsibilities are either incorrect or imperfect. On their own, the establishment of illustrated procedure charts doesn’t untangle all the stakeholders’ uncertainty towards Technical Management. Further actions would be needed to clarify Technical Management’s role also in other ways than in sub-process task level in procedure charts. In addition, Technical Management could conduct further to-be analysis to optimize their processes to produce the best benefit for the surrounding organiza- tion. KEYWORDS: Business process, business procedure, process development, swim lane diagram, business process management, process modelling, as-is analysis, procedure chart 3 VAASAN YLIOPISTO School of Technology and Innovations Tekijä: Anniina Syrjälä Tutkielman nimi: Establishing Technical Management processes to support the sur- rounding organization Tutkinto: Diplomi-insinööri Oppiaine: Industrial Systems Analytics Työn ohjaaja: Ahm Shamsuzzoha, Turo Kuoppala, Kai Lehtonen Valmistumisvuosi: 2022 Sivumäärä: 88 TIIVISTELMÄ: Tämä diplomityö on tehty toimeksiantona erään teknologiasektorin yrityksen tuotekehitysorganisaatiolle. Tutkielman tavoitteena on luoda sisäiset prosessikaaviot kohdeyrityksen tekniselle tuotteenhallinnalle ja selvittää heidän sisäisten prosessien kehityskohdat. Viimeaikaisten kohdeyrityksen liiketoimintaprosessien uudelleen muodostamisten johdosta yrityksen organisaatiorakenne ja sisäisten osastojen vastuualueet ovat muuttuneet paljon. Tekninen tuotehallinta on yksi kohdeyrityksen sisäisistä osastoista, joka ei ole onnistunut päivittämään omia proseduurikuvauksiaan vastaamaan heidän tämänhetkistä toimintaansa yrityksessä. Koska teknisellä tuotteenhallinnalla ei ole olemassa olevia proseduurikuvauksia kuvaamaan tämänhetkistä toimintaansa, heidän vastuualueet ja rooli nykyorganisaatiossa eivät ole yksiselitteiset. Tämä tutkimus on jaettu kahteen eri osaan. Ensiksi tutkimuksessa määritetään teknisen tuotteenhallintaryhmän as-is proseduurikuvaukset kuvaamaan heidän tämänhetkistä toimintaa mahdollisimman tarkasti uimaratakaavioiden muodossa. Seuraavaksi teknisen tuotehallinan sidosryhmiä haastatellaan teemahaastatteluin, jotta saadaan selvitettyä heidän odotukset ja kehitysideat teknistä tuotteenhallintaa kohtaan. Haastattelutuloksia analysoidaan temaattisesti ja verrataan nykyisiä prosesseja kuvaaviin uimaratakaavioihin, jotta saadaan selville vastaavatko nykyiset toimintamallit kaikkien sidosryhmien odotuksia, vai tulisiko teknisen tuotehallinnan kehittää prosessejaan tukeakseen ympäröivää organisaatiota peremmin. Sidosryhmien haastattelut olivat tuloksekkaita, sillä tekninen tuotehallinta sai suuren määrän palautetta koskien heidän prosessejaan. Haastattelujen tulokset osoittavat sen että proseduurien kuvaaminen on tarpeen, sillä useiden sidosryhmien kuvaukset teknisen tuotehallinnan roolista ja vastuualueista olivat joko virheellisiä tai vajavaisia. Kuvatut proseduurikaaviot ratkaisevat suurimman osan sidostyhmien epäselvyyksistä teknistä tuotehallintaa kohtaan, mutta niiden olemassa olo ei kuitenkaan yksinään riitä selvittämään kaikkia epäselvyyksiä. Jatkotoimenpiteenä teknisen tuotehallinnan tulisi selventää roliaan myös muilla tavoin, kuin ainoastaan aliprosessitasolla tehtäväkohtaisten proseduurikuvausten muodossa. Lisäksi teknisen tuotehallinnan olisi aiheellista jatkaa prosessien kehitystä to-be analyysin mukaisesti, jotta heidän prosessit sataisiin optimoitua ja sidosryhmien odotuksiin voitaisiin vastata paremmin. AVAINSANAT:Prosessi, proseduuri, prosessinkehitys, uimaratakaavio, liiketoimintaprosessien hallinta, prosessimallinnus, as-is analyysi, proseduurikaavio 4 Foreword Firstly, I want to thank the case company for the opportunity to write my thesis on such an interesting and practical topic. The research process was smooth because I constantly felt doing something meaningful and understood how rewarding the outcome will be for Technical Management and their stakeholders. I want to thank my supervisors who had trust in me, and always were available for help and support during the research process. Secondly, I would like to thank the University of Vaasa for the rewarding study years. The past years have been full of studying, but the University of Vaasa has served other things in my life as well. Already at the end of my first year in university, “Takuuteekkari” sum- mer job opportunity in the energy sector company was given to me. Since that, I have been able to contribute my theoretical knowledge in practice in several different posi- tions on the side of studying. One of the best memories of my studying years must be my exchange studies in Asia that allowed me to move to study in a different culture. That journey taught me a lot more than 20 credits of industrial engineering that were re- warded in my academic credit account afterwards. Last but not least, I am grateful for all the friends that I made during my student years. Friends, that sat with me till the late night at school when studying for a difficult exam, and for a counterweight attended in various amusing activities that subject associations had to offer for us. Finally, I would like to thank my family and friends who have supported me during my studies, writing this thesis, and in life in general. Vaasa 28th of February 2022 Anniina Syrjälä 5 Table of Contents 1 Introduction 9 1.1 Background 9 1.2 Research problem 10 1.3 The purpose of the study 11 1.4 Research scope 11 1.5 Research structure 12 1.6 Confidentiality 13 2 Literature review 14 2.1 Process thinking 14 2.1.1 Expounding business processes 17 2.1.2 Business Process Reengineering (BPR) 20 2.1.3 Business Process Management (BPM) 23 2.2 Process improvement tools and techniques 25 2.2.1 As-is and to-be comparison 25 2.2.2 Swim lane diagrams 28 3 Study Methodology 31 4 Results analysis 36 4.1 Defining current processes of Technical Management 36 4.1.1 Defining Technical Management responsibilities 36 4.1.2 Defining Technical Management main processes 37 4.1.3 Establishing Technical Management as-is procedure charts 43 4.1.4 Conclusions about the as-is situation 64 4.2 Stakeholder interviews 65 4.2.1 Defining interview questions 65 4.2.2 Interview responses 68 4.2.3 Interview conclusions 76 4.3 Identifying development areas in Technical Management processes 77 4.3.1 Stakeholder interview analysis 77 6 4.3.2 Conclusions 80 5 Summary and conclusions 81 5.1 Managerial implications 83 5.2 Further research 84 References 85 7 Figures Figure 1. Research structure. 12 Figure 2. Traditional thinking vs. Process thinking (Adapted from Schulte, 2020). 14 Figure 3. Berman’s checklist for determining whether procedures are needed or not (Berman 2014, p 19) 19 Figure 4. BPR process model (Adapted from Roberts, 1994) 21 Figure 5. Business Process Management lice cycle phases (Lutkevich, 2022). 23 Figure 6. An example of a swim lane diagram created with Microsoft Visio 30 Figure 7. NSR procedure. 43 Figure 8. Performance & installation manuals procedure. 44 Figure 9. Stakeholder 10 support procedure. 45 Figure 10. JV support quality & localization procedure. 46 Figure 11. JV support sales projects procedure. 47 Figure 12. Compliance support procedure. 48 Figure 13. Certification support procedure. 48 Figure 14. Delivery projects support procedure. 49 Figure 15. Configurator selections procedure. 50 Figure 16. IOS template maintenance procedure. 51 Figure 17. Standard register procedure. 52 Figure 18. Development projects procedure. 53 Figure 19. Design stages procedure. 53 Figure 20. Production support procedure. 54 Figure 21. Order intake procedure. 55 Figure 22. Standard tools master list procedure. 56 Figure 23. Product operating parameter document procedure. 57 Figure 24. Product presentations procedure. 57 Figure 25. Testing needs in JV procedure. 58 Figure 26. Test needs in production procedure. 59 Figure 27. TM test needs procedure. 60 Figure 28. MTBF follow-up procedure. 61 8 Figure 29. Field follow-up procedure. 62 Figure 30. Issue register procedure. 62 Figure 31. Design quality assurance procedure. 63 Figure 32. PAP participation procedure. 64 Tables Table 1. Stakeholder interview participants 34 Table 2. Interview results for the second question. 69 Table 3. Interview results for the third question. 71 Table 4. Interview results for the fourth question. 73 Abbrevations BPM BPR CI CN IOS JV MTBF NSR OE PAP PIP PLM PO PPM QI R&D STH TM TPM TQM VSM Business Process Management Business Process Reengineering Continuous Improvement Change Notice Internal Order Specification Joint Venture Mean Time Between Failure Non-Standard Request Operational Excellence Part Approval Process Product Improvement Process Product Lifecycle Management Purchase Order Product Portfolio Management Quality Improvement Research and Development Smart Technology Hub Technical Management Technical Product Management Technical Quality Management Value Stream Mapping 9 1 Introduction This is the introduction chapter of the thesis. In this chapter project background, re- search problem, research scope and confidentiality are presented to create a detailed description of the research structure. 1.1 Background Today’s fierce competition in the technology industry thrives companies to do all they can do to stay competitive. Apart from being competitive with the product quality and cost, companies need to be flexible and responsive to the rapid changes of the market (O’Neill & Sohal, 1999). For being able to respond to the fierce competition and rapid changes in the market, organizations must focus on their process management to in- crease their effectiveness. (Hermkens, 2007) In 1990, Michael Hammer, an American engineer wrote an article “Reengineering Work: Don’t Automate, Obliterate” in Harvard Business Review. He was convinced that the cur- rent way of working of companies is not flexible enough for rapidly changing technolo- gies and customer demands. At the time, companies tend to increase their business per- formance by automation and process rationalization. In practice, they replaced old methods with computers to speed up their processes. Hammer thought that the key for increasing business process performance is somewhere deeper than speeding up the existing processes. Hammer was the first one to introduce Business Process Reengineer- ing (BPR) as a method to achieve dramatic improvements in business performance. (Hammer 1990) BPR as a term means “using the power of modern information technology to radically redesign our business processes to achieve dramatic improvements in their performance” -Hammer 1990. When reengineering business processes, all the outdated processes should be obliterated, and new processes should be designed from the beginning by 10 using one’s imagination. All the unspoken rules about the organization or process struc- ture should be forgotten. Process reconstruction should lead to a new way of doing things, more efficiently than before. (Hammer, 1990) Since the day when BPR was introduced, companies implemented business process reengineering to radically redesign their processes to improve their effectiveness. Active business performance improvement activities have the best of intentions, but the out- come is not automatically glorious. Adapting to a new organizational structure might be difficult for an organization’s employees and internal departments. (Hermkens, 2007) 1.2 Research problem Due to various Business Process Reengineering (BPR) activities in the case company dur- ing the last ten years, organization structure and responsibilities have been changed a lot. Technical Management (TM), as an internal department of the case company, ha- ven’t managed to update their internal procedures charts accordingly, and therefore they lack procedure charts to illustrate their current responsibilities in the company. Be- cause of TM internal processes are not modelled, no one knows exactly which processes are in TM’s response or what even is their main role in the organization nowadays. From an efficiency point of view, it is vital to model internal processes to have a guiding principle available for everyone to follow. Unclear scope of responsibilities leads to time- wasting extra work when no-one knows exactly who needs to deliver what to whom. Employees in different departments might do double work when they are not aware of who is responsible for a specific task. A worse situation than doing double work is that no-one does a specific task because they are not aware who is in response to it. If task level procedures are modelled of all the processes, it is easy to check who is in response to some specific task and the risk of leaving an important task undone is minimized. In addition, illustrated procedure charts will be helpful when onboarding new team mem- bers in the team and educating them about their responsibilities. 11 This thesis aims to establish Technical Management’s processes to support the surround- ing organization as well as possible. The aim is to illustrate TM’s current processes as they are and by interviewing stakeholders gaining feedback and improving ideas towards TM’s processes. 1.3 The purpose of the study The research question of the thesis is: “How to establish Technical Management pro- cesses to support the surrounding organization?”. To achieve a qualified answer to the research question of the thesis, following two questions needs to be evaluated: Q1: “What is the status of Technical Management processes in the case company?” Q2: “How could Technical Management processes be improved to support the surround- ing organization better?” 1.4 Research scope The research is an as-is analysis of Technical Management processes. As-is analysis in- cludes documenting the current processes, detecting improvement ideas towards these illustrated processes via stakeholder interviews and analysing the interview results by comparing them to as-is procedure charts and literature findings. To-be analysis, practi- cal implementation of the suggested changes or any other further actions are excluded from the scope. The processes that are analysed in this thesis belong to Technical Management, which consist of two different teams: Technical Product Management (TPM) and Technical Quality Management (TQM). All the other department’s internal procedure charts are considered out of scope and therefore excluded from the final procedure charts. Some of the TM’s stakeholders’ activities are included in the procedure charts to illustrate the interfaces of responsibilities in specific processes. All the data gathered for charting is data from the current situation of the company. 12 1.5 Research structure This research is structured as illustrated in figure 1. The research begins with the intro- duction chapter that presents the background of the thesis, research problem, purpose of the study, research scope and the structure of the thesis. The second chapter includes a literature study about the related topics such as process thinking and process develop- ment. In addition, Business Process Management and Business Process Reengineering tools and techniques: as-is to-be analysis, swim lane diagrams are presented there. The third chapter includes all the information about research methodology. Unit of analysis, research data, process steps, tools and methods will be explained in detail to give a plain understanding about the research structure. The fourth chapter of the thesis includes all the practicalities of the thesis. In that chapter, as-is analysis in conducted for Technical Management processes. The chapter includes all the research findings, such as Technical Management procedure charts and interview results will be presented and analysed. In the last chapter of the thesis all the conclusions have been summed up to create a prompt description about the research. Figure 1. Research structure. In the beginning of the practical part of the thesis, as-is situation of TM’s processes is modelled. After that, stakeholders are interviewed to gain understanding about their current role in the company and their expectations and improvement ideas towards TM. As-is procedure charts are compared to stakeholder interview feedback and results are analysed to find improvement areas in technical management activities. Any other fur- ther actions, for example conducting to-be analysis for technical management is outlined from the thesis. Introduction Literature review Method Analysis and results Summary and conclusions 13 Even if the result of the thesis is internal procedure charts for TM, the result has an im- pact for all the stakeholders as well, since the illustrated procedure charts smoothen the daily cooperation of all. TM has more than 15 different departments to be in contact in weekly basis. Also, the whole company’s effectiveness improves if Business Process Re- engineering activities are done in every level of an organization. 1.6 Confidentiality All the confidential information about the case company is removed from the public ver- sion of the thesis. The company name and products are referred generally as “a case company” and “products”. Also, all the stakeholder departments’ names will be anony- mous, and they are referred as “stakeholder 1, stakeholder 2...”. Stakeholder interview recordings were deleted after transcript have been made. 14 2 Literature review This chapter is the theoretical part of the thesis and includes a literature study about the relevant topics related to conducting the research. The chapter begins with an introduc- tion to process thinking. After that, relevant process management and improvement methods, tools, and techniques are presented. 2.1 Process thinking Paula Berman (2014, p 12) has defined a process to be “a set of interrelated activities designed to transform inputs into outputs”. Therefore, any phenomenon in the world that has an input and output can be considered as a process (Hartmann, 1996). Process thinking is a decision to consider some phenomena dynamically in terms of movement, activity, events, change, and temporary evolution. In other words, process thinking is a philosophical point of view interpreting that all phenomena are being affected by the constant evolution of the world. Process thinking sees that separate phenomenon adapts on its constantly changing surrounding by changing by itself, too. Traditional thinking instead is a philosophical point of view interpreting that a phenomenon has a cause and effect. Traditional thinking philosophy sees that changes in a specific phenom- enon cause the effect on its surroundings. Figure 2 illustrates the difference between traditional thinking and process thinking. (Langley, 2007) Figure 2. Traditional thinking vs. Process thinking (Adapted from Schulte, 2020). 15 Process thinking philosophy has been capitalized in organizations as a strategic action to stay competitive in the constantly changing world. Today’s fierce competition in technol- ogy industry can be considered as a constantly changing surrounding that forces compa- nies focus on continuous organizational learning to improve their business performance and effectiveness (Flores et al, 2012, p 641). Organizational learning enables organiza- tions to keep up with the constant evolution of the market by adapting their processes, products, and services to match with the current state of the surroundings. (Langley, 2007) As with any other phenomenon in the world, business processes are naturally led by traditions, prejudices, and familiar ways of working. It is common in organizations to just fulfil the assigned tasks as advised without questioning whether it is the most efficient way to fulfil the task or if there even is an actual need to do the task at present time (Roberts, 1994). Quality improvement (QI) and continuous improvement (CI) has been invented to solve this problem by making the conscious decision not to let deep-rooted habits to determine the way of working in all kinds of organizations around the world (Antony et al, 2017). Instead, the goal of continuous improvement is to continuously in- crease business performance and effectiveness by questioning the current ways of work- ing and adapting processes to fit the current situation (Nikkola, 1995). During the past decades, Operational Excellence (OE) has been found to be a popular theme in companies in every industry. OE as a term means that the business is commit- ted for improving their quality and performance for their best in every level of an organ- ization (Mast et al, 2022). As a part of OE, the importance of business processes improve- ment has been reasoned in different ways. Business process improvement has been compared to production process improvement and it has been noted that it is more dif- ficult to become aware of the ineffectiveness in business processes. Unlike the produc- tion process, business process usually involves many different departments which leads to horizontal issues. For that reason, in business processes it is more common to spend time on the things that are not producing any additional value for the customer when in 16 production process it is easier to register the unnecessary steps of the process. It has also been noted that customers more often change the supplier due to supplier’s poor business processes than their poor products. Due to before mentioned examples, there is a reason to believe that business process improvement is helpful and even necessary activity for today’s organizations. (Roberts, 1994) Some of the existing process management and process improvement methods focus more on creating sudden dramatic changes on processes (Business Process Re-engineer- ing), and some of the techniques have their focus on the stabile and constant changes (Business Process Management). Lean thinking as a continuous improvement strategy is an approach towards business processes by eliminating the activities that don’t add value for the company so that the company can focus on only value adding activities and by that increase their business performance (Anthony et al, 2017). Nevertheless, all the process improvement methods have many similarities, and they are all somehow adapted from the previous process improvement trend in the industry. None of the pro- cess improvement methods is totally unique without including any shared practises. (Hermkens, 2007) Two well-known process management methods called Business Pro- cess Reengineering and Business Process Management will be introduced in the follow- ing chapters to exemplify the ideological differences between different process manage- ment methods. Even if there are various process improvement methods available, any of them shouldn’t be implemented in the company’s activities precisely as they guide. As an example, Lean Six Sigma, as a process improvement strategy provides instruments and guidelines for the organizations, that process owners can adapt to fit exactly for their needs (Mast et al, 2022). Any process improvement activity should be considered as a one-time project that is planned to fit exactly for the specific organization’s, department’s, or team’s pur- pose. Existing business process improvement methods offer customizable guides for companies to adapt in their businesses’ diverse activities. (Salomäki, 1999) 17 2.1.1 Expounding business processes The process is an established practice to fulfil recurring tasks in a business (Salomäki, 1999). The business process is distinguished from the business project by its nature to be a cyclic and recurring set of activities to provide the needed outcome, whereas a business project is a non-recurring and unique set of activities to provide the needed outcome. (Roberts, 1994) In a business process, an input is something that triggers the process activities to begin. An input can be for example stakeholder’s request, some spe- cific time, or customer demand. An output instead is something that ends the specific process and is the product or service that needs to be delivered to the internal or exter- nal customer. In addition to input and output, a specific process includes specific number of interrelated activities that need to be completed before receiving the desired out- come. (Berman, 2014, 12-13) Also, the whole company can be considered as a process where the input of the process is a customer requesting the product from the company and the output would be the company providing the product for the customer (Salomäki, 1999). Processes can be divided into three different levels: Process level, sub-process level and task level. A few examples of some of the most common business processes are order handling, invoicing, and delivery process. Sub-processes instead, are all the smaller scale processes needed to be completed to complete the previously listed main processes. Any process has usually at least two or more sub-processes to be completed depending on how complex it is. Task level instead, include all the task level activities that need to be done to provide the outcome for the sub-process and therefore for the main process. The process level is analysed when finding out what is achieved by the process. Sub- process level is analysed, when finding out how the process is organized. Task level is analysed when one needs to know how the work is carried out. There is only a subtle difference between sub-process level and task level and that is why they are sometimes hard to distinguish from another. The most significant difference between sub-process level and task level is that task level process is usually executed by one specific person, 18 when sub-process is usually executed by more than one person or department. (Roberts, 1994) Naturally, the more complex the process is, the more departments are involving in the process (Roberts, 1994). When there are many departments involving in the process, it is extremely important to utilize different process management methods to ensure that all the different parties are unanimous of their responsibilities in the specific process (Smith & Erwin, 2005). One way to make sure that all the responsibilities of the processes are divided unambig- uously is creating procedures of them. Procedure is a standardized and documented pro- cess, and it is needed when multiple people or teams are working with the same process. Procedure is a sort of a guideline how to perform in a specific process and it can be used for not to only standardize the way of working, but also to train new employees to com- plete standard tasks. Procedures are an effective way to inform the processes in detail for the people who are not working with the process, such as managers and directors who are interested in the operations of their lower-level teams. After creating proce- dures, one need to remember to launch them successfully, monitor, measure and im- prove them continuously to get the best benefit out of them. Procedures are not useful if they are created, but no one knows that they exist or where to find them. By continu- ous monitoring, measuring, and improving, one ensures that the procedures are up to date to correspond the current way of working and the current way of working is as efficient as possible. (Berman, 2014) Processes are always needed to keep up the business performance, but procedures are not mandatory. Creating procedures can be only a waste of time in some of the cases. (Berman, 2014, p 17). Paula Berman (2014, p 19) has created a practical checklist to check if procedures should be created for some specific process. Procedures are unnec- essary to be documented if the answer is not yes for any of the questions in figure 3. 19 Figure 3. Berman’s checklist for determining whether procedures are needed or not (Berman 2014, p 19) If the answer is yes for any of the above questions, procedures should be created. For creating procedures, Berman has listed four key rules. The first rule is to keep procedures as simple as possible, but not simpler than that. This means that procedures should al- ways be illustrated so that they include all the mandatory steps including in the process an all these tasks should be minimized to make the process as simple as possible. How- ever, procedures should include all the mandatory steps of the process, so that there is no room for conjecture. The second rule is to minimize the number and the length of procedures. This can be done by creating procedures only for processes that create some additional value. If the answer is not yes for any of the questions in Berman’s checklist in figure 3, procedures don’t create any additional value and they shouldn’t be docu- mented. The third rule is to customize processes to fit in the organization’s culture. Pro- cedures shouldn’t be too generic so that they would be easily understood and describe exactly the procedure, tasks, and organization or team in question. The fourth rule is not to reinvent the wheel. When creating procedures, one should familiarize with common practises in the industry and find out the most suitable practises that fit to one’s own organizations or department’s activities. (Berman, 2014, p 21–38) 20 2.1.2 Business Process Reengineering (BPR) In 1990, Michael Hammer, an American engineer was convinced that the current way of working of companies is not flexible enough for rapidly changing technologies and cus- tomer demands. Hammer thought that the key for increasing business process perfor- mance is somewhere deeper than gradually improving up the existing business pro- cesses. Hammer was a first one to introduce Business Process Reengineering (BPR) as a method to achieve dramatic improvements in business performance. (Hammer 1990) Business Process Reengineering (BPR) as a term means “using the power of modern in- formation technology to radically redesign our business processes in order to achieve dramatic improvements in their performance” -Hammer 1990. When reengineering business processes, all the outdated processes should be obliterated, and new processes should be designed from the beginning by using one’s imagination. All the unspoken rules about the organization or process structure should be forgotten. Process recon- struction should lead to a totally new way to doing things, more efficiently than before. (Hammer, 1990) Dramatic process improvements can be made in sub-process levels of an organization since they are all segments of a company’s main processes (Roberts, 1994). This means that organization’s internal departments can redesign their internal processes to improve their overall performance and therefore benefit the whole organ- ization’s effectiveness (O’Neill & Sohal, 1999). 21 Figure 4. BPR process model (Adapted from Roberts, 1994) Figure 4 illustrates an example of a BPR process flow. The process starts with estimating opportunities for BPR activities and analysing the current state of processes. Analysing phase is often skipped by companies when people are excited on planning the new and better processes instead of analysing the current ones. However, analysing phase is ex- tremely important phase of business process re-engineering and it should not be skipped in any situation. This thesis concentrates exactly on researching, documenting, and ana- lysing the current state to provide TM the best possible base for improving their pro- cesses. 22 After current state analysis, TM can continue with planning their new processes. When new processes have been planned, one can continue with risk assessment and create an implementing plan for the new processes. After this, pilot tests should be carried for the new processes. If test results fulfil all the expectations, structural changes can be imple- mented for the processes. If test results don’t fulfil expectations, one should return on the process planning phase and implement the necessary changes. When processes are on track, one needs to follow-up processes and maintain continuous improvement in them. (Roberts, 1994) As mentioned already earlier, process improvement methods are not meant to be used literally as they are presented. Every company that utilizes BPR methods in their operations, they need to adapt the techniques to fit for their activities. Also, the above BPR process model should be considered as a customizable guide for conducting BPR activities in an organization. Since the day when BPR was introduced, companies implemented business process reengineering to radically redesign their processes to improve their quality, outputs, costs, services, or speed (Roberts, 1994). Active business performance improving activi- ties have the best of intentions, but the outcome is not automatically glorious. Adapting to a new organization structure might be difficult for organization’s employees and in- ternal departments. It was also noted that BPR projects tend to fail unexpectedly and if the results were gained, they were temporary. The failure of the BPR activities was caused by too ambitious objectives, that were not possible to be achieved due to lack of organizations’ resources that were overestimated in the planning phase. (Hermkens, 2007) Failures in Business Process Reengineering projects reduced its favour, and that in- creased the need for more sustainable process improvement techniques. This doesn’t mean that BPR would have been replaced completely by the more sustainable process improvement techniques, but sustainable process improvement techniques are nowa- days a growing trend in organizations. Organizations or departments that are in a trouble relating for example to their quality of work, or customer satisfaction have no other 23 choice than utilize dramatic process improvement techniques to stay competitive, and for that purpose BPR is a proper method. Also, if the organization or department is not yet in trouble, but the troubles are expected to be confronted in the future, dramatic BPR activities would be required. (O’Neill & Sohal, 1999) 2.1.3 Business Process Management (BPM) While Business Process Reengineering (BPR) strives to gain dramatic improvements for the business processes, Business Process Management (BPM) has a different approach for process improvement. BPM is a comprehensive process management method that concentrates on perseverance and patience, instead of radical reengineering activities and therefore it is a way to gradually perform business performance. By utilizing BPM continuously end-to-end, companies have been found to perform better in the business. BPM shouldn’t be considered as an extra effort a company can do to improve their busi- ness performance, but it should be a fundamental principle in companies. (Hermkens, 2007) (Harmon, 2019). Figure 5. Business Process Management lice cycle phases (Lutkevich, 2022). 24 Business Process Management lifecycle includes five different main phases: 1. Design 2. Model 3. Execute 4. Monitor 5. Optimize (Lamghari et al, 2018). The design phase includes identifying and analysing the existing processes and planning future improvement areas for the processes. Modelling phase examines how the im- provement suggestions operate in different scenarios and if they are worth of executing. In the implement phase, operationally confirmed processes will be executed and stand- ardized. Monitoring phase examines how the improved processes operates in practise and the optimize phase enables the continuous improvement of business processes. (Lutkevich, 2022). As shown in the figure 5, BPM lifecycle is a continuous circle that has no end point. When the last phase of the lifecycle, optimizing phase, has been completed, it is time to start the whole cycle again from the design phase. In this thesis, only the design phase is executed partially by conducting as-is analysis for Technical Manage- ment’s existing processes and discovering the improvement areas for their internal pro- cesses. Following phases should be conducted in future research of TM’s processes. Business Process Management presents different tools and techniques for companies to perform at their best. These techniques are process visualization, process mapping, change management, benchmarking, and process and customer focus (O’Neill & Sohal, 1999). Processes can be visualized by flow chart diagrams, swim lane diagrams or Value Stream Mapping (VSM). Some examples of different BPM techniques are: Total Quality Management, Reengineering, Six Sigma & Lean. All these techniques have similarities with each other, and they are all adapted from the previous trend in the industry. All the techniques have their own twists that separates themselves from other techniques. (Harmon, 2019) (Hermkens, 2007). 25 As one may notice after presenting the basics of BPR and BPM, these two methods have many similarities. The biggest difference between these two methods is that BPR con- centrates on dramatic one-time improvements and BPM concentrates on consistency in process improvement. This can be noted especially from the illustrated figures 4 and 5. While BPR process model is a line of activities to be executed and it has a clear end point, BPM process model is a continuous cycle that has not end point. Business Process Management tools and methods can be used in practise to increase organization’s efficiency, customer satisfaction, predictability, and manageability. BPM can be also utilized for shortening lead time of processes, improving quality, and improv- ing risk control and management. (Hermkens, 2007). In this thesis, BPM methods and tools are used to increase organization’s efficiency by illustrating procedure charts for TM. Also, one area of improvement is internal stakeholder’s satisfaction, which will be investigated and improved through stakeholder interviews. 2.2 Process improvement tools and techniques In this sub-section some of the tools of Business Process Reengineering and Business Process Management are presented. The tools have been chosen to benefit finding out the answer for the research question to establish Technical Management’s processes to support the surrounding organization. As-is to-be analysis is a process management method that is utilized to analysing the current state of TM’s processes. As a part of as- is analysis, swim lane diagrams are used for modelling and documenting the as-is situa- tion of Technical Management’s processes. 2.2.1 As-is and to-be comparison A comparison between as-is and to-be is considered as a major phase of Business Pro- cess Reengineering (Okrent & Vokurka, 2004). As-is process analysis is a technique for analysing a company’s or some of its department’s current processes. Analysing the cur- rent state of the processes is the key for identifying the opportunities for improvement 26 and therefore optimizing processes to produce the best benefit. Without understanding the current state of the processes thorough, it would be hard or even impossible to im- prove them. (Roberts, 1994) There are several different reasons to improve business pro- cesses. The goal of optimizing processes might be some of the following list: • To save money • To improve current processes • To create totally new processes • To increase customer satisfaction • To improve business coordination • To improve organizational responsiveness • To meet new standards (Lucidchart, 2022). Even if the opportunity for BPR activities has already been detected, as-is analysis should be conducted properly. If as-is analysis is not conducted properly, it is not guaranteed that people understand the current situation as it is. People might have false assump- tions of the current state and there is a huge risk that re-engineering activities take the wrong course. By understanding the current situation thoroughly, people can make ra- tional re-engineering decisions and improve processes the best possible way. That is the reason why as-is analysis is extremely important base for the process improvement. However, one need to remember that there is a risk to get stuck on the analysing process. Many processes are so complex that even the three process levels described formerly, are not enough to present all the details of the processes. When conducting as-is analysis, one needs to keep analysis in a relevant level and not getting stuck on the details to be able to continue with the reengineering process on a convenient schedule. Even though as-is analysis provides a solid base for business process reengineering and it should be conducted carefully, it shouldn’t be a project that has no end. (Roberts, 1994) As-is process analysis includes three different phases: research, document & analyse. In the research phase, one needs to clarify which are the main activities of the company. 27 All their products and services should be listed, and the processes needed in delivering the outcome should be identified. The necessary information can be gained for example through stakeholder interviews, direct observation, surveys, or group meetings. In the documentation phase, all the procedures should be modelled in the form of some pro- cess diagram. The most important thing is that the map documents all the process inputs, activities needed performing the process and their responsible persons or teams, and all the outcomes of the process. When procedures are modelled, the possible bottlenecks, deficiencies, and weaknesses can be detected and analysed. (Lucidchart, 2022). Structural analysis concentrates on process’ structural efficiency. It strives for detecting and eliminating the lacking, overlapping, conflicting or unnecessary steps in a process. By conducting structural analysis, one can spot the current efficiency of the process and either approve the current processes or confirm the need for process re-engineering. Processes can also be analysed dynamically by performance metrics, such as in terms of lead-time and costs. (Roberts, 1994) In this thesis, structural analysis will be conducted for Technical Management’s processes because in as-is analysis phase it is not necessary to concentrate on such a detailed characteristics such as process lead-times or process costs, especially when as-is analysis is done for all Technical Management’s processes and not only one of them. After the as-is situation has been researched, documented, and analysed completely, one can move on to determining the future state to-be processes. When creating to-be processes, one needs to evaluate at first which processes are critical for the business. Critical processes create the most value for the internal or external customer. After de- termining the critical processes, to-be illustrations can be drafted without any con- straints such as funds and human resources. The next step can be either to modify to-be models according to the current constraints of the business or eliminating steps of the process that don’t add any value for the customer. (Okrent & Vokurka, 2004) 28 As as-is analysis, and all the other Business Process Management or Reengineering ac- tivities, to-be analysis need to be adapted to fit for the case company’s purposes. As the result of this thesis, as-is analysis has been conducted for TM’s processes and TM needs to figure out what kind of to-be analysis project they will conduct for their processes to improve them in practise. Both BPR and BPM methods provided their own model, and TM can either choose one of them to adapt for their usage or combine these two meth- ods and adapt them to improve their processes. 2.2.2 Swim lane diagrams The swim lane diagram is an effective tool to illustrate cross-functional business pro- cesses that include several different parties, because it presents how the responsibilities of the process are divided and which tasks are in a specific party’s response (Roberts, 1994). Swim lane diagram has been developed to illustrate especially complex and non- linear processes that are difficult to illustrate with other diagrams, such as value stream mapping (Roser, 2015). Swim lane diagrams are used for not to only model or design processes, but also to validate the processes within the company (Jeyaraj & Sauter, 2014). Process modelling and process design should be considered as two different things. Pro- cess models are used to illustrate the business processes and with the help of then one can analyse or validate the processes. When modelling the processes, one need to ask from themselves that how the process could be visualized, and which steps should be included in the illustration. Process design instead is more than just illustrating the pro- cesses. When designing processes, one needs to ask from themselves how the processes should be organized, which techniques should be used and who is the responsible per- son or group to perform the process steps. In as-is analysis phase, processes are mod- elled, not designed. (Reijers, 2021) Swim lane diagram has four different elements that helps to illustrate the process the most efficient and explicit way. These four elements are: swim lanes, shapes, connectors & phases (Bakar et al, 2020, p 5). Swim lane is the most significant element because it distinguishes swim lane diagrams from other process diagrams. Swim lane is a bounded 29 area, which is always restricted for only one responsible group or person, one entity. For that reason, swim lane diagrams are especially convenient, when illustrating cross-func- tional processes where many different stakeholders are involved. In cross-functional pro- cesses, there can be several swim lanes in top of each other and every one of them is titled with the name of the responsible department and they contain all the process steps for that specific entity. Swim lane diagram can also be vertical and in that case, there can be there are several swim lanes side by side to represent every entity involved in the process. (Lucidchart, 2022a) All the other elements in swim lane diagram are similar as in the basic flow chart. Pro- cess steps are illustrated with shapes. The round shape illustrates the start and the end of the process. The rectangle shape illustrates processes or sub-processes. Connectors illustrate the route of the whole process, and it combines every shape together. Con- nectors have an arrow which illustrate the correct direction to proceed. Diamond illus- trates decision. There are also two different shapes to illustrate data and document. (Mi- crosoft 2021) In the example picture 6, swim lanes are titled as “swim lane X” just to illustrate the meaning of a swim lane. Swim lanes are usually titled with the name of the responsible stakeholder. The title of the swim lane diagram can be the name of the process or sub- process and in every shape a specific step of the process should be specified. For exam- ple, decision shape could be named as “Is the needed document complete?”. Decision shape has two, or more, different paths to proceed after it and the process proceeds in the direction depending on the decision. These two paths might lead to a totally different outcome of the process, or then the paths will unite, and the process has the same out- come regardless of the decision and the different path. A process shape represents some typical step in the process, that transfers one or more inputs into one or more outputs (Roberts, 1994). (Microsoft, 2021) 30 Figure 6. An example of a swim lane diagram created with Microsoft Visio Swim lane diagram is a great tool for illustrating problems within processes between different departments or people. Swim line diagram itself doesn’t solve the problems that occurs in processes, but it is in key role for recognizing the issues. When processes have been illustrated with swim lane diagrams, all concerned people can brainstorm to- gether how to improve their common processes. (Roser, 2015) Modelling procedure charts for complex processes is time consuming and complicated. If the process is complex, it is not easy to mark the boundaries of the process and deter- mine inputs and outputs. Processes might also include parallel activities, dead ends, and exceptional situations that might be difficult to model. In addition, every person has their own view of the process, and the illustrated procedure might be different depending on who has created it. For that reason, the people who know the process best should be in response of modelling the process or at least being strongly involved in the process mod- elling project. Especially in modelling phase it is necessary to keep in mind to not get stuck on the analysing process and keep the procedure charts in relevant, not too de- tailed level. (Roberts, 1994) 31 3 Study Methodology This chapter is a compact description about the research methodology. Unit of analysis, research data, process steps, tools and methods are explained in detail to give a plain understanding about the research structure. The goal of the research was to establish Technical Management’s (TM’s) processes to support its surrounding organization. For achieving the goal, two separate objectives for the thesis were determining the status of TM’s processes and investigating how they should be improved to support the surround- ing organization better. Qualitative research method is a holistic approach towards the research issue (Brodsky et al, 2016, p 13). Since this research is a preliminary study of TM’s processes, qualitative approach was natural method to be chosen. Nomothetical research is finding out how things are currently, and normative research tries to find the solution for how things should be in the future (Helo et al, 2019). This Thesis is a combination of both two re- search types since the first research objective is nomothetical and the second research objective is normative. Business Process Reengineering (BPR) and Business Process Management (BPM) tools and techniques will be utilized to achieve a creditable outcome of the research. In this research, as-is analysis is utilized to find out the solution for the research question. The practical part of the research has been divided in the following three different sections, which go along with as-is analysis’ structure: 1. Document: Creating as-is procedure charts of Technical Management processes 2. Research: Interviewing stakeholders 3. Analysis: Determining the improvement propositions for Technical Management processes In the first step of the research the current situation of TM’s processes was documented. In this part, data of analysis is general manager’s and managers’ descriptions about TM 32 current activities. As-is swim lane diagrams about TM processes were illustrated with Microsoft Visio in six two-hours workshops together with the general manager of TM and managers of Technical Product Management and Technical Quality Management. These people were considered as “process experts”. In a process development project, process expert is a person who works daily in the sub-process level have the most com- prehensive knowledge about the current processes. (Roberts, 1994). Swim lane diagram method has been chosen because it best describes the responsibility areas of a specific process. All the steps in the cross-functional processes that are not in TM’s response, were outlined from the TM’s swim lane. As the result of the first part of the thesis, re- search objective one has been achieved and the situation of TM’s current processes has been established. Qualitative research strives to understand people’s experiences and what is important for them (Silverman, 2021, p 3). In the second step, Technical Management’s internal stakeholders’ experiences of TM’s processes are collected via in-depth interviews, which are considered the most common way to collect data in qualitative research. However, interviews shouldn’t be held if it is possible to obtain the information from any other route. (Baškarada, 2014, p 11). In this research, interview sessions were necessary to gain the data from various stakeholders, because cross-functional perspective is essen- tial when reengineering business processes at the fundamental level (Hammer 1990). The data is collected via semi-structured individual in-depth interviews with open-ended pre-defined questions. In semi-structured interviews, pre-defined questions are asked from the interviewee, but the question categories are not pre-defined. Semi-structured interviews allow interviewer to pose any additional questions during the interview ses- sion depending on the interviewee’s responses (DiCicco-Bloom et al, 2006, pp 315–316). Open-ended questions allow people to give their answers spontaneously because the possible answer options are not suggested for them. By using open-ended questions, researcher doesn’t lead interviewees to answer in a specific way and the results can be diverse. This method suits best for the research topic because the questions are easy to 33 predefine in advance, but various stakeholders’ answers can’t be predicted. Open-ended questions are often used in a preliminary study for some specific research subject where even the interviewer can’t predict the possible interview answers. Closed questions in- stead can be conducted in further research where target group’s thoughts have already been mapped. (Popping, 2015) As TM is in response of managing all the technical documentation, product maintaining and product care activities of complex technology products, they have plenty of stake- holders. A stakeholder is a quarter that has a stable interest in some organization’s or department’s activities. Stakeholders can be either internal, or external. Internal stake- holders have a direct relationship with the organization such as an employee or an owner. External stakeholders instead don’t work in the organization, but they still are affected by its actions. External stakeholders can be for example suppliers or creditors. (Fernando, 2021) Stakeholder analysis is a systematic process to determine which stakeholders’ in- terests should be considered when developing or implementing policies, for example in form of processes. Stakeholder analysis gathers and analyses qualitative information about all the stakeholders and identifies the key stakeholders from others by their knowledge, interest, positions, alliances, and importance related to the policy process. The established process is more likely success if stakeholder analysis has been utilized. (Schmeer, 2000) In total, 16 different departments, considered as key stakeholders of TM, were inter- viewed according to table 1. The stakeholder list consists of all the key stakeholders that are cooperating with TM in weekly basis. All in all, 21 people attended in the interviews to represent their department’s expectations and improve ideas towards TM. The inter- view invite was sent primarily for one representative of the department, but if they wanted to have some of their colleagues involving in the interview too, it was allowed. When the initiative to invite another person to the interview, it was assumed that the colleague would have much to say about the subject, and the invited interviewees wouldn’t feel themselves uncomfortable in group interview session. The interview invite 34 included all the interview questions which allowed interviewees to think about their re- sponses beforehand. This was done to gain the most fruitful feedback as possible. Table 1. Stakeholder interview participants Department Number of interviewees Stakeholder 1 1 Stakeholder 2 1 Stakeholder 3 1 Stakeholder 4 1 Stakeholder 5 1 Stakeholder 6 1 Stakeholder 7 2 Stakeholder 8 1 Stakeholder 9 1 Stakeholder 10 3 Stakeholder 11 1 Stakeholder 12 2 Stakeholder 13 1 Stakeholder 14 2 Stakeholder 15 1 Stakeholder 16 1 Interviews were held via Teams to ensure the possibility to give the most extensive an- swers to the questions. The most fruitful environment for the interviews would be face- to-face meeting, but due to Covid-19 restrictions Teams interviews were chosen. Inter- views’ duration was varying between twenty minutes and hour depending on how much interviewees had to say. All the interviews were held during November and December of 2021. Interview language was either Finnish or English depending on the interviewee’s native language. All the interviews were recorded with the consent of the interviewee and the records were written down on subject level in the interview transcript. Word- for-word accuracy was not necessary since the matter to be investigated is in subject level. After transcripts were created, interview recordings were deleted. Stakeholders did not stay anonymous for the interviewer, but the interview results were anonymized. Only stakeholders’ answers and the department name were documented and analysed. 35 This ensured that the interviewees don’t have any limitations to dare to answer for the questions honestly and the feedback is fruitful. Also due to anonymity, the results can be analysed unprejudiced in the possible future to-be analysis. The interview results, honest feedback and improvement ideas are utilized in the third step, where the interview results are analysed and compared to TM’s as-is procedure charts. Open-ended questions are a great way to gather wide-ranging and genuine opin- ions but is a laborious task to analyse all the diverse data (Cho, 2022). Thematic analysis is a flexible approach to analyse complex qualitative data (Nowell et al, 2017) and it is used to ease the analysing process. The first step of thematic analysis is to familiarize oneself with the collected data by listening interview recordings, reading transcripts thoroughly, and by that creating a clear overall view about the collected data. When the data is understood properly, researcher can code the answers based on the subject they are relating to and after that create theme titles for them to simplify the data. (Clarke et al, 2015, pp 222–248), (Riger & Sigurvinsdotter, 2016). In this research, the themes were created only for the interview answers, that were gen- eral enough to be united under the same theme without losing the meaning of separate answers. The interview answers that were specified to describe a specific process, weren’t united in themes so that their meaning was preserved. The interview results were presented in the form of a table to rank them based on their repetition in the in- terview answers. By the end of the interview chapter, one can spot the improvement areas of TM’s current processes. 36 4 Results analysis This chapter includes all the practicalities of the thesis according as-is analysis: illustrat- ing the current Technical Management’s (TM) procedures (document), interviewing stakeholders about their expectations towards TM (research), and establishing the im- provement ideas towards Technical Management (analyse). 4.1 Defining current processes of Technical Management In this chapter the current process charts of Technical Management (TM) are established. The result of this chapter is as-is swim lane diagrams of Technical Management’s current processes. When procedures are documented, the possible bottlenecks, deficiencies, and weaknesses can be detected and analysed. 4.1.1 Defining Technical Management responsibilities Technical Management is a small department inside the case company’s research and development (R&D) organization. The case company is a global leading company pro- ducing sustainable technology solutions to the market to create a sustainable future. Case company’s R&D department is in response of research and development of new products, technologies, and concepts with their respective areas. Their strategic goal is to develop the right technologies, products and integrated solutions to enable most competitive offering to the market. Key responsibilities and deliverables of R&D organi- zation are listed below: • Technology strategy and long-term roadmap definition & execution • Research and development of new market-shaping technologies • New product development • Developing new integrated systems to create customer value • Drive connected portfolio to enable big data analysis and new business models 37 • Customer order specific configuration and engineering • Product improvement, quality issue resolution and product maintenance • Development of core competencies, tools, and ways of working. Inside R&D organization, TM’s main response area is managing research and develop- ment activities of a set of the complex technology products by being responsible of prod- uct technical related maintenance and giving technical support for huge number of in- ternal stakeholders to fulfil their tasks. TM’s mission is to “develop, validate and maintain company’s products with selected technologies in order to create added value to cus- tomers business and environment” (Lehtonen, 2021). TM’s responsibilities are divided for two different teams: Technical Product Management (TPM) and Technical Quality Management (TQM). In total there are 22 people working in TM including two technical managers and one general manager. In TPM there are 11 people working with titles: product engineer, technical expert, or technical manager. In TQM, 9 employees are titled as product improvement engineers, or technical manager. Technical product management (TPM) is working with the products, starting from sales support, and continuing until products are delivered from Factory. Technical Quality Management (TQM) responds for commissioning and field support as well product qual- ity related tasks during the development and delivery process. TM has the technical end to end responsibility of a set of the complex technology products of the company. The ownership of these products belongs to a different department, stakeholder 10. 4.1.2 Defining Technical Management main processes As TM has the technical end to end responsibility of a set of case company’s complex technology products, they have many internal processes. In below list one can see the current main processes of TPM. Below processes are considered as main processes be- cause they are needed in delivering the outcome of TM. 38 • Non-standard request (NSR) technical evaluation • Technical responsibility of the products o Input to installation & performance manuals o Inputs for product presentations • Sales & stakeholder 10 support • Delivery project support • Production support • Joint Venture (JV) support o Quality & localization o Sales projects • Classification support o Certification support o Compliance support • Ownership of technical documents: Product parametrization, Standard tools master lists, products design stages • Configurator selections • IOS validation and template maintenance • Standard register selections • Development projects core team participation • TM order intake • Scheduling test activities in co-operation with Testing & Validation and produc- tion if testing is done with delivery project products Non-standard request support is giving technical support for sales and stakeholder 10 to enable sales for special needs. Salesperson creates an NSR, when customer has re- quested some customization or adaption of portfolio products based on their require- ments. The customer might request special product performance, special product clas- sification or for example special product testing. In practise, TM is to give the most ex- tensive analysis as possible for the sales about the risks, extra effort, extra lead time and the adaptability of the requested characteristics. After TM has completed the technical 39 evaluation, stakeholder 10 analyses the business opportunity based on the technical evaluation and possible risks defined, and they are to make the final decisions whether to proceed with the deal or not. Technical Product Management has the technical end-to-end responsibility of a set of complex technology products of the company. TPM is the responsible team to give the latest technical feasibility for the requested functionalities. For example, if customer has some special request for the product, TPM investigates if it is possible to fulfil the re- quested feature or not. TPM’s function is not to investigate all the requested features by themselves, but they are to collect all the needed information by communicating with specialists in case company’s R&D organization and by that conclude if request is techni- cally feasible or not. Due to overall technical knowledge, TPM is to support stakeholder 8, who is in response of creating installation- and performance manuals of the products. Installation and per- formance manuals are vital internal documents of the product characteristics and in the past, TPM used to own these documents. For example, sales and stakeholder 10 are reg- ularly using the content of the manuals to investigate answers for the customer requests about the products. It is crucial that these documents are always easily available and up to date so that extra customer inquiries can be responded without any delays. Stake- holder 8, as an owner of the manuals, is in response of collecting all the needed data for the new manuals and keeping existing manuals up to date. TM is strongly involving in the process of creating manuals for the new products. Also, whenever a mistake has been spotted in some of the existing manuals, stakeholder 8 will be notified, and they will edit manuals as requested. If some product specification changes, technical man- agement needs to inform stakeholder 8 to update manuals according to the changes. TPM is also in response of providing technical input for product presentations that are owned by stakeholder 10. Product presentations are internal documents, but they can be shared to end customer if needed. Presentations provides only general information 40 and technical features of the products, while the sensitive information is in internal doc- uments like Performance- and Installation Manual. Sales support is giving technical support for sales and Project Management after contract is signed. The customer might have detailed technical questions about the product, that stakeholder 10 or salesperson is not able to find an answer from internal documentation. In that case stakeholder 10 contacts Technical Product Management to provide technical support so that they can provide an answer to sales who provides it to the customer. TPM is the first point of contact inside R&D department and if they are not able to an- swer to the question by themselves, they will direct the question to a correct team inside R&D organization. In addition to sales, TPM is to give technical support for JVs located in China, product deliveries, production, classification, or any other party that needs technical support. As sales, JVs might as well have detailed questions about the product that is not described in product manuals or access is denied for the external users. Regarding product deliv- eries, Technical Product Management is regularly involving in internal order specification (IOS) validation meetings by providing technical input. TPM is the owner of standard tools list, product parametrization document and small and product design stages document. Standard tools master list is a list about standard tools included in the product delivery. TPM, as the owner of the document, will keep it updated for all the relevant stakeholders that use it for different needs. Relevant stake- holders in this case are Parts Coordination Management (PCM), stakeholder 10, 11, and 14. Product parametrization document is a guide for test run, and it includes all the ref- erence values of the product. Test run will utilize the document while checking if the product functions as expected. Product design stage document instead is a document that visualizes the current design stages of the products. It is utilized to keep every rele- vant stakeholder up to date about the design stages of the separate products. Design 41 stages are also communicated between case company and classification societies to con- trol different products and their emission levels. In addition to above mentioned responsibilities, Technical Management is in response of configurator options, IOS validation and IOS template maintenance, and standard reg- ister selections. Configurator is a tool providing the released options for sales use, mak- ing Internal Order Specification (IOS) and managing new options and features based on the agreed Sales Release Plan. TM should make sure that everything is correct in config- urator and configurator includes all the possible variations of the products so that they can be ordered from the factory according sales contract. Responsibilities in IOS tem- plate maintenance, and with standard register selections are similar with configurator. TPM is involving in order intake meetings, where all the internal orders sent via Polarion tool will be analysed together with the managers of different R&D departments. TPM is also involved in scheduling test activities in co-operation with Testing & Validation and production if testing is done with delivery project products. All TPM processes will be explained in detail in the next chapter, where they have been illustrated in the form of swim lane diagrams. In the below list, one can see Technical Quality Management’s (TQM) main internal pro- cesses. These processes are considered mandatory for Technical Quality Management to deliver their required outcome. 42 • PIP process (process owned by Product Quality Management) • Issue register • MTBF follow up for selected customers • Field follow up with selected customers / products • Design quality assurance • WPAP participation • Scheduling test activities in co-operation with Testing & Validation, Performance and production depending on if the testing is done with delivery project products Leading Product Improvement Process (PIP) as issue managers is a major part of TQM’s responsibilities. TQM provide technical support for customer issues in the field together with stakeholder 15. Issues can be for example a breakout of some product component. TQM is in response of finding out the solution of the breakage with relevant R&D stake- holders. Some of the issues are extensive enough to start product improvement process. The aim of the Product Improvement Process is to find out the root cause of the issue and find out the solution how to improve the specific part of the product. PIP process is owned by product quality management and therefore won’t be illustrated in this thesis. The issue register captures and keeps track of all the issues related to products. TQM is involving the process by providing technical support when needed by Product Quality Management. Mean time between failures (MTBF) is a value that describes system’s reliability. MTBF value is the expected time between two failures for a repairable system. It is used for example for estimating product’s warranty and obsolescence schedules. (Hupje, 2021)(Krasich et al, 2009). When MTBF is required for some product, TQM is involving the process by providing their technical support. TQM is also involving in field follow-up, Part Approval Process (PAP), and design assurance processes explained detailed in the next chapter’s procedure charts. 43 4.1.3 Establishing Technical Management as-is procedure charts In this chapter, TM’s as-is procedure charts are illustrated. This chapter can be consid- ered as as-is analysis’ document section where Technical Management procedures are illustrated in the form of swim lane diagrams. These diagrams document all the process inputs, activities, and outcomes needed for performing the process from Technical Man- agement’s perspective. All the departments included in the process are illustrated in their own swim lane to recognize the responsibilities of specific tasks. Technical Management Processes / NSR process Te ch ni ca l P ro du ct M an ag em en t St ak eh ol d er 1 0 R el ev an t st ak eh ol de r( s) JV / Pr od uc ti on Does NSR include all the necessary information? Review NSR in SalesForce Perform technical evaluation Evaluate the request Yes No Supplementing feasibility evaluation Is Techncial evaluation complete? No Yes Request Technical Manager Approval Is NSR approved? Yes No Send back to feasibility evaluation Request support from the relevant stakeholder(s) via Polarion/e-mail/ Teams Approving/rejecting NSR Is NSR approved? No Yes Information about the new NSR received via e-mail Send evaluation to TM Feasibility evaluation completed for the NSR Information about the rejection by salesforce tool Final decision NSR evaluation by JV / Production Figure 7. NSR procedure. Figure 7 describes TPM’s involvement in NSR process. TPM receives non-standard re- quest from stakeholder 10, that have already completed the feasibility evaluation of the NSR. When TPM receives the information about the new NSR via e-mail, they review it via Salesforce tool. If feasibility evaluation is incomplete or otherwise unclear, TPM needs to send the NSR back to feasibility evaluation for stakeholder 10’s evaluation. When the feasibility evaluation is complete from stakeholder 10’s side, TPM can perform technical evaluation of the NSR. In most of the cases, TPM can’t evaluate NSR’s by them- selves and they need to request support from some of the internal stakeholders. The most common stakeholders to advice in NSR related questions are stakeholder 1, 2, 3, 4 44 or 6. When the technical evaluation is completed, TPM product engineer can approve or reject the NSR depending on if it is technically feasible or not. If the NSR is approved, the Technical Manager of TPM needs to agree or disagree with the product engineer and confirm if the NSR can be approved or not. If the technical manager of TPM approves the NSR, it will be directed to production’s evaluation via Salesforce tool. Production will receive an automatic e-mail that they can now evaluate the NSR from their perspective. When production have evaluated the NSR from their perspective, stakeholder 10 needs to do the final decision to proceed or not to proceed with the deal based on the evalua- tions. Technical Management Processes / Performance & Installation manuals Te ch ni ca l P ro du ct M an ag em en t St ak eh ol d er 8 In te rn al st ak e h o ld e r Create polarion request to update performance/ installation manuals Yes Receives polarion task to update manuals Updating performance/ installation manuals Technical responsibility of products Performance & installation manuals up-to-date Ownership of installation & performance manual Yes Create polarion reguest to update performance/ installation manuals Update need in performance/ installation manual detected Update need in performance/ installation manual detected Figure 8. Performance & installation manuals procedure. The figure 8 illustrates TPM’s current role in Performance & Installation manual process. The ownership of the installation and performance manuals is currently in stakeholder 8 so they, as technical writers, are in response of the manuals in general. Technical Product Management has the technical responsibility of the products and therefore they are in response of the technical input of the performance and installation manuals. When TPM detects a mistake in the manual, they need to send an update request to stakeholder 8 45 via Polarion tool. Stakeholder 8 will then revise the document according to the instruc- tions given by TPM. Also, if any other internal stakeholder detects a mistake in the man- ual, they will send an update request to the owner of the manual. Customer, sales, or stakeholder 13 address frequently complex questions for stakeholder 10. Sometimes they find the answer for the requester from installation- or performance manual or some other way, but if not, they need to contact Technical Product Manage- ment for the support according to the figure 9. TPM might also need some additional help finding out the answer and they need to contact the relevant internal stakeholder inside R&D for help via Polarion, e-mail, or via Teams. Technical Management Processes / Stakeholder 10 support Te ch ni ca l P ro du ct M an ag em en t St ak eh ol er 1 0 R el ev an t st ak eh ol de r Technical question received from the customer/ stakeholder 13 / sales Technical question received via Polarion/e-mail/ Teams Answer a question? No Answer a question? Yes Send a response to stakeholder 10 No Yes Answer to the requester Send a request in Polarion/e-mail/call in Teams to relevant stakeholder Find the answer for technical question An answer received Figure 9. Stakeholder 10 support procedure. Joint venture support can be divided in different categories: Quality & localization and sales projects sold by JV. Quality and Localization procedure is illustrated in figure 10. Technical Product Management receives quality and localization related questions from both joint ventures and stakeholder 12 because sometimes JV contacts TPM directly and sometimes they contact stakeholder 12. If stakeholder 12 is not able to answer JV’s ques- tion, they assign the question for Technical Product Management. TPM, as a coordinator 46 inside R&D organization, contacts correct stakeholders for further support if needed and reports the answer for both stakeholder 12 and JV. Technical Management Processes / JV support (Quality & localization) Te ch ni ca l P ro du ct M an ag e m e n t JV R e le v an t st ak e h o ld e r St ak e h o ld er 1 2 Technical question from JV Technical question received via Polarion/e-mail/ Teams Answer to a question? Yes Send a response to JV & stakeholder 12 No Answer received Send an Polarion/e- mail/call in Teams to relevant stakeholder Find the answer for technical question An answer received Answer received Answer to a question? Yes No Send a response to JV Figure 10. JV support quality & localization procedure. TM’s participation in JV sales projects procedure is illustrated in the figure 11. In JV sales projects, the process is otherwise similar as in quality and localization, but stakeholder 10 is acting between Technical Product Management and stakeholder 12. In sales pro- jects, stakeholder 10 is the first point of contact for JV and stakeholder 12, and they will direct the questions for TPM. TPM’s internal process is similar as in the sales support procedure chart. 47 Technical Management Processes / JV support (Sales project sold by JV) Te ch ni ca l P ro du ct M an ag em en t JV R el ev an t st ak eh ol de r St ak eh ol d er 1 2 St ak eh ol d er 1 0 Technical question from JV Technical question received via Polarion/e-mail/ Teams Answer to a question? Yes Send a response to Product management No Send an Polarion/e- mail/call in Teams to relevant stakeholder Find the answer for technical question An answer received Technical question received via e-mail/ Teams Answer to a question? Yes Send a response to JV Answer to sales project Answer received Answer to a question? Yes No No Figure 11. JV support sales projects procedure. Compliance and certification support has been divided in two different procedure charts. The first procedure chart “compliance support” (Figure 12) illustrates TPM’s involvement in the compliance process. TPM is the initiator of compliance processes of safety concept, EN ISO 12100 product risk assessment. Also, any other internal stakeholder can act as an initiator of the compliance process. The compliance process (DMAA00006924) itself is in response of the safety manager who will start the process after receiving an initiative from TPM or any other internal stakeholder. 48 Technical Management Processes / Compliance support Te ch ni ca l P ro du ct M an ag em en t In te rn al st ak eh ol de r Sa fe ty m an ag er Compliance related need e.g. Safety concept, EN ISO 12100 (product risk assessment) Start requested compliance process Compliance related need e.g. Safety concept, EN ISO 12100 (product risk assessment) Compliance process DMAA00006924 Figure 12. Compliance support procedure. Technical Management Processes / Certification support Te ch n ic al P ro d u ct M an ag em en t St ak eh o ld er 2 In te rn al st ak eh ol de r RDE project Line Activity Create activity request to stakeholder 2 in Polarion EIAPP/ type approval need Type approval/ EIAPP / Unic type approval? Unic type approval Arrange kick off meeting for unic type approval DMAA00007685 Arrange kick off meetingEIAPP / type approval Follow-up meetings EIAPP/ type approval Create activity request to C&C in Polarion Activity request received in Polarion Create activity request to stakeholder2 in Polarion EIAPP/ type approval need Figure 13. Certification support procedure. The initiative for certification process (figure 13) comes usually from TPM, but it can also come from any other internal stakeholder. The initiative can be for example need for EIAPP, product type approval or research and development project line activity. If there 49 is a need for EIAPP or type approval, TPM needs to arrange kick-of meeting. If there is a need for UNIC type approval (DMAA00007685), TPM (or any other stakeholder with the need) needs to create activity request to stakeholder 2, and they will arrange the kick of meeting. In any case, stakeholder 2 will arrange follow-up meetings and proceed with approval processes onwards. Technical Management Processes / Delivery projects support (IOS) T e ch n ic al P ro d u ct M an ag em en t Sa le s / C us to m er de liv er y St ak eh ol d er 1 4 Pl at fo rm Contract signed Checking IOS from technical perspective Arrange technical IOS meeting Inputs for technical IOS meeting Is there something that needs to be changed in IOS? Yes No First IOS released Order intake Design request Polarion activity requests & tasks to relevant stakeholders Regular delivery project process Arrange technical IOS meeting Figure 14. Delivery projects support procedure. In delivery projects (figure 14), TPM has an important role giving technical input for in- ternal order specification (IOS) meetings. After sales have signed the contact with the customer, customer delivery organization releases the first version IOS based on the sales contract. Every necessary stakeholder receives an information about the released IOS via automated e-mail notification. Stakeholder 14 creates design requests based on the released IOS and these requests are managed in the platform’s weekly order intake meeting. After the meeting, the person of the TPM who is in response of that specific product checks the IOS from the technical perspective and creates Polarion activity re- quests for the relevant stakeholders. The relevant stakeholder can be for example stake- holder 1, 2, 6, or 16. Via these created Polarion requests, TPM collects all the needed 50 inputs for technical IOS meeting that is organized by stakeholder 14. Technical IOS meet- ings are organized until the IOS is complete and free from defects. After that delivery management can proceed with their regular delivery project process. Technical Management Processes / Configurator selections Te ch ni ca l P ro du ct M an ag em en t St ak eh ol de r 9 or 1 0 Re le va nt st ak eh ol de rs St ak eh ol de r 7 St ak eh ol de r 4 St ak eh ol de r 8 Responsible of configurator selections Update request received Update need in configurator Update need in configurator Update need in configurator Change request evaluation Consulting relevant stakeholders Provide input & expertise for the request Configurator to be updated No Yes Configurator to be updated Inform requester Input for IOS template Figure 15. Configurator selections procedure. An update need for product configurator can be received from stakeholder 4, 7, 9, or 10. TPM who is in response of the configurator selections is in response of executing these configurator changes. When TPM receives a change request, they evaluate the request by themselves and consult relevant stakeholders about the request. Possible relevant stakeholders are listed in the figure 15. When the evaluation is complete, TPM knows if the configurator should be updated or not. If the result is not to update the configurator according to the request, TPM needs to inform the requester accordingly. If configurator is to be updated, TPM assigns stakeholder 8 to implement the changes in it. Stakeholder 51 8 will then make the requested changes to configurator and these changes will be im- plemented also for the IOS template. One of TPM’s newest responsibilities is to maintain Internal Order Specification (IOS) template. As illustrated in the figure 16, TPM can receive an update request for IOS tem- plate from any of the stakeholders. All the configurator changes are related to IOS tem- plate, which means that when TPM edits configurator selections, they must check if it is needed to do the changes for IOS template as well. After receiving a request to update IOS template, TPM evaluates the request and validates the changes. If the change re- quest was configurator related, stakeholder 8 will order IOS template update from IM- portal. If the change request is not relating to configurator, TPM will implement the changes to correspond Configuration selections and follow-up to make sure that changes are made with the requested due date. Technical Management Processes / IOS template Te ch ni ca l P ro du ct M an ag em en t (O w ne r of IO S te m pl at e) R el ev an t st ak eh o ld er s St ak eh ol d er 8 Evaluate change request Update request for IOS template Input for IOS template Validate changes Implement changes to IOS template (according configurator) Implement changes to IOS template (other than configurator related) IM ticket IM ticket Validate: Change management Figure 16. IOS template maintenance procedure. According to the figure 17, change request for standard register can be received from any of the internal stakeholders if the change is not included in release meeting. TPM is to evaluate the request and if they decline it, they will send the information about the 52 decision to the requester. If the request is accepted by TPM, they will assign stakeholder 8 to implement the requested changes to standard register. Stakeholder 8 will then up- date the standard register as requested. TPM can also request standard register change from stakeholder 8 due to some product development, product improvement or new component validation. If standard register needs to be updated due to design change, stakeholder 8 will receive the information about it via change notice directly from stake- holder 4 and TM is not transmitting the information between these two departments. Technical Management Processes / Standard register Te ch ni ca l P ro du ct M an ag em en t St ak eh ol d er 4 St ak eh o ld er 8 R el ev an t st ak eh ol de r configurator Design change notice Update standard register Standard register updated Product development/ Product improvement / new component validation Change need to standard register (outside release meeting) Evaluation of change request Yes Update request for product information No Request declined Send information to requester Figure 17. Standard register procedure. In product development projects, TPM needs to evaluate and perform their tasks as- signed by stakeholder 7. TPM might as well receive product development related tasks participating core team meetings as illustrated in the figure 18. 53 Technical Management Processes / Development projects T e ch n ic al P ro d u ct M a n a g em e n t St ak e h o ld er 7 Request to technical management Perform requested task Inform stakeholder 7 about the result Request received from stakeholder 7 Via Polarion Evaluate & perform requested task Task received for technical management Result received Core team participation Figure 18. Development projects procedure. Technical Management Processes / Product design stages Te ch ni ca l M an ag em en t St ak eh ol d er 7 R & D New product/ feature New product/ feature New product/ feature Evaluate & perform requested task product names DAAE087664 New design stage? Yes No Update design stage document design stages DMTA00043906 Inform requester & stakeholders Figure 19. Design stages procedure. TPM is in response of updating product design stages document (DMTA00043906) when needed (figure 19). Stakeholder 7, any other R&D department or Technical Management by themselves assigns a task for Technical Product Management if there is a new product or feature upcoming. TPM will evaluate the request assigned to them and perform tasks 54 by using product names document (DAAE087664). If the evaluation shows that a new design stage is required, TPM updates the design stage document. If there is no need to create a new design stage, TPM needs to inform the requester and stakeholders accord- ingly. TPM supports production in technical issues as illustrated in the figure 15. TPM is the first point of contact inside of R&D department and they will ask the additional support from the relevant stakeholder if needed. Technical Management Processes / Production support Te ch ni ca l P ro du ct M an ag em en t R el ev an t st ak eh ol de r Pr od uc ti on Technical support request received Request technical support Answer received Answer a question? Yes Send a response to factory No Send a request in Polarion/e-mail/call in Teams to relevant stakeholder Find the answer for technical question An answer received Figure 20. Production support procedure. TPM involves in order intake process by at first pre-evaluating the Polarion request re- ceived from some of the stakeholders. TPM needs to evaluate if the request is approved, and it can be discussed in the weekly order intake meeting. If the request is declined, TPM needs to inform the requester accordingly. In the weekly order intake meeting, managers are prioritizing all the received Polarion tasks of the department. They also double-confirm if the request is approved or not. If the request is approved, and it is for TPM, they assign the task for them. Then TPM can evaluate the request, perform the 55 tasks, and possibly create sub-tasks all the relevant parties. When all the tasks have been completed, TPM informs the requester accordingly. The procedure is illustrated in the figure 21. Technical Management Processes / TM order intake Te ch ni ca l M an ag em en t R e le v an t st ak eh o ld er Pl at fo rm o rd er in ta ke R el ev an t R& D an d o th er or ga n iz at io ns Request technical support Create Polarion request Order intake meeting, including prioritization Pre-evaluation for the Polarion request Task for Technical management? Yes Evaluation No Polarion task for all relevant parties Perform the task Perform the task Follow-up actions Ready? Yes No Inform requester Approved? Yes Approved? Yes No Inform requester Assigned to responsible team No Figure 21. Order intake procedure. TPM is the owner of standard tools master lists so whenever some of the stakeholders 7, 10, 11, or 15 require a change for the master list according to figure 22, TPM will eval- uate the request. If the change of the tool requires design changes, TPM creates a design request for stakeholder 4. Stakeholder 4 will do the design, release change notice and after that TPM can update standard tools master list. When standard tools master list is up to date, TPM informs relevant stakeholders about the changes and releases the new revision of the list. 56 Technical Management Processes / Standard tools master list Te ch ni ca l P ro du ct M an ag em en t St ak eh ol d er 10 St ak eh ol d er 1 5 St ak eh ol d er 11 St ak eh o ld er 7 St ak eh ol d er 4 Evaluate the new requirement New tool design needed Yes No Requirement for Standard tools list Requirement for Standard tools list Requirement for Standard tools list Requirement for Standard tools list Do desing Request via Polarion CN notice Update Standard tools master list Inform relevant stakeholders about the changes Standard tools list Standard tools list up-to-date Figure 22. Standard tools master list procedure. Product parametrization document contains all the reference values for product test run. The request for updating the document can be received from stakeholder 1, 3, 6, or 16 as illustrated in figure 23. Also, the need for a change can be from TPM themselves. The reason for the update might be for example a product performance upgrade due to au- tomation system or component change. If the change request is clear and doesn’t re- quire any additional clarifications, TPM updates the document as requested. If further clarification is needed, TPM is to arrange meeting with relevant stakeholders to discuss about the issue. When everything is clear regarding the changes in product parametri- zation document, it can be updated as requested. 57 Technical Management Processes / Product operating parameter criteria document Te ch ni ca l P ro du ct M an ag em en t St ak eh ol d er 1 6 St ak eh ol d er 6 St ak eh ol d er 3 St ak eh ol d er 1 Evaluate the request/need Update request for the document Update request for the document Update request for the document Update request for the document Update need for the document Arrange meeting with the relevant stakeholders Meeting needed? No Yes Update product operating parameter criteria document Product operating parameter document Product operating parameter document up-to- date Figure 23. Product operating parameter document procedure. Technical Management Processes / Product presentations Te ch n ic al P ro d u ct M an ag em en t St ak eh ol d er 1 0 R el ev an t st ak eh ol de r Evaluate the request/need Update request for product presentation Update request for product presentation Update need for the document Via Polarion Arrange meeting with the relevant stakeholders Meeting needed? No Yes Update product presentation Product presentation Product presentation up-to- date Figure 24. Product presentations procedure. According to figure 24, TPM receives update requests for product presentations usually from stakeholder 10 that is the owner of the document. However, the update request can be received from any other stakeholder or from TPM themselves. This procedure is similar as product parametrization document procedure, but instead on TPM, stake- holder 10 is the owner of the document, and it is in their response to publish the final product presentation when TPM has updated its technical information. 58 TPM is involved in determining test needs for the products. Test needs have been divided in three different swim lane diagrams: test needs in JV, test needs in production, and TM test needs. If test need is in JV, the procedure is as in the figure 25. Technical Management Processes / Test need in JV Te ch ni ca l Pr od uc t M an ag em en t St ak eh ol d er 7 St ak eh ol d e 6 St ak eh ol d er 1 6 St ak eh ol de r 12 JV PP M R & D M an ag em en t R el ev an t st ak eh ol de r Testing need in JV Purchase order to JV Budget available? No Yes Test arrangement Single test? Yes Via Polarion Perform tests Decision in management level No Part of existing project? No Decision to start project in PPM Yes To project Test requirements Update Purchase order to JV if necessary Create test request Test request to JV Pre-quotation for the test Via E-mail Detailed test plan: Running hours & needed equipment Consulted Via WeBuy Facilities and manpower Update quotation as per real consumption Analyze test results Test arrangement & emission measurement PO Test support Test slot Testing need in JV Testing need in JV Testing need in JV Update documents & inform relevant stakeholders Figure 25. Testing needs in JV procedure. TPM, stakeholder 6, 12, or some other relevant stakeholder can act as an initiator of the process. After TPM have received information about the test need, they will determine test requirements by consulting stakeholders 6 and 16. Stakeholder 12 is consulted by stakeholders 6 and 16. When test requirements are clear, TPM sends test request to JV via e-mail, and they create pre-quotation for the test. After receiving the pre-quotation, TPM will check if there is budget available for the test. If there is no budget available, the decision about the test needs to be done in research and development management level. If budget is available and it is not a single test, stakeholder 7 checks if the test is part of a project. If the test is part of some project, they will take care of the testing. If the test is not part of any project, Product Portfolio Management (PPM) needs to decide whether to start or not to start a project. In case of a single test, TPM creates purchase 59 order (PO) for JV and test request for stakeholders 6 and 16. These stakeholders will then arrange, perform test in cooperation with JV and stakeholder 12. When test results are analysed by stakeholders 6 and 16, TPM updates the necessary documents and informs relevant stakeholders. TPM also updates the PO for JV as per real costs. Technical Management Processes / Test need in Production (excluding order validation) Te ch ni ca l Pr od uc t M an ag e m e n t St ak eh ol d er 1 6 St ak eh ol d er 6 In te rn al bu si ne ss St ak eh ol d er 7 P P M In te rn al M an ag em en t St ak eh ol d er 1 Polarion request received & evaluated Testing need & testing rquirements Via Polarion Create test request Budget available? No Yes Test arrangement Via Polarion Single test? Yes Results Via Polarion Test arrangement Perform tests Perform tests Decision in management level No Part of existing project? No Decision to start project in PPM Yes To project Consulted Consulted Consulted Consulted Consulted Update documents Figure 26. Test needs in production procedure. If test need is in production, the procedure follows the figure 26. Energy business (EB) or Marine Business (MB) determines testing need and requirements by consulting vari- ous stakeholders according the procedure chart above. When everything is clear regard- ing the need and requirements, TPM receives a Polarion task to evaluate. TPM check also in this situation if there is budget available or if it is a single test. If the answer is yes for both questions, TPM creates test requests for stakeholders 6 and 16 via Polarion. 60 They arrange and perform tests and when everything is completed from their side, TPM updates the documents and informs EB/MB about the result. Technical Management Processes / Test needs from TM Te ch ni ca l M an ag em en t St ak eh o ld er 1 6 St ak eh ol d er 6 St ak eh ol d er 7 PP M St ak eh ol d er 1 Testing need & testing rquirements Create test request Test arrangement Via Polarion Via Polarion Test arrangement Perform tests Perform tests Consulted Consulted Consulted Consulted Results receivedSingle test? No Part of existing project? No Decision to start project in PPM Yes Yes To project Update documents & inform relevant stakeholders Analyze test results Figure 27. TM test needs procedure. Technical management test needs process (figure 27) follows pretty much production test need procedure chart. The difference is that here TM is to consult relevant stake- holders about the test requirements and TM needs to analyse test results. Also, when test requirement comes from TM, the budget is already expected to be available when determining test need requirements. TM test needs process chart is shared between both TPM and TQM because both teams are frequently in the initiator role for testing. Need for MTBF (mean time between failure) can be received from many stakeholders inside R&D organization as illustrated in figure 28. When receiving request for MTBF, TQM is to evaluate the request and decide whether there is an actual need for MTBF or not. If there is an actual need for MTBF, TQM arranges a meeting with stakeholder 15 that will find a suitable installation for it. After the suitable installation has been found, 61 stakeholder 15 arranges a meeting with TQM that will create material for customer con- tact. Either TQM or stakeholder 15 will contact the customer and if they accept MTBF, TQM is to inform relevant stakeholders accordingly and continue with regular MTBF fol- low-up. If customer doesn’t accept MTBF, stakeholder 15 need to find another installa- tion to use for this purpose and procedure continues normally. Technical Management processes / MTBF follow-up Te ch nc ia l Q u al it y M an ag em en t R & D St ak eh ol d er 1 5 C us to m er Need for MTBF Evaluate the request Actual need for MTBF? Yes No Arrange meeting with stakeholder 15 Inform relevant stakeholders Find suitable installation Arrange meeting with Technical Quality Management Create material for customer contact Contact customer Contact customer MTBF accepted?No Yes Regular MTBF follow-up Yes Figure 28. MTBF follow-up procedure. Field follow-up need can be received from development project or from any other R&D stakeholder as illustrated in figure 29. Either the requester or TQM creates field follow- up plan and arranges field follow-up kick of meeting. TQM will evaluate if there is a budget for the field follow-up and if yes, they arrange a meeting with stakeholder 15, development project and relevant experts. Stakeholder 15 finds the suitable installation for the follow-up and contacts the customer. If customer accepts the field follow-up plan stakeholder 15 arranges a meeting with TQM and experts before actual customer visits. Finally, stakeholder 15 proceeds with the regular field follow-up. 62 Technical Management processes / Field follow-up Te ch nc ia l Q u al it y M an ag em en t St ak eh ol d er 1 5 D ev el op m en t pr oj ec t / R& D C us to m er Need for field follow-up Arrange meeting with stakeholder 15, Development project and experts Create field follow- up plan Arrange field follow- up kick-off meeting Budget for field follow-up? Yes No Inform stakeholders Find suitable installation Contact customer Field follow-up plan accepted? Yes Regular field follow-up, e.g. 2000h, 4000h, 8000h inspections. Including reporting & informing technical quality management & component experts No Arrange meeting with technical quality management & experts before actual customer visits Create field follow- up plan Arrange field follow- up kick-off meeting Figure 29. Field follow-up procedure. Technical Management processes / Issue register Te ch nc ia l Q u al it y M an ag em en t St ak eh ol d er 1 7 Issue register process Provide technical support No Yes Technical support needed? Issue register process continues Figure 30. Issue register procedure. TQM’s internal issue register procedure chart (figure 30) is simple. TQM is involving in issue register process by providing technical support whenever they receive a request from stakeholder 17. 63 If TQM detects change need in design quality assurance, they request stakeholder 3 to do the work for the components according to figure 31. TQM checks, if design assurance is ready and if not, they request stakeholder 3 to fulfil the assurance. However, each component group should keep their design quality assurance up to date. The initiative for design assurance update can be received also from development project. They will inform TQM about the incomplete design quality assurance and TQM will request stake- holder 3 to update the assurance. Technical Management processes / Design quality assurance Te ch nc ia l Q u al it y M an ag em en t D ev el op m en t pr oj ec t St ak eh ol d er 3 Design quality assurance is done Request component expertise to fulfill the assurance Is quality assurance ready when project has been closed? No Yes Design quality assurance Design asurance work for the components Design assurance ready? YesNo Changes in design quality assurance needed Each component group should keep their design quality assurance up-to- date. Changes in design quality assurance needed Figure 31. Design quality assurance procedure. Part Approval Process (PAP) starts if there is a new supplier, or new or revised component to be released (figure 32). A new or revised component initiative can come from stake- holders 3, or 4. A new supplier initiative can come from supply management or supplier development departments, who own the PAP process. TQM is involving the process to- gether with stakeholder 3, 4 or some other relevant stakeholder e.g., factory. TQM is in response of accepting or declining the component release. If the component release is reclined, the PAP process continues. Otherwise, the component can be released. 64 Technical Management processes / PAP participation T e ch n ci al Q u a lit y M an ag e m e n t St ak eh ol d er 4 St ak eh ol d er 3 St ak eh ol d er 1 8 / St ak eh ol d er 1 9 R el ev an t st ak e h o ld e r New or revised component PAP process Component release accepted? No Yes New or revised component New supplier Participating in PAP process Participating in PAP process Participating in PAP process Participating in PAP process Relevant stakeholder: E.g. Factory Component release Figure 32. PAP participation procedure. 4.1.4 Conclusions about the as-is situation As the result of this chapter, it can be concluded that TM has many internal processes. Especially for TPM, in total 20 procedure charts were modelled to illustrate their main internal processes. For TQM instead, six different procedure charts were illustrated. One of the most significant processes of TQM, Product Improvement Process (PIP), was not illustrated because the process is owned by Product Quality Management. To conclude, TPM had in total 14 internal processes more than TQM. This means that TQM has notably distinct sphere of responsibility whereas TPM seems to be involved in everything. The huge amount of TM’s procedure charts can be explained by their role description which is to have technical end to end responsibility of the products. By having technical end-to-end responsibility of the products, they are required to be involved in various activities to provide technical support that allow other departments to fulfill their tasks. 65 These illustrated procedure charts will be valuable for both TM and their stakeholders. These procedure charts illustrate TM’s responsibilities in task level in all the shared pro- cesses with their stakeholders. Task level procedure charts should tangle current prob- lems relating to confusion about the responsible person for a specific task. If considering bigger picture, these procedure charts will be valuable for the whole company, who’s operations will smoothen, and efficiency will be improved due to clear division of tasks between Technical Management and their stakeholder departments. 4.2 Stakeholder interviews This part of the thesis is as-is analysis’ research section. In this chapter, TM’s stakeholders are interviewed. Interviews are organized to gain cross-functional perspective on TM’s processes. The stakeholder interview feedback will be used to analysing the improve- ment areas of TM. As TM is in response of managing all the technical documentation, product maintaining and product care activities of a set of complex technology products, they have plenty of stakeholders. As already presented in the method chapter, the interview invite was sent all the 16 different departments that are considered as internal key stakeholders of TM. 4.2.1 Defining interview questions One of the goals of this chapter is to understand TM’s internal stakeholders’ activities in today’s company. During past ten years, organizational structure has been changed a lot and it is vital to make sure that TM’s surrounding organization is understood properly before creating improving propositions for TM processes. When the surrounding organ- ization’s activities are clear, it is possible to adapt TM processes to match with them. Another goal is to discover stakeholders’ expectations towards TM and receive possible improvement ideas towards TM’s current processes and way of working. Stakeholders’ opinions are vital when the intention is to improve Technical Management processes to support the surrounding organization as well as possible. 66 All the predefined 16 stakeholders to be interviewed have different kind of connections with TM, because they are separate departments in the case company. Interview ques- tions need to be general enough to suit for all the stakeholders, because they all have different perspective towards TM. Also, the interview answers might be totally different with all the stakeholders and for that reason unstructured interview method was chosen. In semi-structured interviews open-ended answers are allowed and answer categories are not predefined. Open-ended questions ensure, that the interviewee is not encour- aged to answer to some specific question in a specific way. When the interview objectives and interview method are determined, the interview questions can be shaped. The natural approach for the interview is to pose the first ques- tion for the interviewee about their own role in the company. Firstly, it is an excellent icebreaker because it is supposedly the easiest question to reply when interviewees can talk about their own job and their department’s responsibilities in the company. Sec- ondly, the interviewer gains immediately the complete understanding about the stake- holder’s role in the company and their connection with technical management. The first question was determined to be: 1. What is your department’s main function? After interviewees have told everything essential about their own roles in the company, it is time to distract the attention from stakeholder to TM for the rest of the interview. The second question is basically similar as the first one, but instead of talking about their own role in the company, they should talk about TM’s role. A structural difference be- tween the first and the second question is that the second question includes a word “think” representing stakeholder’s own opinions. Stakeholders don’t probably know for a fact, what is TM’s role in the company nowadays, but they can give their personal im- pression about it. There are no wrong answers for the question. Some of the stakehold- ers might know precisely what TM’s role is and some of them might not know at all and that is also valid information to know. The question is formulated vague by purpose, so that the interviewee would give a general description about TM’s role in the company. 67 2. What do you think is Technical Management’s role in the company? After the attention has been focused to TM’s role, it is time to dig a bit deeper. Next, we would like to know what stakeholders expect from technical management in practice in their daily work. At this point we are getting to hear concrete examples about the ex- pected activities that should be considered in the process level. Especially in this ques- tion, varying answers are expected from different stakeholders, because all of them have different demands towards TM. 3. What do you expect from Technical Management in practice? The next question is the most important one for the thesis. It is an open question about stakeholders’ improvement ideas for Technical Management. At this point, the stake- holder can tell in what parts TM should improve their activities and in what parts TM doesn’t fulfil stakeholder’s expectations. Stakeholder’s sentiments about TM’s opera- tions are important and essential when creating to-be proposition for the future pro- cesses. 4. What should be improved in Technical Management side? After the official questions, the fifth questions enable interviewees to talk about any- thing that they still have to say. They might have something more to say for the previous questions or they might have some other comments regarding the subject. Adding a question for free comments, minimizes the risk that something essential remains to be unsaid. 5. Free comments? With the above five questions the interview objectives can be achieved. By stakeholders answering these questions, we can understand Technical Management’s stakeholders’ 68 role in the company, their expectations towards Technical Management, and their im- proving suggestions for TM’s processes. 4.2.2 Interview responses In this chapter, answers for stakeholder interview questions 2-4 will be presented. An- swers for questions 2-4 are significant data for detecting improvement areas in Technical Management processes. Answers for the question 1 will not be presented because it was asked by external researcher to gain the understanding about the stakeholder’s role in the company and their connection with Technical Management. Stakeholder’s role in the company don’t affect the research result, which is to detect improvement areas in Tech- nical Management processes. All answers for all the questions are documented in the interview transcript on the background material. Answers are presented in a form of a table and text. The intention of tables is to illustrate the most common answers for the questions in a decreasing order. This creates a clear vision of the most common subjects that were brought up during the interview sessions. Free text is added to explain the ideas described in the table more detail to create an unambiguous impression about the results. 4.2.2.1 Technical management’s role in the case company For the second question, “What do you think is Technical Management’s role in the com- pany?”, various answers were received. Answers are listed in the below table 2. The num- ber in the right column indicates the number of departments that provided the answer in the left column. The names of the stakeholder departments are not required to be shown in the table, because it is not affecting to analysis process. All the data will be analysed in the subjective level regardless of the respondent’s department. 69 Table 2. Interview results for the second question. What do you think is Technical Management’s role in the company? Number of responses The overall technical responsibility of the products 11 Communicator between different departments 8 Technical support role 5 Owner of product manuals 4 Technical ownership of the products 3 Coordinator role 2 Suggester role because resources are not in TM 2 In total, 11 department’s representatives thought that TM has the overall technical re- sponsibility of the products. Three of the stakeholders described TM to have technical ownership of the products. Two of the interviewees instead, were not sure what does it mean when Technical Management has the technical responsibility or ownership of the products. They thought that TM is rather an important communicator between different businesses. In their opinion, TM doesn’t have the capacity to be in the response of the whole product technically: for example, the responsibility of the specific product com- ponents belongs to stakeholder 3, and the responsibility of product performance be- longs to stakeholder 6. According eight stakeholders, TM has an important communicator role inside of R&D. TM is expected to understand the surrounding organization, what kind of stakeholders they have around them and where to find help in all kinds of situations. TM should be a communicator between R&D, sales, and factory. Because TM has the technical respon- sibility of the products, they shouldn’t be skipped in any kind of communication between these departments so that they are always aware about the activities related to products. Two of the interviewees mentioned that TM has also coordinator role relating to the products. Five different stakeholders mentioned that TM has the technical support role inside pf the case company. Technical Management is expected to support the surrounding or- ganization technically in different technical issues because of their overall technical re- sponsibility of the products. 70 Four of the stakeholders stated that TM is the owner of technical documentation of the products. These documents are installation and performance manuals. As having tech- nical responsibility of the products, TM should be in response of the content in product manuals and own the documents. Two of the stakeholders mentioned that TM seems to have a suggester’s role in the cur- rent organization model. TM don’t have resources so at the end they can’t make any decisions by themselves about what should be done with the products. According to the respondents, this is inconsistent with technical ownership role. If they are technical own- ers of the products but can’t make any decisions relating to the products, what does it mean to have technical ownership of the products? 4.2.2.2 Stakeholders’ expectations towards Technical Management For the third question, “What do you expect from Technical Management in practice?”, various answers were received as well. Many of the answers were similar as for the an- swer two, but they were more precise. Many of the stakeholders described practical ex- amples of their personal expectations towards TM. That is why the list of the answers contains many answers that are received only from one department. Answers are listed in the table 3 on next page. 71 Table 3. Interview results for the third question. What do you expect from Technical Management in practice? Number of responses Communicating between different departments 8 Providing input for installation and performance manuals 8 Keeping product manuals up to date 6 Evaluating NSRs from technical perspective 6 Handling PIP cases 5 Providing technical support 5 Keeping up continuous communication and info sharing 5 Taking care and maintaining portfolio products 3 Understanding customer perspective 3 Prioritizing tasks/projects 2 Having solution-oriented mindset 2 Providing documents and certificates on time 2 Coordinating, testing, and budgeting WPAP components 1 Providing technical support for product deliveries 1 Supporting stakeholder 14 1 Supporting JV 1 Taking care of design releases 1 Taking care of configurator selections 1 Involving in product development projects 1 Providing technical details for certification documents 1 Arranging EIAPP and Type Approval kick-off meetings 1 Quidance for design requests 1 Controlling techncial product information 1 Fast and lean decision making in technical questions 1 Having proper versioning system for the products 1 Expressing functionality level demands for stakeholder 1 1 Keeping up commonality in portfolio products 1 Understanding overall picture in addition to own scope 1 Taking the most out of opportunities 1 As mentioned already in answers to the previous question, eight of the stakeholders ex- pect TM to communicate between different departments. Five of the interviewees men- tioned that TM is expected to keep up continuous communication and info sharing so that the stakeholders are also aware of what is going with the products. Eight of the stakeholders mentioned that TM is expected to provide input for installation and performance manuals. Six of the stakeholders added that TM, as technical owner of the products, is in response of keeping the documentation in order. TM should actively 72 maintain these product documents to be always easily available and up to date for other organizations’ usage. One of the most mentioned expectations towards TM was to provide technical support for various departments and issues. TM is expected to support sales by evaluating NSRs from technical perspective, supporting product deliveries, supporting stakeholder 14, providing guidance for design requests, involving in product development projects, sup- porting JV, and providing technical details for certification documents and product man- uals. TM is expected to perform fast and lean decision making in technical questions to enable other departments to fulfil their tasks. In addition, for above mentioned expectations, TM is expected taking care and maintain- ing portfolio products, design releases, configurator selections, and product information in general by having proper versioning system. TM is expected prioritizing projects and tasks, handling Product Improvement Processes (PIP), providing documents and certifi- cations on time, arranging EIAPP and Type Approval kick-off meetings, expressing func- tionality level demands towards stakeholder 1, keeping up commonality in portfolio products and finally coordinating, testing, and budgeting WPAP components. TM is also expected to have solution-oriented mindset to take the most out of the op- portunities. For taking the most out of opportunities, TM is required to understand the customer perspective and the whole picture outside of their own scope. 4.2.2.3 Improvement ideas for Technical Management The fourth question, “What should be improved in Technical Management side?”, was the most fruitful regarding the number of the answers. Some of the interviewees men- tioned that generally everything is working fine now, and it is hard to find something to improve, but they still suggested some improvement areas where one could always be better at. For some of the interviewees it was easy to enumerate improvement ideas towards TM. All the improvement ideas towards TM are presented in the table 4. 73 Table 4. Interview results for the fourth question. What should be improved in Technical Management side? Number of responses Communication and infosharing 10 Faster actions in general (PIP, NSRs, documents, problem solving, tech- nical support...) 8 Keeping all documents up to date 5 Having a clear role & responsibilities in the organization 5 Having the ownership of product manuals 4 Supporting sales 4 Understanding customer perspective 4 Developing product manuals 3 Maintaining optimistic attitude towards new development ideas 3 Design release process 2 Deeper understanding of product performance 2 Understanding overall picture in addition to own scope 2 Providing precise evaluations for NSRs 1 Providing precise estimates for design requests 1 Having a specific contact person for different situations 1 Resources to be added if that is a reason for not being owner of product documents 1 Handling of versioning and its documentation 1 TM should have technical leadership 1 Having overview for past NSR requests 1 Guiding automation systems and their development 1 Prioritization, order intake, task management 1 Challenging leaders about resoucing 1 Supporting development projects 1 Concentrating in EB product development as much as MB product de- velopment 1 Conducting clear configurator selections 1 Handling transitional stage products better 1 Small size product support would be clearer if stakeholder 12 wasn't act- ing between TM 1 Accuracy in PIP change lists 1 Accuracy in information sent for product manuals 1 Traceability for delivered products 1 Year-of-manufacture-thinking in product developments 1 More innovations from TM side 1 Several times mentioned improvement area of TM is their communication and info shar- ing. Stakeholders hope that TM would inform them spontaneously what is going on with 74 the products. Some of the stakeholders feel that they need to ask several times to re- ceive some updates about product related activities. Some of the stakeholders hope also that product versioning, documentation, and design release process would be improved, because nowadays it is not that easy to track which design changes have been imple- mented in the products around the world. That would also be an improvement for com- munication and info sharing in another level. TM should also have specific contact per- sons to contact in specific cases. One stakeholder brought up that sometimes it is diffi- cult to know who to contact inside TM in specific issues. Nowadays when it is unclear who to contact, they use to contact the manager, who’s workload gets increased. Relating to communication, one stakeholder stated that TM should always be in a com- municator role between them and other organizations. Now the stakeholders’ depart- ment is lacking peaceful working conditions because they receive several requests from several departments. TM would filter the requests before sending them for the stake- holder’s department’s processing and therefore they wouldn’t be as overwhelmed with the workload as now. In addition, one stakeholder stated that small size product support would be clearer if stakeholder 12 weren’t acting between TM and China. Four of the stakeholders were confident that TM should own product manuals that are currently owned by stakeholder 8. This was validated by TM’s technical knowledge and their role having technical responsibility of the products. TM should be in charge of de- veloping and approving these documents because stakeholder 8 doesn’t have the overall technical knowledge of the products. Nowadays, when a mistake is detected in manuals, it is not clear who to contact for support to correct the mistake. One of the stakeholders stated that if TM’s role in product manual process have been decreased due to lack of resources, the right direction would be to increase resources and not to decrease their responsibility in manuals. Some of the stakeholders thought that TM should have clearer role and responsibilities inside R&D. Some of the stakeholders don’t know which are the differences of Technical 75 Management’s and stakeholder 4’s responsibilities. For some of the stakeholders it is not clear what is in response of TM and what is in response of stakeholder 10. One of the stakeholders stated that TM should have technical leadership, because nowadays it is difficult to make decisions. Nowadays, decisions should be made in Product Portfolio Management and Product Lifecycle Management (PPM/PLM) forums, and they don’t usually lead into any results because there are too many departments involved, and the power to decide is in wrong department’s response. Eight stakeholders would hope faster actions from TM in general. The case compnay doesn’t have the cheapest products in the market so the competition must be tackled by the characteristic of quality, reliability, and the response time. Especially in NSR eval- uations and PIP processes the actions should be as fast as possible. Technical Manage- ment should concentrate on seeing the whole picture outside of their own scope. Stake- holders stated that by understanding the customer perspective better, TM might be able prioritize their use of time more wisely. Stakeholders stated as well that TM team mem- bers have always an enormous workload and that is why it is hard for them to act faster. Five different stakeholders said that keeping all documents up to date is not functioning as they wish. Documents and instructions are often outdated regarding automation sys- tem updates. In addition, product parametrization document has not been updated yet, as one stakeholder has wished for a long time ago. Some of the stakeholders would also hope TM to be more accurate in creating PIP change lists and providing information for product manuals. Stakeholders would wish that the technical information received from TM would be correct at once, and there was no need for making any changes afterwards. More precise estimations would also be desired for NSR evaluations and design requests. In NSRs, all the risks, extra costs and time should be evaluated as precise as possible. In design requests, the estimated time is nowadays not as exact as wished. 76 Three different stakeholders stated that TM could be more optimistic towards new de- velopment ideas. New development ideas should be handled with unprejudiced attitude and TM would also challenge leaders more about resourcing. Also, in NSRs, instead of declining the request, TM is expected to estimate the risks and additional costs and time. One of the stakeholders mentioned that TM should concentrate equally MB and EB prod- uct development, when nowadays product development seems to be more concen- trated on MB side. TM is expected to grow their own resources based on the future sights and needs. Also, more innovation ideas would be expected from TM side. Two of the stakeholders mentioned that TM could have deeper understanding about product performance so they could evaluate simple performance related NSRs inde- pendently. Relating to NSRs, one stakeholder hopes that TM would create an overview for all past NSR requests so that they could be easier to track. In addition, stakeholders mentioned that TM could improve in supporting development projects, guiding automation systems and their development, conducting clear configu- rator selections, and handling transitional stage products. Year-of-manufacture-thinking would be hoped by one stakeholder. TM is also expected to improve their prioritization, order intake, and task management. 4.2.3 Interview conclusions After couple of interviews had been conducted, it was clear that questions 2-4 were all answered quite similarly. Some of the interviewees impressed their improvement sug- gestions or their ambitions already during the second or the third question. For that rea- son, answer’s analysis process was more laborious than expected. Interview questions could have been specified better, so that it would have been easier for the interviewees to respond for the questions as desired. However, TM’s stakeholders provided fruitful and various answers for all the interview questions. The goal of the interview sessions was to gain information about stakeholder’s expectations and improvement ideas to- wards TM and the results were surprisingly comprehensive. 77 4.3 Identifying development areas in Technical Management processes This chapter is as-is analysis’ analysing section. In this chapter, stakeholder interview re- sults are analysed and compared to as-is process charts to find out the improvement areas of Technical Management’s processes. 4.3.1 Stakeholder interview analysis For some of the interviewees, TM’s current role in the organization was not clear. Stake- holders were not sure what does it mean when Technical Management has the technical ownership or responsibility of the products. As-is procedure charts that were created in this Thesis, will do their part in clarifying TM’s responsibilities in practise. These proce- dure charts illustrate TM’s activities in a tasks level and stakeholders can easily check all the TM’s responsibilities from them. Process wise, TM’s responsibilities have been clari- fied as detailed as possible. In addition to having procedure charts describing TM’s re- sponsibilities in practise, technical responsibility and ownership role could be defined clearly because it is such an abstract description. TM’s current role has been described also as a “suggester” because they don’t have resources or authority for making deci- sions. To having technical leadership and more responsibility, organization’s sphere of responsibilities should be changed. TM on their own, are not able to effect on their role and responsibilities. Also, TM’s communicator role, technical support role, and coordinator role were illus- trated clearly in created as-is procedure charts. These above-mentioned roles are prac- tical and unambiguous enough to be described in the form of procedure charts only. When TM is illustrated to be the first point of contact in all situations, it is easy for all the stakeholders to follow the procedure and stakeholders’ departments are not over- whelmed by the requests received from other departments than TM. To ensure that every stakeholder know to contact primary TM, TM’s communicator role should be at- 78 tached to general external procedure charts as well. This applies for all the other respon- sibilities and created internal procedure charts as well. All the crated procedure charts should be integrated to the general main procedure charts to increase the business per- formance. One stakeholder stated that it is difficult to know who to contact inside TM for support in specific issues. For that issue, TM has already created a documented specifying con- tact person for different kind of issues. For some reason, all the stakeholders are not aware of this document. This indicates that either stakeholder hasn’t paid attention to the information received from TM, or TM has something to improve in their info sharing. Because 10 different stakeholders mentioned that TM could improve their info sharing, it is one important aspect that should be considered in to-be analysis of TM processes. TM could validate an active procedure for their info sharing to fulfil their stakeholder’s expectations better. In addition to improving communication and info sharing, TM was hoped to have faster actions in general and keeping all the documents and systems up to date (IOS template, configurator, product parametrization document, standard register, and standard tools master list). TM most likely have currently too wide sphere of responsibilities or limited resources to satisfy all the stakeholder’s needs. To-be analysis should be conducted to find out how to organize TM operations more efficiently. In to-be analysis, TM’s role in maintaining documents and systems should be clarified. In as-is procedure charts TM’s role is to contribute changes to product documents and systems whenever they receive a request from the relevant stakeholder or notice the change need by themselves. More consistent and continuous procedure for making sure that documents and systems are always up to date would probably be useful. TM were described surprisingly many times for being the owner of product manuals, having the role of keeping these manuals up to date, and developing them. Some of the stakeholders thought that TM really is the owner of these documents and some of the 79 stakeholders stated their ambitions about the ownership. In the current organization structure, TM is in response of providing inputs and improvements for stakeholder 8 (as any other internal stakeholder in the case company), who is the owner of product man- uals. This responsibility was also illustrated clearly in as-is procedure charts. Organiza- tion’s sphere of responsibilities should be changed if TM’s responsibilities in product manuals wanted to be raised. People in response of the current organization structure, should consider what is the most efficient and convenient way to handle product manual process. TM on their own, are not able to effect on their responsibilities in the process. In addition to being in response of product manuals, false assumptions about TM’s re- sponsibilities were received regarding design releases, and how TM is involved in WPAP component process. Some of the stakeholders thought that TM is in response of design releases and versioning while in the current organization model, stakeholder 4 is in re- sponse of mechanical changes, and stakeholder 1 on automation system updates. Cre- ated as-is procedure charts don’t include design release process and versioning because they are not in TM’s response. Internal procedure charts should be created for stake- holders 1 and 4 (and all the other departments that don’t have them) to underline the responsibilities in design release processes. For WPAP process, TM’s involvement was illustrated in the task level in as-is procedure charts. Sales support was also hoped to be improved by a few stakeholders. This is not exclu- sively in TM’s response, and there is currently NSR process development discussion on- going with relevant parties involving in it. TM team members could of course actively maintain the solution-oriented mindset and keep the customer perspective on mind when supporting sales. TM team members could also try to provide as precise and com- prehensive evaluations for NSR request as possible. In process wise, it was suggested that TM would maintain overview for the past NSR request so that everyone would be aware of what kind of requests there have been for different product types. TM should consider implementing this overview when conducting to-be analysis for their processes. 80 4.3.2 Conclusions Stakeholder interview results justified the fact that internal procedure charts were nec- essary to model. The current role of Technical Management was not clear for most of the stakeholders, because their descriptions about TM’s role and responsibilities were either incorrect or imperfect. When internal processes were not modelled, it is under- standable to not understand TM’s role totally, since they are involved in so many pro- cesses. When stakeholder interview results were analysed, it was clear that the illus- trated as-is procedure charts tangle most of stakeholder’s uncertainties. Still, further ac- tions would be needed for example to give a definition for TM’s role as a technical re- sponsible of products. Also, to-be analysis would be required for determining how TM can optimize their processes to produce the best benefit for the surrounding organiza- tion. The following questions should be analysed in future to-be analysis: • How should TM’s role and responsibilities to be clarified in another way than just in task level procedure charts? • Should TM have more responsibility and authority in their role for being technical owner of products? • How to ensure that TM’s info sharing and communication about the products is systematic? • How to build a consistent and continuous procedure for TM for keeping docu- ments and systems up to date? • Should TM have more responsibility for product manuals as technical owner of products? • Should TM create and maintain an overview for the past NSR requests to improve sales support? • How to optimize TM processes so that the sphere of responsibilities is not too wide comparing to resources? 81 5 Summary and conclusions Due to various organizational changes during the last ten years in the case company, and Technical Management not updating their internal procedure charts accordingly, proce- dure charts illustrating TM’s current processes didn’t exist. This caused confusion in eve- ryday work with different stakeholders when no-one knew exactly which tasks belong to TM and which don’t. The primary purpose of the thesis was to illustrate Technical Man- agement processes as they currently are and survey improvement areas towards Tech- nical Management by interviewing their stakeholders from the surrounding organization. The theoretical part of the thesis introduced the basics of process thinking and process improvement methods Business Process Reengineering and Business Process Manage- ment. In addition, process tools and techniques: as-is to-be comparison, swim lane dia- grams were presented. These tools and methods were utilized in the practical part of the thesis for determining the current state of Technical Management processes. The practical part of the thesis included three major steps. The first step was to illustrate as-is situation of TM processes with swim lane diagrams to document the current state of TM’s processes. The second step was to interview TM’s key stakeholders to gain the understanding about TM’s surrounding organization, and stakeholder’s expectations and improvement ideas towards TM. The third major step was to analyse stakeholder inter- view results and compare them with as-is procedure carts to find out the actual improve- ment areas of TM’s processes. The most significant limitation of this research study was the limited time. The scope of the research was wide when investigating the situation of all Technical Management internal processes. For that reason, the research centred on mapping out the current situation of the processes and detecting their improvement areas on a general level. The most significant bottleneck of this research study was the time-consuming process of turning the qualitative interview results to usable data in the study. In this kind of holistic research study, qualitative interview was the only reasona- ble approach to be chosen, and the interviews provided surprisingly comprehensive data for the research and were worth spending much time on ultimately. 82 The first research question “What is the status of Technical Management processes in the case company?” was addressed thoroughly by illustrating TM’s current processes via swim lane diagrams. By the result of that step, it was clear that TM has an extensive number of internal processes. Because TM has technical end-to-end responsibility of a set of a complex technology products of the case company, they must be involved in various activities concerning these products. By the result of the first step of the practical part of the thesis, in total 20 procedures were illustrated for TPM. For TQM, in total 6 processes were illustrated. The difference between the amount of TPM and TQM inter- nal processes were significant. TPM had in total 14 internal processes more than TQM. This means that TQM has notably distinct sphere of responsibility whereas TPM seems to be involved in everything. The second research question “How could Technical Management processes be im- proved to support the surrounding organization better?” was addressed in the step two and three when interviewing stakeholders about their expectations and improvement ideas towards Technical Management and comparing the results for the illustrated swim lane diagrams. The second step of the practical part of the thesis, stakeholder interviews, justified the fact that internal procedure charts were necessary to model. The current role of Technical Management was not clear for most of the stakeholders, because their descriptions about Technical Management’s role and responsibilities were either incor- rect or imperfect. Interviews were succeeded on the grounds of the comprehensive feedback that were provided for TM. The feedback was the main data for investigating improvement areas in TM current processes. In the end of the interviews, and after comparing the data to TM’s illustrated procedure charts, it was clear that the illustrated procedure charts tangle most of the stakeholder uncertainties. However, further actions would be needed to clarify TM’s role also in an- other way than only in task level procedure charts. In addition, to-be analysis would be required for determining how TM can optimize their processes to produce the best ben- efit for their stakeholders. All the open questions confronted at the end of stakeholder 83 interview analysis should be considered carefully in to-be analysis phase to improve TM’s processes the best possible way. 5.1 Managerial implications This research study was planned to benefit especially Technical Management and the case company by documenting TM’s processes and detecting their improvement areas, and by that increase the business effectiveness and quality. In general, the results of this research study show how much only illustrating the current processes as they are, ben- efit companies. Especially the large companies as the case company, most probably have the same problems about how to ensure that everyone in the company understand pro- cesses the same. In addition, for providing a guideline how processes are set up, manag- ers should actively map and survey the current situation of their processes to ensure that the things are done as effective as possible. If the company don’t implement con- tinuous Business Process Management, it is never too late to begin to do so. Only by documenting the current processes in the form of swim-lane diagrams, one can spot the bottlenecks of the processes even if the person has known the process by heart for years. Illustrating the process in the form of the swim lane diagram is also an effective tool to be used in communication with various stakeholders. Right away after illustrating Tech- nical Management processes, they have been in active use in TM when communicating with stakeholders and own team members. On the other hand, this research study is an excellent example of how much valuable data can one qualitative research provide for its executor. Even if the situation of a com- pany or a team seems quite stable, there might be lots of things to improve. Qualitative research provides a holistic approach towards the research issue, and it is an excellent way to start to map the processes and their improvement areas. Also in this research study, the results were much more comprehensive than expected and they can lead to various further studies about the processes in question. 84 5.2 Further research The scope of this thesis was limited to conducting as-is analysis for TM’s processes. A future study would be needed for conducting to-be analysis for TM’s processes to imple- ment the detected improvement areas in them. In to-be analysis one should analyse TM’s processes dynamically and evaluate the most critical processes for them. Critical processes are creating the most value for their internal stakeholders or external custom- ers. After determining the critical processes, to-be illustrations should be drafted with- out any constraints such as funds and human resources. The next step of the analysis could be either to modify to-be procedures according to the current constraints of the business or eliminating steps of the process that don’t add any value for the internal or external customers. By conducting to-be analysis, TM would utilize the effort of as-is analysis and get the most out of their operations by improving their processes in practise. In addition to con- ducting to-be analysis, all TM’s internal sub-procedure charts should be attached to the organizations main processes as well. That would ensure that TM’s role in the processes would be unambiguous for everyone regardless of which level’s procedure chart the per- son is looking at. In addition, Technical Management should implement Business Process Management lifecycle in their daily activities to be able to ensure the continuous process improvement and by that keep up their business performance and effectiveness. 85 References Antony, J., Snee, R. & Hoerl, R. (2017) Lean Six Sigma: yesterday, today and tomorrow. International Journal of Quality & Reliability Management. Vol. 34 Issue: 7, pp.1073-1093 https://doi.org/10.1108/IJQRM-03-2016-0035 Bakar, N. W. A., Musa, S. & Mohamad, A. H. (2020). A Mini Comparative Study of Require- ments Modelling Diagrams towards Swimlane: Evidence of Enterprise Resource Planning System. Journal of Physics: Conference Series 1529 052054. IOP Publish- ing. http://dx.doi.org/10.1088/1742-6596/1529/5/052054 Baškarada, S. (2014, 19th of October). Qualitative Case Study Guidelines. The Qualitative Report. Volume 19, p 1–25 Berman, P. K. (2014). Successful Business Process Management - What You Need to Know to Get Results. AMACOM. American Management Association. Brodsky, A. E., Buckingham, S. L., Scheibler, J. E. & Mannarini, T. (2016). Introduction to Qualitative Approaches. Handbook of methodological approaches to community- based research. Qualitative, Quantitative, and Mixed Methods. Section One: Qualitative Approaches. Oxford University Press Cho, s. (2022). How to analyze open-ended survey responses. Curiosity at Work. Re- trieved 2022-2-17 from https://www.surveymonkey.com/curiosity/open-re- sponse-question-types/ Clarke, V., Braun, V. & Hayfield, N. (2015) Thematic analysis. Qualitative psychology. A practical guide to research methods. 3rd edition. Pages 222–248. SAGE. DiCiccio-Bloom, B. & Crabtree, B. F. (2006, 28th of March). The qualitative research inter- view. Medical education. Volume 40, Issue 4. pp 314–321. Wiley Online Library. https://doi.org/10.1111/j.1365-2929.2006.02418.x Fernando, J. (2021, 19th of August) Stakeholder. Investopedia Retrieved 2021-10-18 from https://www.investopedia.com/terms/s/stakeholder.asp Flores, L., G., Zheng, W., Rau, D. & Thomas, C., H. (2012, 2nd of March) Organizational Learning: Subprocess Identification, Construct Validation, and an Empirical Test of Cultural Antecedents. Journal of Management Vol 38 No. 2 pp 640–667 https://doi.org/10.1177/0149206310384631 86 Guha, S., Kettinger, W. J. & Teng, J. T. C. (2007, 6th of February). Business Process reengi- neering: building a comprehensive methodology. Information Systems Manage- ment Volume 10 pp 13–22 Taylor & Francis. https://doi- org.proxy.uwasa.fi/10.1080/10580539308906939 Hammer, M. (1990). Reengineering Work: Don’t Automate, Obliterate. Harvard Business Review. Available: https://hbr.org/1990/07/reengineering-work-dont-automate- obliterate Harmon, P. (2019). Business Process Change: A Business Process Management Guide for Managers and Process Professionals (4th edition) Morgan Kaufmann Publishers Helo, P., Tuomi, V., Kantola, J. & Sivula, A. (2019). Quick guide for Industrial Management thesis works. Universy of Vaasa Reports, 14. http://urn.fi/URN:ISBN:978-952- 476-871-9 Hermkens, F. (2007). BPM let it flow. Eindhoven University of Technology. Department of Industrial Engineering & Innovation Sciences Hupje, E. (2021). Simple guide to MTBF – What it is and when to use it. Road to reliability. Retrieved 2022-2-16 from https://roadtoreliability.com/mtbf-mean-time-be- tween-failure/ Jeyaraj, A., Sauter, V. L. (2014). Validation of business process models using swimlane diagrams. Journal of Information Technology Management. ISSN #1042-1319. A Publication of the Association of Management Krasich, M. (2009, 12th of May). How to Estimate and Use MTTF/MTBF Would the Real MTBF Please Stand Up? IEEE Xplore. https://doi.org/10.1109/RAMS.2009.4914702 Lamghari, Z., Radgui, M., Saidi, R. & Rahmani, M. D. (2018, 7th of May). A set of indicators for BPM life cycle improvement. IEEE Xplore. https://doi.org/10.1109/ISACV.2018.8354057 Lehtonen, K. (2021) Technical Management, Small and Medium Bore (TMSMB). Power Point. Retreived 2021-09-28 Lucidchart. (2022). The basics of documenting and analyzing your as-is process. Re- trieved 2022-1-7 from https://www.lucidchart.com/blog/as-is-process-analysis 87 Lucidchart. (2022a). What is a Swimlane Diagram. Retrieved 2021-12-12 from https://www.lucidchart.com/pages/tutorial/swimlane-diagram Lutkevich, B. (2022). business process management (BPM). TechTarget. Retrieved: 2022- 2-25 from https://www.techtarget.com/searchcio/definition/business-process- management Mast, de J., Does, R.J.M.M., Koning, de H., Lameijer, B.A. & Lokkerbol, J. (January 2022) Operational Excellence with Lean Six Sigma. Handbook for Implementing Process Improvement with Lean Six Sigma. Van Haren Publishing. ISBN: 978-94-018-0829- 3 Microsoft. (2021). Create a basic flowchart in Visio. Retrieved 2021-10-18 from https://support.microsoft.com/en-us/office/create-a-basic-flowchart-in-visio- e207d975-4a51-4bfa-a356-eeec314bd276 Nikkola, J. (1995). Uusi teollinen Suomi – Muutosopaskirja. Metalliteollisuuden Keskusliitto, MET. Tammer-Paino Oy. Nowell, L. S., Norris, J. M., White, D. E. & Moules, N. J. (2017). Thematic Analysis: Striving to Meet the Trustworthiness Criteria. Internal Journal of Qualitative Methods. Volume 16: 1–13. SAGE. https://doi.org/10.1177/1609406917733847 Okrent, M., D. & Vokurka R., J. (2004). Process mapping in successful ERP implementa- tions. Industrial Management & Data Systems. Volume 104, Number 8, pp 637- 643 https://doi.org/10.1108/02635570410561618 O’Neill, P. & Sohal, A. S. (1999, September). Business Process Reengineering A review of recent literature. Technovation. Volume 19, Issue 9, Pages 571–581 https://doi.org/10.1016/S0166-4972(99)00059-0 Popping, R. (2015, 30th of September) Analyzing Open-ended Questions by Means of Text Analysis Procedures. Bulletin de Me´thodologie Sociologique. SAGE journals. Vol 128 23–39. https://doi-org.proxy.uwasa.fi/10.1177/0759106315597389 Reijers, H. A. (2021, April). Business Process Management: The evolution of a discipline. Computers in Industry. Volume 126. https://doi.org/10.1016/j.com- pind.2021.103404 88 Riger, S. & Sigurvinsdottir, R. (2016). Thematic analysis. Handbook of methodological ap- proaches to community-based research. Qualitative, Quantitative, and Mixed Methods. Section One: Qualitative Approaches. pp 33–42 Oxford University Press Roberts, L. (1994, 1st of March). Process Reengineering: The Key to Achieving Break- through Success. Roser, C. (2015). All About Swim Lane Diagrams. AllAboutLean. Organize your Industry! Retrieved 2021-10-15 from https://www.allaboutlean.com/swim-lane-diagrams/ Salomäki, R. (1999). Suorituskykyiset prosessit – Hyödynnä SPC. Metalliteollisuuden Keskusliitto MET. ISBN 951-817-707-4 Schmeer, K. (1999). Stakeholder Analysis Guidelines. Section 2. Schulte, P. (10th of December 2020). How systems thinking can help us develop lasting solutions to our deepest challenges. Kindling. Retrieved 2022-2-25 from https://kindling.xyz/change-101/systems-thinking/ Silverman, D. (2021). Introducing Qualitative Research. QUALITATIVE RESEARCH. Part 1. pp 1–35. SAGE. Smith, M. L. & Erwin, J. (2005). Role & Responsibility Charting (RACI). Project Management Forum. Tritonia LibGuides. (2020). Vaasan yliopiston kirjoitusohjeet: Lähteet ja viitteidenhallinta. Retrieved 2022-2-17 from https://uva.libguides.com/kirjoitusohjeet/lahteet- viitteidenhallinta