Tuulia Haiko

Improving Invoicing and Reporting of Complex Service Agreement Services Using New Maintenance Software

Helsinki Metropolia University of Applied Sciences

Master’s Degree

Industrial Management

Master’s Thesis

3 May 2020

Preface

After handing over this thesis, I have no old ground to land on. The world around me has

seen enormous crisis and a change during my thesis process. When starting the project

in late November 2019, I had only distant feeling of universal pressure swelling invisibly

for too long but zero idea how the landscape and norms all over the world would turn

upside down overnight.

Still I have no fear of what is to come. This is thanks to my carefully picked and well

equipped backpack that carries my selected belongings – love, values and what I have

learned. The latest investment on my backpack is these studies. The Master’s title or

certificate never motivated me but the path filled with the best knowledge, travelled to-

gether with other curious fellas and most importantly lead by this amazing crew of pro-

fessors called “Muppets” - the top notch life and business experts – was irresistible.

Given this chance to study further it would have been criminal not to take it.

First I want to thank Algol Technics for supporting the journey on the side of my daily

work. Especially I want to thank Harry Broman and Sauli Mäntylä for the opportunity to

learn and develop. Thank you all that shared your knowledge with me in the interviews.

I want to thank the whole Metropolia Master of Industrial Engineering crew and the en-

tourage for this unforgettable journey that taught me more than I ever imagined. I want

to thank my supervisor Dr. Thomas Rohweder for not supervising well which he indeed

did but teaching me about life and my own roots.

I want to thank my mum and my family always inspiring me to keep going ahead in my

life. I want to thank my wonderful partner Teemu for patience, support and all the food

you gratuitously brought me when I had no sense of time or ears. Most of all I want to

thank the most precious jewel, my son Samuel. No one has taught me more about myself

than you have.

They say that feelings teach a human being better than any methods. These studies I

have felt deep in positive but touching, even savage ways. I shall carry these lectures

and people in my backpack forever. Thank you.

Tuulia Haiko

In Helsinki

May 3rd 2020

Abstract

Author Title Number of Pages Date

Tuulia Haiko Improving Invoicing and Reporting of Complex Service Agree-ment Services Using New Maintenance Software 50 pages + 3 appendices 3 May 2020

Degree Master of Engineering

Degree Programme Industrial Management

Instructors

Dr. Thomas Rohweder, Principal Lecturer Harry Broman, Business Unit Director

Even the most traditional industries are in the middle of new customer demands and industry standards. The era of digital services and continuous availability is here. The case company of this study has recently implemented a new maintenance software. It enables on time ser-vices in digital environment. The improvement of the new mobile digital environment is continuous and this study con-centrates on improving the invoicing and reporting process and data of the complex service agreement services. As an essential part of this study an implementation plan for the im-provements is also proposed. The study is conducted as an applied action research which supports the strong connection and cooperation with the case organization. The conceptual framework and the proposal are target oriented and the goal was to find tailored solution for certain business problem. The key stakeholders of the case company have been involved in the current state analysis and creating the solution. Qualitative methods such interviews and workshops were used as the primary data collection method. There isn’t a one comprehensive solution to the business problem but several small ones that lead the case organization towards its targets of digital maintenance services. This re-port suggests improvements to finetune the process and the platform. These improvements retell the natural ways of the case organization but focus strongly on generating better in-voicing and reporting data in more efficient ways. The case organization has already begun to implement the results of this study to the oper-ations. It is recommended to keep up with the good work and use the knowledge collected into this report to improve further.

Keywords industrial maintenance, service, software development, soft-ware implementation, implementation plan, process develop-ment, invoicing and reporting

List of Figures

Figure 1. Research design of the study. ........................................................................ 5

Figure 2. Architectural based software development process (Koskimies & Mikkonen;

2005) .......................................................................................................................... 10

Figure 3. Waterfall model as the system development life cycle model ....................... 11

Figure 4. UML diagram types. (Fowler 2004). ............................................................. 12

Figure 5. Conceptual framework of the thesis ............................................................. 17

Figure 6. From work order to invoicing information flow – illustration of the process in the

new maintenance system. .......................................................................................... 23

Figure 7. The information pours into two separate streams and comparison is done

manually ..................................................................................................................... 24

Figure 8. The strengths and weaknesses of the case company in recent implementation

of new software. ......................................................................................................... 25

Figure 9. Proposal building focuses on beige development cycle that does require

architectural changes. ................................................................................................. 28

Figure 10. The short and long term recommendations to improve current invoicing and

report-ing process and the initial implementation plan. ............................................... 33

Figure 11. UML class diagram of WO and SA relations. ............................................. 37

Figure 12. An UML sequence drawing proposal on recommended technical execution of

hour card and service appointment information flow at the new maintenance software.

................................................................................................................................... 38

Figure 13. Recommendations to improve invoicing and reporting of separately billable

work orders in urgency order. ..................................................................................... 40

Figure 14. An action plan for the urgent process changes that can be applied right away.

................................................................................................................................... 41

Figure 15. Implementation is a strong and needed companion for the recommendations.

................................................................................................................................... 41

Contents

Preface

Abstract

List of figures

1 Introduction 1

1.1 Business Context 1

1.2 Business Challenge, Objective and Outcome 2

1.3 Scope and Structure 3

2 Project Plan 4

2.1 Research Approach 4

2.2 Research Design 5

2.3 Data Collection and Analysis 6

3 Existing Knowledge and Framework 8

3.1 IT System Development 8

3.1.1 System Development in Service Business 8

3.1.2 Architectural Design 9

3.1.3 Architectural Based Software Development Process 9

3.1.4 System Development Life Cycle Models 10

3.1.5 UML Unified Modeling Language 12

3.2 Implementation of IT System 13

3.2.1 Success and Failure Factors in IT Implementation Projects 13

3.2.2 The Scale of the Implementation 15

3.3 Conceptual Framework of the Thesis 16

4 Current State Analysis 19

4.1 Overview of the Current State Analysis Stage 19

4.1.1 Data 1 Interviews 19

4.1.2 Data 1 Documents 21

4.2 Technological and Practical Challenges in the “Reporting and Invoicing” Module of the New Maintenance Software 22

4.3 A Recent Implementation in Case Company 25

4.3.1 Strengths of a Recent Implementation in Case Company 26

4.3.2 Weaknesses of a Recent Implementation in Case Company 26

4.4 Key Findings from the Current State Analysis (Data Collection 1) 27

5 Building Proposal on Improving Invoicing and Reporting of the Complex Service Agreement Services for the Case Company 29

5.1 Overview of the Proposal Building Stage 29

5.2 Findings of Data Collection 2 29

5.2.1 Proposal of Technical and Operational Changes 31

5.2.2 Implementation Plan 32

5.3 The Initial Proposal on Improving Invoicing and Reporting of the Complex Service Agreement Services 32

6 Validation of the Proposal 34

6.1 Overview of the Validation Stage 34

6.2 Findings of Data Collection 3 35

6.3 Developments to the Proposal Based on Findings of Data Collection 3 35

6.3.1 Further Improvements Regarding the Process and Operational Side 36

6.3.2 More Detailed Technical Descriptions on Recommended Changes 36

6.3.3 Further Improvements to the Implementation Plan 39

6.4 Final Proposal 39

7 Conclusions 42

7.1 Executive Summary 42

7.2 Next Steps and Recommendations towards Implementation 43

7.3 Thesis Evaluation 44

7.3.1 Validity 45

7.3.2 Reliability 45

7.3.3 Relevance 46

7.3.4 Logic 47

7.4 Closing Words 47

References 49

Appendices

Appendix 1. A record of Data

Appendix 2. A note of a stakeholder interview, an example of Data 1 collection

Appendix 3. Work shop note, an example of Data 2 collection

1

1 Introduction

Industrial maintenance services are digitalizing fast throughout the industry. Customer

demands for added services such as IOT and cost cut pressures drive companies to

develop their operations and information flow. Just a while ago digitalized service was a

business advantage and good way to differentiate from competitors. Now it seems that

competition has tightened and a real time interface for services is becoming a must to

succeed in business.

In this thesis a case company has implemented a new maintenance service software but

it still requires further development. Basic usage and customer interface are working

effectively at the moment but reporting and invoicing regarding more complicated service

agreements are still done manually.

In order to have full benefit from the new software, this thesis focuses on proposing rec-

ommendations on how to improve invoicing. It is also hard to expand into new big cus-

tomerships if the model for complex on site services do not run smoothly.

1.1 Business Context

The case company Algol Technics is a Finnish family owned company specialized in a

wide range of industrial product solutions. Algol Technics is part of Algol Group which

consists of five daughter companies in the field of chemical supply, technical products

and services, health care and diagnostics products and services.

Algol Technics engineers, supplies and executes product deliveries such as cranes, con-

veyors, robotic lines and cells and warehousing systems. Customers are mainly manu-

