Miksi integraatioprojektit epäonnistuvat?

Miksi integraatioprojektit epäonnistuvat yleensä muita hankkeita useammin? Vai epäonnistuvatko ne? Ainakin integraatioprojekteilla tuntuisi olevan maine, että työmääräarviot epäonnistuvat usein, ja projektit ovat kalliita ja vievät paljon aikaa. Eikö markkinoilla ole taivaan tähden yhtään hyvää integraatioratkaisua? Emmekö voisi tehdä vain point-to-point-integraatioita? Se olisi edes nopeaa ja halpaa. Ongelmat liittyvät yleensä projektijohtamiseen, eivätkä tekniikkaan. Integraatioprojekteilla on monia erityispiirteitä, jotka on otettava huomioon, kun integraatioprojektiin ryhdytään.

Muutos on väistämätöntä - nauti siitä!

Perinteinen vesiputousmalli ei sovi hyvin integraatioprojekteihin, koska vaatimukset muuttuvat tämän tästä - jatkuva muutos on integraatioiden yhteydessä enemmän sääntö kuin poikkeus. Jos järjestelmiä, joita ollaan integroimassa, kehitetään projektin kuluessa, myös niiden väliset integraatiot muuttuvat - ja monta kertaa. Joten, unohda vesiputous ja varhaisessa vaiheessa lukkoon lyödyt vaatimukset. Sen sijaan integraatioiden vaatimusmäärittelyt tulisi tehdä vasta, kun kyseisen integraation kuluttamat rajapinnat on suunniteltu ja toteutettu. Integraatioiden kehitys pitäisi pyrkiä aina tekemään mahdollisimman ketterällä tavalla, ja muutoshallinnan tulisi olla jouhevaa.

Integraatioiden suunnittelussa voi olla vaikeaa tunnistaa yhteiset ja uudelleenkäytettävät komponentit ja ne, joilla on vain yksi käyttötarkoitus ja luultavasti vähemmän jatkokehitystarpeita. Uudelleenkäytettävät ja monikäyttöiset komponentit tulisi suunnitella siten, että muutokset ovat helppoja ja nopeita tehdä ja että ratkaisut ovat jo alun alkaen mahdollisimman yleiskäyttöisiä.

Joskus järjestelmiä vaihdettaessa tarvitaan myös väliaikaisia ​​integraatioita, joita käytetään vain vähän aikaa vanhan ja uuden järjestelmän toimiessa rinnakkain. Väliaikaisten integraatioiden tulisi päätyä nopeasti suunnittelupöydältä tuotantoon, ja niitä voi vähän purkkaviritelläkin - kunhan ne tekevät halutun asian. Mutta kannattaa varmistaa, että väliaikaiset integraatiot pysyvät väliaikaisina.

Tärkeintä on ymmärtää, ettei ymmärrä kaikkea

Integraatioiden monimutkaisuus on otettava huomioon projektia suunniteltaessa. Jos automatisoituja liiketoimintaprosesseja ei ymmärretä kokonaisuudessaan, voi helposti jäädä huomioimatta integraatioiden olennaisia yksityiskohtia. Tämä taas voi johtaa hankkeen virheelliseen suunnitteluun ja työmäärien ylityksiin. Siksi integraatioasiantuntijoiden tulisi olla mukana jo hankkeen alkuvaiheessa.

Integraatioprojektin alussa eri sidosryhmillä saattaa olla erilainen käsitys projektin tavoitteesta. Integroitujen järjestelmien käyttäjät ajattelevat asioita luonnollisesti omasta näkökulmastaan ​​ja oman tuotteensa toiminnan kannalta - eivät koko prosessia. Kaikkien osapuolten pitää olla ennen projektin aloittamista yhtä mieltä siitä, mitä ollaan tekemässä. Tämän lisäksi automatisoitavat prosessit on dokumentoitava. Jos et pysty kuvaamaan liiketoimintaprosessiasi, et tunne sitä.

