V prvem delu serije smo razpravljali o tem, kako lahko postanemo nezdravo odvisni od našega dobavitelja, in predvsem o tem, kakšne težave lahko to povzroči za naše podjetje.
Danes bomo pogledali, kaj lahko storimo, da se izognemo takšni odvisnosti.
1. Ohraniti lastništvo nad znanjem o procesih in sistemih ter načrti za njihov razvoj
Če se odločite, da se ne želite ukvarjati O nas in svojemu IT-ponudniku podate le splošna navodila, ste na najboljši poti k odvisnosti. Presenetilo vas bo morda to, da takšen pristop pogosto povzroča težave tudi samemu ponudniku; kajti čez nekaj časa se zahteve naročnika začnejo prekrivati in zapletati, izpolnjevanje novih zahtev pa postane za ponudnika velik problem.
Za podjetje, ki želi ostati konkurenčno, je pomembno, da informacijsko tehnologijo obravnava kot orodje za podporo, izboljšanje in merjenje svojih procesov. Ni težko ugotoviti, kako to storiti, saj imamo danes na voljo dovolj metodologij in standardov, ki nam omogočajo, da ohranjamo pregled nad procesi in izvajamo učinkovito načrtovanje:
- Podjetniška arhitektura – način opisovanja ciljev organizacije; načinov, kako se ti cilji uresničujejo prek poslovnih procesov; ter kako lahko tehnologija podpira te procese. Za več informacij si preberite članek »Ne obtičajte« zaradi slabe podjetniške arhitekture. Dva najbolj znana pristopa k podjetniški arhitekturi sta na voljo na spletnih straneh The Open Group in Zachmann.
- Opis procesov – najbolj znane in najpogosteje uporabljane standarde je razvila skupina Open Management Group (www.omg.org). Opisovanje procesov v skladu s specifikacijo BPMN (Business Process Model and Notation) omogoča vodstvu podjetja, da enostavno razume in dokumentira procese, ki potekajo v njihovem podjetju.
- Uporabniška dokumentacija – to ni nujno dokument, ki ga pripravi dobavitelj in ga nato odloži v predal, kjer se bo prašil. Dober pristop je snemanje videoposnetkov, ki uporabnikom prikazujejo, kako uporabljati aplikacijo v vsakdanjem delu; s tem se poenostavi podpora za izdelek in usposabljanje novih uporabnikov. Videoposnetki so pogosto dolgi le nekaj minut in opisujejo vse, kar morate vedeti za učinkovito uporabo sistema. Oglejte si na primer navodila za uporabo Yammerja v raziskovalnem projektu ali navodila za naročanje blaga v spletni trgovini.
Vsi standardi in metodologije so opremljeni s celovito dokumentacijo in študijskim gradivom, ki podrobno opisujejo vsako področje. Po mojih izkušnjah se splača najeti strokovnjaka, ki bo izbral tiste dele metodologije, ki so primerni za konkretno podjetje.
Če svoje znanje in izkušnje obdelate v standardizirani obliki, ne boste imeli le orodja za razpravo o temah, ki vodijo k izboljšanju poslovanja, ampak boste tudi pridobili gotovost, da boste našli skupno podlago z veliko večino vaših sedanjih in potencialnih dobaviteljev.
Če želite spremeniti kaj v svojih procesih in pretoku informacij, začnite s spremembami v organizaciji dela – bodisi na ravni modela bodisi s pilotnim poskusom – in preverite, ali bo sprememba prinesla pričakovane koristi. Nato izračunajte koristi spremembe in stroške njenega izvajanja. Če je vse tako, kot bi moralo biti, začnite spreminjati sisteme; če pa ni, lahko ukrep brez težav ustavite. Ko to v celoti zaupate zunanjemu izvajalcu, le redki imajo pogum, da ustavijo projekt, v katerega smo že vložili sredstva.
2. Podatki morajo biti v vsakem primeru vaši
Podatki so shranjeni pri našem ponudniku; zdaj smo se z njim sprli in nam je povedal, da so podatki njegovi... Na žalost ta situacija ni tako redka, kot bi si morda mislili. Pri ponudnikih storitev v oblaku in gostovanja se to ne dogaja pogosto, kot ljudje pogosto domnevajo, ampak najpogosteje pri sistemih, razvitih po meri, kjer so podatki shranjeni v »črni skrinjici«, ki jo v celoti nadzira ponudnik.
To je tradicionalen način, s katerim dobavitelj ohranja nadzor nad stranko. Problem se na splošno lahko reši na dva načina – z neposrednim nadzorom nad podatki ali z zagotovitvijo zanesljivega načina za njihovo pridobivanje v uporabni obliki.
Na primer: storitev za upravljanje e-poštnih stikov, ki jih pridobimo z registracijo na spletni strani našega dobavitelja. Prvi pristop je zagotoviti, da se podatki sinhronizirajo v naših lastnih sistemih; drugi pa je, da redno prenesemo podatke, shranjene v sistemih dobavitelja, in jih shranimo pri nas za vsak primer.
Tudi v našem lastnem sistemu, kjer je shranjevanje podatkov dobro dokumentirano, lahko metodologija izvoza podatkov v standardno tabelo, bazo podatkov ali XML znatno olajša integracijo novega sistema. Pomembno je vzpostaviti postopke za izpisovanje podatkov, preverjanje delovanja izvoza in dobro dokumentiran format, saj je ključni trenutek, ko moramo pridobiti podatke, prav tisti najslabši trenutek, da ugotovimo, da izvoz ne deluje ali da so popolnoma izvoženi podatki kodirani v formatu, s katerim ne moremo delati.
Zgoraj navedene zahteve je treba preveriti ob prevzemu kakršnih koli novih funkcionalnosti ali sprememb sistemov s strani dobavitelja.
3. Ohraniti pravice intelektualne lastnine do aplikacij
Lastništvo nad aplikacijami zajema lastništvo nad izvorno kodo ali zasnovo aplikacije. Če nimamo nadzora nad izvorno kodo, tvegamo, da bomo ob morebitni zamenjavi dobavitelja ugotovili, da ta poseduje ključni del kode in ga ne bo pripravljen brezplačno predati. To lahko preprečimo tako, da v pogodbi jasno opredelimo lastništvo in navedemo, da je koda, razvita kot rezultat zahtevanih sprememb, izključno naša last, ali da so te spremembe ustvarjene v skladu z licenco, ki nam omogoča njihovo brezplačno uporabo in distribucijo.
Čeprav smo si lastništvo zagotovili s pogodbo, to še ne pomeni, da nam bo dobavitelj, s katerim O nas pogodbo O nas omogočil dostop do kode. Zato je zelo priporočljivo, da se sistem za upravljanje virov, wiki in druga dokumentacija shranijo pri tretji osebi ter da se partner obvezuje, da bo podatke shranil na določenem mestu in v določenem času, tako da bomo imeli dostop do aktualnih različic.
4. Integracija sistema namesto razširitve funkcionalnosti
Vmesniki API (vmesniki za programiranje aplikacij) so danes pogosta značilnost številnih komercialnih in odprtokodnih aplikacij. To pomeni, da so vse funkcije, ki so na voljo uporabnikom aplikacij, na voljo tudi za uporabo med različnimi sistemi in aplikacijami.
Z uporabo protokolov in standardov za opredelitev tega vmesnika te storitve predstavljajo enotno komunikacijsko sredstvo in platformo; aplikacija, napisana v enem jeziku ali za en operacijski sistem, je dostopna sistemom, ki so napisani na povsem drugačen način. Podatki se prenašajo v skupnem formatu, kot sta XML ali JSON, pri čemer ostajata kodni osnovi obeh sistemov popolnoma Neodvisno.
Danes si vsak uporabnik lahko predstavlja, kako izgleda integracija sistemov. Konec koncev vsi uporabljamo spletne aplikacijske storitve, ki so med seboj integrirane – na primer Google Koledar z Google Stiki in Gmailom. Če se odločimo, da bomo namesto obstoječega koledarja začeli uporabljati drugega, ga moramo le povezati z obstoječimi podatki. Ta način menjave sistemov ni mogoč, če imamo lasten sistem, ki smo ga prvotno kupili le za računovodstvo, nato pa smo dobavitelju naročili, naj postopoma razvije modul CRM, modul za storitve itd.
Enaka logika velja tudi za integracijo s sistemi, ki jih ponujajo ponudniki storitev v oblaku (SaaS – Software as a Service). Uporaba spletnih storitev ločuje posamezne aplikacije med seboj, zaradi česar je celoten sistem bolj prilagodljiv in Transparentno. Nasprotno pa fiksne povezave med različnimi moduli ponudniku olajšujejo povečanje naše odvisnosti od njih, povečajo zapletenost kode, prilagodljivost sistema pa je omejena na najmanj prilagodljiv del.
5. Poskusite čim bolj omejiti spremembe standardnega sistema
Poskusite zahtevani sistem vzpostaviti z čim manj spremembami standardne izvedbe. Ponavadi niste prvi kupec tega dobavitelja. Poskusite pri uvajanju sistema čim bolje izkoristiti izkušnje, ki jih je dobavitelj pridobil pri drugih strankah. Verjetno boste presenečeni, kako veliko učinkoviteje je mogoče izvajati nekatere procese ali da bodo določeni podatki, ki smo jih prej spregledali, postali naša konkurenčna prednost.
Če bomo potrebovali večje spremembe v delovanju aplikacije, lahko to v prihodnosti znatno oteži prehod na nove različice; vsak prehod pa bo zahteven tako z vidika razvoja kot tudi uvajanja.
6. Uporabite več dobaviteljev
Poskusite sami upravljati celotno zasnovo sistema, razvoj, uvedbo in delovanje ter tega ne prepustite dobavitelju. Priporočljivo je, da na primer poslovne analitike ločite od razvijalcev. Priporočljivo je tudi, da sistem preizkusijo preizkuševalci, ki niso člani razvojne ekipe. Delo bodo opravili učinkoviteje, verjetnost, da boste dobili brezhiben izdelek, pa je precej večja. Če je za delovanje odgovorna druga stranka (npr. ponudnik storitev v oblaku), se prepričajte, da bo ta pritiskala na razvijalce, da bodo dostavili izdelek, ki zmanjšuje težave pri delovanju sistema.
7. V pogodbi opredelite postopek prekinitve pogodbe, vključno s kaznimi za dobavitelja
Kako je v pogodbi določena prekinitev sodelovanja? Trimesečni odpovedni rok, po izteku katerega prenehate plačevati, dobavitelj pa preneha nuditi podporo? To je povsem nezadostno.
Treba je natančno opredeliti, kakšno dokumentacijo in v kakšni obliki vam mora dobavitelj predložiti – ali pa jo predloži neposredno novemu dobavitelju – v odpovednem roku. Če ste si zagotovili pravice intelektualne lastnine do zasnove, izvorne kode in drugih delov dokumentacije, navedenih v točki 3, toliko bolje. Pri sklepanju pogodbe z dobaviteljem je dobro preveriti pri podjetjih, ki so zasedla 2. in 3. mesto, kaj bodo potrebovala, če bodo od zmagovalca prevzela razvoj in vzdrževanje.
8. Obvestite dobavitelje o načrtih za prihodnji razvoj
Prizadevajte si za dolgoročno partnerstvo s svojimi dobavitelji. Če z njimi redno razpravljate o svojih razvojnih načrtih in strateških vprašanjih – in ne le o trenutnih spremembah funkcionalnosti –, vam bo dobavitelj morda predlagal rešitve, ki bodo omogočile stabilno, učinkovito in stroškovno učinkovito sistemsko arhitekturo, ki bo ustrezala ne le vašim trenutnim, temveč tudi prihodnjim potrebam. Za pojasnitev vaših zahtev lahko uporabite na primer metodo MuSCoW, ki zahteve razvršča v naslednje kategorije:
- Nepogrešljivo – nepogrešljivo
- Moral bi – moral bi
- Lahko bi – bi bilo lepo imeti
- Tokrat ne bom imel – tega trenutno ne potrebujem
9. Zberite ideje in mnenja drugih udeležencev
Ne obtičite na enem mestu; sledite trendom; poiščite najboljše pristope in prakse; ter imejte vse na očeh. Najemite podjetje, da pridobite tretje mnenje – vaše odločitve bodo ocenili tako s tehničnega kot strateškega vidika. To ni nujno drago. Takšno svetovanje se splača, saj vam bo pomagalo izogniti se napakam. Iz lastnih izkušenj poznam primer, ko je dobavitelj prisilil stranko, da je vložila več milijonov kron v rešitev problema, ki ga je sam povzročil; svetovalec pa je ugotovil, da ta naložba sploh ne bi rešila problema, saj je bil vzrok drugje.
Svetovalec vam lahko pomaga opredeliti strategijo, ustvariti povpraševanje, ovrednotiti možnosti in na stvari pogledati z nepričakovanega zornega kota. Pomaga vam lahko tudi pri pregledu dobaviteljev in zagotavljanju najboljšega možnega izida za vas. Svetovalec mora vedno upoštevati, da želite biti Neodvisno posameznega dobavitelja in da vrednost svojega znanja in izkušenj prepoznavate kot konkurenčno prednost.
Prava izbira dobaviteljev je O nas obvladovanje O nas
Verjamem, da imate po branju tega članka jasnejšo predstavo o tem, kako svoje dobavitelje spremeniti v partnerje pri doseganju uspeha in ne postati njihovi vazali. Preprečevanje neprijetnih situacij O nas obvladovanju tveganj in izbiri rešitev, ki uravnotežajo sedanje zahteve s prihodnjo prilagodljivostjo. Z upoštevanjem zgornjih načel boste zagotovili pravo izbiro dobaviteljev in novih sistemov.