facturing companies operating in Finland.

The service business unit offers maintenance for previously mentioned and other indus-

trial equipment. Service unit has 6 local workshops around Finland and it employs more

than 200 maintenance employees around Finland working in both field and on site cus-

tomerships. Most of the work is based on service agreements made with customers. A

basic field service agreement usually consists of yearly inspections and ad hoc repairs.

On site agreements are more complex including usually 24/7 availability of the case com-

pany’s maintenance personnel and KPIs such as equipment up time.

2

The service organization is currently implementing a new maintenance software which

allows real time monitoring of service appointments for both internal and external cus-

tomers. This thesis concentrates on these complex on site service agreements and how

they are transferred into the new maintenance software.

1.2 Business Challenge, Objective and Outcome

Some parts of the case company’s new maintenance software are still on a very robust

level. Basic work orders run through smoothly into reporting and invoices, but when a

more complex service agreement is applied, the system does not support exact invoicing

and reporting or the organization doesn’t know yet how to utilize all features.

A complex service agreement consists of an agreed amount of workforce working in

customer premises with agreed shift arrangement. In addition to what the basic agree-

ment includes, the case company does extra jobs when agreed. These added service

jobs are invoiced separately according to the existing price list and are very important

upsell business for the case company.

The business problem is that currently all working hours fall into the same pool and the

system does not know which hours belong to the agreement and which should be in-

voiced and separately reported to the customer. Separating the agreement content from

extra invoicing is now done manually and is often inaccurate. There is a high risk of not

invoicing. No value added is created for the customer in the form of specific reporting on

what extra maintenance or safety jobs have been done to improve their production effi-

ciency or safety.

The objective of this thesis is to propose recommendations to improve complex

service agreement invoicing and reporting and an implementation plan for the im-

provements.

The outcome is a list of recommendations to improve invoicing and reporting for complex

service agreement services and an implementation plan.

3

1.3 Scope and Structure

The study consists of 7 chapters: the introduction, project plan, literature review, three

data stages (current state analysis, building the initial proposal and validating the pro-

posal) and finally the conclusions.

The study was started by creating a proper project plan in chapter 2 in order to fulfill the

promised objective and deliver the outcome – recommendations to improve complex

service agreement invoicing and reporting and an implementation. The project plan in-

cludes methods used in this study and visualization how the study was conducted. The

Data Analysis explains the schedule for the three Data phases.

The literature review explores the existing knowledge over the study areas, software

development and good implementation practices. The purpose of this review was to ex-

tract a targeted conceptual framework for the case company. This framework is pre-

sented in the end of chapter three utilized in the next phases and especially as a foun-

dation of the initial proposal.

The next stage of the study was conduct a current state analysis which finds out how the

invoicing and reporting process is handled at that moment in the new maintenance soft-

ware. A recent implementation case was also researched to find out the typical strengths

and weaknesses of the case company in similar cases.

The study was continued building the initial proposal together with the case company

key stakeholders. The proposal grounds on the conceptual framework presented at the

end of chapter three and seizes the findings of the current state analysis.

The initial proposal was validated by a board of the case company senior decision mak-

ers who evaluated the business problem against the proposal. The changes suggested

by the validation board were included to the initial proposal to constitute the final proposal

of the study presented in the end of chapter 6.

The thesis is ended with conclusions chapter drawing together the whole study. The

conclusions chapters includes the executive summary, an action plan for the case com-

pany, an evaluation of the thesis and closing words.

4

2 Project Plan

This section describes the project plan of the thesis: the chosen research approach, re-

search design, data plan and analysis methods used. The research design shows visu-

ally how the study was carried out. The data plan table explains in detail the content and

sources of data collection.

2.1 Research Approach

This sub section explains which type of study research was conducted and the main

methods used. According to Sanders et al (2009):

“…all business and management research projects can be placed on a

continuum according to their purpose and context.”

This study aims to find a tailored solution for the case company rather than discussing

universal principles or typical results on a general problem. Therefore the basic research

methods typically used to purely theoretically understand and expand knowledge are not

suitable. Instead applied research focuses on finding business related solutions that gain

“direct and immediate relevance to managers” and the logic of the study and the results

are easy to understand and implement in the case company (Sanders et al 2009). The

tight time frame also supports choosing the applied research approach. The study was

started in November 2019 and finished by May 2020.

The research approach can further be specified as applied action research that com-

bines relevant principle of action research to applied research which is continuous im-

provement through “plan, do, check, and act – cycle” dealing with organizational issues

(Kananen 2013). Noteworthy is that the iteration rounds typical to action research are

only few in this study but still existing. The final product is created by evaluating and

refining the initial product.

Action research is also suitable for few other reasons. The complete study is made in

tight cooperation with the case company and the managers are involved in the change

process. The study also uses a decent variety of data collection methods. (Coughlan &

Coghlan 2002).

This study utilizes qualitative methods and the main research techniques are interviews

and workshops. In addition to interviews relevant documentation such instructions, sys-

tem data and case customer contract content from relevant parts are used.

5

2.2 Research Design

This study consisted of four stages seen in figure 1 below. The literature part came first

to perceive principles and good practices of software development and good software

implementation practices. The literature part concentrates on establishing conceptual

framework for software development and implementation rather than big scale software

projects.

Figure 1. Research design of the study.

As seen in figure 1, the stage two of the study was the current state analysis which was

also the first data stage of the thesis. Data 1 collection targeted to give overall process

description of the maintenance software and more detailed description of the invoicing

and reporting module that required further improvement. After finding the current general

process, it’s strengths and weaknesses were identified.

In order to have better chances to succeed in implementing proposed developments, a

recent implementation of same type of software was also analyzed.

6

Together with the conceptual framework and analysis of the current state of the new

maintenance system and recent implementation case, study continued in stage 3 by de-

veloping the suggestions and an implementation plan. As a data 2 stage it includes

stakeholder interviews and workshops described later in table 1.

Finally, the proposed blueprint and implementation plan was validated by the decision

makers of the case company. With the feedback (data stage 3 in table 1) of the decision

makers the final proposal was put together. The final proposal is the outcome of the

thesis and figure 1 illustrates the way how it was generated.

2.3 Data Collection and Analysis

Data collected for this study is from various sources. Table 1 shows the data collection

methods and sources in more detail with the timetable and outcomes of each stage. As

mentioned in the previous section, the literature was explored already before entering

the data stages.

Table 1. Data collection in detail

7

Interviews were the primary method for data collection but as seen in table 1, in stage 1

also other sources such current invoicing and reporting data, agreements and other re-

lated documents were used. The interviews were conducted as semi-structured, pre-

scheduled one to one interviews in those locations where the stakeholders operate. Vis-

iting the customer and technician in those premises they operate in gives information

and insight on how the software is actually used and what the elements it is used for are

(machinery etc).

The interviewees were chosen so that the whole process and those involved in develop-

ing the new software are covered. The Business Unit Director is responsible for the whole

software project and the project manager leads the development. The service provider

(for software) was also interviewed to get the best understanding of the current state,

possibilities and expected limitations. Technicians are the everyday users of this mainte-

nance software and therefore it is mandatory to have 1 to 1 interviews with them. The

target is to describe the current process as it is. After mapping the process the same

stakeholders were interviewed to identify the strengths and weaknesses of the process.

Before entering the first data stage, the study continues in next chapter with reviewing

existing knowledge over the study area and building a conceptual framework based on

the existing knowledge and good practices.

8

3 Existing Knowledge and Framework

This section discusses the existing knowledge in essential subjects around this study.

The core of the conceptual framework is information system development which en-

ables further technical development of the invoicing and reporting software module at

the proposal building phase of this study. The second part of proposal consists of the

implementation plan for such system module.

The conceptual framework is built of literature review about software architecture, sys-

tem development life cycle models, IT project management and IT implementation man-

agement. To connect pure software development into the environment the case com-

pany operates in, in literature review there is a link to service business.

3.1 IT System Development

Before creating any new software ideas the requirements of the system needs to be

known well. In order to find out what needs to be developed, the current system, here

legacy, needs to be investigated closely. What are the tools and interfaces that the or-

ganization is using at the moment? What are the actual things that do not work in the

current system?

The following sub sections study the technical elements of IT system development.

3.1.1 System Development in Service Business

Service businesses are traditionally developed from the customer experience point of

view. According to Miettinen (2017) in service businesses as important as customer ex-

perience is employee experience. It is described as another side of the coin. Bryan Solis

(2017) describes the traditional experience as “the silent films of yesterday”.

The systematic usability of a software has been strong for some time but recently also

user experience called as UX has gained importance. Employees use more and more of

their working time operating with different softwares. The consumer services offer great

experiences and the same demands have arrived to b2b side.

9

The only way to find out what is the best experience for the user is to involve the actual

users in the development process. The earlier the users are involved in the design phase,

