Mölnlycke Health Care

Mölnlycke Health Care (MHC) är en internationell koncern som tidigare var en division inom bolaget SCA. MHC tillverkar engångsprodukter för operation och sårvård. Koncernen är uppdelad i ett antal dotterbolag med huvudkontor i Göteborg. Antalet anställda globalt är drygt 6000 varav 350 arbetar i Sverige. MHC:s två affärsområden är Operation och Sårvård. Inom Operation tillverkas produkter designade för att skapa en bättre miljö i operationssalar, exempelvis operationsrockar, personalkläder, olika engångsprodukter för användning i operationssalen och kundanpassade operationsset. Inom Sårvård tillverkas bland annat förband med mjuk silikon, kirurgiska förband, absorberande förband och sårkontaktlager. Tillverkning sker för närvarande i Belgien, Tjeckien, Finland, Malaysia, Thailand och Storbritannien. Totalt uppgick koncernens omsättning år 2007 till 3,6 miljarder kronor.

Personen vi intervjuat heter Lars Jerrestrand, IT direktör, Mölnlycke Health Care. Han har arbetat inom företaget sedan 2001 och har ett övergripande ansvar för företagets globala IT infrastruktur. I detta ligger teknisk drift och teknisk arkitektur för båda användarmiljö och applikationer. Innan han tillträde som IT direktör har Lars en mångårig erfarenhet av arbete från olika IT leverantörs företag.

Bakgrund och drivkrafter till investeringen

Lars beskriver att deras IT infrastruktur varit tvådelad, SAP miljön, och de delar som ligger utanför SAP miljön. Dessa miljöer har genom åren behövt integreras och det har varit den drivande orsaken till att MHC vid olika tillfällen investerat i olika integrationsplattformar.

”Integrationsplattformen blir liksom nyckeln att knyta ihop allt. SAP måste ju ha en integrationsplattform kring sig och då har man ju valet att vilken är den bästa produkten kring detta för oss.”

Lars förtydligar MHC:s behov av en integrationsplattform.

”Om jag säger så, har du inte en integrationsplattform så har du inte en fungerade integration och hela affärsflödena bygger på att du har en fungerande integrationsstruktur. Kan du inte skicka igenom fraktsedlar genom hela ditt flöde kan du inte leverera produkter. Kan du inte få fakturorna att flöda genom din struktur och din meddelandeplattform kan du inte leverera fakturor. Det finns dessa grundläggande saker som integrationsstrukturen måste klara av, så det är inte riktig en

fråga om att inte ha eller ha utan mer att man måste ha en integrationsplattform för att hantera dessa transaktioner. Och dessa behöver bytas ut ibland.”

Lars redogör för att det framförallt skett tre större byten av integrationsplattformar under den tid han arbetat på MHC. Den första investeringen skedde då MHC 2000-2001 bröt sig ur SCA. På grund av att SCA sedan tidigare hade integrationsplattformen Amtrix byggde MHC upp en egen Amtrix plattform för att kunna flytta över data till denna. Beslutet föregicks mot denna bakgrund inte av någon omfattande beslutsprocess utan mer utifrån att detta var den lösning som MHC ansåg enklast just då.

”Första valet var när MHC bröt sig ur SCA, då var det så att SCA hade en integrationsplattform som hette Amtrix och då var man tvungen att ta över kundflöden och EDI flöden. För att klara detta var man tvungen att bygga upp en egen Amtrix miljö. Man flyttade sedan över data från SCA:s integrationsplattform till MHC:s egna Amtrix plattform. Det var det kravet som fanns då.”

Inom MHC blev senare Amtrix integrationsplattformen mot affärssystemet SAP. Men med tiden undergrävdes dock framtiden för Amtrix plattformen menar Lars.

”Amtrix är en egen produkt som vandrat ett antal olika vägar. Från början utvecklades den inom Frontec, dagens Acando, men sedan såldes och köptes den fram och tillbaka mellan olika leverantörer vilket ledde till att kunderna blev skakis. För vår del inträffade det under 2002-2003. IT kraschen påverkade även på så sätt att det blev dåligt med Amtrixkompetens på marknaden. Vi knöt upp folk från Frontec för att hålla plattformen vid liv medan många gick över till något annat.” Problemet med kompetens kring Amtrix och ett nytt affärsbehov som uppmärksammats under ett projekt i Tyskland 2004 bidrog till att MHC behövde en ny integrationsplattform.

