Ads 468x60px

tiistai 25. elokuuta 2015

Ajatuksia jatkuvuuden hallinnasta

Jatkuvuuden hallinnan kymmenen sudenkuoppaa ja miten vältät ne
Yrityksen ja organisaation johdolla on velvollisuus asettaa tavoitteet ja varmistaa resurssit sille, että yrityksen ydinliiketoiminta pystyy jatkumaan ja toipumaan merkittävistä häiriötilanteista.
Väitän, että suurella osalla suomalaisten yritysten ja organisaatioiden johtajista ei kuitenkaan ole riittävää varmuutta siitä onko yrityksen kriittisten ydinsovellusten jatkuvuus oikeasti varmistettu riittävällä tasolla IT:n ja sovellusylläpidon osalta (palvelutuottajilla tai omassa ylläpidossa) tapahtuvan merkittävän häiriön sattuessa.
Kaikilla ammattimaisilla palveluntuottajilla tai yrityksen omilla jaetuilla alusta- tai infrastuktuuripalvelua tuottavilla yksiköillä on varmasti omat jatkuvuussuunnitelmansa kirjoitettuna ja ylläpidettyinä, monella toimijalla myös riittävällä tasolla säännöllisesti testattuna. Nämä jaetun infrastruktuurin jatkuvuussuunnitelmat eivät vain kata yritysten liiketoimintasovelluksia.
Väitän myös, että kun yrityksen liiketoiminnassa tapahtuu merkittävä pitkävaikutteinen häiriö, häiriötä johtavalla tai toipumista edistävillä ryhmillä ei välttämättä ole käytettävissään ajan tasalla olevaa tilannekuvaa häiriöistä, kommunikointikanavat ovat puutteellisia, sovelluskohtaiset toipumisratkaisut ovat epäselviä tai puuttuvat sekä pahimmassa tapauksessa jopa toipumista johtavan ja korjaavan ryhmän työvälineetkään eivät toimi. Lisäksi toipumista ohjataan vaillinaisen tai väärän tiedon varassa.
Olen listannut alle jatkuvuuden hallinnan kymmenen sudenkuoppaa, jotka huomioimalla tai korjaamalla ylläolevia riskejä saadaan pienenettyä:
  1. Yrityksen ylin johto ei ole asettanut tavoitetta yrityksensä sisällä siitä, että liiketoiminnan ja IT:n tulee yhdessä varmistaa ydinliiketoimintojen jatkuvuus. Joissain tapauksissa yritysjohto on saattanut tämän vaatimuksen asettaa, mutta ei ole silti varmistanut resursseja tälle toimeksiannolleen.
  2. IT:n ja liiketoiminnan/prosessiomistajan (yhä) erilainen näkökulma kriittisiin sovelluksiin. Jaettuja alustoja ylläpitävä IT-ryhmä näkee yleensä vain omat tutut turvalliset palvelunsa, eikä heillä ole välttämättä mitään tietoa siitä, mitkä sovellukset ovat yritykselle kaikista kriittisimpiä eivätkä he tunne sovelluksiin liittyviä integraatioita ja/tai sidonnaisuuksia. Liiketoimintayksiköt puolestaan eivät tunne riittävällä tasolla alustapalveluiden tarjoamia mahdollisuuksia tai rajoitteita.
  3. Ympäristöjä ylläpitäviä IT-infrastruktuuriryhmiä syytetään usein siitä, että he eivät kommunikoi liiketoiminnan tai sovellusylläpitäjien kanssa tarpeeksi tai samalla kielellä. Tässä tapauksessa oikeasti liiketoimintayksiköiden tulee ensin kertoa selkeästi IT-ryhmille vähintäänkin kriittiset sovelluksensa, integraationsa ja prosessinsa, niiden keskeytyksen sietoajat, siedetty tiedon menetysaika, tekemänsä riskiarviot ja -skenaariot sekä kerrottava IT:lle haluttu kriittisten sovellusten palautusjärjestys. Tämän tiedon saatuaan IT-ryhmillä on merkittävästi helpompaa kertoa liiketoiminnalle mitä tavoitetilaan pääseminen itse IT:n osalta vaatii (esimerkiksi aika, investoinnit, resurssit, mahdollisesti tarvittavat uudet osaamiset ja prosessit).
  4. Suunnitellaan vain alustapalveluiden ylläpitäjävetoisesti. Sovellusylläpidon ryhmiä ei tuoda tarpeeksi syvälle mukaan jatkuvuuden hallinnan suunnittelu- ja toteutusprosessiin. Tämän vuoksi sovellusten vaatimat Integraatiot, riippuvuudet ja prosessit toiminnan varmistamiseksi voivat jäädä liian vähälle huomiolle ja jatkuvuuden hallinnan toipumissuunnitelmat  jäävät vajaiksi.
  5. Jatkuvuuden hallintaa toteutetaan ja ymmärretään yrityksessä ja yrityksen yksiköissä eri tavalla. Liian usein vieläkin mennään siitä mistä aita on matalin, tehdään yksi jatkuvuusdokumentti, jossa on toteutettu vain ohjaava toiminne (jatkuvuussuunnittelu) ja unohdettu itse korjaava toiminne (toipumissuunnittelu), ”kyllä palvelutuottaja nämä korjaa”.  Palvelutuottaja varmasti tavalla tai toisella korjaa, mutta kyse onkin siitä, että pyritään hallitusti ohjaamaan ja varmistamaan etukäteen se, että kriittiset sovellukset ja alustat palvelisivat parhaiten merkittävässä häiriötilanteessa sitä käyttävää liiketoimintaa. Riittävällä syvyydellä ja samaan malliin pohjautuvalla suunnittelutavalla ympäristöt olisivat todistettavasti varmennettuja, toipuminen testattu, kommunikointitavat määritelty ja eri sovellusten kriittisyys olisi kaikilla palvelua tuottavilla osapuolilla selvillä sekä jatkuvuuden johtaminen ja toipumistoimet toteutettaisiin ennalta sovitun toistettavan palautustavan mukaisesti.
  6. Varaudutaan vain niihin merkittäviin häiriötilanteisiin, joihin on olemassa helpot korjaus- tai toipumistavat. Tämä lähestymistapa on yksi yleisimmistä jatkuvuussuunnittelun helmasynneistä.  Kun tuodaan mukaan myös aikaisemmin mainittu sovellusnäkemys ja ylläpitäjistä riippumaton riskien arviointiprosessi riskiskenaarioineen tämä riski pienenee.
  7. ”Nämä on näitä IT:n juttuja” Myös liiketoimintayksiköiden on oltava vahvasti mukana jatkuvuussuunnittelussa sekä myös omalta osaltaan oltava valmis kehittämään, lisäämään osaamistaan ja muuttamaan omia prosessejaan jatkuvuuden varmistamiseksi.
  8. Jatkuvuuden hallinta ei ole kertalaukaus, vaan elävä jatkuva prosessi jonka toimintaa tulee myös testata, kehittää ja ylläpitää. Yrityksen kassakaappiin haudattu useamman vuoden takainen päivittämätön jatkuvuuden hallinnan dokumentti voi pahimmillaan johtaa myös vääriin korjaustoimenpiteisiin tai kriisiohjaukseen, joka ei ole enää toipumista parhaiten palveleva.
  9. Jatkuvuuden hallinnan prosesseja ei kouluteta niitä ylläpitäville henkilöille eikä jatkuvuuteen liittyviä toipumistilanteita ja niihin liittyvää kommunikointia harjoitella riittävästi. Jo yksinkertaiset työpöytäharjoitukset tuovat toipumista johtaville ja suorittaville henkilöille varmemman pohjan oikeaa kriisitilannetta varten. Pääsääntöisesti jokaisesta läpiajetusta harjoituksesta löytyy puutteita, jotka korjattuna parantavat ja kehittävät jatkuvuuden hallintatoimia tulevaisuudessa.
  10. ”Nämä ovat niin monimutkaisia ja vaikeasti rakennettavia asioita”. Eivät ole. Jatkuvuuden hallinnan osa-alueille on olemassa standardeja, parhaita käytäntöjä sekä ohjeita. Näitä standardeja ja malleja yritysten kannattaa seurata toteuttaessaan jatkuvuuden hallintaa.  Esimerkki hyvästä jatkuvuuden hallinnan standardista on ISO22301. Tätä ISO22301 standardia vasten yrityksen jatkuvuuden hallinta voidaan myös auditoida ja sertifioida ja tehdä ydinliiketoiminnan jatkuvuudesta toimivaa, yksinkertaista, ymmärrettävää, toistettavaa ja tasalaatuista toimintaa.

Ei kommentteja:

Lähetä kommentti