Nopeat muutokset sote-arkkitehtuuriin

Muutosmatkalle otetaan mukaan kaikkein muutoskykyisimmät ja avoimeen yhteistyöhön uskovat organisaatiot. Näin mahdollistetaan sote-arkkitehtuurin jatkuva evoluutio, joka on välttämätöntä organisaaiotioiden toiminnan jatkuvan kehittämisen mahdollistajana. Käsittelen arkkitehtuurin evoluutiota tarkemmin aiemmassa kirjoituksessani.

Sote-uudistuksessa rakennetaan yhteentoimivia järjestelmiä monitoimittajaympäristössä. Tällainen ympäristö vaatii erityishuomiota todellisen ja jatkuvan muutoskyvykkyyden rakentamiseksi ja ylläpitämiseksi. Tulevaisuuden vaatimukset ovat vähintään yhtä tärkeitä kuin nykyiset vaatimukset. Ongelmana tulevaisuuden vaatimusten osalta on tietysti se, että niitä ei pystytä määrittelemään vielä tänään. Onneksi tässä vaiheessa riittää, että hankitaan rekkalasteittain muutoskyvykkyyttä tulevaisuuden tarpeisiin. Muutoskyvykkyyteen vaikuttavat kaupalliset, tekniset sekä operatiiviset asiat.

Kaupallisiin asioihin kuuluvat mm. kilpailutukset, sopimukset sekä hankintakokonaisuuksien hallinta. Kilpailutuksen osalta ei kannata ostaa pisteratkaisua, joka ratkaisee vain nykyiset ongelmat. Samalla pitää ostaa tuki jatkuvalle kehittämiselle. Mikäli  ensimmäisen vaiheen kesto on pidempi kuin puoli vuotta niin silloin jo ensimmäisen vaiheen osalta on tärkeämpää ostaa muutoskyvykkyyttä kuin tiukasti etukäteen määriteltyä vaatimussettiä.

Teknisessä mielessä tarvitaan modulaarisia kokonaisuuksia hallituilla rajapinnoilla. Rajapintojen osalta tarvitaan avoimuutta, reiluja käyttöehtoja sekä muutoshallintaa, joka mahdollistaa jatkuvan kehityksen monista eri suunnista tulevien muutospyyntöjen toteuttamiseksi. Käytännössä tämä tarkoittaa esimerkiksi sitä, että kun tiedolla johtamisen tueksi tarvitaan tietoja useammista eri järjestelmistä niin ne myös saadaan käyttöön vaivatta. Monitoimittajaympäristössä tämä voi tarkoittaa muutoksia useamman toimittajan järjestelmiin sekä synkronoituja toimituksia lyhyelläkin aikavälillä. Voitaisiinko tarvittavat muutokset tehdä muutamassa kuukaudessa vuosien sijaan? Hyvänä tavoitteena voisi pitää tuotantoon viennin alle kolmessa kuukaudessa idean toteutuspäätöksestä.

Operatiiviset asiat pitävät sisällään arkkitehtuurin muutosten hallinnan – reilun ja avoimen käsittelyn muutospyynnöille. Kaikki muutokset ja niiden perustelut pitää jakaa kaikkien toimijoiden kanssa, jotta niistä voidaan keskustella ja tarvittaessa palata myöhemminkin uusien muutospyyntöjen koskettaessa samoja alueita. Muutospyyntöjä pitää katsoa suhteessa arkkitehtuurin tavoitteisiin ja sitä kautta myös strategisen tason asioihin – arkkitehtuuritavoitteiden määrittely ja mittaaminen käsiteltiin aiemmassa kirjoituksessani. Tilaajat voivat tukea tätä toimintaa esimerkiksi arkkitehtuuritoimiston avoimella ja aktiivisella toimintatavalla. Toimittajat pitää sitouttaa arkkitehtuuritoimiston aktiiviseen toimintaan jo kilpailutus- ja sopimusvaiheessa.

Edellä kuvatut asiat koskettavat kaikkia sote-tietojärjestelmien toimijoita. Erityisen paljon vaaditaan tilaajilta, joiden rooli muuttuu voimakkaasti isoista kertaluontoisista hankinnoista kohti jatkuvaa suunnittelua ja kehittämistä. Parhaimmassa tapauksessa arkkitehtuurin hallinta muuttuu sujuvaksi pienten muutosten virraksi, jossa uudistuksia voidaan vielä ideasta asiakkaille kymmennesosassa siitä ajasta mitä tyypilliset tietojärjestelmähankkeet ovat vaatineet. Näin mahdollistettaisiin mahdollisimman nopea palaute asiakkailta sekä ammattilaisilta. Toimittajilta tämä vaatii jatkuvaa yhteistyötä tilaajien kanssa, jatkuvaa julkaisujen virtaa, sekä nopeaa reagointia asiakaspalautteen perusteella.

Jos tätä toimintatapaa vertaa aiemmin vallalla olleeseen tapaan toimia niin isoimmat muutokset näkyvät työn tekemisen tavoissa arjessa, tilaajien ja toimittajien roolituksissa sekä kaikkien sote-arkkitehtuuriin osallistuvien organisaatioiden toimintakulttuureissa.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

Liity joukkoon

Backend-kehittäjä

Helsinki, Jyväskylä, Tampere

Frontend-kehittäjä

Helsinki, Jyväskylä, Tampere