Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma

Transkriptio

1 Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma Janne J. Korhonen

2 Agenda 1. Prosessit ja palvelut, BPM ja SOA 2. BPM-projekteista yleensä 3. Prosessin elinkaarimalli 4. Kokemuksia BPM-hankkeista Liikkeelle lähtö Ensimmäinen hanke Prosessien määrittely Jatkuva kehittäminen 5. Mahdollisia kompastuskiviä

3 Prosessit ja palvelut Viime vuosien suosikkilyhenteitä tietojärjestelmien kehitykseen ja tietojärjestelmäarkkitehtuureihin liittyen ovat olleet Palveluarkkitehtuuri, SOA Liiketoimintaprosessien hallinta, BPM Konseptien taustat ovat erilaiset, mutta ne ovat yhdentymässä arkkitehtuuriksi, johon tulevaisuuden tietojärjestelmien uskotaan perustuvan Ohjelmistotoimittajien paketit tukevat molempia käsitteitä Puhujasta riippuen termit ovat erilliset tai sisältyvät toisiinsa Yhteistä niille on, että Ne lupaavat liiketoiminnalle ketteryyttä tietojärjestelmien kehittämisessä ja muuntelussa Perustuvat osaltaan liiketoiminnan käsitteiden ja tietojärjestelmien läheisempään vastaavuuteen Teknisissä toteutuksissa pääosassa ovat prosessikuvaukset ja hyvin määritellyt palvelut

4 BPM-projekteista BPM on strateginen ratkaisutapavalinta, ei vain yksittäinen tietojärjestelmä BPM-projektin läpivientimalli on luonteeltaan hyvin erilainen kuin perinteinen tietojärjestelmäprojekti BPM-kehitys on iteratiivista ja jatkuvaa Toistettava menetelmä prosessien mallintamiseen, toteutukseen ja käyttöönottoon tuo organisaatioon todellista pitkän tähtäimen hyötyä

5 Prosessin elinkaarimalli Aloitus Liiketoimintatarve Määrittely Prosessikuvaukset Suunnittelu Julkaisu Suoritus Kehitys Ajettavat prosessimallit Mittarit Optimointi Analyysi

6 Liikkeelle lähtö Kokemuksia BPM-hankkeista Edellytyksenä prosessilähtöinen ajattelu- ja toimintatapa BPM-järjestelmä tukee prosessijohtamista ja on yksi osa prosessimaisen toimintatavan käyttöönotossa Tutustuminen teknologiaan pilotoinnin ja kokeilujen (Proof of Concept) avulla Ohjelmistokustannukset eivät ole este Saatavilla on ilmaisia pilotointiin sopivia ohjelmistoja ja monet ohjelmistotoimittajat antavat tuotteilleen rajoitettuja kokeilulisenssejä Prosessienhallinta on liiketoiminnan ja IT:n yhteinen asia Kehittäjien on ymmärrettävä syvällisesti kohdealueen liiketoimintaa ja liiketoimintaprosesseja sekä tunnettava olemassa oleva ITjärjestelmäarkkitehtuuri Sopivan tuotteen valintaan kannattaa uhrata hieman aikaa ja vaivaa Tuotekirjo on laaja ja eri tuotteiden painopistealueet vaihtelevat Huomioitavia tekijöitä mm. prosessien luonne, IT-arkkitehtuuri, tavoitteet,

7 Ensimmäinen hanke Kokemuksia BPM hankkeista Näkyvä, merkityksellinen ja toteutettavissa oleva kohde Ei liian laaja eikä monimutkainen Kohtuullisella panostuksella pitäisi voida saavuttaa näkyviä ja mitattavia hyötyjä Suurin potentiaali ei-standardeissa prosesseissa, jotka ovat yritykselle olennainen kilpailutekijä ja joista heijastuu sen ydinliiketoimintaosaaminen Varmistetaan organisaation tuki hankkeille jatkossa Ensimmäisen BPM-toteutuksen konkreettisena tavoitteena on ottaa käyttöön tekninen ympäristö (BPM System), jossa liiketoimintaa ja sitä tukevia tietojärjestelmiä voidaan kehittää integroidusti yhdessä BPM-ajattelussa pyritään hyödyntämään mahdollisimman paljon jo tehtyjä tietojärjestelmäinvestointeja Mahdollisia ongelmakohtia Muutokset henkilöiden työnkuvissa ja organisaation toimintatavoissa Intressiristiriidat prosessien ylittäessä organisaatioyksiköiden väliset rajat

8 Prosessien määrittely Kokemuksia BPM hankkeista Prosessikuvauksia on yleensä aiemmin tehty PowerPointilla tai prosessien mallinnustyökaluilla, mutta paljon työtä vaaditaan vielä ennen kuin niitä voidaan suorittaa BPM-järjestelmissä Organisaatiossa on useita erilaisia toimintatapoja Riippuvuudet prosessien välillä eivät ole selviä Kaikkea ei ole kuvattu, mutta kaikkea ei kannatakaan kuvata Kaikki mikä kuvataan on kuvattava tarkasti Prosessikuvaukset ovat oleellisesti BPM-järjestelmässä suoritettavia ohjelmia, jolloin niiden on oltava eksaktisti määriteltyjä Prosessiarkkitehtuurin suunnittelu olennaisen tärkeää Toimijoiden välinen koordinointi, prosessihierarkia, tietojärjestelmäliittymät, jne Mahdollistaa monimutkaisen kokonaisuuden hallinnan ja muutettavuuden Palveluajattelu sekä liiketoimintapalveluissa että tietojärjestelmien integroinnissa

9 Jatkuva kehittäminen Kokemuksia BPM hankkeista BPM-järjestelmässä esitettyihin prosesseihin voidaan tietyissä rajoissa tehdä muutoksia ilman ohjelmistokehityshankkeita Integroidut tietojärjestelmät ja käyttöliittymät asettavat rajat pelkille prosessikuvausten muutoksille Usein joudutaan tekemään muutoksia palvelurajapintoihin ja käyttöliittymiinkin Suoritettavan prosessilogiikan luominen graafisilla kuvauksilla ei vähennä sen luontaista monimutkaisuutta Muutosten teossa vaativinta on ymmärtää mihin kaikkialle se vaikuttaa ja mitä kaikkea on muutettava Zero code ei ole sama kuin Zero work Muutokset voivat vaatia paljon hiirityöskentelyä Muutosten hallinta, dokumentointi ja testaus tärkeitä

10 BPM ja SOA: Palveluajattelu prosessinhallinnassa Kollaboratiiviset prosessimallit SOApalvelut Prosessikehitys Ajettava prosessi Ajettava prosessi BPMS IT-kehitys Tietojärjestelmät

11 Mahdollisia kompastuskiviä Analyysiparalyysi Määritellään liian pitkälle Määrittely, suunnittelu ja toteutus iteratiivista ja päällekkäistä BPM-tuote = BPM-ratkaisu BPM on ratkaisutapavalinta Yhden prosessikoneen ideologia Tuotteen valinta vaatimusten mukaan Kärrypolun asfaltointi Älä anna liiketoiminnan suunnitella uusia prosesseja! BPM on ihmelääke Ei ratkaise kaikkia liiketoiminnan ongelmia Liiallinen räätälöinti Vähentää joustavuutta, viivästää valmistumista Monimutkaisuuden aliarvioiminen Jotkin liiketoimintaprosessit voivat olla hyvin, hyvin monimutkaisia