Miks 90% integratsioonidest ebaõnnestub (ja kuidas sinu oma võib õnnestuda)

“Meil on tarnija, kes vingub iga kord meie muudatuste protsessi üle. Igas projektis on neil jälle mingi uus andmebaas või API vaja… ja siis peame meie jälle läbi käima kogu change-protseduuri.” – r/sysadmin

Kui sa oled olnud integratsiooniprojektide maailmas rohkem kui viis minutit, oled sa midagi sellist kuulnud – ja tõenäoliselt ka kogenud. Integratsioonid ei kuku tavaliselt läbi sellepärast, et tehnoloogia ei suudaks. Nad kukuvad läbi, sest inimesed ei suuda.

Kui müügiosakond ei tea, et uus CRM on juba käigus; kui operatsioonitiim hoiab kinni oma “varjatud Excelist”, sest “ERP pole veel valmis”; kui IT kustutab veel tulekahjusid eelmise integratsiooni järel – on projekt juba enne surnud, kui API-d üldse ühendust võtavad.

Ja ometi käitutakse, nagu oleks see tehniline probleem.

Päris põhjus: integratsioonid surevad “vahekohtades”

Integratsioonid kukuvad läbi seal, kus tekivad lüngad – osakondade vahel, ootuste vahel, selle vahel, kuidas inimesed arvavad, et nad töötavad, ja kuidas nad tegelikult töötavad.

Esimene koosolek on alati täis optimismi. Kõik noogutavad, kui ekraanile ilmuvad voodiagrammid. Kastid ja nooled liiguvad kenasti vasakult paremale. Keegi ütleb: “Tundub üsna lihtne,” ja kõik otsustavad hetkeks uskuda.

Kaks nädalat hiljem avastab finantsosakond, et andmevorming ei sobi nende aruandesüsteemiga. Turundus selgitab välja, et neil polegi ligipääsu testkeskkonnale. Lao inimesed mõistavad, et “reaalajas uuendused” tegelikult tähendavad “pärast öist sünkroniseerimist.”

See pole sabotaaž – see on entroopia. Suurtes organisatsioonides on kõik nii hõivatud oma väikese osa optimeerimisega, et keegi ei näe, kuidas kogu süsteem ummistub.

Saladus: asi pole koodis, vaid koordineerimises

Ettevõtted, kes pääsevad integratsioonide “hauaplatsilt” – sealhulgas mitmed Kaunase High Tech Clusteri liikmed – ei käsitle integratsiooni tehnilise probleemina. Nad käsitlevad seda koordinatsiooniprobleemina.

Nad ei ehita ainult API-sid; nad ehitavad arusaamist.

Enne, kui kirjutatakse esimene koodirida, korraldavad nad “sõjaruume”. Mitte show pärast, vaid ühtse suuna saavutamiseks. Nad toovad ühte ruumi müügi, operatsioonid, IT, finantsi ja isegi praktikandi, kes uuendab juhtimislauda, ning küsivad lihtsa küsimuse:
“Mis sinu jaoks muutub?”

Nad teevad pilootprojekte osakondade kaupa. Nad kirjutavad “inimloetavad väljalaskemärkmed” – lühikesed, lihtsas keeles tekstid, mis selgitavad, mis tegelikult muutub.
(“Sa ei pea enam kasutama Exceli tabeli 3. sakki. Uus väli ‘Product_ID’ asendab ‘SKU’. Ja ei, sa ei pea vana andmestikku parandama – see on juba tehtud.”)

See pole glamuurne töö. See pole tehisintellekt ega pilveime. Aga see töötab. Ja päästab projekte, mis muidu hukkuksid kommunikatsioonipuuduse tõttu.

Näide elust enesest

Üks meie klastriliikmetest töötas keskmise suurusega tootmisettevõttega, kes püüdis ühendada oma ERP-, logistika- ja CRM-süsteemid – tõeline ettevõttekaose kolmik.

Enne koodi kirjutamist nõudis meeskond, et iga inimene, keda muudatus puudutab, osaleks ühetunnisel sessioonil, kus seletati, mis muutub ja miks. Klient ohkas. Projekti algus lükati kahe nädala võrra edasi.

Aga kui süsteem lõpuks käivitati, juhtus midagi haruldast: mitte miski ei läinud katki.
Müügitiim lõpetas IT-abile helistamise iga kümne minuti tagant. Ladu ei paanitsenud. Kõik teadsid, mis juhtub ja miks.

Need kaks nädalat viivitust päästsid kolm kuud kriisihaldusega tegelemist.

Kuidas panna oma integratsioon õnnestuma

1. Ära alusta enne, kui kõik mõjutatud osapooled oskavad kirjeldada “pärast”-seisundit.
   Kui kasutajad ei suuda selgitada, kuidas edu välja näeb, siis pole koodil tähtsust.
2. Kaardista sõltuvused enne, kui alustad kodeerimist.
   Ja eelda, et sa oled mõne unustanud – sest oled. Peidetud andmevood ja vanad skriptid on igas nurgas.
3. Määra üks integratsiooniomanik, kes pole arendaja.
   Vali inimene, kes mõistab protsesse, mitte ainult koodi. Tema märkab inimlikke lõkse enne, kui need tootmisse jõuavad.
4. Suhtle inimkeeles.
   200-sõnumiline Slacki teema pole dokumentatsioon. Inimesed peavad mõistma ja tundma, kuidas nende töö muutub.

Integratsioonid ei kuku läbi pilves. Nad kukuvad läbi koosolekuruumis.

Järgmisel korral, kui keegi süüdistab API-t, vaata ringi. Väga tõenäoliselt istub tegelik “viga” kusagil kontoritoolis, mitte serveris.

Unusta “plug-and-play” illusioon. Ära usu PowerPointi, mis lubab “saumatu integratsiooni.”

Lõpeta suurte nimede usaldamine. Alusta päris probleemide lahendamist.