Times like these

(Human) Task Management

Maaliskuu 31st, 2006

Olin tänään kuulemassa Borlandin esittelyä, jonka aiheena oli Scrum ja kuinka se peilautuu olemassa oleviin ohjelmistokehityksen menetelmiin.

Mitään kovin uutta ei esittelyssä tullut esiin, mutta aloin siinä miettiä, että nykyinen projektimallimme, missä asiakas pystyy seuraamaan verkosta mitä milloinkin teemme, priorisoimaan tehtäviä ja näkemään, paljonko työtä missäkin on vielä jäljellä, on oikeastikin erittäin toimiva systeemi. Sen lisäksi, ettei kenelläkään projektin tekijällä ole koskaan epäselvää, että mitä pitäisi tehdä, voi asiakas jatkuvasti kommunikoida työn alla olevien artefaktien (sovelluskomponentin, dokumentaation, ym) toiminnallisia ja laadullisia vaatimuksia sekä käyttötapauksia esimerkkeineen tekijöille. Lisäksi projektin hallinnollinen henkilöstö näkee järjestelmästä, missä kohdin projektin vaatimuksiin on tullut muutoksia, aika-arvio muuttunut, ym.

Tämän aasinsillan kautta pääsemmekin itse otsikon aiheeseen. Erilaisista prosessinhallintaratkaisuista on puhuttu viime vuosina poikkeuksellisen paljon. Mikään uusi asiahan ei ole kyseessä, mutta nyt uusia ja olemassa olevia ratkaisuja sorvataan yhteisten standardien päälle (BPEL, ebXML, WS-I, jne) ja toisaalta taas koetetaan saada liiketoimintaprosessit liitettyä suoraan ihmisten jokapäiväisiin asiointipalveluihin verkossa.

Jossain määrinhän kaikki verkon itsepalvelut ovat osa jotain prosessia; aina kun maksat laskun, tilaat kirjan tai varaat hammaslääkäriajan netissä, käynnistät jonkun prosessin. Prosessin omistajan kannalta merkittävää kuitenkin on se, miten prosessi hallitaan: Tästä juuri on kyse, kun puhutaan BPM:stä (Business Process Management). On nimittäin tosiasia, että toistaiseksi suhteellisen harva verkkopalvelu finanssialaa lukuunottamatta hallinnoi keskitetysti liiketoimintaprosessejaan. Toki tapahtumat kirjataan talteen sovellusten tietovarastoihin ja niitä voidaan käydä sieltä kurkkimassa, mutta kun prosessit sitten jatkuvat esimerkiksi laskutus-, HR- tai vaikka logistiikkajärjestelmiin, joudutaan usein turvautumaan useisiin eri ylläpito- ja raportointikäyttöliittymiin. Tällöin mm. samaan liiketoimintaprosessiin kuuluvan datan hallinnointi voi käydä hyvinkin työlääksi.

Tämän vuoksi prosessien hallintaa suunniteltaessa onkin erittäin tärkeää tarkastella BPM:n kolmea toiminnallista aspektia: Itse teknistä prosessimoottoria (ominaisuudet, suorituskyky, samanaikaisuus, skaalautuvuus, rajapinnat, valtuutus, virheensietokyky, jne), suorituksessa olevien prosessien seuranta- ja hallintatyövälineitä, sekä sitä, miten ratkaisu tukee ihmisille annettuja tehtäviä (Human Task Management). Näistä viimeksi mainittu on jäänyt turhan vähälle huomiolle, vaikka kyseessä on toiminnallisuudeltaan laaja ja erittäin tärkeä ominaisuus BPM-järjestelmissä.

Esimerkiksi BPEL-standardi ei toistaiseksi ota tehtävänhallintaan mitään kantaa ja siksi pelkästään BPEL-standardin toteuttava tuote jättää kaikki ihmisten toimintaan liittyvät seikat (tehtävän luonti, vastuutus, vastaanottaminen, suorittaminen, eskalointi, roolitus, jne) joko järjestelmän kehittäjien toteutettavaksi tai jonkun toisen sovelluksen hallittaviksi. Juuri tämän vuoksi IBM ja SAP julkaisivatkin yhteisen ehdotuksen BPEL-standardin laajennokseksi (BPEL4People).

Teknisellä puolella BPM-ratkaisun evaluointi menee vieläkin hauskemmaksi: Miten prosessit, tehtävät ja käyttäjät rooleineen määritellään? Miten prosessi- ja tehtäväinstansseja hallitaan? Miten järjestelmän tila persistoidaan? Mitä prosesseja oikeastaan kannattaa automatisoida? Ja niin edelleen. Kaikki erittäin tärkeitä seikkoja. Itsestäni hauskimpia pähkäiltäviä ovat ns. “process choreography”-käyttötapaukset (vrt. “process orchestration”), joissa useampi toisistaan irrallinen prosessi vaihtaa tietoa keskenään.

Mutta koska tarkoitukseni ei tosiaan ollut kirjoittaa romaania, niin lopettelen nyt tähän. Hyviä viikonloppuja kaikille!

Artikkeli on luettu 572 kertaa. Kuuluu luokkiin: Menetelmät, BPM, Scrum