the better results are. If different ERP development projects are compared, those who

involved users in the actual design phase, succeeded better than those who didn’t (Scott

& Vessey 2002). Solving for experience takes time, empathy and vision (Solis 2017).

3.1.2 Architectural Design

System architecture gives high abstract level view for the system or software and ena-

bles even more complex system analysis. System architecture has risen to it’s own field

due it’s possibility to define some common standards for development and documenta-

tion. Architecture can reveal system vulnerabilities and problems already in early stage

when changing the system is still cheap. In architectural stage of system development

project moves from defining the issues towards solving them. IEEE 2000 is a standard

regarding system architecture and it defines architecture as a organization inside system

which includes the information about the parts of the system, their relations with each

other and with environment and the principals that control system development and evo-

lution. (Koskimies & Mikkonen; 2005).

Architecture defines the limits so that developers do not use excessive and negative

creativity developing the system. It is basically the law book of the system and includes

those parts that remain stable in further stages of development, usage and maintenance.

System architecture must be properly documented and without documentation it basi-

cally does not exist. Poorly documented architecture will eventually lead to eroding sys-

tem (Clements et al. 2003). The architecture is the input of the development phase.

3.1.3 Architectural Based Software Development Process

At architectural based software development process (see figure 2 below), the design

and analysis of architecture are the development fundamentals. The architecture is built

first by defining the leading demands of the new system. Both functional and qualitative

demands define the initial design. Qualities like flexibility, formability, effectivity and

memory demands often are contradictory factors and the architecture must either bal-

ance or compromise all necessary “*ilities”.

10

Figure 2. Architectural based software development process (Koskimies & Mikkonen; 2005)

Only when the basic architecture is ready the detailed design, execution and testing be-

gins. First all primary classified functionalities are developed through the cycle and even-

tually also secondary functionalities. Usually the secondary functionalities do not effect

to the basic architecture any more.

3.1.4 System Development Life Cycle Models

Choosing a life cycle model, gives system development project a framework to manage

and structure the development project.

The waterfall model was introduced in 1970’s and it gives basic structure best suitable

for small and well defined system development projects. The basic idea in waterfall

model is that only after passing every phase quality assurance inspection, project can

move to the next stage (Weaver; 2004, Stenberg;2006).

11

Figure 3. Waterfall model as the system development life cycle model

The stages vary depending on the project itself but principle is always the same. In real

life pure model where each step is fulfilled and quality checked before moving to the next

stage can cause unnecessary delays and costs in project, so reality often is that the

stages overlap with each other. In example project in figure 3 there are six stages. In the

project initiation the need for the new system is decided. In the second stage is analyzed

what the current problems are and what the new system could do. After that comes sys-

tem design stage where decisions are made on how the system will work and look. Only

after previous stages are qualified, the actual construction work starts. It is followed by

the implementation and finally the maintenance of the software.

Spiral Model

When requirements are not well known beforehand, spiral model provides iterative de-

velopment framework. There are repeated and developed further with prototypes until

stable requirements and user acceptance. After each round the prototype gets nearer to

its final form. Spiral model suits for both entire system development or just piece of it but

projects with unclear or emerging requirements can benefit using spiral model. But when

project is straightforward, there is no excuse to use spiral model instead of systematic

production like waterfall method.

Incremental system development model (Weaver 2004) works best when require-

ments are clear and relatively stable. After first prototype phase often needed to com-

ment again on the previous stage, requirements analysis and return refined analysis into

next increment.

12

3.1.5 UML Unified Modeling Language

UML is a series of graphical notations to support creating and developing a software.

UML is a relatively open graphical modeling language. It is a good way to sketch ideas

of a software and communicate aspects of the system. Purposes to use UML are:

Design

Code Generation

Documentation

Reverse engineering

Forward engineering means making the design for the software and the drawing is made

before writing the actual code. In reverse engineering the drawing is created afterwards

to describe an existing code. The aim of forward engineering via UML is to discuss ideas

with the developer team members. Following strict rules in sketching isn’t that important.

The emphasis is on the communication rather than on a puristic specification of a pro-

gram. (Fowler 2004).

There are 14 different types of a diagram seen in figure 4 below. Two main diagram types

are structure diagrams and behavior diagrams.

UML Diagram

Structure Diagram

Behaviour Diagram

Class DiagramCompound Diagrams

Object diagram

Activity Diagram

Use Case Diagram

State Machine Diagrams

Interaction Diagram

Interaction overview

Secuence Diagram

Communication Diagrams

Timing Diagrams

Deployment Diagram

Composite Structure Diagram

Profile Diagram Package Diagram

Figure 4. UML diagram types. (Fowler 2004).

13

Structure diagrams on the left of the figure 4 are very static and they describe the differ-

ent components of the system and their relations to each other.

Behavior diagrams on the right side describe what is happening during the runtime of

the program. They show the program logic and reactions to stimulus. The sub group of

behavioral diagrams are the Interaction diagrams that show the relationships between

the components where other behavioral diagrams show the actions within the compo-

nents. (Fowler 2004).

3.2 Implementation of IT System

Developing new software isn’t only a technical performance. Even the implementation of

a best in class software can fail if the project management isn’t professional. According

to Stenberg (2006) clear and well defined targets are key factors in project success.

Blurry and unclear project is most likely to fail. As important is the after care of the project.

Therefore the best practices of an implementation of an IT system is highlighted in this

study and the following sub sections concentrate on the managerial side of the system

development called implementation.

3.2.1 Success and Failure Factors in IT Implementation Projects

This sub section investigates key success and failure factors in IT projects implementa-

tions in general.

Automating a process is not only creating a new software but it includes renewing oper-

ations, way of work and a lot of training to the personnel (Kettunen, 2002). According to

almost every literature source, most of the issues are not technical but managerial and

business problems. Logic of the business can conflict with the logic of the system and if

such project goes through, implementation is to fail automatically (Davenport; 1998).

Davenport also states that the relation between the organization and its systems:

“If a company's systems are fragmented, its business is fragmented.”

Scott & Vessey (2002) studied two companies in same business implementing similar

software approximately at the same time. Another one succeeded and the other one

14

failed at the project. Scott & Vessey (2002) found positive and negative factors seen in

table 2 from their case companies while implementing new software.

Table 2. Factors in Scott and Vessey’s case organizations that influenced positively (+) or neg-

atively (-) to success of software implementation.

In open and trustworthy organization the employees are alert and warn the management

about possibilities of failure. When organization culture is closed and employees are un-

willing to speak to the management, issues are not brought up early enough to manage-

ment to make decisions accordingly. Such organization is also less willing to change

even when it is necessary. Project needs also strong leader and committed project team.

Small steps and acknowledgement of small wins helps organization go through system

implementation. If the expectations are too high or there are big changes in KEY cus-

tomer base during project, failure is more possible.

Thought the usage of external consultants is on the minus side of the table, it does not

mean that all successful IT projects are run without consultants. If consultants are only

ones takin part to system project and own personnel is not involved, the end result is

likely to be poor. When personnel can participate with the consultants and are willing to

study and explore new system, results are more likely to be better than when whole

15

organization relies only in consultants. The right balance between consultants and

personnel participating seems to be one success factor.

In other hand, some obvious seeming factors did not have influence on the end result of

the IT project. These factors are seen in table 3 below.

Table 3. Below factors do not have an effect on the success of the project in Scott and Vessey’s

case organizations.

Technical or system skills of the personnel did not have an effect on the project success.

Neither had that if the users were trained correctly. Training could be poor or targeted to

wrong part of the system, but this did not disturb a motivated organization. Both organi-

zations had equally tough business positioning and another succeeded and another one

did not. Most of the issues were managerial issues, not technical ones.

3.2.2 The Scale of the Implementation

Information system development and management is a huge area to conquer so firstly it

is very important to recognize what sort of software development project lies in hands.

Cadle & Yeates (2008; 3-11) divide software projects into nine different types:

Software development

Package implementation

System enhancement

Consultancy and business analysis assignments

System migrations

16

Infrastructure implementation

Outsourcing (and in-sourcing)

Disaster recovery

Smaller IS projects

The type in this case study is closest to a “system enhancement project”. This is a type

of a project where the software already exists and is in use but new features or functions

are developed.

Common difficulty is that developers involved in enhancement are typically the key peo-

ple supporting the existing system also. If this is the case, it can be hard to balance

developer’s time usage between support and enhancement. Further problems normally

occur at testing and implementation stage. New features need decent amount of proper

data to be tested with. If test data is corrupted or the whole test is overlooked, results are

too (Holland & Light; 1999). It is often impossible to tell in advance how the new parts

effects on the already existing system. Those parts that are working well, should stay

unharmed by new enhancements. Safety of the legacy can only be secured by sufficient

test rounds of the new module.

Key success factors in enhancement projects are careful analysis of the requirements

and good planning of the project and especially its implementation part. Time manage-