Joskus integraatioalustoja ja integraatioita kohdellaan kuten muita järjestelmiä, vaikka integraatioilla on paljon enemmän riippuvuuksia kuin muilla ohjelmistoilla, eivätkä ne ole samalla tavalla valmiita tuotteita. Integraatiota ei voi testata ilman integroitavia järjestelmiä tai ratkaisuja suunnitella ja toteuttaa tietämättä, millaista dataa siinä liikutellaan. Integraatio on siinä mielessä ihmisen kaltainen, että se on varsin sosiaalinen tapaus. Integraatioilla ei edes ole merkitystä yksinään ilman integroituja järjestelmiä.

Pelkkä tekninen asiantuntemus ei yleensä riitä takaamaan integraatioprojektin onnistumista; tarvitaan asiantuntijoita, jotka ymmärtävät liiketoimintaprosesseja ja osaavat käsitellä monimutkaisia toiminnallisia vaatimuksia. IT:n ja liiketoiminnan yhteistyö on integraatioprojekteissa välttämätöntä. Asiantuntijat, jotka ymmärtävät sekä teknisiä yksityiskohtia että liiketoimintaprosesseja, takaavat integraatioprojektin onnistumisen.

Kuka saa päättää?

Integraatioprojekteissa on tyypillisesti useita osapuolia, joilla voi olla ristiriitaisia vaatimuksia. Jonkun pitää olla vastuussa lopullisten päätösten tekemisestä: kuka saa integraationsa ensin: hr vai taloushallinto? Missä master dataa säilytetään? Ennen projektin käynnistämistä tulisi valita integraatioprosesseille omistaja, joka on vastuussa kokonaisuudesta. Kyseisen henkilön pitäisi pystyä tekemään lopulliset päätökset ristiriitaisissa tilanteissa.

Joskus eri järjestelmätoimittajat haluavat tehdä kaiken itse. Kolmannet osapuolet eivät usein ole tervetulleita hankkeisiin, koska he monimutkaistavat viestintää. Joskus myös organisaatio saattaa olettaa, että heidän EAS (Enterprise Application Software) -toimittajansa voi myös toteuttaa integraatiot, eikä erillistä integraatiotoimittajaa tarvita. Vaikka valittu ERP tai CRM tarjoaisi monipuolisen valikoiman suoria liittymiä, johtaa tämä lähestymistapa spagetti-integraatioihin, joita on hankala operoida ja ylläpitää.

Osallista liiketoimintaa!

Kehittäjä voi yksikkötestata integraatiot, mutta ne pitää aina myös testata järjestelmien välillä oikealla datalla. Integraatioita testattaessa on oltava tietoa lähde- ja kohdejärjestelmästä ja niiden toiminnasta kussakin käyttötapauksessa. Integraatioiden testaus ei voi olla yksinomaan integraatiotarjoajan vastuulla: jos halutaan projektin onnistuvan, sillä pitää olla liiketoiminnan tuki. Jos liiketoiminta ei ole valmis käyttämään aikaansa projektille, projekti epäonnistuu varmasti. Integraatioita ei kehitetä IT:lle, vaan liiketoiminnalle: integraatioilla automatisoidaan liiketoimintaprosesseja, ja prosessien omistajan pitää osallistua niiden kehittämiseen.

Yhteenveto

Viisi yleisintä syytä, miksi integraatioprojektit epäonnistuvat

• Projektimalli ei tue jatkuvaa ja nopeaa muutostenhallintaa, mikä aiheuttaa viivästyksiä ja tulee kalliiksi
• Projektinhallinnasta puuttuu integraatioiden ymmärrystä, ja siten luodaan epärealistisia odotuksia
• Ristiriitoja ei ratkaista määrittelyvaiheessa, ja päätökset jätetään roikkumaan, mikä aiheuttaa viivästyksiä ja lisää muutoksia
• Kehitetään spagetti-integraatioita, koska integraatioalustaa ja erillistä integraatiotoimittajaa ei käytetä
• Liiketoiminta, jonka prosesseja automatisoidaan, ei ole mukana projektissa, ja IT:n on pärjättävä yksin

Miten me voimme auttaa?

Integraatiostrategia