”Sedan kom det upp ett affärsbehov från ett projekt nere i Tyskland om att man skulle integreras mot olika portaler, health care portaler, som egentligen knöt upp ett antal sjukhus bakom sig och sedan fanns det vad man kallar en samlingspunkt och så skulle man prata med den för att förse den med kataloginformation och en massa andra tjänster. […] För att hantera detta krävdes en ny integrationsplattform.”

För att lösa problemet lade projektgruppen i Tyskland fram en lösning baserad på BizTalk, men då denna lösning inte tillgodosåg ett globalt behov omformades lösningen. I samband med detta förekom en del intern diskussion mellan framförallt projektgruppen som tyckte att de hade en färdig och bra lösning och ledande representanter för IT verksamheten, men efter ett litet tag var alla överens och ett upphandlingsförfarande startades där slutligen Tibco valdes som integrationsplattform.

”Upphandlingen gick till så att man gjorde en utvärdering av olika plattformar utifrån kraven. På den tiden hade SAP i princip ingenting och deras produkt var inte tillräckligt tillförlitlig än, så här tittade man på IBM WebSphere och andra alternativ. På slutet stod valet mellan WebSphere och Tibco, där valet föll på Tibco på grund av att licenskostnaderna för IBM:s produkt var för höga.”

År 2007, ett och ett halvt år efter Tibco satts i drift valde MHC att återigen byta integrationsplattform. Denna gång till SAP XI som nu heter SAP PI. Från och med 2008 är även Amtrix och Tibco plattformarna helt avvecklade.

”Vår organisation är väldigt SAP centrisk och man fick problem med att hålla Tibco plattformen i luften på grund av olika skäl. Tibco var en helt okej plattform men ungefär som med att köra en bil, kör du en bil och aldrig kör in den på verkstad så degenererar den till slut.”

Lars menar att valet av SAP PI som integrationsplattform kan ses ur lite olika aspekter som är relevanta att beakta vid investeringar i integrationsprodukter, och då framförallt SAP produkter. Sett ur ett arkitekturellt perspektiv var MHC tvungna att bygga till ett antal SAP miljöer kring SAP PI för att allt skulle fungera.

”Tittar man på rena arkitekturfrågor kan man säga att SAP PI är en SAP setup som ihop med det projektet vi körde krävde att man byggde en mängd olika miljöer runt omkring, så vi fick ett antal miljöer kring SAP PI.”

En annan aspekt som relaterar till SAP PI är att integrationsplattformen inte är en traditionell SAP produkt menar Lars.

”Utmaningen i detta är ju den att SAP PI inte är en traditionell SAP produkt, det finns både en java- och en ABAB stack. Och kring java delarna krävs det en helt annan kompetens och den kompetensen finns inte alltid hos de externa leverantörerna. Och det har varit en liten bumpig resa kan man väl säga men nu är det uppe och snurrar och är operationellt.”

En tredje aspekt som Lars tar upp är att ett val av SAP produkter leder till högre driftkostnader. ”Väljer man SAP produkter så har man en högre driftkostnad, men många går ju in i dessa saker utan att man är så medveten om dessa kostnader, man skall inte underskatta de löpande driftmässiga och operationella kostnaderna kopplade till integrationsplattformar och inte minst kopplade till SAP PI.”

Som ett exempel på detta beskriver Lars att driftkostnaderna och de operationella kostnaderna för SAP PI var ungefär 10 gånger större än för Amtrix plattformen.

”Själv när man då frågar leverantörerna om vad de ser för operationella och driftmässiga kostnadsskillnader mellan dessa plattformar. Då får man svaret att det är väl en faktor 10 mellan att hantera Amtrix som är väldigt enkel och traditionellt kopplad och SAP PI. Här har vi alltså en skillnad i drift och operationella kostnader som i högsta graden är signifikant. […] Det blev ju en aha upplevelse för oss när vi tittade på SAP PI plattformen. När vi hade Amtrix och Tibco plattformen låg vi på några hundra gigabyte i datamängd medan nu med SAP handlade datamängden istället om total cirka 2,3 terabyte för alla systemfunktioner kring SAP PI.”

Lars berättar vidare att de inom MHC än så länge inte har någon EA modell som grund för sitt sätt att arbeta med arkitekturfrågor.