ment of the developers needs to be supported also if they are supporting existing envi-

ronment already.

3.3 Conceptual Framework of the Thesis

The conceptual framework of this thesis consists of two pars visualized in figure 5.

1. Design of software module

2. Implementation plan

17

Figure 5. Conceptual framework of the thesis

The conceptual framework starts from the world of software development. The good

practice of developing both totally new software and enhancing old features follow the

same process. First one needs to be familiar with the current way of working and in the

other hand what are the exact needs for the new way of working. Any sort of changes

should be strongly supported by the strategy.

With the strategy and the current state it is possible to analyze what are the best ways

to proceed. Only after these steps, as the waterfall model works, the actual design part

can begin. With the developments it is not always necessary to be too conservative. The

best solutions may occur totally out of the box and those businesses that find innovative

ways of doing often gain advance at the markets.

The implementation plan is a crucial part of any system project. It all begins with project

planning. When the team and targets are set by the strong strategic level support, build-

ing the technological part can begin. Good practice is to involve the users into the actual

design and development process. The technological capabilities of the users don’t meas-

ure the results. When the system side starts to be ready, the user organization prepara-

tion can begin. Depending on the scale of change the preparation can include reorgan-

izing or only training and communication. At the deployment also called as go live the

18

organization needs extra support, guidance and control for some time. According to con-

tinuous development the project isn’t finalized before lessons learned. Almost all systems

require also constant support and maintenance.

To the end of the chapter 3 it is good to remind oneself of the human side of the business

behavior. The management plans processes like a landscape architect designs the

roads. But the processes can’t always be forced and they also mold from the inside out

like people create their own paths instead using ready built roads. Hammer (1990) states

the phenomenon well:

“Processes are often not made, they just happen with time.”

In current state analysis in the next chapter 4 the goal is to identify the case company’s

strengths and weaknesses and take them into account when planning the development

of the invoicing and reporting module and its implementation.

19

4 Current State Analysis

This section reports the current state of the business problem. The current state was

established according to the thesis data plan presented in section 2.3. The current state

analysis is based on stakeholder interviews and available documents related to the topic.

The maintenance operator is called user hereafter. The user makes maintenance work

at the customer site and logs all daily tasks into the new maintenance system.

4.1 Overview of the Current State Analysis Stage

The current state analysis stage started by defining in detail the different stakeholders

related to the business problem. This was done together with the company instructor,

here also the Business Unit Director. He also provided documentation like the customer

service contract and material how separately billable materials have been handled and

invoiced so far. The record of all data collected in all three data stages is seen as an

Appendix 1. All materials mentioned in Appendix 1 are available for the thesis instructors.

When all stakeholders were named, all interviewees were contacted to arrange meet-

ings. All except the last interview were possible to arrange in person visiting the sites

where interviewees run their daily tasks. The last interview was held as an online hang

out meeting due to restrictions in traveling and face to face meetings caused by the co-

rona pandemic in spring 2020. An example of the interview data collection is seen in

Appendix 2.

After the data 1 collection part all materials were considered together to create a clear

picture of the main problem areas for:

1. New maintenance software usage and functionality in separately billable work

orders at complex service agreement services

2. Recent software implementation in case company

Interviews, documents and observations are described in the following sub sections.

4.1.1 Data 1 Interviews

All interview questions and topics were prepared in advance. The interviews were rec-

orded by writing to the memos listed in table 4 below.

20

Table 4. List of interviews held at current state analysis stage

The first and the last interview was held together with the business Unit Director of the

Service Unit. He has the main responsibility for the new maintenance software. He has

handled the separately billable work process and the initiation to improve it came from

him. After interviewing all other stakeholders I discussed with him one more time to verify

the observations made on the field.

The solution architect is the contact person between the case organization and the soft-

ware supplier. He is responsible for the architecture of all Sales Force related to soft-

wares and the interfaces between them. He develops and maintains the new mainte-

nance software and he has been involved in this system project since *beginning as an

ICT project manager. He is not responsible for the customer or business side, only the

technical part.

On site supervisors lead the local sites operationally. They create maintenance plans,

agree on extra work with the customer and run the roster planning.

Title Interview held Document number in Ap-

pendix 1

Business Unit Director 7.2.2020

2.3.2020

6

Head of Maintenance Ser-

vice Center, member of IT

project

26.2.2020 1, Appendix 2

ICT, Solution Architecht,

Platform Owner

27.2.2020 2

On site supervisor, Vantaa 28.2.2020 3

On site supervisor, Pasila 30.3.2020 4

Customer: Postal Services

Strategy and Development

28.2.2020 5

21

The Postal Services Strategy and Development person is the main local contact person

from the customer side who negotiates extra work together with on site supervisors.

4.1.2 Data 1 Documents

All related documents were collected in the interviews and they are listed below in table

5.

Table 5. List of documents collected for the thesis

Document folder name Source Document number in Ap-

pendix 1

Contract + appendices Business Unit Director 7 (confidential)

Invoicing and shift materi-

als July – September 2019

Business Unit Director 8

Instructions for separately

billable work

Business Unit Director 9

User instructions for FLS

mobile system

Head of Maintenance Ser-

vice Center, member of IT

project

10

The contract and the appendices is the basis of the whole thesis because they are the

fundamental documents that describe what has been agreed about the maintenance

service content, resourcing and conditions with the customer.

The new maintenance software is the mandatory cornerstone of the whole service agree-

ment. On time logging of work orders utilizing new software is defined in the contract

appendices. Difference between contract work and separately billable work is done by

interpreting the following statement of the contract:

“If extra work inside a normal shift arrangement does not obstruct normal

service level agreed in the service agreement, a mutually agreed extra

work inside the normal shift arrangement does not cause charge. “

22

Invoicing and shift materials are the only way to dig in deeper to the data and examine

the value, quality and diversity of the normal and separately billable hours and their con-

nection.

User instructions represent the way the system is designed to be used. These instruc-

tions are compared to the actual way users are utilizing the system interviewing the on

site supervisors.

4.2 Technological and Practical Challenges in the “Reporting and Invoicing” Module of

the New Maintenance Software

In order to determine what could be wrong with the invoicing information, the current

process for information flows affecting invoicing information needed to be described. Be-

low in figure 6 can be seen that after the work order has been completed, the information

flow divides permanently in two. Invoicing and reporting information flows to the right

side and pre filled work hour list to the left side. Everything on the invoicing side is based

on what has been logged in the work order process. Work hour logs don’t effect to the

invoicing without manual actions.

After the work order has been closed (invoicing information is then complete) the user

needs to go complete his/her work hours, seen in the left side of figure 6. User’s salary

is based on this hour log completion. The hour list is based on work orders but the user

can correct and complete hours and add extras. In case the user should get extra com-

pensation due to extra or extended shift or add own costs like kilometers or materials,

the user fills info at this point and salaries are paid according to the final hour logs.

23

Figure 6. From work order to invoicing information flow – illustration of the process in the new maintenance system.

The problem lies here: Users don’t log separately billable work. They do fill in their per-

sonal hour lists which don’t affect invoicing.

If the user has extra hours or additional costs, according to the contract, they can always

be invoiced from the customer. The comparison between the hour list and invoicing list

is now done manually comparing hour lists and ready work orders via a complex Excel.

The Excel is generated monthly by hand by exporting hour lists from the system and then

rearranging information by cut and paste. Audit of this Excel reveals not all overtime is

automatically invoiced. There is no interface between these two information streams

though the content should be identical on both sides.

All valuable information remains at the hour log side on the left, which is also the cost

side to the case company. This information should be identical and available also at the

invoicing side on the right. The current process of manual comparison is time consuming

and inaccurate. The problematic situation is shown in figure 7 below.

24

Figure 7. The information pours into two separate streams and comparison is done manually

Another problem lies in the description texts of the work orders. Now that the comparison

of work hour lists and invoicing data is done manually, the descriptions of work orders

should be detailed and clear enough to enable comparison in case of separately billable

hours of shifts. There should also be customer reference for additional shifts or explana-

tion for extra hours. The system has a weakness firstly in the text box length and saving

the information. The text box is only 250 characters long and the user can’t see if they

exceed the accepted amount of 250. If the user writes too long description and pushes

“save”, the system does not autosave and the description text is gone. When this hap-

pens, usually at the end of the work shift when work logs are completed, it is more likely

that the quality of the description decreases. When the description text is incomplete or

defective, the arguments for the extra invoice get poorer for the customer and more dif-

ficult to recognize for the supervisor who goes through the separately billable work hours.

On time logging of work orders doesn’t work like designed. The instructions differ from

the practice. It seems that this may not be totally accepted but at least overlooked by the

management at the moment. On time logging with the mobile device is seen as slow and

challenging task. Finding the right asset amongst hundreds of assets is easier said than

done. The users feel that the quality of the actual maintenance service suffers if the