Ennen kuin aloitat, hengitä syvään ja mieti hetki integraatiostrategiaasi. Mitä organisaatiossanne ja IT-infrastruktuurissanne tapahtuu lähitulevaisuudessa? Mitkä ovat tavoitteenne digitalisaatiossa? Jos näihin kysymyksiin on vaikea vastata yksin, strateginen konsultointi voi auttaa. Joskus tarvitaan joku, joka kysyy oikeita kysymyksiä. Se joku voi olla integraatiokumppaninne.

Integraatioarkkitehtuuri

Kun strategia on selkeä, voidaan ottaa ensimmäiset askeleet kohti integraatioita. Tähän tarvitaan integraatioarkkitehtuuria, jotta voidaan välttää integraatiospagetti ja sekava järjestelmäkartta. Hyvä tapa aloittaa on integraatioarkkitehtuurin nykytilan arviointi. Sen jälkeen on helpompaa tehdä strategisia teknologiavalintoja. Integraatiokartoitus on palvelu, jossa HiQ:n integraatioarkkitehti arvioi nykyisen arkkitehtuurinne, kartoittaa integraatiovirrat ja tekee ehdotuksia arkkitehtuurin yleisestä suunnittelusta sekä seuraavista askelista kohti tavoitearkkitehtuuria.

Unohda laatuportit!

Ajattele koko projekti uudelleen: joskus muut tavat soveltuvat paremmin integraation kehittämiseen kuin perinteinen (vesiputous)projekti laatuportteineen. Kun vaatimuksia tipahtelee yksitellen, voi olla vaikea antaa missään vaiheessa edes karkeita työmääräarvioita, jotka pitäisivät paikkansa. Työlään muutostenhallinnan ja lisäbudjettien hakemisen välttämiseksi kannattaa harkita integraatiokehityksen ostamista kaistana eikä projektina. Jos organisaatiosi varaa kolme kokoaikaista integraatiokonsulttia koko ERP-projektinne ajaksi, voivat nämä asiantuntijat suunnitella ja toteuttaa integraatiot ketterästi aina saatuaan kulloisetkin vaatimukset. Näin voitte keskittyä vaatimusten hankkimiseen ajoissa ja unohtaa työmäärän, budjetin ja projektilaajuuden työlään seurannan.

Muutostarpeita voidaan vähentää myös luomalla ketteristä projektimalleista tutut laatumääritelmät, kuten Definition of Ready ja Definition of Done. Varsinkin DoR:n määrittely vähentää iteraatioiden määrää, mutta sillä on myös hintansa - jos asiakasorganisaatio ei ole tottunut ketteriin projekteihin, tulee laatumääreistä ja määrittelytyöstä helposti pullonkauloja tehokkuudelle.

Jos organisaatiossanne on useampi kuin yksi liiketoimintayksikkö, saattaa niillä olla päällekkäisiä integraatiotarpeita. Tällöin keskitetty integraatioiden hallinta voi olla oikea lähestymistapa. Keskitetty integraatioiden kompetenssikeskus tarjoaa palveluja koko organisaatiolle ja hallinnoi "integraatiotehdasta" eli integraatioiden kehitystiimiä. HiQ voi auttaa organisaatiotanne käynnistämään kompetenssikeskuksen ja tarjota avuksenne myös asiantuntevia integraatiopäälliköitä vetämään kompetenssikeskustanne.

Kuuntele liiketoimintaa

Kuka on prosessin omistaja? Kenelle integraatioita kehitetään? Ota heidät mukaan prosessiin! Joskus on vaikeuksia saada IT ja liiketoiminta kommunikoimaan ja puhumaan samaa kieltä. Tässä integraatioasiantuntija, jolla on myös liiketoimintaprosessien tuntemusta, voi auttaa rakentamaan siltoja eri sidosryhmien välille.

Joskus IT:llä ei ole tarpeeksi aikaa puhua liiketoiminnan kanssa ja tiedustella niiden uusista integraatiotarpeista. Integraatiot eivät kuitenkaan määrittele itse itseään. Määrittelijä, joka keskittyy liiketoimintatarpeiden, käyttötapausten ja muiden toiminnallisten vaatimusten hankkimiseen liiketoiminnalta kehittäjille, auttaa välttämään pullonkaulat integraatiokehityksessä.