Informationsväxel V8

I samband med hantering av underhållsåtgärder dokumenterar OKG ABs konstruktionsenheter utformning och konstruktionsdata i företagets

konstruktionssystem. Objektidentiteter med tillhörande kravdata för nya och/eller ändrade objekt- och delobjekt i ärendet är konstruktionsdata som en systemingenjör tillsammans med en detaljkonstruktör dokumenterar i konstruktionssystemet. Efter det att den här informationen har överförts till ODU måste underhållsavdelningen bland annat bryta ner huvudartikeln i fristående stycklistor, bedöma behovet av reservdelar och koppla artiklar till aktuell anläggningsidentitet. Om man exempelvis har köpt in en ny artikel med ett annat fabrikat måste det göras en koppling mellan objekt och huvudartikel i ODU. Eftersom detaljkonstruktören vet vilka artiklar som berörs i ärendet och då fabrikatet oftast är känt i konstruktionsfasen kan

detaljkonstruktören göra den här kopplingen i konstruktionssystemet. På så sätt skulle den här informationen överföras med informationsväxel V8 direkt och kopplingen skulle inte behöva göras i ODU efter överföringen, detta skulle resultera i besparingar av både tid och pengar. För att det här ska bli möjligt krävs ändringar i system och rutiner, på grund av reduceringen av tid och kostnader som förändringen skulle medföra kan den här ändringen vara värt besväret.

7.8 Datorstöd i underhållsåtgärdsprocessen

När man tittar på listan som finns i slutet av resultatdelen över samtliga datorstöd som används i de olika stegen i processen för eltekniska och mekaniska underhållsåtgärder tycker jag att man slås av tanken att det är väldigt många applikationer. En anledning till det stora antalet kan vara att det har uppkommit behov av ny elektronisk lagring av data med tiden, därigenom har man köpt in och/eller tagit fram applikationer som stödjer respektive behov. Istället för att integrera nödvändiga funktioner i befintliga applikationer har man köpt in nya. Ett exempel är applikationen Rosetten som

används för att ta fram en montagepärm för mekaniska åtgärder. Jag anser att det hade varit betydligt lämpligare att lägga in en funktion i konstruktionssystemet som används på konstruktionsenheten för mekanisk teknik för det här ändamålet. På så sätt hade man dragit stora fördelar som jag nämnt tidigare i avsnitt 7.1.3.

En nackdel med det stora antalet applikationer är att det sker dubbelinmatning. Ett exempel på detta är när montageledaren för ett mekaniskt ärende ska ta fram en montagepärm. Då matar montageledaren in uppgifter i Rosetten som en konstruktör redan har tagit fram i Oden under konstruktionsfasen. Dubbelinmatningar innebär onödig lagring av samma data, det leder också till att det krävs mer tid för hanteringen av underhållsåtgärden.

En annan nackdel som finns med det stora antalet applikationer är kostnaderna för service och support som eventuellt finns för respektive applikation. Det kan också vara så att man har köpt in applikationer för vilka det saknas service och support, det här är inte heller bra då en applikation eventuellt kan behöva omkonstrueras om man exempelvis behöver en ny funktion. Jag anser också att det blir svårt att ha översikt över helheten för en underhållsåtgärd när olika uppgifter som ingår under hanteringen genomförs i så pass många olika applikationer. Det är ansvarig handläggare för en underhållsåtgärd som ska hålla ihop alla olika delar under processens gång.

Handläggaren skulle kunna följa och se helheten för varje ärende på ett betydligt bättre sätt om man hade ett integrerat system för hantering av ärenden och

konstruktionsdata. I Oden kan handläggaren sedan exempelvis gå in och titta hur långt konstruktören har kommit i konstruktionsfasen och på så sätt hålla en bättre koll på ärendet. Dock integreras inget moderniserat uppdragsuppföljningssystem i den här applikationen, det här är något som det finns ett behov av hos handläggarna enligt vad jag nämnde tidigare. För att underlätta handläggarens arbete måste denne ha tillgång till ett uppdragsuppföljningsregister som visar de ärenden för vilka denne är ansvarig. Detta register ska helst kunna redigeras av handläggaren själv för att få en så snabb uppdatering som möjligt och för att handläggaren ska kunna dokumentera detaljerad information.