”Någon EA modell kan jag inte säga att vi har, då talar man lite vidare strukturer och vi är inte framme i den delen än men vi driver ett arbete för att ta fram en struktur kring EA.”

Lars beskriver även hur SAP PI plattformen förhåller sig till och tillgodoser kraven från den del av IT infrastrukturen som inte ingår i SAP miljön.

”Det finns ju ett antal andra system som inte är SAP och som måste kommunicera och samverka både inom och utom SAP och det ställer ju en del krav på denna. Hittills har SAP PI med de inte alltför stora kraven tillgodosett dessa krav med de övriga systemen men vi får se hur detta tillgodoses framöver. Hittills har man tillgodosett detta genom ett antal tilläggsadapters som man köpt från SAP.”

Beslutsprocessen som ledde fram till investeringen

Valet att välja SAP PI initierades av ledningen och var ett beslut som följde gällande IT strategi att i så stor mån som möjligt bygga IT infrastrukturen på SAP produkter. Investeringen var på detta sätt ännu ett steg i ledet att skapa ett mer standardiserat IT landskap med SAP som nav. ”Så då beslutandes om att gå in i en produkt som det stod SAP på och då valde man SAP PI som integrationsplattform.” Som underlag för investeringen i SAP PI lades det fram ett antal business case. Dessa togs främst fram utifrån, vid den tiden, kända och troliga förutsättningar menar Lars.

”Utgående från dessa business case jag skulle vilja säga att det inte gjorts någon formell uppföljning på dessa efteråt.” De som fick ansvar för investeringen var IT verksamheten.

”Vi har ju en struktur systemägare, där vår ICC grupp, som utifrån ett SAP perspektiv har ett ansvar för de olika inlagda interfacen i SAP PI miljön. Det har de gjort ett bra jobb med, bra dokumenterat och bra strukturerat.”

Lars kan inte beskriva några direkta utmaningar i beslutsprocessen däremot beskriver Lars att det funnits utmaningar ur ett kostandsperspektiv och ett kompetensperspektiv kopplat till investeringen i SAP PI.

”Det är ju alltid så att om vi tittar i SAP implementationen så har det saknats kompetens hos de olika inblandade parterna, speciellt på leverantörssidan. Om man ser till integrationsprojekt överlag så är det åtta av tio projekt som går över tid och tar längre tid än planerat. […] Man har ju alltid en stor kostnadsmassa kring SAP och andra sidan är SAP väldigt bra när allt väl faller på plats.”

Betydelsefulla faktorer för investeringsbeslutet

Det som drev investeringen i SAP PI ur ett strategiskt perspektiv var visionen om en mer enhetlig och standardiserad IT infrastruktur. Detta hade en större inverkan på beslutet än de ekonomiska faktorerna menar Lars.

Ur ett tekniskt perspektiv säger Lars att det framförallt var två faktorer som var viktiga. Dels att MHC länge arbetat med SAP och har byggt upp en god kompetens kring SAP, både internt men även hos deras externa partners, och dels den rådande IT strategin om att bygga IT infrastrukturen på SAP produkter.

Sett ur ett kulturellt perspektiv betonar Lars att MHC är en SAP organisation vilket påverkade beslutet.

”Vi är en SAP organisation och det påverkade beslutet ganska starkt.”

Lars berättar att gällande verksamhetsmässiga aspekter på investeringen så kan man se det på ett enkelt sätt. För att kunna integrera sina system, den klassiska integrationen som Lars beskriver, är det är inte en fråga om att ha det eller inte ha det, utan det måste MHC ha. För detta behövs en eller flera integrationsplattformar.

Sammanfattning Mölnlycke Health Care Strategiska

Vision om ett enhetligt IT landskap

o Enhetlig och standardiserad IT infrastruktur IT strategin

o Integration skall ske genom en integrationsplattform

Att kunna integrera affärssystemet SAP med den övriga IT infrastrukturen

Tekniska IT strategin

o IT infrastrukturen, SAP produkter skall väljas i första hand God kompetens kring SAP

o Internt

o Externt hos partners

Verksamhetsmässiga

Måste ha en integrationsplattform för att kunna integrera system på ett bra sätt

Kulturella

Vana att arbeta i en SAP miljö

Den befintliga IT infrastrukturen präglades mycket av SAP produkter

Ekonomiska

Business case för investeringen