loggings are made on time. An on time digitalized system is at the center of the case

company’s customer proposition. It also affects the quality and traceability of the data at

the separately billable work hours.

25

4.3 A Recent Implementation in Case Company

As a second part of the current state analysis a recent implementation case of new soft-

ware case was examined to recognize the strengths and weaknesses of the case com-

pany in implementing a new software. This information can be used to help to implement

the enhanced invoicing and reporting module.

The recent implementation case is the implementation of the same new maintenance

software. It has been implemented gradually since spring 2019. Figure 8 below visualizes

the strengths and weaknesses of a case company in the recent software implementation

case.

Figure 8. The strengths and weaknesses of the case company in recent implementation of new software.

This visualization places the case company into the implementation part of the concep-

tual framework of the study presented in section 3.6. The strengths and weaknesses are

explained below in more detail.

26

4.3.1 Strengths of a Recent Implementation in Case Company

A strong strategic level initiation for the new maintenance software is an important

success factor. The digitalization of maintenance services is in the top level strategy of

the case company. C-level support has been strong throughout the project.

Though the implementation has been very long and parts of it has been postponed sev-

eral times, the sequences have been very rational. The organization hasn’t compromised

the best order for the implementation and check points have been used as planned and

gradually proceeding has helped *organization to adapt to the new way of working during

the long implementation phase.

The user experience has been one of the leading design forces for the system devel-

opment. The legacy system didn’t support current user expectations. Pain points such

as lack of mobility are solved in the new system.

The organization’s capability to adapt changes has improved significantly throughout

the project. Change resistance was bigger in the beginning but strong market pressure

for digital renewal and long implementation step by step utilizing small wins has slowly

turned the organization into adaptable mode.

The new maintenance software has been improved continuously since the beginning

and the development continues. The current list of improvement needs is very long but

one by one the topics get to agile development that represents incremental system de-

velopment model.

4.3.2 Weaknesses of a Recent Implementation in Case Company

All interviewed persons verified the fact that the project doesn’t have a project leader at

all. Some responsibilities are clear but nobody holds the overall responsibility. This

seems to be the biggest weakness and the actual root cause of other weaknesses and

further problems. Implementation plan, schedule and communication plans are made but

they only fulfill the purpose of documentation, not effectiveness.

27

Lack of communication emerged as a weakness in all interviews. The common feeling

was that nobody knows exactly the effect of next steps to their operations. The infor-

mation is scattered and those who have the best information are unable to share relevant

information to the whole organization in a way that receivers feel is well informed. The

majority of trainings were held remotely and this seemed to leave distance between us-

ers and the instructions. The commitment to the new instructions suffered when very little

of personal guidance was given. The lack of presence seems to cause also lack of trust

between informers and informants. When user trainings were held only remotely, the

distance may have caused misinterpretation of the abilities and skills of the users. This

causes unnecessary preconceptions and prevents solving minor problems only by nor-

mal communication. In change situation users need patience, support, trust and encour-

agement.

The continuous development process is good in case company but lack of resources

makes it extremely slow. The responsibility of the maintenance, training and develop-

ment of the software is for one person only. This is also one root cause for the above

training distancing and lack of proper attention to users. With this tight resourcing, the

quality or the schedule always suffers.

4.4 Key Findings from the Current State Analysis (Data Collection 1)

The current state analysis finding is that there are both technological and managerial

issues that cause inefficient invoicing and reporting of separately billable work orders.

The managerial and process related issues seem to be more significant than the tech-

nological issues. From the process point of view the biggest issue is that only the on site

supervisors are entitled to log separately billable work orders to the system. Instruction

at the moment is that users don’t log separately billable work orders. If the user stays

longer at work to repair an urgent fault, these hours can always be invoiced with the extra

costs of labor and spare parts. In these cases the on site supervisor might not be present

and adding the costs to separate invoicing isn’t done the same way any time. At any rate,

from the data could be seen that there are frequent prolongations of work shifts caused

by ad hoc repairs that are detected weeks later at the heavy Excel checking routine.

From the technological part the main issue is that those working hours that should be

separately invoiced diverge too early on in the system and has no link back to the invoic-

ing. As the technological challenges aren’t that significant, the technological part of the

28

proposal building concentrates on the reduced beige development cycle seen in figure 9

below.

Figure 9. Proposal building focuses on beige development cycle that does require architectural changes.

Better functionality of the invoicing and reporting features is a new requirement for the

software and it is handled accordingly. A requirements analysis was already done at the

current state analysis phase and the requirement was identified as secondary function-

ality demand that does not change the system architecture.

Altogether the small technological disabilities and the current process make it very hard

to detect those extra hours and costs that appear at challenging time, example during

end of the night shift or example just before or during the holiday season. The proposal

concentrates on enhancing that process but also giving suggestions on how to support

it technologically. The on time logging is also key driver on improving the process. The

lack of communication came out so strongly that all the enhancement suggestions are

given with emphasis on leadership and good communication.

The next section 5 of this study, building proposal for the case company, concentrates

on finding solutions and enhancements to the above mentioned main issues found out

in data 1 stage.

29

5 Building Proposal on Improving Invoicing and Reporting of the Com-plex Service Agreement Services for the Case Company

This section merges the results of the current state analysis and the conceptual frame-

work towards the building of the proposal using data collection stage 2.

5.1 Overview of the Proposal Building Stage

The proposal building stage concentrated on generating a proposal solving the key

weaknesses of handling separately billable work in the new maintenance software. The

weaknesses were identified in the current state analysis at data 1 in section 4. All best

practices were found in the scientific literature reviewed in section 3.

The technological side carries a few moderate shortages and finding solutions to these

shortages was part of the proposal. Perhaps bigger issues lie on the managerial side

and the proposal seeks improvements for the root causes that emerge later as big variety

in the quality of the invoicing data. The attention to both development and implementing

has been rather pale and suffered from tight resources such as lack of project manager

for implementing the new maintenance software. To give the proposal a better chance

of success the proposal includes an implementation plan for the suggested improve-

ments. The implementation plan focuses on tackling the lack of management and com-

munication risen in the recent software implementation in the case company.

After interviewing stakeholders at the data 1 stage it was easy to recognize who should

be involved in the proposal building. The solution architect could respond to all techno-

logical issues and the site supervisors have both the responsibility and user experience

from the operational side. The business unit director holds all the pieces together.

First the intuitive ideas of stakeholders were gathered separately and after that the work-

shop was called out with all the above specialists.

5.2 Findings of Data Collection 2

All findings of data collection 2 Stage are either discovered or supported by the key

stakeholders. At the workshop few directional ideas were presented based on the re-

searcher’s observations and stakeholders’ own ideas which the stakeholders then either

30

discarded or refined. Some parts of the proposal were entirely suggested by the stake-

holders at the workshop. All solutions were considered together from various viewpoints:

technological, practical (user side) and process points of view. At last the list of the pro-

posal components were once more gone through and accepted by all attendees. In the

table 6 below all the suggestions are listed.

Table 6. Stakeholder findings in data 2 collection

Key focus area based on CSA and CF

Stakeholder suggestions Description of the suggestion

1 Separately billa-ble work order process

Prepone the opening of sep-arately billable work order in case of ad hoc maintenance causing prolonged shift

No technical solution helps if the pro-cess is wrong or late from the begin-ning.

It is noticed that ad hoc prolongations of work shift that cause problems at the Excel check stage occure most likely when the supervisor is not at the site. Therefore the logging of those separately billable hours need to be the users responsibility and made im-mediately after the maintenance has been performed.

2 Technical changes to the new maintenance software

a) Enhance data quality on the hour list

b) Make it faster and eas-ier for user to open new separately billable work order

c) Elongation of work or-der description field

Work hour list doesn’t include any text field to explain possible exceptions to planned working hours. This type of field is easy to generate and it helps the supervisor at the list audit stage.

It is also possible to build a link from work hour list to new separately billa-ble work order.

The work order description works as an invoicing and reporting input. A longer text field improves the descrip-tion quality and prevents already writ-ten description from vanishing in case the character string is too long.

3 Communications and training

More support needed A profound training about the sepa-rately billable work order rules and responsibilities. New process training to all users. Other processes to be checked also. All communications should be better related to pro-cesses, changes and improvements.

31

4 The customer contract

A detailed agreement on way of working in case of separately billable work or-ders

The current contract comments the subject very widely. The more pre-cise the contract is, the more it is possible to automate such rules

5 New tools Software supplier develops new features regarding work shift

The case company could investigate if the new feature (available later) could ease the shift arrangements and calculations regarding.

6 Implementation plan

How the changes are im-plemented

Good instructions, plan and support is needed when new ways of work and new tools are deployed.

The initial proposal is built around these suggestions.

5.2.1 Proposal of Technical and Operational Changes

The initial proposal includes both short term and long term recommendations to improve