När det gäller de Word- och Excelmallar som används i processen tycker jag att dessa borde integreras i övriga applikationer. De artikelspecifikationer som tas fram på konstruktionsenheten för mekanisk teknik utgör exempelvis excelblad som lagras i en separat databas. Dessa specifikationer borde lämpligtvis läggas in i Oden så att de blir mer lättillgängliga för konstruktörerna, så att de därmed inte behöver ta fram dessa separat. Om det skulle finnas ett integrerat system för hantering av ärenden, dokument och konstruktionsdata så finns det även möjlighet att lägga in de meddelanden och intyg som ska tas fram under hanteringen av en underhållsåtgärd i systemet. Fördelen med det här är att dessa blir mer lättillgängliga och antalet applikationer minskar. Jag tycker därför att man ska sträva efter att få så många av de separata Word- och Exceldokument som möjligt integrerade i de applikationer som används i hanteringen av underhållsåtgärder.

Om man tittar på antal applikationer för eltekniska och mekaniska ärenden så kommer antalet applikationer att sjunka i och med att Oden börjar gälla. Ärendedatabasen och Alladin kommer att ersättas av Oden vilket minskar antalet för båda inriktningarna. Man borde undersöka möjligheten att integrera de funktioner som

uppdragsuppföljningssystemet Tuppen* erbjuder i Oden, för att på så sätt minska antalet ytterligare. Det här är funktioner som jag anser vore användbara även för mekaniska ärenden, då skulle även problemet med uppföljning av ärenden för konstruktörer på konstruktionsenheten för mekanisk teknik lösas. När det gäller de mekaniska ärendena kommer Rosetten fortfarande efter Odens inträdande att ligga som en egen applikation. Jag anser enligt vad jag nämnde tidigare att konstruktören under konstruktionsprocessen borde ta fram montagepärmen och att Rosetten borde sluta användas, detta för att eliminera dubbelinmatning, vinna tid och minska antalet applikationer.

Det finns dock en stor nackdel med ett integrerat system i vilket flera applikationer ingår. Vid de tillfällen då Oden står stilla är det många som berörs och som inte kan utföra sitt arbete. Man måste överväga denna nackdel mot de fördelar som finns. De applikationer som saknar service- och supportstöd måste på ett eller annat sätt förnyas eller ersättas. Genom att minska antalet applikationer kan man skapa en integrerad lösning för ärenden. För att åstadkomma en hög tillgänglighet kan fokus läggas på att bygga en infrastruktur, drift- och supportorganisation för applikationen Oden istället för att sprida ut detta fokus på ett stort antal applikationer.

Efter att ha satt mig in i processen för underhållsåtgärder på en mycket detaljerad nivå har jag identifierat ett problem när det gäller uppföljningen. Det saknas en applikation med ett uppföljningssystem där man kan se de hållpunkter som finns att stödjas mot

under hanteringen av ett ärende. Det finns inget bra system för att följa upp datum för när exempelvis konstruktionsunderlaget ska vara klart. Genom att man i ett tidigt skede fattar beslut om genomförandetid skapas automatiskt hållpunkter för när konstruktionsunderlaget ska vara färdigt, vilken tidpunkt beslut måste ha tagits om införande och när planeringsenheten måste ha tillgång till arbetsorder för att planera in arbetet. Jag tror att översikten över hanteringen av underhållsåtgärder skulle förbättras betydligt med ett sådant system. Verksamhetsansvarig chef skulle då kunna kontrollera ärenden på ett bättre sätt och därför rekommenderar jag att ett uppföljningssystem för underhållsåtgärder etableras.

En tanke som slog mig var att uppföljningssystemet möjligen kunde administreras av planeringsenheten i applikationen Primavera som de nyttjar. Därmed skulle planerarna kunna ha ansvaret för planeringen av hela hanteringen av underhållsåtgärder. Då de har lämplig kunskap för detta ändamål och eftersom Primavera är ett

planeringsverktyg ser jag det som en bra lösning. Om det är möjligt skulle Primavera lämpligtvis integreras i Oden så att samtliga som är involverade i hanteringen av underhållsåtgärder och som har tillgång till Oden skulle kunna gå in och följa upp ärenden där. En annan lösning är att skapa ett uppföljningssystem direkt i Oden. Under arbetets gång har jag reflekterat över att hela den här processen med hantering av underhållsåtgärder präglas av god kommunikation. Det räcker inte med att ha många applikationer som stödjer respektive aktivitet i processen. En aktiv kommunikation är en nödvändighet mellan samtliga inblandade parter för att processen ska fungera.