I den første delen av serien diskuterte vi hvordan vi kan bli usunt avhengige av leverandøren vår, og fremfor alt hvilke problemer dette kan forårsake for bedriften vår.
I dag skal vi se på hva vi kan gjøre for å unngå en slik avhengighet.
1. Beholde eierskap til prosess- og systemkunnskap og planer for utvikling av disse.
Hvis du bestemmer deg for at du ikke vil bekymre deg Om IT og gi generelle instruksjoner til IT-leverandøren din; du er på den beste veien til avhengighet. Det som kanskje overrasker deg er at denne tilnærmingen ofte forårsaker problemer for leverandøren selv; fordi etter en stund begynner kundens krav å overlappe og bli viklet inn; og det å møte nye krav blir et stort problem for leverandøren.
For et selskap som ønsker å forbli konkurransedyktig, er det viktig å se på IT som et verktøy for å støtte, forbedre og måle prosessene sine. Det er ikke vanskelig å finne ut hvordan man gjør dette, fordi vi i dag har nok metoder og standarder som lar oss opprettholde oversikt over prosesser og gjennomføre effektiv planlegging:
- Virksomhetsarkitektur – en måte å beskrive en organisasjons mål på; måtene disse målene oppnås på gjennom forretningsprosesser; og hvordan disse prosessene kan støttes av teknologi. For mer informasjon, se artikkelen «Ikke bli hengende fast» av dårlig bedriftsarkitektur. De to mest kjente tilnærmingene til bedriftsarkitektur finner du på nettsidene til The Open Group og Zachmann .
- Prosessbeskrivelse – de mest kjente og mest brukte standardene er laget av Open Management Group (www.omg.org). Å beskrive prosesser i henhold til BPMN-spesifikasjonen (Business Process Model and Notation) gjør det enkelt for bedriftsledelsen å lese og registrere prosessene som foregår i bedriften.
- Brukerdokumentasjon – dette trenger ikke å være et dokument skrevet av leverandøren og liggende i en skuff for å samle støv. En god tilnærming er å filme videoer som viser brukere hvordan de bruker applikasjonen i sitt daglige arbeid. Dette forenkler produktstøtte og opplæring for nye brukere. Videoene er ofte bare noen få minutter lange og beskriver alt du trenger å vite for å bruke systemet effektivt. For eksempel, ta en titt på veiledningen for bruk av Yammer i et forskningsprosjekt , eller veiledningen for hvordan du bestiller varer fra en nettbutikk .
Alle standarder og metoder er ledsaget av omfattende dokumentasjon og studiemateriell som beskriver hvert område i detalj. Etter min erfaring er det verdt å ansette en spesialist som vil velge ut de delene av metodikken som passer for et bestemt selskap.
Hvis du bearbeider kunnskapen din i en standardisert form, vil du ikke bare ha et verktøy for å diskutere temaer som fører til forbedringer i bedriften, men du vil også få vissheten om at du vil finne felles grunnlag med de aller fleste av dine nåværende og potensielle leverandører.
Hvis du ønsker å endre noe i prosessene og informasjonsflyten din, start med å gjøre endringer i arbeidsorganiseringen, enten på modellnivå eller gjennom et piloteksperiment – test om endringen vil gi de fordelene du forventer. Beregn deretter fordelene med endringen og kostnadene ved å implementere den. Hvis alt er som det skal være, begynn å endre systemene, og hvis ikke, kan du stoppe handlingen uten problemer. Når du overlater dette fullstendig til en ekstern leverandør, er det få som har mot til å stoppe et prosjekt der vi allerede har investert ressurser.
2. Dataene må være dine under alle omstendigheter
Dataene er lagret hos leverandøren vår; nå har vi hatt en krangel med dem, og de har fortalt oss at dataene er deres... Dessverre er ikke denne situasjonen så uvanlig som man kanskje tror. Det skjer ikke ofte med leverandører av skytjenester og hosting, slik folk ofte antar, men oftest med spesialutviklede systemer, der dataene er lagret i en svart boks som er fullstendig kontrollert av leverandøren.
Dette er en tradisjonell måte å holde kunden under leverandørens kontroll. Problemet kan vanligvis løses på to måter – ved å kontrollere dataene direkte eller ved å sikre en pålitelig måte å innhente dem i et brukbart format.
For eksempel; en tjeneste for administrasjon av e-postkontakter som vi får ved å registrere oss på leverandørens nettsted. Den første tilnærmingen er å sikre at dataene replikeres i våre egne systemer; og den andre er å regelmessig laste ned informasjonen som er lagret i leverandørens systemer og lagre den hos oss for «bare i tilfelle».
Selv i vårt eget system, der datalagring er godt dokumentert, kan metodikken for å eksportere data til en standardtabell, database eller XML i stor grad legge til rette for integreringen av et nytt system. Det er viktig å etablere prosedyrer for datauttrekking, verifisering av at eksporten fungerer, og at formatet er godt dokumentert, fordi det kritiske øyeblikket når vi trenger å hente dataene, er nettopp det verste øyeblikket for å oppdage at eksporten ikke fungerer, eller at de perfekt eksporterte dataene er kodet i et format vi ikke kan jobbe med.
Ovennevnte krav bør verifiseres ved aksept av ny funksjonalitet eller endringer i systemer fra leverandøren.
3. Behold immaterielle rettigheter til applikasjoner
Eierskap til applikasjoner består av eierskap til kildekoden eller designet til applikasjonen. Hvis vi ikke har kontroll over kildekoden, risikerer vi at når vi ønsker å bytte leverandør, vil vi oppdage at den eksisterende leverandøren eier en kritisk del av koden og ikke vil være villig til å tilby den gratis. Vi kan unngå dette ved å definere eierskap tydelig i kontrakten; ved å oppgi at koden som er utviklet som et resultat av de forespurte endringene utelukkende er vår eiendom; eller at disse endringene er opprettet under en lisens som tillater oss å bruke og distribuere dem gratis.
Selv om vi har sikret oss eierskap kontraktsmessig, betyr ikke dette at leverandøren vi har et samarbeid med Om Å si opp kontrakten vil gi oss tilgang til koden. Av denne grunn er det sterkt tilrådelig at kildekontrollsystemet, wikien og andre dokumenter lagres hos en tredjepart, og at partneren er forpliktet til å lagre dataene på et bestemt sted og til et bestemt tidspunkt, slik at vi har tilgang til de gjeldende versjonene.
4. Systemintegrasjon snarere enn funksjonalitetsutvidelse
Webtjeneste-API-er (applikasjonsprogrammeringsgrensesnitt) er nå en vanlig funksjon i mange kommersielle og åpen kildekode-applikasjoner. Dette betyr at alle funksjonene eller funksjonene som er tilgjengelige for applikasjonsbrukere, også er tilgjengelige for bruk mellom forskjellige systemer og applikasjoner.
Ved å bruke protokoller og standarder for å definere dette grensesnittet, er disse tjenestene et enhetlig kommunikasjonsmiddel og plattform. En applikasjon skrevet på ett språk eller på ett operativsystem er tilgjengelig for systemer skrevet på en helt annen måte. Data overføres i et felles format, for eksempel XML eller JSON, og kodebasene til begge systemene forblir fullstendig identiske. Uavhengig .
I dag kan alle brukere forestille seg hvordan systemintegrasjon ser ut. Tross alt bruker vi alle webapplikasjonstjenester som er integrert med hverandre – for eksempel Google Kalender med Google Kontakter og Gmail. Hvis vi bestemmer oss for å begynne å bruke en annen kalender i stedet for den eksisterende, trenger vi bare å koble den til de eksisterende dataene. Denne metoden for å bytte system er ikke mulig hvis vi har vårt eget system; som vi opprinnelig kjøpte kun for regnskap og gradvis fikk leverandøren til å utvikle en CRM-modul, servicemodul osv.
Den samme logikken gjelder for integrasjon med systemer levert som en tjeneste av skytjenesteleverandører (SaaS – Software as a Service). Bruken av webtjenester skiller individuelle applikasjoner fra hverandre, noe som gjør hele systemet mer fleksibelt og transparent Tvert imot; faste koblinger mellom ulike moduler gjør det enklere for leverandøren å øke vår avhengighet av dem; øker kompleksiteten i koden; og systemets fleksibilitet er lik den minst fleksible delen.
5. Prøv å minimere endringer i standardsystemet
Prøv å implementere det nødvendige systemet med et minimum av modifikasjoner i forhold til standardimplementeringen. Du er vanligvis ikke leverandørens første kunde. Prøv å få mest mulig ut av leverandørens erfaring med andre kunder under implementeringen. Du vil sannsynligvis bli overrasket over hvor mye mer effektivt noen prosesser kan implementeres, eller at visse data vi tidligere overså, vil bli vårt konkurransefortrinn.
Hvis vi trenger store endringer i applikasjonens funksjonalitet, kan dette komplisere overgangen til nye versjoner betydelig i fremtiden, og enhver overgang vil være utfordrende med tanke på utvikling og distribusjon.
6. Bruk flere leverandører
Prøv å håndtere hele systemdesignet, utviklingen, utrullingen og driften selv, og ikke overlat det til leverandøren. Det er for eksempel lurt å skille forretningsanalytikere fra utviklere. Det er lurt å få systemet testet av testere som er utenfor utviklingsteamet. De vil gjøre jobben mer effektivt, og sannsynligheten for at du får et feilfritt produkt er mye større. Hvis en annen part er ansvarlig for driften (f.eks. en skytjenesteleverandør), sørg for at de vil presse utviklerne til å levere et produkt som minimerer problemer med systemdriften.
7. Spesifiser oppsigelsesprosessen i kontrakten, inkludert straffer for leverandøren
Hvordan er oppsigelse av samarbeid spesifisert i kontrakten? Tre måneders varsel; hvoretter du slutter å betale og leverandøren slutter å yte støtte? Det er sørgelig utilstrekkelig.
Det er nødvendig å spesifisere hvilken dokumentasjon og i hvilken kvalitet leverandøren må levere til deg, eller direkte til den nye leverandøren, i løpet av oppsigelsesperioden. Hvis du har sikret deg immaterielle rettigheter til design, kildekode og andre deler av dokumentasjonen nevnt i punkt 3, desto bedre. Når du inngår en kontrakt med en leverandør, er det lurt å sjekke med selskapene som kom på 2. og 3. plass hva de trenger dersom de skal overta utvikling og vedlikehold fra vinneren.
8. Informer leverandører om fremtidige utviklingsplaner
Jobb med et langsiktig partnerskap med leverandørene dine. Hvis du regelmessig diskuterer utviklingsplanene dine og strategiske problemstillinger med dem, og ikke bare aktuelle endringer i funksjonalitet, kan leverandøren komme med forslag som vil skape en systemarkitektur som er stabil, effektiv og kostnadseffektiv, ikke bare for dine nåværende behov, men også for fremtidige behov. For å avklare kravene dine kan du for eksempel bruke MuSCoW-metoden, som deler krav inn i følgende kategorier:
- Må ha – må ha
- Burde ha – burde ha
- Kunne ha – hadde vært fint å ha
- Har ikke denne gangen – trenger ikke å ha akkurat nå
9. Få ideer og meninger fra andre parter
Ikke bli sittende fast på ett sted; følg trender; se etter de beste tilnærmingene og praksisene; og hold øye med alt. Lei inn et firma for å få en tredjepartsvurdering – de vil evaluere beslutningene dine fra både et teknisk og strategisk perspektiv. Det trenger ikke å være dyrt. Og slik konsultasjon er verdt det fordi det vil hjelpe deg med å unngå feil. Fra min erfaring kjenner jeg til et tilfelle der en leverandør tvang en kunde til å investere flere millioner kroner i å løse et problem som han selv hadde forårsaket; og en konsulent fant ut at investeringen ikke ville løse problemet i det hele tatt fordi problemet lå et annet sted.
En konsulent kan hjelpe deg med å definere strategien din, skape etterspørsel, evaluere alternativer og se på ting fra en uventet vinkel. De kan også hjelpe deg med å revidere leverandørene dine og sikre best mulig resultat for deg. En konsulent bør alltid huske på at du ønsker å være Uavhengig hos en bestemt leverandør, og at du anerkjenner verdien av din kunnskap som et konkurransefortrinn.
Det riktige valget av leverandører er Om risikostyring
Jeg tror at etter å ha lest denne artikkelen har du en klarere idé om hvordan du kan gjøre leverandørene dine til partnere i suksessen din og ikke bli deres vasall. Å forhindre ubehagelige situasjoner er Om konsekvent risikostyring og valg av løsninger som balanserer nåværende krav med fremtidig fleksibilitet. Ved å følge prinsippene ovenfor sikrer du riktig valg av leverandører og nye systemer.
