I den första delen av serien diskuterade vi hur vi kan bli ohälsosamt beroende av vår leverantör och, framför allt, vilka problem detta kan orsaka för vårt företag.
Idag ska vi titta på vad vi kan göra för att undvika ett sådant beroende.
1. Behålla äganderätten till process- och systemkunskap samt planer för deras vidareutveckling
Om du bestämmer dig för att inte bry dig Om oss och istället ger allmänna instruktioner till din IT-leverantör, är du på god väg mot ett beroendeförhållande. Det som kanske kommer att överraska dig är att detta tillvägagångssätt ofta skapar problem för leverantören själv; för efter ett tag börjar kundens krav överlappa varandra och trassla ihop sig, och det blir ett stort problem för leverantören att uppfylla de nya kraven.
För ett företag som vill förbli konkurrenskraftigt är det viktigt att betrakta IT som ett verktyg för att stödja, förbättra och mäta sina processer. Det är inte svårt att ta reda på hur man gör detta, eftersom vi idag har tillräckligt med metoder och standarder som gör det möjligt för oss att behålla överblicken över processerna och genomföra en effektiv planering:
- Företagsarkitektur – ett sätt att beskriva en organisations mål, hur dessa mål uppnås genom affärsprocesser och hur dessa processer kan stödjas av teknik. För mer information, se artikeln ”Don't get bogged down” av Poor Enterprise Architecture. De två mest kända metoderna för företagsarkitektur finns på webbplatserna för The Open Group och Zachmann.
- Processbeskrivning – de mest kända och mest använda standarderna har tagits fram av Open Management Group (www.omg.org). Genom att beskriva processer enligt BPMN-specifikationen (Business Process Model and Notation) kan företagsledningen enkelt förstå och dokumentera de processer som pågår inom företaget.
- Användardokumentation – det behöver inte vara ett dokument som leverantören skriver och som sedan hamnar i en byrålåda för att samla damm. Ett bra tillvägagångssätt är att spela in videor som visar användarna hur de använder applikationen i sitt dagliga arbete; detta förenklar produktsupport och utbildning för nya användare. Videorna är ofta bara några minuter långa och beskriver allt du behöver veta för att använda systemet effektivt. Ta till exempel en titt på guiden för hur man använder Yammer i ett forskningsprojekt; eller guiden för hur man beställer varor från en webbutik.
Alla standarder och metoder åtföljs av omfattande dokumentation och studiematerial som beskriver varje område i detalj. Enligt min erfarenhet lönar det sig att anlita en specialist som kan välja ut de delar av metoden som passar just det aktuella företaget.
Om ni sammanställer er kunskap i en standardiserad form får ni inte bara ett verktyg för att diskutera frågor som leder till förbättringar inom företaget, utan ni kan också vara säkra på att ni kommer att hitta en gemensam grund med de allra flesta av era nuvarande och potentiella leverantörer.
Om du vill ändra något i dina processer och informationsflöden bör du börja med att göra förändringar i arbetsorganisationen, antingen på modelnivå eller genom ett pilotprojekt – testa om förändringen ger de fördelar du förväntar dig. Beräkna sedan fördelarna med förändringen och kostnaderna för att genomföra den. Om allt är som det ska, börja anpassa systemen, och om inte kan du avbryta åtgärden utan problem. När du överlåter detta helt till en extern leverantör är det få som vågar stoppa ett projekt där vi redan har investerat resurser.
2. Uppgifterna måste under alla omständigheter tillhöra dig
Uppgifterna lagras hos vår leverantör; nu har vi hamnat i konflikt med dem och de har meddelat oss att uppgifterna tillhör dem... Tyvärr är denna situation inte så ovanlig som man kanske tror. Det händer inte ofta hos leverantörer av molntjänster och webbhotell, som många tror, utan oftast hos leverantörer av specialutvecklade system, där uppgifterna lagras i en ”svart låda” som helt kontrolleras av leverantören.
Detta är ett traditionellt sätt att hålla kunden under leverantörens kontroll. Problemet kan i allmänhet lösas på två sätt – genom att direkt kontrollera uppgifterna eller genom att säkerställa ett tillförlitligt sätt att erhålla dem i ett användbart format.
Till exempel en tjänst för hantering av e-postkontakter som vi får tillgång till genom att registrera oss på vår leverantörs webbplats. Den första metoden går ut på att se till att uppgifterna replikeras i våra egna system, och den andra att regelbundet ladda ner den information som lagras i leverantörens system och spara den hos oss för säkerhets skull.
Även i vårt eget system, där datalagringen är väl dokumenterad, kan metoden för att exportera data till en standardtabell, databas eller XML underlätta integrationen av ett nytt system avsevärt. Det är viktigt att fastställa rutiner för datautvinning, kontrollera att exporten fungerar och att formatet är väl dokumenterat, eftersom det kritiska ögonblicket när vi behöver hämta data är precis det värsta ögonblicket att upptäcka att exporten inte fungerar eller att de perfekt exporterade uppgifterna är kodade i ett format som vi inte kan arbeta med.
Ovanstående krav bör kontrolleras när man godkänner ny funktionalitet eller ändringar i systemen från leverantören.
3. Behålla immateriella rättigheter till applikationer
Äganderätten till applikationer omfattar äganderätten till applikationens källkod eller design. Om vi inte har kontroll över källkoden riskerar vi att, när vi vill byta leverantör, upptäcka att den nuvarande leverantören äger en viktig del av koden och inte är villig att tillhandahålla den kostnadsfritt. Vi kan undvika detta genom att tydligt definiera äganderätten i avtalet och ange att den kod som utvecklas till följd av de begärda ändringarna är vår exklusiva egendom, eller att dessa ändringar skapas under en licens som tillåter oss att använda och distribuera dem kostnadsfritt.
Även om vi har säkerställt äganderätten genom avtal innebär detta inte att den leverantör som vi Om oss säga Om oss avtalet med kommer att ge oss tillgång till koden. Av denna anledning rekommenderas det starkt att versionhanteringssystemet, wikin och övriga dokument lagras hos en tredje part, samt att partnern åläggs att lagra uppgifterna på en specifik plats och vid en specifik tidpunkt så att vi har tillgång till de aktuella versionerna.
4. Systemintegration snarare än utökning av funktionaliteten
Webbtjänst-API:er (Application Programming Interfaces) är numera en vanlig del av många kommersiella och öppen källkodsapplikationer. Detta innebär att alla de funktioner som är tillgängliga för användarna av applikationerna även kan användas mellan olika system och applikationer.
Genom att använda protokoll och standarder för att definiera detta gränssnitt utgör dessa tjänster ett enhetligt kommunikationssätt och en gemensam plattform; en applikation som är skriven i ett språk eller på ett operativsystem blir därmed tillgänglig för system som är uppbyggda på ett helt annat sätt. Data överförs i ett gemensamt format, till exempel XML eller JSON, och kodbaserna för de båda systemen förblir helt Oberoende.
Idag kan alla användare föreställa sig hur systemintegration fungerar. Vi använder ju alla webbtjänster som är integrerade med varandra – till exempel Google Kalender med Google Kontakter och Gmail. Om vi bestämmer oss för att börja använda en annan kalender istället för den befintliga behöver vi bara koppla den till de befintliga uppgifterna. Denna metod för att byta system är inte möjlig om vi har ett eget system som vi ursprungligen köpte enbart för bokföring och sedan gradvis lät leverantören utveckla en CRM-modul, en servicemodul osv.
Samma logik gäller för integration med system som tillhandahålls som tjänster av molntjänstleverantörer (SaaS – Software as a Service). Användningen av webbtjänster skiljer de enskilda applikationerna från varandra, vilket gör hela systemet mer flexibelt och transparent. Tvärtom gör fasta kopplingar mellan olika moduler det lättare för leverantören att öka vårt beroende av dem, öka kodens komplexitet, och systemets flexibilitet begränsas till den minst flexibla delen.
5. Försök att minimera ändringarna i standardsystemet
Försök att implementera det önskade systemet med så få ändringar som möjligt av standardimplementeringen. Du är oftast inte leverantörens första kund. Försök att dra nytta av leverantörens erfarenheter från andra kunder under implementeringen. Du kommer troligen att bli förvånad över hur mycket effektivare vissa processer kan genomföras, eller att vissa uppgifter som vi tidigare förbises kan bli vår konkurrensfördel.
Om vi kräver omfattande ändringar av applikationens funktionalitet kan detta avsevärt komplicera övergången till nya versioner i framtiden, och varje övergång kommer att innebära utmaningar både vad gäller utveckling och driftsättning.
6. Använd flera leverantörer
Försök att själv sköta hela systemets utformning, utveckling, driftsättning och drift, och överlåt inte detta till leverantören. Det är till exempel en god idé att hålla affärsanalytiker åtskilda från utvecklare. Det är också en god idé att låta testare utanför utvecklingsteamet testa systemet. De kommer att utföra arbetet mer effektivt, och sannolikheten att ni får en felfri produkt är betydligt större. Om en annan part ansvarar för driften (t.ex. en molntjänstleverantör), se till att de pressar utvecklarna att leverera en produkt som minimerar driftsproblemen i systemet.
7. Ange villkoren för uppsägning i avtalet, inklusive påföljder för leverantören
Hur regleras uppsägningen av samarbetet i avtalet? Tre månaders uppsägningstid, varefter ni slutar betala och leverantören upphör med supporten? Det är alldeles för otillräckligt.
Det är viktigt att ange vilken dokumentation och i vilken kvalitet leverantören måste tillhandahålla till er – eller direkt till den nya leverantören – under uppsägningstiden. Om du har säkrat immateriella rättigheter till designen, källkoden och andra delar av den dokumentation som nämns i punkt 3 är det desto bättre. När du ingår ett avtal med en leverantör är det en god idé att kontrollera med de företag som kom på andra och tredje plats vad de behöver för att kunna ta över utveckling och underhåll från vinnaren.
8. Informera leverantörerna om framtida utvecklingsplaner
Arbeta för ett långsiktigt samarbete med dina leverantörer. Om du regelbundet diskuterar dina utvecklingsplaner och strategiska frågor med dem – och inte bara aktuella förändringar i funktionaliteten – kan leverantören komma med förslag som skapar en systemarkitektur som är stabil, effektiv och kostnadseffektiv, inte bara för dina nuvarande behov utan även för framtida behov. För att tydliggöra dina krav kan du till exempel använda MuSCoW-metoden, som delar in kraven i följande kategorier:
- Måste ha – måste ha
- Borde ha – borde ha
- Kunde ha – vore trevligt att ha
- Det går inte den här gången – det behövs inte just nu
9. Ta del av idéer och synpunkter från andra parter
Stå inte stilla; följ trenderna; leta efter de bästa metoderna och rutinerna; och håll koll på allt. Anlita ett företag för att få en tredje åsikt – de kommer att utvärdera dina beslut både ur ett tekniskt och strategiskt perspektiv. Det behöver inte kosta skjortan. Och en sådan konsultation är väl värd pengarna eftersom den hjälper dig att undvika misstag. Av egen erfarenhet känner jag till ett fall där en leverantör tvingade en kund att investera flera miljoner kronor i att lösa ett problem som han själv hade orsakat, och en konsult upptäckte att investeringen inte alls skulle lösa problemet eftersom problemet låg någon annanstans.
En konsult kan hjälpa dig att utforma din strategi, skapa efterfrågan, utvärdera olika alternativ och se på saker ur ett nytt perspektiv. De kan också hjälpa dig att granska dina leverantörer och säkerställa bästa möjliga resultat för dig. En konsult bör alltid ha i åtanke att du vill vara Oberoende en viss leverantör och att du ser värdet i din egen expertis som en konkurrensfördel.
Att välja rätt leverantörer är en viktig del Om oss
Jag tror att du efter att ha läst den här artikeln har en tydligare bild av hur du kan göra dina leverantörer till partners i din framgång, istället för att bli deras underordnade. Om oss undvika obehagliga situationer krävs Om oss riskhantering och Om oss väljer lösningar som balanserar dagens behov med framtida flexibilitet. Genom att följa principerna ovan säkerställer du att du gör rätt val av leverantörer och nya system.
