Sarjan ensimmäisessä osassa käsittelimme sitä, miten voimme joutua epäterveelliseen riippuvuussuhteeseen toimittajaamme ja ennen kaikkea sitä, mitä ongelmia tämä voi aiheuttaa yrityksellemme.
Tänään tarkastelemme, mitä voimme tehdä välttääksemme tällaisen riippuvuuden.
1. Säilyttää prosessi- ja järjestelmäosaamisen sekä niiden kehittämissuunnitelmien omistusoikeus
Jos päätät, ettet halua huolehtia Meistä ja annat IT-palveluntarjoajallesi vain yleisiä ohjeita, olet matkalla kohti riippuvuutta. Saatat yllättyä siitä, että tämä toimintatapa aiheuttaa usein ongelmia palveluntarjoajalle itselleen, sillä ajan myötä asiakkaan vaatimukset alkavat limittyä ja sotkeutua toisiinsa, ja uusien vaatimusten täyttäminen muuttuu palveluntarjoajalle suureksi ongelmaksi.
Yritykselle, joka haluaa säilyttää kilpailukykynsä, on tärkeää nähdä IT prosessien tukemisen, parantamisen ja mittaamisen välineenä. Tämän toteuttaminen ei ole vaikeaa, sillä nykyään käytettävissä on riittävästi menetelmiä ja standardeja, joiden avulla prosesseista voidaan pitää kokonaiskuvaa ja toteuttaa tehokasta suunnittelua:
- Yritysarkkitehtuuri – tapa kuvata organisaation tavoitteita, tapoja, joilla nämä tavoitteet saavutetaan liiketoimintaprosessien avulla, sekä sitä, miten teknologia voi tukea näitä prosesseja. Lisätietoja löytyy artikkelista ”Älä juutu paikoillesi huonon yritysarkkitehtuurin takia”. Kaksi tunnetuinta yritysarkkitehtuurin lähestymistapaa löytyy The Open Groupin ja Zachmannin verkkosivuilta.
- Prosessikuvaus – tunnetuimmat ja yleisimmin käytetyt standardit on laatinut Open Management Group (www.omg.org). Prosessien kuvaaminen BPMN-määrittelyn (Business Process Model and Notation) mukaisesti antaa yrityksen johdolle mahdollisuuden helposti ymmärtää ja dokumentoida yrityksessä toteutettavat prosessit.
- Käyttöohjeet – niiden ei tarvitse olla toimittajan laatima asiakirja, joka jää pölyttymään laatikkoon. Hyvä tapa on kuvata videoita, joissa näytetään käyttäjille, miten sovellusta käytetään päivittäisessä työssä; näin tuotetuki ja uusien käyttäjien koulutus helpottuvat. Videot ovat usein vain muutaman minuutin pituisia ja niissä kerrotaan kaikki, mitä järjestelmän tehokkaaseen käyttöön tarvitaan. Katso esimerkiksi opas Yammerin käyttöön tutkimusprojektissa tai opas tavaroiden tilaamiseen verkkokaupasta.
Kaikkiin standardeihin ja menetelmiin liittyy kattava dokumentaatio ja oppimateriaali, joissa kukin osa-alue kuvataan yksityiskohtaisesti. Kokemukseni mukaan kannattaa palkata asiantuntija, joka valitsee menetelmästä juuri kyseiselle yritykselle sopivat osat.
Jos dokumentoit osaamisesi vakiomuotoon, saat käyttöösi paitsi työkalun, jonka avulla voit keskustella yrityksen kehittämiseen johtavista aiheista, myös varmuuden siitä, että löydät yhteistä pohjaa valtaosan nykyisten ja potentiaalisten toimittajiesi kanssa.
Jos haluat muuttaa jotain prosesseissasi ja tiedonkulussasi, aloita tekemällä muutoksia työn organisointiin joko mallitasolla tai pilottikokeilun avulla – testaa, tuoko muutos odotetut hyödyt. Laske sitten muutoksen hyödyt ja sen toteuttamisen kustannukset. Jos kaikki on niin kuin pitääkin, aloita järjestelmien muokkaaminen; ja jos ei, voit keskeyttää toimenpiteen ilman ongelmia. Kun uskot tämän kokonaan ulkoiselle toimittajalle, harvat ihmiset uskaltavat keskeyttää projektin, johon on jo investoitu resursseja.
2. Tietojen on oltava sinun omia kaikissa tilanteissa
Tiedot on tallennettu palveluntarjoajamme järjestelmään; nyt olemme riitaantuneet heidän kanssaan, ja he ovat ilmoittaneet, että tiedot kuuluvat heille... Valitettavasti tämä tilanne ei ole niin harvinainen kuin saattaisit luulla. Sitä ei tapahdu usein pilvipalvelu- ja hosting-palveluntarjoajien kohdalla, kuten usein oletetaan, vaan useimmiten räätälöityjen järjestelmien yhteydessä, joissa tiedot tallennetaan palveluntarjoajan täysin hallinnoimaan ”mustaan laatikkoon”.
Tämä on perinteinen tapa pitää asiakas toimittajan hallinnassa. Ongelma voidaan yleensä ratkaista kahdella tavalla: joko hallitsemalla tietoja suoraan tai varmistamalla, että ne saadaan luotettavasti käyttökelpoisessa muodossa.
Esimerkiksi: palvelu, jolla hallitaan sähköpostiyhteystietoja, jotka saamme rekisteröitymällä toimittajamme verkkosivustolle. Ensimmäinen tapa on varmistaa, että tiedot kopioidaan omiin järjestelmiimme; toinen tapa on ladata säännöllisesti toimittajan järjestelmiin tallennetut tiedot ja tallentaa ne omille palvelimillemme ”varalta”.
Jopa omassa järjestelmässämme, jossa tietojen tallennus on hyvin dokumentoitu, menetelmät tietojen viemiseksi vakiomuotoiseen taulukkoon, tietokantaan tai XML-tiedostoon voivat helpottaa huomattavasti uuden järjestelmän integrointia. On tärkeää luoda menettelytavat tietojen poimimiseksi, vientiä koskevan toimivuuden varmistamiseksi ja formaatin dokumentoimiseksi, sillä kriittinen hetki, jolloin meidän on haettava tiedot, on juuri pahin hetki huomata, että vienti ei toimi tai että täydellisesti viedyt tiedot on koodattu formaatissa, jota emme voi käyttää.
Edellä mainitut vaatimukset on tarkistettava, kun toimittajalta hyväksytään uusia toimintoja tai järjestelmämuutoksia.
3. Sovellusten immateriaalioikeuksien säilyttäminen
Sovellusten omistusoikeus kattaa sovelluksen lähdekoodin tai suunnittelun omistusoikeuden. Jos lähdekoodi ei ole hallinnassamme, on olemassa riski, että kun haluamme vaihtaa toimittajaa, nykyinen toimittaja omistaa kriittisen osan koodista eikä ole valmis luovuttamaan sitä ilmaiseksi. Voimme välttää tämän määrittelemällä omistusoikeuden selkeästi sopimuksessa ja ilmoittamalla, että pyydettyjen muutosten seurauksena kehitetty koodi on yksinomaan meidän omaisuuttamme tai että nämä muutokset on luotu lisenssillä, joka antaa meille oikeuden käyttää ja jakaa niitä ilmaiseksi.
Vaikka olisimme varmistaneet omistusoikeuden sopimuksella, se ei tarkoita, että toimittaja, jonka kanssa Meistä sopimuksen Meistä myöntäisi meille pääsyn koodiin. Tästä syystä on erittäin suositeltavaa, että versionhallintajärjestelmä, wiki ja muut asiakirjat tallennetaan kolmannen osapuolen palvelimelle ja että kumppani velvoitetaan tallentamaan tiedot tiettyyn paikkaan ja tiettynä ajankohtana, jotta meillä on pääsy ajantasaisiin versioihin.
4. Järjestelmän integrointi toiminnallisuuden laajentamisen sijaan
Verkkopalveluiden sovellusrajapinnat (API) ovat nykyään yleinen ominaisuus monissa kaupallisissa ja avoimen lähdekoodin sovelluksissa. Tämä tarkoittaa, että kaikki sovellusten käyttäjille tarjolla olevat ominaisuudet ja toiminnot ovat käytettävissä myös eri järjestelmien ja sovellusten välillä.
Kun tätä rajapintaa määritellään protokollien ja standardien avulla, näistä palveluista muodostuu yhtenäinen viestintäväline ja alusta; yhdellä kielellä tai yhdellä käyttöjärjestelmällä kirjoitettu sovellus on käytettävissä järjestelmissä, jotka on toteutettu täysin eri tavalla. Tiedot siirretään yhteisessä muodossa, kuten XML:nä tai JSON:na, ja molempien järjestelmien koodipohjat pysyvät täysin Riippumaton.
Nykyään jokainen käyttäjä osaa kuvitella, miltä järjestelmien integrointi näyttää. Käytämmehan kaikki toisiinsa integroituja verkkosovelluspalveluita – esimerkiksi Google Kalenteria yhdessä Google-yhteystietojen ja Gmailin kanssa. Jos päätämme alkaa käyttää toista kalenteria nykyisen sijaan, meidän tarvitsee vain yhdistää se olemassa oleviin tietoihin. Tällainen järjestelmänvaihto ei ole mahdollista, jos meillä on oma järjestelmä, jonka ostimme alun perin vain kirjanpitoa varten ja johon toimittaja on vähitellen kehittänyt CRM-moduulin, palvelumoduulin jne.
Sama logiikka pätee myös integrointiin pilvipalveluntarjoajien palveluna tarjoamien järjestelmien kanssa (SaaS – Software as a Service). Verkkopalvelujen käyttö erottaa yksittäiset sovellukset toisistaan, mikä tekee koko järjestelmästä joustavamman ja Läpinäkyvä. Päinvastoin: kiinteät yhteydet eri moduulien välillä helpottavat toimittajaa lisäämään riippuvuuttamme heistä, lisäävät koodin monimutkaisuutta, ja järjestelmän joustavuus on yhtä suuri kuin sen joustamattomimman osan joustavuus.
5. Pyri tekemään mahdollisimman vähän muutoksia vakiojärjestelmään
Yritä toteuttaa vaadittu järjestelmä muuttamatta vakiototeutusta mahdollisimman vähän. Et yleensä ole toimittajan ensimmäinen asiakas. Yritä hyödyntää toimittajan kokemusta muista asiakkaista järjestelmän käyttöönoton yhteydessä. Tulet todennäköisesti yllättymään siitä, kuinka paljon tehokkaammin jotkin prosessit voidaan toteuttaa, tai siitä, että tietyt aiemmin huomiotta jääneet tiedot muuttuvat kilpailueduksi.
Jos sovelluksen toiminnallisuuteen joudutaan tekemään suuria muutoksia, se voi vaikeuttaa huomattavasti siirtymistä uusiin versioihin tulevaisuudessa, ja mikä tahansa siirtymä on haastava sekä kehityksen että käyttöönoton kannalta.
6. Käytä useita toimittajia
Yritä hoitaa koko järjestelmän suunnittelu, kehitys, käyttöönotto ja käyttö itse äläkä jätä sitä toimittajan tehtäväksi. On suositeltavaa erottaa esimerkiksi liiketoiminta-analyytikot kehittäjistä. On suositeltavaa, että järjestelmän testaavat kehittäjätiimistä riippumattomat testaajat. He hoitavat työn tehokkaammin, ja todennäköisyys saada virheetön tuote on paljon suurempi. Jos toinen osapuoli vastaa käytöstä (esim. pilvipalveluntarjoaja), varmista, että he painostavat kehittäjiä toimittamaan tuotteen, joka minimoi järjestelmän käyttöongelmat.
7. Määritelkää sopimuksessa irtisanomismenettely, mukaan lukien toimittajalle määrättävät seuraamukset
Miten yhteistyön päättäminen on määritelty sopimuksessa? Kolmen kuukauden irtisanomisaika, jonka jälkeen lopetat maksut ja toimittaja lopettaa tuen tarjoamisen? Se on täysin riittämätöntä.
On määriteltävä, mitä asiakirjoja ja millaisessa muodossa toimittajan on toimitettava sinulle – tai suoraan uudelle toimittajalle – irtisanomisaikana. Jos olet varmistanut immateriaalioikeudet suunnitteluun, lähdekoodiin ja muihin kohdassa 3 mainittuihin asiakirjoihin, niin sitä parempi. Kun teet sopimusta toimittajan kanssa, on hyvä selvittää 2. ja 3. sijalle tulleilta yrityksiltä, mitä ne tarvitsevat, jos ne ottavat kehityksen ja ylläpidon haltuunsa voittajalta.
8. Ilmoita toimittajille tulevista kehityssuunnitelmista
Pyrkikää luomaan pitkäaikainen kumppanuus toimittajienne kanssa. Jos keskustelette heidän kanssaan säännöllisesti kehityssuunnitelmistanne ja strategisista kysymyksistä – eikä pelkästään nykyisistä toiminnallisuuden muutoksista –, toimittaja saattaa esittää ehdotuksia, joiden avulla voidaan luoda vakaa, tehokas ja kustannustehokas järjestelmäarkkitehtuuri, joka vastaa paitsi nykyisiä myös tulevia tarpeitanne. Vaatimustenne selkeyttämiseksi voitte käyttää esimerkiksi MuSCoW-menetelmää, jossa vaatimukset jaetaan seuraaviin luokkiin:
- Pakollinen – pakollinen
- Olisi pitänyt – olisi pitänyt
- Voisihan olla – olisi kiva, jos olisi
- Ei tarvita tällä kertaa – ei tarvitse olla tällä hetkellä
9. Kerää ideoita ja mielipiteitä muilta osapuolilta
Älä juutu paikoillesi; seuraa trendejä; etsi parhaita toimintatapoja ja käytäntöjä; ja pidä silmällä kaikkea. Palkkaa yritys saadaksesi kolmannen mielipiteen – se arvioi päätöksesi sekä teknisestä että strategisesta näkökulmasta. Sen ei tarvitse olla kallista. Ja tällainen konsultointi on kannattavaa, koska se auttaa sinua välttämään virheitä. Kokemukseni perusteella tiedän tapauksen, jossa toimittaja pakotti asiakkaan investoimaan useita miljoonia kruunuja ongelman ratkaisemiseen, jonka se oli itse aiheuttanut; ja konsultti totesi, että investointi ei ratkaisisi ongelmaa lainkaan, koska ongelma oli muualla.
Konsultti voi auttaa sinua määrittelemään strategian, luomaan kysyntää, arvioimaan vaihtoehtoja ja tarkastelemaan asioita yllättävästä näkökulmasta. Hän voi myös auttaa sinua arvioimaan toimittajiasi ja varmistamaan, että saat parhaan mahdollisen lopputuloksen. Konsultin tulisi aina pitää mielessä, että haluat olla Riippumaton tietystä Riippumaton ja että tunnustat oman osaamisesi arvon kilpailuetuna.
Oikea toimittajavalinta on Meistä
Uskon, että tämän artikkelin lukemisen jälkeen sinulla on selkeämpi käsitys siitä, miten voit tehdä toimittajistasi menestyksesi kumppaneita sen sijaan, että joutuisi heidän alaisekseen. Epämiellyttävien tilanteiden ehkäiseminen Meistä riskienhallintaa ja sellaisten ratkaisujen valitsemista, joissa nykyiset vaatimukset ja tulevaisuuden joustavuus ovat tasapainossa. Noudattamalla edellä mainittuja periaatteita varmistat, että toimittajat ja uudet järjestelmät valitaan oikein.