reporting and invoicing of separately billable work orders. Short term recommendations

are sorted into three categories: technological changes, process and operative changes

and communications and training.

The responsibilities of the separately billable work order process will change from the

current process. To make the process more understandable, the separately billable work

orders are divided into two categories:

1. Extra work orders agreed in advance with the customer

2. Ad hoc maintenance cases caused by broken machinery or other urgent repair work

needs that prolong pre planned work shift

The initial proposal of the operational part is that users have responsibility over the case

two, the ad hoc repair cases that cause separately billable work. Previously users ha-

ven’t made any invoicing decisions but according to the proposal they will hold the re-

sponsibility over the ad hoc situations.

32

5.2.2 Implementation Plan

The management, maintenance operations and the software development seem to op-

erate well but very separately from each other at the moment. The on site organization

is still on the learning curve and needs a lot of support regarding the new maintenance

software. In the other hand the development side is running with one shared resource

and can only carry out limited amount of support and development. The management

operates with the data which quality varies from site to site.

A common platform, here called an implementation plan would help all the parties dis-

cuss better when following the recommendations.

5.3 The Initial Proposal on Improving Invoicing and Reporting of the Complex Service

Agreement Services

The initial proposal provides suggestions and an implementation plan on how to improve

the current way of invoicing and reporting of complex service agreement services that

are separately billable.

The recommendations are categorized into short and long term recommendations and

into sub categories that help understanding what sort of mission is ahead. Those sub

categories (technical, operational and communication) also determine later on what par-

ties need to be involved in the project team. The most important suggestion is that the

process responsibilities change in a way that users log by themselves and right away

those separately billable work orders that occur promptly without prior notice. To support

this change there can be made enhancements to the software but more important is to

improve communications and provide profound training and support for the users and

site supervisors at the new way of working.

The long term recommendations are ideas for the management to consider later on.

They need closer investigation and evaluation if they are to help the case company.

The initial implementation plan utilizes the best practices of software development and

implementation cases from the literature and considers the strengths and the weak-

nesses of the case company.

33

The classified recommendations and implementation plan is visualized in the figure 10

below.

Figure 10. The short and long term recommendations to improve current invoicing and report-ing process and the initial implementation plan.

The initial proposal is only the suggestion for the improvements and the next Section 6

is for validating the initial proposal. The validation is done by senior decision makers of

the case company and the final proposal is presented at the end of the Section 6.

34

6 Validation of the Proposal

In this section the validation process of the initial proposal is described and the findings

of the validation are listed. At the end of the section, the final proposal is presented in-

cluding those changes that came up in the validation part.

6.1 Overview of the Validation Stage

This section is the final data stage 3 and validates the proposal developed together with

the key stakeholders in Section 5. The validation is executed by presenting the initial

proposal to the management of the case company and asking them to critically evaluate

the proposal against the business problem and suggest corrections or improvements.

The validation board needs to have authority to make decisions over the thesis topic

area. Therefore the case company CEO was invited to represent strategic level leader-

ship. The Business Unit Director of Maintenance Operations was also invited. He is in

responsible for the business side. Third member was the case company group ICT Di-

rector. He is the highest decision maker in the new maintenance software related issues

and developments.

After a quorate board was chosen, invites to the validation event were sent. According

to current company instructions for the corona pandemic era all meetings are held as

remote hang out meetings. After invitation the material including description of the busi-

ness problem and initial proposal for improving the invoicing and reporting of complex

service agreement services was sent to all participants prior the meeting.

The meeting was recorded with the permission of all participants. At the meeting the

current state of the process was first presented and the main strengths and weaknesses

were gone through. After this introduction the board was asked to give feedback and

improvements to the initial proposal.

Finally the proposal including the board’s improvements was accepted by the board.

35

6.2 Findings of Data Collection 3

The proposal got good feedback from the validation board. The CEO gave special recog-

nition for the presentation and proposal for being able to understand the whole problem-

atic for the first time. The proposal was able to explain the current situation and clarify

those parts of it that have been previously difficult to understand.

The discussion over the validation meeting was good and vivid and the board considered

all of the proposal points. After the discussion the final suggestions to improve initial

proposal were given. All improvements are listed in table 7 below.

Table 7. The improvements to the initial proposal requested by the validation board

Decision maker observa-tions

Description of the observation

1 The managerial and opera-tional changes can be executed right away. Make those the pri-ority one of the proposal.

The CEO ensured that the suggested change in sepa-rately billable work order process could also be imple-mented already without technical changes. These oper-ational changes are the priority one and planned and executed as soon as possible.

2 Create instructions for sepa-rately billable work orders for users and site supervisors

There are many possible ways to create WO and SA in the new maintenance system. The best way to do it should be described in written instruction document.

3 To specify figure 7 work order log process

The figure is correct but the technical side is easier to understand right if the relations between work order, service appointment and work hour list are presented in more detail.

4 To draw more detailed tech-nical description of the tech-nical improvements of the ini-tial proposal

The Business Unit Director wished for more detailed drawing for the possible technical changes to the sys-tem to enable possible further assessment and devel-opment.

The suggestions are described in detail in following sections.

6.3 Developments to the Proposal Based on Findings of Data Collection 3

This chapter presents all requested improvements for the initial proposal. According to

the validation board, the initial proposal is good and accepted with following improve-

ments:

36

1. Separate those recommendations that can be applied right away and implement

them as soon as possible

2. Create new instruction to open separately billable work order

3. Draw a skitch for the technical changes in the system to enable further evaluation

and development

In addition to the improvements a close up description of the figure 7 work order log

process was requested. The requested clarifications are seen later in figure 11.

6.3.1 Further Improvements Regarding the Process and Operational Side

The part of the initial proposal that could be implemented right away without any technical

changes was decided to execute right away. The change to the proposal is that the “Short

term recommendations” is divided into two and the first part of the proposal will be those

recommendations that can be implemented right away. The content of the proposal re-

mains identical than presented in Stage 5.

As an immediate action to this the validation board requested already a meeting with the

operational management of the case organization. Process changes were gone through

and a decision to make a clear instruction for the best way to open separately billable

work order was made. The author of this thesis was named to create the instructions for

both users and to site supervisors together with chosen site supervisors. These instruc-

tions were made immediately and are listed in Appendix 1 Record of Data as documents

number 13 and 14. These instructions are available for the thesis instructors.

These instructions are recommended to take into use according to the validated imple-

mentation plan. The case organization management is responsible for implementing the

new instructions created.

6.3.2 More Detailed Technical Descriptions on Recommended Changes

A requested adjustment was a correction to the process flow figure 7. The whole work

order process is described as an entity but the actual system component that effects to

the hour logs is Service Appointment (SA) which is a sub operation for Work Order (WO).

37

The actual and more detailed relations between WO, SA, User and Hour card are pre-

sented in figure 11 below.

Work OrderWO

Service Appointment

SA

1..*

Hour card

1..*

1

1

User

1..*

1

1..*

1 1

Figure 11. UML class diagram of WO and SA relations.

.

From the black diamond relations we can notice that none of the other classes can exist

without an User. A User can have more than one Work Order but a Work Order can only

have one User. Same applies to SA. A User has one Hour Card and vice versa. Hour

card though can exist without any SAs but Hour Card gets its info only from the User and

SA, it is not in straight relation to WO.

This relation diagram information is necessary in order to get all pieces right in the next

validation correction – a sketch of the functionality of initial proposal technical changes

to the maintenance software. At the initial proposal building stage the technical changes

seemed to be rather small and the workshop members didn’t see more detailed mapping

necessary but from the wish of the Business Unit Director the more detailed sketch is

drawn.

Now that the relations are easier to understand, the figure 11 is followed by a proposal

sketch of recommended logic of the user hour log at the complex service agreement

sites. The sketch is presented as an UML sequence drawing in figure 12 below.

38

User

SA Hour card Separately billable

Site supervisor

Payroll

Log work

Prefill hour info

Confirm all hours

Log final hours

Alternative

[if separately billable extra hours]

Open new separately billable SA

Request fill in

Fill in

Add to separatele billable work order listRequest approval

Approve (or reject)

SA approved (or reject)

SA approved

Ask for approval

Approve (or reject)

To the payroll

Hours accepted

[if else and after previous]

Figure 12. An UML sequence drawing proposal on recommended technical execution of hour card and service appointment information flow at the new maintenance software.

The only difference to the current system in the above figure is the functionality that

checks if the hour card has extra hours that are separately billable. If yes, the system

creates a new SA for separately billable work order using the existing protocol. Only the

check point for extra hours is new compared to the legacy system. To avoid duplicate

work orders the system could first offer a list of open separately billable work orders. If

the work hasn’t been created yet, the system directs to open a new service appointment.

This functionality would bring desired double check up for the extra hours and the addi-

tional costs of them. The system forces to pay attention to extra hours and automatically

wants to allocate them to new or existing separately billable service appointment.

