I den første del af serien talte vi om, hvordan vi kan blive usundt afhængige af vores leverandør, og frem for alt hvilke problemer dette kan medføre for vores virksomhed.
I dag skal vi se på, hvad vi kan gøre for at undgå en sådan afhængighed.
1. Bevare ejerskabet til proces- og systemviden samt planer for udviklingen heraf
Hvis du beslutter dig for, at du ikke vil bekymre Om os og i stedet giver din IT-leverandør generelle instrukser, er du godt på vej mod afhængighed. Det vil måske overraske dig, at denne fremgangsmåde ofte skaber problemer for selve leverandøren, for efter et stykke tid begynder kundens krav at overlappe hinanden og blive indviklede, og det bliver et stort problem for leverandøren at imødekomme de nye krav.
For en virksomhed, der ønsker at forblive konkurrencedygtig, er det vigtigt at betragte it som et redskab til at understøtte, forbedre og måle sine processer. Det er ikke svært at finde ud af, hvordan man gør dette, for i dag har vi tilstrækkeligt med metoder og standarder, der gør det muligt at bevare overblikket over processerne og gennemføre en effektiv planlægning:
- Enterprisearkitektur – en metode til at beskrive en organisations mål, de måder, hvorpå disse mål nås gennem forretningsprocesser, og hvordan disse processer kan understøttes af teknologi. For yderligere information henvises til artiklen »Don't get bogged down« af Poor Enterprise Architecture. De to mest kendte tilgange til enterprisearkitektur findes på hjemmesiderne for The Open Group og Zachmann.
- Procesbeskrivelse – de mest kendte og udbredte standarder er udarbejdet af Open Management Group (www.omg.org). Ved at beskrive processer i henhold til BPMN-specifikationen (Business Process Model and Notation) kan virksomhedsledelsen nemt gennemgå og dokumentere de processer, der foregår i virksomheden.
- Brugervejledning – det behøver ikke at være et dokument, der er udarbejdet af leverandøren og derefter gemt væk i en skuffe, hvor det samler støv. En god fremgangsmåde er at optage videoer, der viser brugerne, hvordan de bruger applikationen i deres daglige arbejde; hvilket forenkler produktsupport og oplæring af nye brugere. Videoerne er ofte kun få minutter lange og beskriver alt, hvad man behøver at vide for at bruge systemet effektivt. Se for eksempel vejledningen til brug af Yammer i et forskningsprojekt; eller vejledningen til, hvordan man bestiller varer fra en onlinebutik.
Alle standarder og metoder ledsages af omfattende dokumentation og undervisningsmateriale, der beskriver hvert enkelt område i detaljer. Efter min erfaring er det en god idé at ansætte en specialist, der kan udvælge de dele af metoden, der passer til den pågældende virksomhed.
Hvis du systematiserer din viden, får du ikke blot et redskab til at drøfte emner, der kan føre til forbedringer i virksomheden, men du får også vished for, at du vil kunne finde fælles fodslag med langt de fleste af dine nuværende og potentielle leverandører.
Hvis du ønsker at ændre noget i dine processer og informationsstrømme, skal du starte med at foretage ændringer i arbejdets tilrettelæggelse – enten på modelniveau eller gennem et pilotprojekt – og teste, om ændringen vil medføre de fordele, du forventer. Beregn derefter fordelene ved ændringen og omkostningerne ved at gennemføre den. Hvis alt er, som det skal være, kan du begynde at ændre systemerne, og hvis ikke, kan du stoppe forløbet uden problemer. Når du overlader dette fuldstændigt til en ekstern leverandør, er der kun få, der har modet til at stoppe et projekt, som vi allerede har investeret ressourcer i.
2. Dataene skal under alle omstændigheder tilhøre dig
Dataene opbevares hos vores leverandør; nu er vi kommet på kant med dem, og de har fortalt os, at dataene tilhører dem... Desværre er denne situation ikke så usædvanlig, som man måske skulle tro. Det sker ikke så ofte hos udbydere af cloud-tjenester og hosting, som mange antager, men oftest hos specialudviklede systemer, hvor dataene opbevares i en »black box«, der er fuldt ud kontrolleret af leverandøren.
Dette er en traditionel metode til at holde kunden under leverandørens kontrol. Problemet kan generelt løses på to måder – enten ved direkte at kontrollere dataene eller ved at sikre en pålidelig måde at indhente dem på i et brugbart format.
For eksempel en tjeneste til administration af e-mailkontakter, som vi får ved at registrere os på vores leverandørs hjemmeside. Den første fremgangsmåde går ud på at sikre, at dataene replikeres i vores egne systemer, og den anden går ud på regelmæssigt at downloade de oplysninger, der er gemt i leverandørens systemer, og gemme dem hos os som en sikkerhedsforanstaltning.
Selv i vores eget system, hvor datalagringen er velbeskrevet, kan en metode til eksport af data til en standardtabel, en database eller XML i høj grad lette integrationen af et nyt system. Det er vigtigt at fastlægge procedurer for dataudtræk, verifikation af, at eksporten fungerer, og at formatet er godt dokumenteret, fordi det kritiske øjeblik, hvor vi har brug for at hente dataene, netop er det værste tidspunkt at opdage, at eksporten ikke fungerer, eller at de perfekt eksporterede data er kodet i et format, vi ikke kan arbejde med.
Ovenstående krav bør kontrolleres, når der godkendes nye funktioner eller ændringer i systemerne fra leverandøren.
3. Behold rettighederne til applikationerne
Ejerskabet til applikationer omfatter ejerskabet til applikationens kildekode eller design. Hvis vi ikke har kontrol over kildekoden, risikerer vi, at vi, når vi ønsker at skifte leverandør, vil opdage, at den nuværende leverandør ejer en afgørende del af koden og ikke vil være villig til at stille den til rådighed gratis. Vi kan undgå dette ved klart at definere ejerskabet i kontrakten og angive, at den kode, der udvikles som følge af de ønskede ændringer, udelukkende er vores ejendom, eller at disse ændringer skabes under en licens, der giver os ret til at bruge og distribuere dem gratis.
Selvom vi kontraktmæssigt har sikret os ejendomsretten, betyder det ikke, at den leverandør, som vi er Om os opsige kontrakten med, vil give os adgang til koden. Af denne grund anbefales det på det kraftigste, at kildekontrolsystemet, wiki’en og andre dokumenter opbevares hos en tredjepart, og at partneren forpligtes til at gemme dataene på et bestemt sted og på et bestemt tidspunkt, så vi har adgang til de aktuelle versioner.
4. Systemintegration frem for udvidelse af funktionaliteten
Webtjeneste-API'er (Application Programming Interfaces) er i dag en almindelig del af mange kommercielle og open source-applikationer. Det betyder, at alle de funktioner, der er tilgængelige for brugerne af applikationerne, også kan anvendes på tværs af forskellige systemer og applikationer.
Ved at anvende protokoller og standarder til at definere denne grænseflade udgør disse tjenester et samlet kommunikationsmiddel og en fælles platform; et program skrevet i et bestemt sprog eller på et bestemt operativsystem kan dermed kommunikere med systemer, der er udviklet på en helt anden måde. Data overføres i et fælles format, såsom XML eller JSON, og kodebaserne i de to systemer forbliver fuldstændig Uafhængig.
I dag kan enhver bruger forestille sig, hvordan systemintegration fungerer. Vi bruger jo alle webapplikationstjenester, der er integreret med hinanden – for eksempel Google Kalender med Google Kontakter og Gmail. Hvis vi beslutter os for at begynde at bruge en anden kalender i stedet for den eksisterende, behøver vi blot at forbinde den med de eksisterende data. Denne metode til at skifte system er ikke mulig, hvis vi har vores eget system, som vi oprindeligt kun købte til regnskab og gradvist fik leverandøren til at udvikle et CRM-modul, servicemodul osv.
Den samme logik gælder for integration med systemer, der leveres som en tjeneste af cloududbydere (SaaS – Software as a Service). Brugen af webservices adskiller de enkelte applikationer fra hinanden, hvilket gør hele systemet mere fleksibelt og transparent. Tværtimod gør faste forbindelser mellem forskellige moduler det lettere for leverandøren at øge vores afhængighed af dem, øge kodens kompleksitet, og systemets fleksibilitet bliver begrænset af den mindst fleksible del.
5. Forsøg at holde ændringer i standardsystemet på et minimum
Prøv at implementere det ønskede system med så få ændringer som muligt i forhold til standardimplementeringen. Du er som regel ikke leverandørens første kunde. Prøv at drage størst mulig nytte af leverandørens erfaringer med andre kunder under implementeringen. Du vil sandsynligvis blive overrasket over, hvor meget mere effektivt visse processer kan gennemføres, eller at visse data, vi tidligere har overset, vil blive vores konkurrencefordel.
Hvis vi kræver væsentlige ændringer af applikationens funktionalitet, kan dette i betydelig grad komplicere overgangen til nye versioner i fremtiden, og enhver overgang vil være en udfordring med hensyn til udvikling og implementering.
6. Brug flere leverandører
Prøv selv at stå for hele systemets design, udvikling, implementering og drift, og overlad det ikke til leverandøren. Det er en god idé at adskille forretningsanalytikere fra udviklere, for eksempel. Det er en god idé at få systemet testet af testere, der står uden for udviklerteamet. De vil udføre arbejdet mere effektivt, og sandsynligheden for, at du får et fejlfrit produkt, er langt større. Hvis en anden part er ansvarlig for driften (f.eks. en cloud-udbyder), skal du sikre dig, at de presser udviklerne til at levere et produkt, der minimerer driftsproblemerne i systemet.
7. Angiv opsigelsesproceduren i kontrakten, herunder sanktioner for leverandøren
Hvordan er opsigelse af samarbejdet fastlagt i kontrakten? Tre måneders opsigelsesvarsel, hvorefter I holder op med at betale, og leverandøren ophører med at yde support? Det er helt utilstrækkeligt.
Det er nødvendigt at præcisere, hvilken dokumentation og i hvilken kvalitet leverandøren skal stille til rådighed for dig – eller direkte til den nye leverandør – i opsigelsesperioden. Hvis du har sikret dig immaterielle rettigheder til designet, kildekoden og andre dele af den dokumentation, der er nævnt i punkt 3, er det så meget desto bedre. Når du indgår en kontrakt med en leverandør, er det en god idé at tjekke med de virksomheder, der kom på 2. og 3. pladsen, hvad de har brug for, hvis de skal overtage udvikling og vedligeholdelse fra vinderen.
8. Informer leverandørerne om de fremtidige udviklingsplaner
Arbejd på at opbygge et langsigtet partnerskab med dine leverandører. Hvis du regelmæssigt drøfter dine udviklingsplaner og strategiske spørgsmål med dem – og ikke kun aktuelle ændringer i funktionaliteten – kan leverandøren komme med forslag, der skaber en systemarkitektur, der er stabil, effektiv og omkostningseffektiv, ikke kun i forhold til dine nuværende behov, men også i forhold til fremtidige behov. For at præcisere dine krav kan du f.eks. bruge MuSCoW-metoden, som inddeler kravene i følgende kategorier:
- Et must – et must
- Burde have – burde have
- Kunne have – ville være rart at have
- Det behøver jeg ikke denne gang
9. Indhent ideer og synspunkter fra andre parter
Bliv ikke stående på ét sted; følg med i tendenserne; søg efter de bedste metoder og fremgangsmåder; og hold øje med det hele. Ansæt et firma for at få en tredjepartsvurdering – de vil vurdere dine beslutninger både ud fra et teknisk og strategisk perspektiv. Det behøver ikke at være dyrt. Og en sådan rådgivning er pengene værd, fordi den vil hjælpe dig med at undgå fejl. Ud fra min erfaring kender jeg til et tilfælde, hvor en leverandør tvang en kunde til at investere flere millioner kroner i at løse et problem, som han selv havde forårsaget; og en konsulent fandt ud af, at investeringen slet ikke ville løse problemet, fordi problemet lå et andet sted.
En konsulent kan hjælpe dig med at fastlægge din strategi, skabe efterspørgsel, vurdere mulighederne og se tingene fra en uventet vinkel. De kan også hjælpe dig med at gennemgå dine leverandører og sikre det bedst mulige resultat for dig. En konsulent bør altid have i baghovedet, at du ønsker at være Uafhængig en bestemt leverandør, og at du anerkender værdien af din egen viden som en konkurrencemæssig fordel.
Det rigtige valg af leverandører er Om os
Jeg tror, at du efter at have læst denne artikel har fået et klarere billede af, hvordan du kan gøre dine leverandører til partnere i din succes og undgå at blive deres vasal. For at undgå ubehagelige situationer handler Om os og Om os at vælge løsninger, der skaber balance mellem de nuværende krav og fremtidig fleksibilitet. Ved at følge ovenstående principper sikrer du, at du træffer det rigtige valg af leverandører og nye systemer.
