More
Businesslike
Maintenance
Management
Phone: +46 46 31 20 oo Fax: +46 46 32 04 41
Copying ban.
This work is protected by copyright. All copying is banned apart from a teachers right co make copies for educational purposes according co BON Us-agreement. BONUS-agreement is signed betwe en copyright organizations and head of education coordinator, e.g. municipality and university. Prohibition applies the entire work as well as parts of it and includes storage in electronic media, screen display and tape recording.
The person that breaks the copyright can according co 53 § be charged by general prosecutor and sentenced to fines or jail in up to two years and be liable 10 pay compensation to the author/ originator.
Art.nr 33066-01
ISBN 978-91-88862-2:z.-8
© The Authors and Dataf<ireningen i Sverige 2007 Graphic design & Typography: Elvaclva Kommunikation
Fonts: Adobe Garamond, American Typewriter and Furura Light & Bold Paper: cover Invercote 240g, content MultiFine 8og.
1.6. The disposition of the book ... 19
2. A businesslike perspective on maintenance ... 20
2.1. Our perspective on what businesslike is ... 21
2.2. Internal assignments and business ... , ... , ... 2 3 2.3. The conditions for being businesslike ... 25
2.3. 1. Value-based attitude and behaviour . .. . . .. , ... . . .. . . .. . .... 25
2.3. 2. Assignment management with interaction .. . .. .. .. . . . ... ... . . . . .. . 2 7 2.3. 3. A buyable assortment based on clarified added value . .... ... ... . . .. . .. . 2 9 2. 3.4. Agreed business interactions ... ... . ... . . . .... . ... .. . . . 3 1 3. Maintenance ... 36
3.1. Three central types of business ... 37
3. 1.1. The delimitation between maintenance activities and business activities ... .. 40
3. 1.2. The delimitation between maintenance and devclopmenr activities ... 42
3.2. Maintenance activities and their development over time ... 4 4 3.2. 1. Should IT operations be seen as a maintenance activity? . . .. . . .. . ... 47
3.3. A definition of maintenance ... , ... 48
4. Maintenance activities ... 52
4.1. Maintenance management ... 5 3 4.2. Support ... ... 55
4. 2.1. Answering questions . . . . ... . . ... . . . .. . . ... ...•... 56
4.2.2. Training and informing .. . . ... . . . ... . . •... . . . •••. . ... 58
4.3. Change management ... 58
4.3. 1. Cause of change, Change object and Type of change .. . . .. . . ••. .. . 6 0 4.3. 2. Change strategy .... . . . .. . . .... . . . .. . . .... . . 6 2 4.3. 3. Initiation and prioritizing ... ... . . ... . . . .... . . .. .. . . 6 3 4. 3. 4. Processing . . .. ... . . . ... . . . . ... . ... .... . . 6 7 4. 3. 5. Realization and tests ... , .•.. . . ... ... . ... . ... 70
4. 3.6. Implementation . . . .... .... ... ... . . . .... ... ... 7 3 4.4. Operations ... , ... , ... 74
6. Maintenance objects ... 90
6.1. From information systems to IT systems and businesses ... 91
6.2. IT systems and businesses as maintenance objects ... 92
6.3. Maintenance products and IT systems as maintenance objects ... 95
6.4. What is a maintenance product? ... 98
6.4. I. Characterization of maintenance products ... . . . .... .... •. . . . ... . . 98
7. Delimiting maintenance object and defining their contents .. 104
7 .1. Gradually evolved maintenance objects ... I 05 7.2. A model for delimiting maintenance objects ... 106
7.2. 1. Delimiting maintenance objects and defining their conte111s ... . . 113
7.3. Examples of delimitations and content definitions of maintenance objects ... 1 1 4 7. 3.1. Example I. Contelll definition of Human Resources (HR)-object .. . . .... I I 5 7. 3.2. Example 2. Content definition of an object for Topographical data . . . .... I I 6 7. 3.3. Example 3. Object division for facilitating activities .. . .. ... .... ... I 18 7. 3.4. Example 4. Content definition of Web channels .. .. . ... ... .... I 19 7.3.5. Example 5. Content definition of a data warehouse ... . . ... .. 121
8. Maintenance Organization ... 124
8.1. Organization form for system maintenance ... 1 2 5 8.2. Comparative analysis ... 1 3 2 8.2.1. Team based organization forms ... .••••••••... . . .. ..•.•... .. . ... 1 3 3 8. 2.2. The project organization . ... ... . . .. . .. ... . . .. . ... 1 3 4 8.2.3. The matrix organization . ... . .. . . .... . . ... .. ... 136
8.2. 4. Comparison between organization forms .. . . ... . . . ... 137 8.3. Roles ... 1 39
IO.The next step ... ... 156
11.Read more ... 158
I I. 1. Preface ... 1 59
11.2. Introduction (chapter I) ... 160 11.3. A businesslike perspective on maintenance (chapter 2) ... 16 3 11.4. Maintenance and maintenance activities (chapter 3 & 4) ... 164 11.5. Maintenance assignments (chapter 5) ... 16 5 I 1.6. The maintenance object (chapter 6) ... 16 5 11.7. Delimiting maintenance objects and defining their contents (chapter 7) ... 166 I 1.8. Maintenance organization (chapter 8) ... l 66 11.9. Maintenance management (chapter 9) ... 168
become a doctor in Informatics at Linkoping University and Tommy has implemented maintenance management and continued to develop the ideas and concepts regarding internal business within the scope of our joint company
Pa
AB.Furthermore, based on the research results and practical experience, we have further developed and packaged the reference model Business Oriented Maintenance Management into the maintenance manage ment model pm3. pm3 stands for
Pa
Maintenance Management Model. Pa, because Businesslike Maintenance Management is called the Pa model in many organizations and in English because many of our cus tomers have expressed needs for an English version. There is an English version of pm3 as well as a Swedish one. T his book has a slightly diffe rent character than our previous books. Whereas the earlier books have described our successively developed maintenance management model, chis book aims at increasing the understanding of manageable system maintenance. Our ambition is chat this book will fill the need for adequate literature in system maintenance education classes. When we were entering the system maintenance arena some 15, respectively 20 years ago, we felt chat there was an absence of such book. For those who are more interested in the packaged version of the model, we refer to the documentation of pm3 and for those interested in implementa tion of the model we refer to pm3 implementation box. Finally, for those who are mainly interested in reading about the development of knowledge that led to this book, we refer to the doctoral thesis Styrbar Systemforvaltning - att organisera forvaltningsverksamhet med hjalp av effektiva forvaltningsobjekt (in English: Manageable System Maintenance 1 Our fl1•st book about system maintenance was published in l 996- organizing maintenance with the help of efficient maintenance objects). These knowledge products can be ordered at www.pais.se.
In the same way as in our earlier books, we co m bine practice and theo ry and give hands-on tips on how to increase the manageability in sys te m maintenance. This book co mbines our practical experience from nearly 300 i mple mentations of Businesslike Maintenance Management (nowadays pm3), that we and our colleagues at
Pa
have carried out. Based on the research results, we can be more precise in this book, for instance regarding the content and deli mitations of maintenance objects and whether IT operations should be included in maintenance or not. It is not necessary for you to have read our earlier books to understand our message, but in this book we have taken the li berty of reflecting upon the knowledge development between this book and earlier pu blications that may be valuable to those who have read/worked with Business Oriented Maintenance Management before. We are very careful to point out that the knowledge development around system maintenance is an ongoing process for us and our colleagues atPa.
This book is no exception from that rule, it should be considered as a report fro m work in progress, though it is more theoretically grounded than earlier pu blications.Just as last ti me, we want to thank our colleagues at
Pa
AB, whose qua lified questions, sprung from practical problem situations, require us to continuously develop our knowledge about syste m maintenance.Further more, we want to thank Dataforeningen, who by publishing our book and arranging training and seminars show that system main tenance is an i mportant area.
Danderyd, Septem ber 2007
With the hope of enjoyable and rewarding reading, MALIN NORDSTROM OCH TOMMY WELANDER
1 . Introduction
Most organizations are becoming more and more dependent on IT systems to conduct their business. Vast financial sums and great amounts of time are invested to computerize businesses. Originally, the purpose of implementing IT systems has been to rationalize businesses and increase productivity, however as time has past the arguments have shifted to be more focused on the increase of quality in decision making and administration.
Nowadays we can see an increased amount of IT systems that actually do business. However, the benefits of an IT system can not be measu red and valued until there is a result of the usage, i.e. when the system is acquired and is in a maintenance situation. In a maintenance situa tion, IT systems are used and must at repeated occasions be changed at the same pace as the business activities they support. This simulta neous presence of use and change is characterizing for system mainte nance and results in that system maintenance must deliver change as well as stability to the business activities it supports. The daily business and IT operations must be guaranteed stability from maintenance, whereas the development activities must be guaranteed change. This situation can be directly paradoxical since change often is a threat to stability. In practice, however, the needs for change and stability exist side by side, which makes great demands on how system maintenance is organized. This book deals with the understanding of what is being done in system maintenance and how it should be organized in order to be manageable for the purpose of enabling increased business value. Galloping IT costs are often pointed out as a problem area in organi zations. Creating manageability in maintenance should be one way of solving the part of the problem that concerns existing IT systems and the change and support of these.
In the 1960:s and 1970:s, IT systems were mainly a concern for the internal IT departments in most organizations. They had their own resources and had a considerable amount of influence regarding how businesses should be rationalized with the help of IT systems. At that
ti me, syste m maintenance was o ften very dependent on key individua ls. This sit uation was bro ught into light in 1 980 by Riksdatafor b undet
(nowadays called Dataforeningen), who between the years of 1980 and 1 987 carried o ut a proje ct a bo ut system maintenance which ai med at co mpiling existing knowledge about system maintenan ce b ut also to sti mulate resear ch and develop ment in this area . They strived to change the manage ment of system maintenance a c cording to the following q uote :
"The most important content of this change is that the responsibility for this business is passed on to the user side and that the role of ADP is mainly to perform tasks initiated by the user side" (RDF, 1981, p VI).
The most well-lmown res ult of the proje ct is the set of roles in the for m of, e.g. syste m owner, syste m maintainer and operations manager that is used in many organizations today. Riksdataforb undet 's work is well in a c cordance with the fact that ever since the l 960's there has been a long-ter m trend to use market me chanisms inside organisations for the p urpose of in creasing prod uctivity, q uality and profitability. As a res ult of the fact that market me chanis ms were s uc cessively being used in organisations, an o utsour cing wave started in the beginning of the 1 990's. In pra ctice, this often meant that the for mer internal co mp u ter departments were made into independent co mpanies, or were sold to an external party who then also took over the I T maintenance responsi bility.
Today, we know that regardless of whether one has chosen to o utso ur ce ones technical maintenance or not, there is in most organizations a clear de mar cation between b usiness a ctivities and I T a ctivities (internal or external). Th us, there are good possibilities to clari fy the assignment relationships and create clear agreements regarding syste m maintenan ce, which in t urn in creases the possi bilities of creating maintenance that s upports the b usiness.
1 .2. What is system maintenance?
In Swedish, the term maintenance may direct the thoughts of the reader to public administration. In English, the word maintenance has strong technical ring to it. Whichever associations it brings, the term mainte nance is often confused with the organization that carries out the maintenance activities. Confusing the activities with the organization that does them is a common phenomenon, and a considerable pro blem in maintenance issues. In the book the terms are related to each other in the following way: An organization conducts business, it car ries out different activities. An activity is that which is done. The term organization often refers to a legal unit and the way responsibilities and authorities are divided in chis unit. However, dividing responsibilities and authorities is an important part of organizing a business and its activities. The terms business, activities and organization are further discussed in chapters 3 and 8. The organization term is clarified in sec tion 1.5.
Therefore, system maintenance means chat which is done, and this ''doing" is done by somebody. The doing in maintenance can be divi ded in two main types; upholding and further development. The upholding is often a combination of corrections, support and daily IT operations, whereas further development consists of adjustments and enhancements (which also may include the category removal). Conse quently we leave the traditional, in our opinion too narrow, basis of division of system maintenance, which usually consist of different types of change (corrections, adjustments, enhancements and removals). A deepened discussion around maintenance activities as well as the clari fying of boundaries between development and maintenance is made in chapter 3.
The international standardization organization IEEE (Institute of Electrical and Electronics Engineers) defines software maintenance as "modification of a software system or component after delivery to correct
faults, to improve pe,formance or other attributes, or to adapt the product to a changed environment" (IEEE, 1998). The mentioned change
gories are ba se d on Lientz an d Swansons (1980) categori zation in dif ferent types o f change. Since we have found that a ma intenance o bject must conta in more than the so ftware, we choo se to u se the ter m sys tem maintenance instead o f software maintenance. Furthe rmore , we o ften u se the term "maintenance management" to clarify that since furt her develo pment is inclu de d in maintenance, it is a proact ive business that needs to be manage d continually.
1 .3. Maintenance objects in maintenance
Since there are other phenomena and/or arte facts that are maintaine d apart fro m I T systems, for instance bu il ding s, roa ds and stock portfo l ios, we find it relevant to speak o f o bjects in ma intenance. Further more, ma intenance see ms meaningless unless there i s so meth ing to maintain. In this book, the term ma intenance o bject i s u se d to define and describe that wh ich is ma inta ine d. In the major part of the exi sting theories on sy ste m ma intenance, there i s a strong unani m ity chat it is the I T syste m that is the ma intenance o bject. Several authors quest ion the de finit ion of sy ste m ma intenance an d say that divergent de fin i tions may be the rea son why there is a l imited a mount o f mo dels and
metho ds for system ma intenance. The I T sy ste m a s a maintenance o bject is not questioned to any greater extent, however. We have found that several I T suppliers have been inspired by the o bject ter m and our
idea a bout th is, but at a closer look it is st ill only the I T sy ste m they re fer to. According to the book, an IT sy ste m i s the co m puterized pro cessing o f infor mation (1'efer to section
6.
I) and the technical com po nents that make s this possible . I n informatic s, it i s co m mon praxis to start by analy sing the business/activ ities when develop ing or chang ing an I T sy ste m, this al so goes for other change e fforts such a s Busine ssProcess Reeng ineering and in the qual ity area. In the ma intenance area this tradit ion is non-ex isting , wh ich may partly be expla ine d by the fact that the development of syste m ma intenance theory has mo stly been done in the so ftware engineering area - where the main focus is technology. Thus, the business that t he IT sy ste m shoul d support is not focu se d in earl ier sy ste m ma intenance theory. Th is may re sult in
isolated IT system maintenance with a low degree of business value. This is something that we paid attention to as early as in our first publications about system maintenance.
Since I T systems are more or less integrated in businesses, they affect them whether chis is to be desired or not. Thus, it is important co cla rify what role the IT systems play in businesses and what business solu tions they deliver. Our experience is that the IT systems' role in busi ness often remain uninvestigated, which may malce it difficult to con duct system maintenance that is well suited to its purpose. In chapter 6 , the discussion about the contents and delimitations of maintenance objects is deepened. Chapin (2003) enlightens the relationship between system maintenance and the business in the following way " ... mainte
nance is a main way of making intentional changes in how organizations work" (ibid p. I). If chis is the main way or not can be questioned, but in any case, it is one way of affecting the business in organizations.
1 .4. Change of metaphor for theory development
The research perspective in existing theories on system maintenance is often characterized by a life cycle reasoning where system maintenance theory is based on a development metaphor. Furthermore, there is a strive for motivating the existence of system maintenance activities on the basis of the extent it can be seen as development. This results in a situation where the assumed negative status of system maintenance in organizations is often pointed out as a problem area in system mainte nance literature, since this comparison seldom results in any advanta ges for maintenance. We think that continually touching upon the negative perspectives that is said to prevail regarding maintenance only results in enforcement of any prejudices that may exist. Against the background of our practical experience of system maintenance, we claim that the acclaimed negative status of maintenance in the field of practice is overrated in the existing system maintenance literature. It is true that we have identified frustration among individuals that work with system maintenance, regarding problems in maintenance, but tocl ai m th at it is a status proble m is t o simplify the wh ole c om plexity of a m ainten ance situ ati on. Ou r opini on is th at it is the bal ance between ch ange and stability as well as m any involve d internal and external parties th at are the g re atest ch allenges in s ystem m aintenance. Further m ore, we think th at s ystem m ainten ance deserves t o be researched and lmow ledge-devel ope d as a form of business itself and n ot be aut om atic ally viewed from a li fe c ycle perspective. This w ould p robably bec ome easier if the metaph or fo r lmowledge devel opment in the s ystem m ainten an ce are a changed. In the doct oral thesis Styr bar Syste mforv altning (in
English: Manageable Maintenance), an othe r metaphor is p resente d -the assignment metaphor. In this book -the assignment metaphor is acc ommod ate d in the businesslike pers pective (refer to chapter 2). In the fiel d of p r actic e, we s ometimes meet th ose wh o s ay th at structure d
m ainten ance is n o l onger necess ar y since the ch anges c ome at such sh ort inte rvals n ow adays. To us, the high speed of ch ange is the m ost i m portant m oti f why m aintenance is m ore i mp ort ant t od ay th an ever before. M ainten ance must functi on in a s atis factory w ay if the m ainte n ance org ani zati on is t o c ontinue t o supp ort businesses in a ch anging w orld - at the s ame time as the st ability is ensu red.
1 .5. Manageability is achieved by organizing
In orde r t o c onduct m aintenance in a businesslike m anner, it must first be organized. The org ani zing te r m is used acc ording t o Wick
(1969)
wh o me ant th at organi zing is s omething m ore than just organizational structu res and m an age ment. He me ant that "organizing aims for reducingthe number of events that may occur and the activities in the organizing aim for establishing a working level of security - and becoming possible to survey and understand''. M ore Businesslike System M aintenance is built on fou r central terms , m aintenance assign ment, m ainten ance object, m aintenance organization and m aintenance activities , which are all rel a ted t o the org ani zing te r m since the first three are me ans in the w ork of org ani zing m ainten ance. In the book, org ani zing is seen as a g oal
that aims for creating manageable mai ntenance . Manageable syste m maintenance is n ot an e nd in itsel f, but a means for c onducti ng main tenance that ful fils it purpose in supp orting the business i n question.
Our studies and experiences sh ow that manageable system mainte nance can be achieve d through;
• de marcating e fficient maintenance objects based on the business pr oducts
• the maintenance objects should contai n IT systems an d maintenance pr oducts
• maintenance plans with clear objectives c onstitute the i nstru ments of c ontr ol in mai ntenance
• organizing the cooperati on between the assig nme nt parties in a micr o
organizati on that ensures change and stability
How the organizing sh ould be done is the sc ope of this book . I n figure 1.1, an overview of central c oncepts is prese nted, which relates the cen tral terms i n this book t o each other .
The graph overview focuses organizing, but the result sh ould be mana geable maintenance (refer to the objectives and methods discussion above).
The four main c oncepts i .e. mai ntenance objects, mai nte nance organi zati on, mainte na nce assignme nts and mai ntenance activities are mar ked i n grey t o illustrate their r ole as means for orga nizing. Further more, the overview c ontains a nu mber of ter ms that are re ferential such as business activities an d I T activities, which are necessary t o make it meaning ful t o talk a b out syste m maintenance . The term "business acti vities" re fers t o business activities/ facilitati ng activities i n which IT sys tems are used (refer to section 3.1).
responsible for consists of Ansvars· roller monned by Individuals --------------------------: IT-solution Maintenance ! --- Products ___ j Business products --- ---Business Activities IT Activities •-------------
-Figure 1.1 Central concepts in More Businesslike Maintenance Management.
The po int of reference in this book is mainte nan ce. To continually start in the a ctivities has bee n a way in creat ing a prag mati c fra mewo rk for manageable maintena nce. Maintenan ce is constit uted by fo ur mai n a ctivit ies ; su pport, cha nge manage ment, mai nte na nce manage ment a nd o peratio ns. Maintenance is ma naged by different maintena nce assign ments between two pa rt ies. The ma intenan ce o rgan ization is the pro ducer of maintena nce and co nd ucts mainte na nce. The ma intena nce o rga nizatio n is built by roles which a re ma nne d by rep resentatives fro m representat ives for the ma intenance pa rt ies . The ma intenance organ izatio n is respons ible for a ma intena nce o bject that is de ma rcated by the bus iness products and co ntains IT syste ms as well as mainte nance p roducts. The ma intena nce o bje ct co nstit utes the basis for as well as the result of ma intena nce. The ma intena nce o bject, the ma inte nance organi zatio n and the mai nte na nce assign ment a re des cribed in a main tena nce plan that ma nages the wo rk of the ma intena nce o rganizatio n.
1 . 6. The disposition of the book
The book is a rranged a ro und the four ce nt ral conce pts that ca n be regarded as co mpo nents in the creation of ma nagea ble ma intenan ce ; ma intenance a ct ivities, maintenance assig nments, ma intena nce o bjects and ma intena nce o rgan izat ion. Each co mpo ne nt is des cr ibe d theoret i cally as well as w ith pra cti cal exa mples. As we w rite in the p re face, the book a ddresses those who work in mainte nan ce as well as those who want to lmow what maintenan ce is . Aime d at the latter, chapte r 4 des cribes what is do ne in mainte na nce. For someone in the fiel d of p ra ct ice, these des criptio ns may seem s upe rfluo us a nd in that case, we
reco mmend moving o n to the next cha pte r.
Th is is not a n academic thes is, a nd th us there a re no dire ct de ma nds on refe rences . Eve n so, we thi nk it is p rope r to speci fy the so urces that we have use d, an d thus also give so me tips for fu rthe r rea ding fo r those who want to go dee pe r in so me pa rti cular a rea. Hen ce, refe ren ces an d co mments to these are ha ndle d in a s pe ci fic, con clu di ng chapte r an d not i n a refere nce l ist.
2. A businesslike perspective on maintenance
The term b usi ness is use d wi th ma ny di ffere nt mea ni ngs. S ometimes i t re fers to the agreeme nt bet ween tw o par ties, s ome ti mes it re fers to thedelivery a nd s ome ti mes the busi ness term is c ombi ne d wi th ac tivi ties a nd the n it ofte n refers t o the c ore b usi ness of a n orga ni zati on. This multi -facet te d mea ni ng of the term res ults i n c onfusion regardi ng the mea ni ng of the term. Th us, there is a nee d for talking about the mea ni ng of the term whe n i t is bei ng use d. We use the term b usi nesslike t o describe the c ondi tion that we thi nk sh ould characterize mai ntena nce . The busi nesslike pers pective is a synthesis be tween di fferent the ories
(refer to section 11.3), a nd even more so our joi nt experience, from doi ng busi ness i n di fferent k ind of busi nesses duri ng a l ong ti me . I n this chapter, we descri be wha t b usi nesslike mea ns. The b usi nesslike pers pective is central i n our entire pers pective on mai ntenance a nd th us, in
this chap ter, we refer t o di ffere nt secti ons of the book whe re the b usi nesslike perspective is p ut i nt o a mai nte na nce c ontext.
2. 1 . Our perspective on what businesslike is
We have had consi dera ble s uccess on the market when we referre d to syste m mai nte na nce as a for m of busi ness (transactions) betwee n thebusi ness a nd the I T par ties. I t has been hel pful to clari fy the c ommit me nts of each party a nd we have calle d this a joi nt resp onsi bility b ut for di ffere nt parts of the mai nte na nce b usi ness. Through research, we have i de nti fie d several b usi nesses (agreements and transactions) that
a ffect mai nte na nce, a nd th us we i ntroduce the term assignme nt that we find s uitable for the e ntirety. The mai ntena nce busi ness betwee n the busi ness party a nd the IT party is th us a case of assignme nt , which we further develop below a nd i n chapter 5.
Whe n the parties are b usi nesslike, i t res ults i n g ood busi ness, which i n turn results i n satis fie d assig nme nt parties i n the sh or t run as well as i n the long run. le is not e nough if the seller a nd buyer i n mai nte nance busi ness are satisfie d, the pri ncipals (often represented by management junctions) muse also be satisfied in the short r un as well as i n the long r un.
Thus, being businesslike is a precondition for making good business. Good business results in high profitability.
In this context we want to point out that satisfaction with one's work, efficiency and wellbeing also result in monetary profitability.
Most people will probably agree with us that business should be good business, but our experiences from the market often speak of other things than good business. There are those who have the opinion that good business is when the seller makes as much money as possible. Of course, this kind of business exists, but it is not good business. Figure 2 illustrates our perspective on the power balance between the seller and the buyer in maintenance businesses.
BUSINESS
TECHNOLOGY
--- --- r---. USER iI
ADP ---__ L_ ---. CUSTOMERI
i SUPPLIER 'Figure 2.1, Historical retrospect
The development has gone from the monopolistic data departments of the 60's and ?O's, who from a rationalization point decided themselves what the users needed, via the customer-oriented phase of the 80's and 90's where the growing buyer-organizations had all the responsibility. Now, in 2006, it is time to focus the business relations instead of pla cing the responsibility with any of the parties.
Both parties have a joint responsibility for the business, but for different parts of it. It is just as wrong to manage the assignment solely from the IT party (the selle,) as it is to put the entire responsibility on the busi ness party (the buye,). It is the good business that needs to be focused.
Our basic perspective is that all kinds of b usiness sho uld be carried out in a businesslike manner. Since this book is about maintenance, however, we will focus the maintenance assignment - maintaining an object in a b usinesslike manner. Maintenance o ften involves many parties (refer to section 5. 1). We usually focus the internal assignments, which is why we start this chapter with a re flection upon this ; internal assignments.
2.2. Internal assignments and business
In internal assign ments , the relat ions may be seen as a triad, which contains t wo result units where one can be seen as b uyer and the other seller, an d a relation bet ween these and the manage ment, according to fig ure 2.2. This res ults in a sit uation where those who make the agree ments concerning the internal delivery consi der it as an assign ment with a seller/ buyer relation (i.e. business), whereas the management sees it as an assignment to make the organization more e fficient. In fig ure 2.2, we have vis ual ise d this with the main parties of the maintenance assignment.
MANAGEMENT
0
BUSINESS PARTY IT PARTY
Figure 2.2, The triad situation in internal assignments
The management controls the b usiness parties an d I T parties, b ut since most organizations have intro duced market-rese m bling coopera tion, there is also so me kind of inter organizational control bet ween
business and IT. Thus, maintenance has elements of both ideal types of management in the literature; hierarchic and market-based manage ment. In the hierarchic ideal type, a structured division of authority into different levels of control together with a common objective is assumed to solve the need for control. In the ideal type market-based management, the main actors seller and buyer are considered to strive for fulfilling their own purposes in the exchange, based on conflicting interests and a lack ofloyalty. The prize is considered the most impor tant information for decision-malci�g and the competition is considered to be a protection against misbehaviour from the seller.
Our opinion is that the greatest complexity factor in an internal assign ment is the very relation that is mentioned in the triad - which is a hybrid of the control mechanisms hierarchical and market-based management. The element of hierarchical management in internal assignments creates a possibility for agreements that is not present in assignments between external parties. If one does not reach an agree ment in the internal assignment, the matter can be escalated to someo ne who can solve the strife. However, it is not unlikely that the triad situation can lead to more conflicts in internal assignments than in external ones. Since there is a defined hierarchic control over the inter nal markets, superior to the relations between the operational units, these relations may even become more complicated than they would have been in assignments with an external organization. For instance, the financing inside the organization is usually centralized which means that there may be internal competition regarding capital. The co-workers are expected to act according to the business ideas, objectives and strategies of the organization, but it is not certain that the mana gement in practice gives the internal buyers a free hand to choose bet ween internal and external suppliers etc. However, there has been more focus on internal assignments lately, and more and more people are of the opinion that co-workers are less likely to create customer satisfac tion if they themselves are not content and engaged. This is illustrated in a quote from Normann "What you can not sell to your own staff, you
can not sell to the customer" {Arnerup-Cooper and Edvardsson, 1998 p 232). Thus, the rel ati on between the in ternal seller and the intern al buyer are si milar t o the wh ole org anizati ons supplying rel ati on wi th the external cus tomers.
2. 3. The conditions for being businesslike
Through experience and research, we h ave found th at a businesslike line of acti on is achieved by ;
• value-b ased attitude and behavi our
• assignmen t manage ment with in terac ti on
• buy able ass ortmen t based on a cl arified added v alue -chain
• agreed business in terac tions
2.3. 1 . Value-based attitude and behaviour
We s tar t wi th the individu al perspec tive, since i t is n ot organi zations that make business wi th e ach other, it is pe ople. Even the best of ideas can be destr oyed by a seller or buyer with the wr ong a ttitude or beh a vi our. Our percepti on is tha t a basic attitude on the individual level sh ould be th at "it depends on me''. I t depends on me to make sure that the w ork cli mate is good, it depends on me to make the mos t of this ch ange, it depends on me th at there is a g ood delivery to my buyers, which I c an personally v ouch for.
I t is i mp ortant that the org ani zation w orks ou t and es ta b lishes the b asic values th at are relevan t for the business p ar ty. If one c onsiders oneself to be a seller and buyer in in ternal assign ments - what d oes th at mean for the individu al ? If the g ood business is the objec tive, i t is i mp ortant to have a v alue-based opinion a b out which attitude and what c onduct the individuals in the org aniza ti on should s trive for. These issues, or more c orrectly, the answers, sh ould be c ommon and shared. The following example is from a c onsultancy assign ment where we w orked with v alue-based atti tude and behavi our among the opera tions technici ans in a b ank.
Attitude;
• be proud of one's company/organization
• be open for the suggested solution and believe in it
• be positive to the buyer/seller
• see the obstacles without focusing them
• want to do business
• believe in the agreed business interaction
Behaviour;
• ace honestly, enthusiastically and actively in the business process • use the meeting form chat the business demands
• ask questions and listen actively to ensure the right solution
• dare to take the next step
• argue based on the problems/needs of ones buyer • plan the next step
In order to make good business, all concerned business parties and roles must act in a businesslike manner. It is not enough that one per son, or a few, in the organization are businesslike. The business can not be said to be businesslike if those who have roles that are close to the customer are businesslike - if those who build the solution or are responsible for the delivery are not.
We use the terms buyer and seller when we speak of a specific mainte nance business. We see the assigner as the buyer and the assignment taker as the seller and their assignment is to conduct maintenance in a businesslike manner. By calling the assignment taker a seller, we get a more active role than a "taker''. It is all about malcing business, not pas sively receive an assignment chat someone else has already defined. Furthermore, calling the assigner a buyer gives the effect of participa tion in the assignment in a more continuous manner.
2.3.2. Assignment management with interaction
The idea of introducing assignment management in maintenance is not new, it was first presented by Berntsson and Welander (1991), who suggested that assignment management should be introduced in main tenance with the motivation that actors in business and IT were even different "nationalities''. Unlike in external business, the internal busi nesses have an internal principal according to the discussion above. Thus, it is important that this principal orders the assignment and gives a well-defined assignment to the buyer and the seller to conduct businesslike system maintenance. This assignment is called a role assign ment, i.e. when a department has an assignment to conduct a certain type of business.
Organizations can be producers in a business, but the organizations themselves can not perform activities. The activities in an organization are carried out by actors, who in their different roles have che authori ty co act on behalf of the organization (based on role assignments). Since system maintenance often is an internal assignment, we have a need for another level in organizations, one that can carry out assignments. The natural thing may have been to use terms such as department or unit. But these terms are proven to be too limiting, since there is often a dis crepancy between a business and its organization regarding mainten ance, we use the term "party" instead. The term party is used for a unit whose role assignment is to conduct a certain type of business/activities, for instance IT activities or business activities. Thus, the party repre sents a certain type of activities. A party can be an organizational unit, for instance the IT department in an organization can represent the IT activities, but there may also be other IT parties that carry out IT acti vities.
The assignment is an important component in becoming businesslike. The assignment ensures that the business is conducted according to the intentions of the assigner, which means that it may have a control ling influence on maintenance. The assignment as a precondition, and thus its controlling effect, has many similarities to that which is called
co nt ract ma nage me nt. Co ntract ma nage me nt mea ns "management of activities that are performed by external contractors or internal actors based on contracts, in the form of agreements with a binding effect" (Bryntse, 2000, p 3). Unlike the ma nage ment between the ma nagerial fu nctio ns and depart me nts a nd units, there is no hiera rchical autho rity here, whe re o ne of the parties can co ntrol the othe r. Co nt ract ma nage ment shoul d not be see n as a disti nctive cont rol mechanism, but rather as a co ntrol mechanis m that combines diffe re nt i nst ru ments of co ntrol i n o rde r to achieve e fficie nt ma nage me nt . We use the term assignment ma nage me nt, a nd by this we mea n that the e ntirety of i de nti fied assig nme nts in a n o rga ni zation is the basis for the ma nage me nt of the busi ness. I n mai ntenance, this mea ns the assig nme nts desc ri bed i n table 5. Within a n assig nme nt there may be seve ral i nstru me nts of con t rol, fo r i nstance ma nageme nt by objectives a nd activity ma nage me nt
(section 9. I).
We thi nk that most people will ag ree with us that it is di fficult to buy a nd supply IT solutio ns with the i nte nded quality, withi n the given time limits and to the p ro mised cost. IT-o rders a re usu ally hard to de fine - i n spite of carefully made re quire me nts fro m the buyers side, the re qui re me nts usually cha nge du ring the realizatio n of the final I T solu tion. Thus , there is often a need fo r successive re fine me nt of each si ng le IT business. I n order for this successive refine me nt to be possible, there is a need fo r so me ki nd of i nteractio n between selle r a nd buye r.
We ofte n see examples that a mai ntenance cont ract is expected to rep lace the co mmu nication betwee n buye r a nd seller. This may be the rea so n why ma ny o rgani zatio ns a re still searching for the busi ness value that they were looki ng fo r when they chose to outsou rce. The reaso n fo r this may be that the bigge r part of the resea rch i n co nt ract ma na ge me nt is a bout the decisio n whether to outsou rce o r not, co nsi de ra bly less is a bout what happe ns o nce the co nt ract is signed. We think that by u nde rstandi ng system mai ntena nce activities a nd the most co m mo n ma nage me nt activities afte r the sig ning of the cont ract a nd the o b jectives that follow i n stakehol de rs a nd thei r relatio ns du ri ng these activities, the buyer a nd the selle r should be able to plan a nd ma nage
thei r c ont racts bette r. In our opinion, a comp lex phen omen on su ch as system m ainten an ce c an never be c ompletely spe ci fie d in a c ontract, and th at the c on ditions c ontinu ally change, which rai se s demands on c ontinu ous man age ment an d c ommun ic ati on du ring the c ontract pe ri od. The reason fo r this i s th at the degree of m an age ment m ay ch ange al ong with the c on dition s. Fu rtherm ore, it i s i mp ortant initially t o set aside en ough ti me for e stabli sh ment of c ontrol me ch anisms as well as relati on s between se lle r and buyer. Once the c ont ract i s put into acti on, manage ment processes must be i mplemented, as wel l as stru c ture s th at promote su pplie r su c ce ss. Even after th at, the re shou ld be regular routines for c om munic ati on and c ontrol, and one shoul d ensu re th at inform ation and ag ree ments are c orre ctly understood through protocol s an d c onfirmati on s. The purpose of the c ont rol sh ould n ot be t o literally che c k th at the c ontract spe ci ficati on s are met, but rather be a w ay of m aintaining the kn owledge and h ave a di al ogue about the mainten an ce activities an d their re su lt. B oth p arties sh ou ld also be wil ling and re ady t o solve proble m s qui ckly when they oc cur.
It i s far too c ommon th at the buyer as well as the seller i s dissatisfied when it c omes t o pure forms of c ontract man age ment. We h ave all p ro
bably he ard an d seen c on siderably more examp les of fai le d purch asing situati on s th an su c ce ssful one s. Diffe rent org ani zati on s are t rying to be c ome better at making re quire ments spe ci fications and u se m ore an d m ore adv anced te chni c al t ools for this. But we think th at the solution rather lies in a c lear focu s on the assignment an d effe ctive interacti on between the i denti fied bu siness partie s. This interacti on sh ou ld be managed by c ont ract too.
2.3.3. A buyable assortment based on darified added value
An i mp ort ant basi c pe rspe ctive for being bu sinesslike i s ch at all busi ness sh ould re su lt in a produ ct (or several). These p roducts should be u sable for the business p arty's buye rs when they the m se lve s are making their own produ cts. This cre ate s something th at i s u su ally c alled an added v alue ch ain. We u se the term produ ct as a resu lt of a business
(the activities in a business) and in the term we include the results that normally are divided in products and services.
The IT party in an· organization is an important internal business party that needs to deliver well-defined and buyable products to internal buy ers. The total delive1y from an IT party regarding technical system main tenance is probably something along the lines of
'a
functioning IT solu tion to the defined businesses/assignments taking care of change as welt as sta bility''. By creating internal businesses with clarified added value, good conditions for a profitable external business are created. In maintenance, the overall business value is mainly constituted by changes in IT systems and maintenance products and lmowledge support to these (refer to section 6.4) . In order to become more precise regarding the value, one must understand the business and the maintenance object.
The reasoning above may sound trivial, but we often meet organiza tions that do not go any further than describing activities - they do not describe what these activities result in. Once it is established where in the internal value chain one is, the added value can be defined and expressed. The selling business party should base its assortment on the added value. The products should not only be sellable, but also buy able. We have seen many service- and product catalogues with detailed lists of the entire assortment in a grouped-together and complex way. The fault with these is that they can not be bought since they are made entirely from a production perspective. There are models and business process descriptions that are based on the sellers perspective which dec lare that everyone in the organization works to satisfy the end custo mer. This is true, of course, but it may be difficult for "Chadie the
Operator" to see, and moreover, to understand the needs of /lnne the Bank Customer" from the perspective of his own work. Other model describe that everything starts in the market needs, but it may be dif ficult to malce the market describe its needs in terms that the selling organization can understand. Moreover, it is not possible to "build a new factory" every time the market needs change. Our business process is a synthesis of both these perspectives, as shown in figure 2.3.
Business activities Facilitating activities IT activities External suppliers M A R K E T / '\ '\. \.
Figure 2.3 A business model
�
The business model takes its starti;,_g point in the market needs, which raise demands on the business parties, which in turn raise demands on the IT parties. When this works, the IT parties support the facilitating parties which in turn support the business parties, which then satisfy the external market needs. Thus, a two-way internal business process is created. The model is generic and can be used on a macro level as well as a micro level. In maintenance, the facilitating activities are the same as business related maintenance and the IT activities are the same as IT related maintenance (refer to section 3. 1). A common problem is that it
is unclear which parties are in which business chain. There is much to gain for organizations in clarifying which added value each party deli vers in the internal business processes.
2.3.4. Agreed business interactions
Finally, it is important to make agreements regarding businesses. In the previous section, we discussed contract management as a control form where activities are performed based on contracts. In system mainte nance, there is often a unanimity regarding the fact that complex busi nesses can be managed by contracts, but there is less unanimity
ding how it i s done o r how it should be done. Cont ract management i s a popular cont rol form in the cases where IT activities are outsour ced. The re are two main directions; eithe r you pay fo r what i s being done, or you pay the supplier co keep the custo me rs sati sfied. These two extre me s can be divided in th ree kinds of contracts;
• se rvice contracts
• st rategic alliance s/ partne rsh ips
• hiring cont racts
Se rvice contracts de mand detailed contracts which fully speci fy the need s, ser vice levels, mea sure ments of perfo rmance, fine s and prices.
Fu rthe rmore, it requi re s short-ter m contracts which last only for the period of time during which the needs can be predicted. Thi s type of cont ract is conside red to be mo st effective for IT activities where the organizations can clearly de fine thei r need s in fool-p roo f cont racts, for instance where the technology i s matu re and sta ble. In a st rategic alli ance , the parties ente r into a long-ter m collaboration where the re i s giving and taking from both sides. In hiring cont racts, the co mpetence i s hi red fro m anothe r company, but the hiring party manages it within their own co m pany.
We often come ac ross ag ree ments which we usually call "gallows docu ments''. They mainly state how the selling party p rotects itself by vario us cleve r formulations, or who should be "hanged" if so mething hap pen s. The se types of agree ments a re mere petitions and the co mmit ments o f both pa rties a re seldo m speci fied. Another p roble m i s that inte rn al ag ree ments are o ften sent between the negotiator s until a com forta ble level of a bstraction i s reached. Thi s means that both pa rties can accept the wordings, but leave the negotiation ta ble with two di f
fe rent, but not expre ssed, images o f what the bu siness contains. In o rder to avoid this and c reate ag ree ments with real penetration, the ag reements should be proce ssed by the concerned pa rties togethe r, and then be decided u pon by the concerned deci sion-make rs. It i s i m po r tant to write agreements a bout IT bu sinesse s in a way that allow s a suc cessive re fine ment of the agreement and how this should be achieved.
The business/assignment should be well defined and the agreements should contain the commitments of both parties. This is extra impor tant since one is very dependent on each other to build the right solu tion. How the business should be reported and who measures what and when should also be specified.
Our opinion is that for agreements to be considered as businesslike, they should be;
• signed between the concerned business parties
• contain the commitments of the seller as well as the buyer
• contain a description of the business in a measurable, realistic and
well-defined manner
• be processed by the concerned parties together
Thus, the agreements become the instruments of control that they should be. IT agreements are often regulated in different levels where framework agreements regulate the possibility to make business, where as suborder agreements regulate specific agreements. Figure 2.4 descri bes a functioning agreement structure chat we usually use in organiza tions when we help them with agreements/agreement structures.
FRAMEWORK AGRE MENT
Business agreement
FRAMEWORK
AGREEMENT FRAMEWORK AGREEMENT
, ---..
' '
' '
i
Delivery agreement for each object regarding:i
! •
development ---1 I : • maintenance : ' 'i •
operationsi
' ' 1_ -- - - --- --- -- ---- - --- - --- - --- --- IOn the top level, the re should be a business agree ment that regul ates the total IT business, e.g. between the CEO and the CI O. This agree
ment would de al with pu rch asin g o f extern al resou rces, p rinciples for ch arging and control for ms. The framewo rk level may conce rn, e.g. a business are a o r p roduct are a and i s si gned between the concerned
inte rn al business partie s. Finally, below the fr amework agreements there should al so be delivery agree ments between the p arties re garding develop ment, mainten ance and operations. Examples of these deliver y agreements are project plans fo r develo pment, mainten ance pl ans for syste m maintenance and S LA:s for ope rations. Regardin g maintenance, we u se maintenance pl an s as agree ments re garding a specific mainte n ance business. I n section 9.2, we describe wh at they contain and how
3. Maintenance
By maintenance activities, we mean that which is done within the scope of maintenance. In this chapter, basic concepts regarding main tenance are introduced and the activities of maintenance are presented. The chapter is ended with a definition of maintenance. For deeper descriptions of maintenance activities, refer to chapter 4.
3. 1 . Three central types of business
The term business is used for what is being done, with or without the help of I T systems. However, the term business has often come to be used as a term for the organizational unit that carries out the activities that the IT system supports. When talking about economy business, it is often the economy department that is referred to, even if economy business (such as accounting, budgeting and reporting) is carried out in many units in an organization. This confusion between business and organization may have considerable consequences in maintenance, since the giver of assignments and the receiver of them are usually in the same organization. Successful organizing demands the ability to separate business and organization. In maintenance it is relevant to refer to organizational units in the terms of parties. An organizational unit within an organization conducts business, and it is quite common that a certain party conducts different types of business. The factor that decides which business is to be conducted, should be the assign ment given to the parry.
In order to describe system maintenance we use different sub catego ries of the business concept. The term business activities is used to describe a set of activities - activities of any kind - which is why we are dependent on a generic term to be used no matter which business acti vities we mean. There may be several units in an organization that carry out sales activities. By IT activities, we mean the technically ori ented activities that are performed to handle IT systems. This work is often divided into the main activities IT development, IT maintenance and IT operations. By maintenance activities, we mean the activities
that are performed in a maintenance situation. Figure 3.1 shows the relations between these three different types of businesses.
BUSINESS ACTIVITIES
A
MAINTENANCE ACTIVITIESC
IT ACTIVITIESE
.. -----
---, A) Business activitiesB) Business related maintenance C) Maintenance management D) IT related maintenance E) IT activities ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ---.J
Figure 3. 1 The relation between business activities, maintenance activities and IT activities
Maintenance is often regarded as a set of sub activities to business acti vities and IT activities, which aim to ensure change and stability in IT systems and maintenance products. This means that a business in this case has two sub businesses in the form of business activities excluding maintenance (field A), and business related maintenance activities (field B). IT activities have, in their turn, two sub businesses; I T main tenance and IT operations (field D) and I T development (field E). Field C is the joint management of maintenance, (field B and D) which arises since maintenance is regarded as sub activities to business activi ties and I T activities and thus, there is a need for joint management. Maintenance management (field CJ is not regarded as a part of the management of the business activities and IT activities. The intentions
in the business activitie s and in the IT activitie s should be the main b asi s for m ainten an ce m an agement, in o rder to ensure th at the business pe r spe ctive as we ll as the IT perspective i s t aken into considerat ion. This pe r spe ctive i s a development of the exi sting theorie s reg ard ing
syste m m ainten ance and it i s a con seq uence of the d iscovered need for se parating busine ss and o rg ani zation. Earlie r theo ries were based on the assu m ption th at the business activ it ie s (field A) and the business related m aintenance (field BJ were conducted by the same organizational parry, but in the org ani zat ions of today, this assu mption i s no longer v alid. The most co mmon situation i s th at there are m any parties who conduct all the activit ie s th at descri bed in figure 3.1. If one does not sep arate o rg an ization fro m busine ss/ activities in this aspe ct, there i s a risk that the m aintenan ce assignment be co me s an i ssue th at involve s two I T p artie s. This i s so meth ing th at we en counter very o ften in org a nizations. The IT syste ms th at are m aintained h ave a rel ation to certain business activitie s th at are pre formed, not to a spe ci fic o rg ani zation al p arty. In m any o rg ani zation s profe ssion ali sed m ainten an ce partie s h ave e me rged, i .e. parties who h ave the assign ment to purch ase the h and
ling ofIT syste ms w ith intern al and exte rn al parties. These purch asing org anizations do not conduct business activities, they conduct purch a sing activ itie s for IT. This o ften le ads to a situation where those who conduct the busine ss activities th at the IT sy stem s support l ack the opportunity to in fluence the IT system s, wh ich often results in i sol ated I T sy ste m m aintenance with low custo mer sati sfaction. Furthermore, it i s co m mon in these situ at ions th at m ainten ance tends to beco me sel f-gene r ating and e stranged fro m the needs of the p arties th at con d uct the business act ivities. When b usiness activitie s ·and m ainten an ce activities coincide in an o rg anization al party, this pro blem seldom o cc urs. In order to avoid i solated I T system maintenance and sel f-generating m ainten an ce activities, all involved partie s must be identified and the m ainten an ce p roduct (mult) must be identified and p ackaged in a w ay th at m ake them usable in business activitie s (refer to section 6.4).
3. 1 . 1 . The delimitation between maintenance activities and business activities
In order to concretize the theoretical model above, we will illustrate it with an example from a HR business. The example in figure 3.2 1s from a HR business in a Swedish government authority.
A
C
� D
!/
\
E
'\\
Field A; Business Activities Field B, C and D; Maintenance activities Field E; IT activities
Examples of activities: Examples of aclivilies: Examples of activilies:
• Recruit • Manage maintenance • Develop new
• Administrate wages and • Support users enterprise system
business trips • Manage changes • Maintain the
• Conduct management- • Corry out operations technical platform
reviews
• Corry out personnel
analysis
• Knowledge management
• Handle personal data • Manage HR issues
• Drow up on HR strategy
• Develop methods and
fools
• Terminate employments
Figure 3.2 The delimitation between business activities and maintenance activities
The business activities (field A) were about recruiting, administrating
wages and business trips, conducting management reviews, carrying out personnel analysis, knowledge management, handling of personal
data, managing HR issues, drawing up an HR strategy, developing methods and tools and termination of employments. The HR activities were carried out centrally in the HR department, but mainly by the managers in the organization and their assistants. This meant that the business party situation was quite complex. The result of the HR acti vities was identified as personnel cards, contracts of employment, HR strategy, travel documents and leaving certificates. The maintenance activities were change management, support, IT operations and main tenance management for the 1 0 IT systems that were used in the busi ness activities.
Furthermore, this work meant taking responsibility for processes and methods regarding the HR activities since they were often built into the IT systems. Maintenance was conducted by people who were orga nized in the central HR department, people who were organized in the internal IT department and by external suppliers. The IT activities that were delimited from this object were separated in a big project that was aimed at purchasing an enterprise system which would, partly, replace the existing IT systems. The biggest problem in this maintenance busi ness was to achieve a functioning communication between those in the business activities and those in business related maintenance activities, i.e. those who were responsible for making requirements on IT deve lopment. By making a clear delimitation between the business activi ties and the maintenance activities and identifying the maintenance object, we could analyze the responsibilities in this situation and clarify who was responsible for what. This resulted in a collaboration regar ding maintenance that was characterized by a joint responsibility but for separate parts.
In section 7.3.1, the example above comes back again, but then from an object delimitation perspective which was also the basis for the organizing. The example shows that by separating business from orga nization, it is possible to delimit business activities from maintenance activities and make these activities manageable separately - even though they are strongly dependent on each other. The business
vities are m anaged in the b ase o rg anization, whe reas the m aintenance activities are m an aged in a m aintenance org ani zation (refer to chapter 8), the rel ation will thus be the s ame as that between a line organiza tion and a project org anization.
In ou r expe rience, there is often con fusion between business activities and m ainten ance activities, which c auses disorder - most of all in those who m an the m aintenance o rg ani zation. W h at do they rep resent -business activities or maintenance activities ? The responsibility for business rel ated m aintenance is sometimes integ r ated into the business activity assignment and is so metimes a sep arate bus iness are a (often called purchasing organizations). It may also be integ r ated in the IT acti vity assign ment , which is so mething th at we h ave found mainly in
loc al authority org ani zations and he althcare org ani zations. No m atter how the assign ment is divided, it m ay be di fficult to achieve e fficient
m aintenance only through man age ment in the b ase org anization (for instance line organization or matrix organization), since maintenance concerns several org ani zational units - so meti mes even external ones.
In orde r to make m aintenance manageable, it is necessary to m ake well-defined deli mitations between business activities and maintenance
activities .
3.1 .2. The delimitation between maintenance and develop ment activities
The deli mitation between maintenance and develop ment is an issue that is o ften de b ated in the o rg anizations that we meet. Most people see m to h ave an opinion on this m atter -o ften it is most intensely dis cussed between IT p arties and purch asing p arties. The discussion tends to be pol arizing and cover whethe r everything or nothing should be regarded as m aintenance or develop ment and which is the best w ay of me asuring to find the deli mit ation. Among the p arties in bus iness acti vities, the question does not see m to be of the s ame current interest ; the activities run into e ach other and it is the s ame people who are engaged in m aintenance activities as wel l as development activities. To be more precise, the discussion conce rns develop ment and ch ange
management, i.e. how many changes should be made within the scope of the maintenance organization, and in the line organization or the project organization. We have met both extremes in several organiza tions; "all change is development" and "all change is maintenance''.
However, our experience is that none of the perspectives above will last long in an organization. The idea of what is prioritized varies over time, which probably indicates that the extremes are not very usable. Furthermore, they are seldom used as they were intended to, since there is a certain freedom of action for the co-workers to categorize activities based on what is regarded as prioritized. For instance, a num ber of small changes can be grouped into a bigger change and thus be seen as development if development is prioritized. Similarly, a conside rably large change can be divided into phases and be regarded as main tenance. We would like to contribute to playing down the issue of development and maintenance as each others opposites. Research and practical experience shows that it is suitable that maintenance contains upholding as well as further development in order to deliver business solutions with a high degree of customer satisfaction.
This means that in practice, one must accept that there is a grey zone
between development and maintenance (refer to figure 3.3) since parts
of maintenance simply are development. This grey zone should not be left uninvestigated in the specific case, however.
Maintenance
Preservation Further
development development New Figu1·e 3.3 The relation between maintenance and development
By reg arding m ainten ance as a bu sine s s and c re ating pos sibilitie s fo r a m anagement th at re se mble s project m an age ment, one c an si mply choose if a cert ain activity shoul d be performed within the re spon si bi lity are a of the m ainten ance o rg ani zation o r if it should be pe rformed as develop ment in the form of a project. Fu rthe rmo re , it i s entirely po s sible to u se the p roject form fo r a limited activity which i s pe rfor
med within the scope of m ai nten ance.
The degree of change c an be guidi ng in how to h andle sep arate activi ties. The m ainten ance o rg ani zation should be re sponsible for stability an d ch ange at the s ame ti me, which m ay be limiti ng fo r the po s si bility of performing l arge ch anges. Anothe r po s si ble deli mitation c an be th at when change s affect seve ral m ainten ance o bjects, they are h andle d in projects. However, thi s re quire s th at the m ai ntenance objects are of a substanti al si ze , othe rwi se there will prob ably be coordination p ro ble m s between p rojects.
Reg ardle s s if an activity i s performed withi n the scope of the m ainte n ance o rg ani zation o r in p roject fo rm, de m and s should be m ade on s ati s fyi ng reporting of costs. If nece s s ary, it i s po s si ble to report "stabi lity costs" separately. One of the fundamental ideas in busines slike m ainten ance m an age me nt i s to m ake hidden co st s visi ble for the pur pose of m aking the m m an age able.
3.2. Maintenance activities and their develop
ment over time
M ai ntenance h as o ften been de scri bed as a co m mon te rm fo r co rrec tion s, adju st ments, enh ancement s an d removals, which me an s th at m aintenance i s synony mous with ch ange m an age ment. Thi s de finition h as been que stio ned, howeve r, by p ractitione rs as well as re se archers -and we are amongst them. Below, a de sc ription i s m ade of how the activities in ou r public ation s h ave develope d over time an d the argu ments why. I T operation s i s p articul arly focused as m ainten ance acti vity since our l atest lmowledge cont ribution. Fo r those who are not