The risk is that the system gets even more complicated to use. First it is recommended

to implement the operational process changes utilizing the current system and see how

it effects to the data accuracy and quality. When those results are available, the technical

changes should be re-evaluated, refined, designed, tested and implemented.

39

6.3.3 Further Improvements to the Implementation Plan

The implementation plan remains as it is but for those changes that are desired to im-

plement right away a separate action plan was made. Separating smaller plan enables

fast implementation of process changes and follow up.

The first step of the plan is to create detailed operational instruction for separately billable

work orders for the users. The management wishes to audit the instruction before the

roll out. These instructions are created and listed in Appendix 1 Record of Data as new

documents.

Now the responsible Operative Manager is intend to arrange training sessions to all 8

customer sites. The training includes a thorough education of the customer agreement

content related to the invoicing terms: what is included in the agreement and what is a

trigger to separately billable work order. The new responsibilities are communicated and

new way of working rehearsed. The supervisors need the training also. They will be in

responsible for ensuring the deployment and accepting both hour lists and separately

billable work orders every week. The progression of the trainings is reported to the CEO.

6.4 Final Proposal

As promised, the thesis outcome, the recommendations visualized in figure 13 are

handed over to the case organization for further implementation. The priority one im-

provement is to change the process responsibilities. According to the recommendation

users start to log separately billable ad hoc work orders by themselves into the new

maintenance system. Previously only site supervisors have opened separately billable

work orders and this causes prolongations and possible left outs in some cases. Clear

instructions to deploy this change are already created. There are two instructions, a mo-

bile instruction for users and a desktop instruction for site supervisors. The supervisor

instruction includes a template for separately billable work order reporting and instruc-

tions to copy and edit the example report.

40

Figure 13. Recommendations to improve invoicing and reporting of separately billable work orders in urgency order.

In addition to the process change there are few recommendations on enhancing and

introducing technical features. When process and technical improvements are taken into

use applying profound communication and training practices, there will be no longer need

for heavy Excel inspection routine and lighter routine can be recreated together with the

case company Solution Architect.

The long term recommendations are to encourage the case company to prevent further

similar problems by defining already at the contract building stage how these type of

cases are handled. There are also further improvements coming up developed by the

software supplier that might be applicable for the case company. These alternatives are

recommended to investigate more closely.

41

Figure 14. An action plan for the urgent process changes that can be applied right away.

In the figure 14 above is visualized the action plan for those urgent process changes that

can be applied right away. When writing this report the first step is finished and next

steps are waiting to be scheduled.

Though the most urgent improvements are already being implemented, the larger scale

implementation plan for all recommendations shown in figure 15 below is still an es-

sential part of the validated proposal.

Figure 15. Implementation is a strong and needed companion for the recommendations.

All three data stages pointed clearly out that the organization has suffered from the lack

of project leadership and communication. For any further development projects this is a

crucial lesson for the case company not to neglect the importance of the professional

implementation.

The thesis report is ended by the following chapter 7 which includes the Executive sum-

mary, a recommended action plan for the case company to continue from here on and

finally the evaluation of this thesis and closing words.

42

7 Conclusions

The final section of this thesis report includes the Executive Summary drawing the

whole study and the most relevant findings and recommendations together. After the

summary the final implications for the case company are listed as an action plan. In the

end of this section the solidity of this thesis is studied through four criteria: validity, reli-

ability, relevance and logic. The thesis report is closed with ending words.

7.1 Executive Summary

The case company has recently implemented a new maintenance software. With cus-

tomerships that include complex service agreements, the invoicing and reporting of sep-

arately billable work orders has been discovered as a tricky entity to manage and follow

up. The objective of this study was to seek improvements for invoicing and reporting

those work orders that are not included in the contract. To support the implementation of

these improvements, an implementation plan for the recommendations was also built.

The final proposal presented in chapter 6.4 is built on best practices selected via a liter-

ature review over areas of software development and good implementation practices.

After analyzing the current state via key stakeholder interviews and relevant data it

emerged that the business problem isn’t formed from one issue but several small ones.

Therefore it was also impossible to create one solution that would correct all the prob-

lems. Instead, with the strong cooperation and support of key stakeholders of the case

company, the final proposal is a collection of improvements and an implementation plan.

The proposal starts with improvement of the process that generates the invoicing and

reporting information. Inputs are generated when work orders are created to the new

system. The target of the improvements is to increase the input data quality with good

instructions and fasten the process in a way that work order logs are made at the earliest

possible time. More responsibility is recommended for the users. This is supported with

quality instructions and comprehensive training including increasing the knowledge on

the contract content and the significance to the case company. This priority compulsion

is supplemented with a separate action plan to ensure fast and successful implementa-

tion.

43

The rest of the proposal consists on improvements that require an implementation plan

also presented at the final proposal. There are couple technical enhancements that up-

grade the user experience and the quality of the data. It is also suggested that future

complex customer agreements should already include exact definitions of settlements

such separately billable work orders. The software supplier also develops new solutions

for shift management related issues and this is advised to follow up in case the case

company could benefit from the features.

The proposal got its final form after validating the initial proposal. The proposal was val-

idated by a Board of Senior Directors that have decision making power over the thesis

related issues. The board made few addings and arrangements on the initial proposal

and after editing these the board accepted the final proposal.

The study didn’t recognize one ultimate solution for the business problem but many small

and easy to apply improvements that are all created and accepted by the key stakehold-

ers. The report suggests an action plan to implement the requested changes. The study

gives a clear view on how the system is planned to use and in the other hand what sort

of own pathways the organization has created to fulfill the business purpose.

The improvements strive to create best quality data at earliest possible time and to erase

unnecessary heavy check an analysis points. Applying the improvements to the invoicing

and reporting process and technologies the organization takes a good leap towards the

goal of on time follow up of the maintenance operations.

This study was possible only because of the support and high interest of the case com-

pany. All in all almost 15 people gave their expertise in this thesis through interviews,

workshops, meetings, phone calls, emails, encouraging and delivering good amount of

data over the subject. They all played very important role in order to create a reliable

piece of work.

7.2 Next Steps and Recommendations towards Implementation

Now it is time for the case organization to continue implementing above suggestions.

The work begins from the action plan step two presented earlier in figure 14. The instruc-

tions for separately billable work orders for complex service agreement customerships

44

are completed during this thesis and they are already reviewed by the management. The

instructions are designed in a way that they support quick and explicit way of working.

The instructions are self explanatory but still the training is an essential part of imple-

menting the new responsibilities.

Planning and arranging the trainings for all eight customer sites is the step one on

the case organizations to do list. Training without a follow up makes no difference. The

management needs to keep track on the process during and after the deployment. The

management support to the site supervisors is vital and so is the site supervisor support

to the users.

When the process is functioning like wanted, the case company can proceed to the tech-

nical changes to the new maintenance system. Adding explanatory fields and a shortcuts

may improve the data quality and user experience even further.

A substantial recommendation is to establish a project office for the new maintenance

software development. The principles and functioning of such project office is described

in the implementation plan presented earlier in figure 15. There are still almost endless

amount of improvements to be made to the system and the current resourcing is not

optimized to achieve those strategical goals that the case organization has set for itself.

A strong business oriented leadership over the system development is severely needed.

The case company is clearly on the right way towards its targets but the organization

hasn’t been able to keep up with all the changes. Now it is good time to take over and

keep on improving utilizing the best practices of the industry.

7.3 Thesis Evaluation

The evaluation of the thesis is good point to look back and discuss the credibility and

weight of a study. The credibility of the study is related to the methods, theory, logic and

variety of the sources used. In following sub sections this thesis is evaluated through four

criteria: validity, reliability, relevance and logic.

45

7.3.1 Validity

The validity of a study concerns whether or not the observations are supported by data

and earlier research. The qualitative studies face typical validity issues such interpreta-

tion of spoken data sources, generalization and social steering.

To increase the validity of this study various sources were used. Every possible level of

the case organization was included either in interview or workshop. The local samples

were chosen geographically from south to north and revenue wise they presented both

big and small sites. Interviewing four out of eight site supervisors triangulated the key

issues precisely and avoided misinterpretation for social reasons.

The issues found were typical according to the literature review and supported by the

conceptual framework. Especially at the validation point of this study the strengths and

issues found were perceived also internally by the senior decision makers. The results

didn’t conflict with the common opinion of the key stakeholders. Only the priority order of

the proposal stirred some kind of disagreement. The final priority order was then judged

by arguing the relevancy and impacts on the problem.

7.3.2 Reliability

The reliability measures the consistency of the study. The report style and study methods

aim for the transparency of the whole study.

All stages of this study and their logic is written open and only high quality sources like

books and scientific articles were used. The raw data used is available for the instructors

and the samples of the data phases are attached as appendices.

In the beginning of data collection phases the interviews were only documented by writ-

ing memos during the interviews and those memos were transcribed later. Somewhere

in the middle of the thesis project is came obvious that recording all the sessions would

have been beneficial. The researcher will naturally face different days and life situations

during the study period, not all forecastable beforehand. Audio recordings would erase

the pressure to memorize everything said during all meetings. Some part of the interview

content can also gain relevance only after some other interview has been held later. Only

the final work shop and validation of the proposal was audio recorded.

46

Some of the most insightful findings are found by combining the older data with the new

one. It would be very interesting to go back to the recordings from the beginning and

connect dots once more after listening to all interviews. Now there is a risk that human

memory makes its own interpretations. Therefore recording all meetings would increase

the reliability of the study. Here the methods of documenting of the study weren’t con-

sistent throughout the project.

A good amount of time and effort was invested in preparation all meetings. The purpose

and relevance of a meeting was explained always beforehand and an agenda and rele-

vant materials were given prior meeting so that no interviewee would have to come up

with the answers from the hip. The interviewees were able to suggest the meeting times

suitable for themselves to avoid unnecessary interruptions and unpleasant time man-

agement issues. The preparation to the meetings presented good reliability where the

documentation part were poorer in reliability terms.

7.3.3 Relevance

The relevance discusses how important the study is to the case organization and if the

results are transferable solving other issues or relevant and helpful for other organiza-

tions also.

The relevance of this study to the case company is ensured by listening closely to the

case company and especially its decision makers and key stakeholders throughout the

project. The study area, digitalization of services, is listed already at the case company

strategy. The need to serve a variation of service contract types smoothly inside the

same system environment is essential. The existent and new processes need to be well

considered and defined. This study provides insights over those areas.

The good practices of software development and implementing are transferable to other

organizations as well. The strengths and weaknesses vary but the key concepts of de-

veloping a software and implementing remain. Despite the case organization targeted

research methods the transferability of this study applies especially to companies going

through software development projects with similar, traditional but changing, organiza-

tional cultures.

47

7.3.4 Logic

In a good study logic all the areas contribute to the research goal.

The reasoning works throughout this study and the balance of the different sections is

decent. All sections are relevant and iteration rounds refine the end result. The logic of

this study keeps together and the outcome equals what was originally promised. Still

must admit that keeping the focus wasn’t an easy task. First the literature review almost

exploded to pointless directions such human resource management and general mainte-

nance issues. The time consuming suffered. It was rather difficult to abandon areas that

absorbed lot of time and effort but were irrelevant to this study.

The second time the study started slipping away from the original object at the validation

part of the study. The management started discussing other issues originated from the

same or close by reasons. The study was in danger to expand under the many wishes

of the management. Fortunately the tight scheduling prevented too ambitious new as-

signments and the further wishes were separated from this study.

Overall the study was able to achieve its original goals despite the fact that the end result

was slightly different from what was expected in the very beginning. In this context it is a

good thing not to fulfill what is expected. The study methods and following the routine

brought up root causes instead of quick medicines. With the findings of this study it is

possible to learn as an organization and apply recommended methods to other similar

issues.

7.4 Closing Words

Making this Master’s thesis has been quite of a journey. Like the northernmost hills of

the Lapland, they may seem rather small and easy to conquer, but quite soon after you

start climbing, you realize you are nowhere near the peak. Some journeys are ment to

travel alone but one will always need help from other people and creatures. Even in the

middle of the wilderness never think you are alone. If you listen, everything around will

guide. Just follow the advice of wiser ones and you’ll be fine.

At some point of this project, I couldn’t tell any more where I am going and where I came

from. The feeling in those blind spots is devastating. But with help and encouragement

of others, I was able to keep going. After travelling uphill for long enough, the point will

48

come when you finally see clearly the whole landscape. Everything is beautiful. All is

correct and natural. Up there you realize why you came. After enjoying the landscapes,

it is time to memorize the graceful view and plan the best route home.

In the glends surrounded by billion mosquitoes or during the fog you curse you never

began the damn trek. But as soon as you get home and sleep overnight, all the pain and

sweat faint away and transfer into achievements and treasures. It wasn’t that bad, right?

49

References

Cadle James and Yeates Donald. (2008). Project Management for Information Systems.

Fifth edition. Essex; Pearson Education Limited.

Davenport Thomas. (1998). Putting the Enterprise into Enterprise System. Harvard Busi-

ness Review. Jul/Aug1998, Vol. 76 Issue 4, p121-131. ADD REFE IN TEXT

Clements P, Bachmann F, Bass L, Garlan D, Ivers J, Little R, Nord R and Stafford J.

(2003). Documenting Software Architectures. SEI Series in Software Engineering. Addi-

son-Wesley.

Coughlan Paul, Coghlan David. (2002). Action research for operations management. In-

ternational Journal of Operations and Production Management. Vol 22 No. 2 pp. 220-

240. MCB UP Limited.

Fließ Sabine & Kleinaltenkamp Michael. (2004). Journal of Business Research 57, 392

– 404.

Fowler Martin. (2004). UML Distilled: A Brief Guide to the Standard Object Modeling

Language. Boston: Addison Wesley.

Hammer Michael. (1990). Reengineering Work: Don’t Automate, Obliterate. Harward

Business Review. Issue July–August 1990.

Holland, Christopher P. & Light, Ben. (1999). A Critical Success Factors Model For ERP

Implementation. IEEE Software. May/Jun99, Vol. 16 Issue 3.

Kananen Jorma. (2013). Design research as thesis research (applied action research):

a practical guide for thesis research. JAMK Univeristy of Applied Sciences. Tampere:

Juvenes Print - Suomen Yliopistopaino Oy.

Kettunen Sami. (2002). Tietojärjestelmän ostaminen. WSOY.

Koskimies Kai & Mikkonen Tommi. (2005). Ohjelmisto-arkkitehtuurit. Jyväskylä: Tal-

entum Media Oy.

50

Miettinen Satu. (2017). An Introduction to Industrial Service Design, Routhledge Taylor

& Francis Group.

Saunders Mark, Lewis Philip, Thornhill Adrian. (2009). Research methods for business

students. 5th ed. Harlow: Financial Times Prentice Hall. Available from: http://www.ac-

ademia.edu/download/61719476/Research_Methods_for_Business_Stu-

dents__5th_Edition20200108-108385-1dqhjh6.pdf (Accessed 1st of Aprin 2020).

Scott Judy E., Vessey Iris, 2002, Managing Risks in Enterprise System Implementations,

Communications of the ACM, Vol 45, No. 4, April.

Solis Bryan. (2017). UX Can Make Your Business Disruption-Proof. Customer Relation-

ship Management. July 2017.

Stenberg Martin. (2006). TIETO – Tietojohtamisen arkkitehtuurit. Keuruu:

Kustannusosakeyhtiö Otava.

Weaver Philip. (2004) Success in your project : a guide to student system development

projects. Prentice Hall : Financial Times cop.

Appendix 1

1 (1)

A record of Data

Document

number

Data

stage Type Date Subject Source Availability Notes

1 1 Interview 26.2.2020 Recent implementation cas Head of Service Center Appendix 2

Interview memo,

an example of

Data 1 collection

2 1 Interview 27.2.2020

FSL architecture and

development ICT, Solution Architecht Available for instructor

3 1 Interview 28.2.2020

FSL usability and separately

billable work orders On site supervisor, Vantaa Available for instructor

4 1 Interview 30.3.2020

FSL usability and separately

billable work orders On site supervisor, Pasila Available for instructor

5 1 Interview 28.2.2020

FSL usability and separately

billable work orders Key Customer Available for instructor

6 1 Interview

7.2 &

2.3.2020

Business problem and key

stakeholders Business Unit Director Available for instructor

7 1 Document 7.2.2020 Contract + appendices Business Unit Director Available for instructor Confidential

8 1 Document 7.2.2020

Invoicing and shift materials

July – September 2019 Business Unit Director Available for instructor

9 1 Document 7.2.2020

Instructions for separately

billable work Business Unit Director Available for instructor

10 1 Document 26.2.2020

User instructions for FLS

mobile system Head of Service Center Available for instructor

11 2 Workshop 3.4.2020 Proposal Workshop Key Stakeholders Appendix 3

The workshop

dokument

12 3

Validation

meeting 15.4.2020 The validation of the proposal Senior decision makers Available for instructor

Meeting

dokumentation

13 3

New

Document 27.4.2020

User instruction for separately

billable work order at complex

service agreement services Key Stakeholders Available for instructor

14 3

New

Document 28.4.2020

Site Supervisor instruction for

separately billable work order

at complex service agreement

services Key Stakeholders Available for instructor

Appendix 2

1 (3)

A note of a stakeholder interview, an example of Data 1 collection

Appendix 2

2 (3)

Appendix 2

3 (3)

Appendix 3

1 (2)

Work shop note, an example of Data 2 collection

Appendix 3

1 (2)