image Erityisesti intranet-projekteissa tulee ajoittain vastaan kysymys, että pitäisikö asiakkaan valita jokin pitkälle kehitetty tuoteratkaisu vai jokin joustavampi räätälöintialusta jonka saisi sitten tehtyä juuri sellaiseksi kuin haluaa.

Tuoteratkaisu houkuttelee erityisesti silloin jos ei ole aikaa tai halua selvittää omalle organisaatiolle tärkeitä asioita. Tällöin tuoteratkaisu jossa on kaikki tärkeät intranettien perustoiminnot (uutiset, blogit, yritystietosivut, yhteystiedot, kalenteritoiminnot, ryhmätyötilat, ym.) tuntuu houkuttelevalta. Jos kerran tuloksia pitää saada nopeasti, niin miksipä ei ottaisi tuotetta ja taivuttaisi organisaatiota sopimaan tuotteeseen?

Tavoite onkin hyvä ja kannatettava. Jos oman organisaation ydintoiminta ei ole suunnitella intranetteja, niin tuoteratkaisu voi auttaa ratkaisemaan monia ongelmia tehokkaasti. Parhaimmillaan tuotepohjaisessa ratkaisussa avaintoiminnot toimivatkin suoraan paketista paremmin kuin asiakas edes olisi osannut toivoa. Esimerkiksi toiminnanohjausjärjestelmien (ERP) kohdalla yli 20 vuotta kehitystyötä on jo monella alueella hionut toiminnallisuudet kohdalleen. Esimerkiksi laskutukseen, tuntikirjauksiin, ym. liittyvät valmistoiminnot ovat monessa järjestelmässä erittäin pitkälle kehitettyjä, eikä monikaan organisaatio enää haaveile koodaavansa omaa laskutussoftaa.

Kaikilla alueilla ei kuitenkaan olla ollenkaan näin pitkällä kehityksessä – ja useimmilla kypsilläkin markkinoilla on joukossa mätiä omenoita varsin paljon. Täten sikaa ei kannata ostaa säkissä vaikka ei kummoisia erityisvaatimuksia possulle osaisikaan esittää. Esimerkiksi sähköpostiohjelmistoja on kehitetty yli 20 vuotta, ja vieläkin Microsoft ja Google kisailevat uusilla innovaatioilla, joista tietotyöläiset ovat aidosti innostuneita nähdessään ne.

Tuotevalinnan tekemisessä on siis oltava tarkkana. Erityisesti tiedonhallinnan kentällä asiat ovat muuttuneet viime vuosina niin nopeasti, että on vaikea kuvitella ohjelmistojen olevan jotenkin kypsässä vaiheessa tällä hetkellä.

Tämä ei tarkoita etteikö hyviä tuoteratkaisuja olisi markkinoilla. Itse asiassa tuotteita on tarjolla varsin paljon – pelkästään erilaisia intranet-tuotteita on tarjolla kymmenittäin jopa isoillekin organisaatioille. Pilvipalveluiden hype myös kiihdyttää entisestään tätä valmistuotteiden markkinaa.

Tuoteratkaisua harkitessa on kuitenkin syytä tuntea tuoteratkaisujen erityispiirteitä. Esimerkiksi intranet-käyttöön tarkoitetuissa tuotteissa on kolme isoa asiaa jotka erottelevat ne joustavammista räätälöintialustoista (kuten nyt vaikkapa suoraan paketista otetusta SharePointista tai jostain Oraclen tai IBM:n portaalituoteratkaisusta):

  1. Monet tuotteet ratkaisevat vain osaongelmia. Pitkälle viety tuote vaatii kehitysresursseja toiminnallisuuksien osalta erittäin paljon – ja jotta saavutetaan lisäksi korkea käytettävyys, niin useimmat tuotteet ovat tarkasti keskittyneitä ratkaisemaan vain jonkun osa-alueen ongelman erittäin hyvin. Esimerkiksi Atlassian Confluence –wikijärjestelmä loistaa wiki-tyyppisessä tiedonjakamisessa, muokkaamisessa ja hallinnassa. Confluencea ei esimerkiksi dokumenttienhallintaan tai vähänkään määrämuotoisempaan ryhmätyöhön taas voi suositella ollenkaan. Myös monien web-julkaisujärjestelmien kylkeen tehdyt “intranet-paketoinnit” tarjoavat intranet-ratkaisuja, joiden ominaisuudet ovat valtaosaltaan keskittyneitä sosiaalisen intranetin vaatimiin toimintojen (esim. EPiServer Relate+ Intranet Edition, Sitecore Intranet Portal). Tämä ensimmäinen kohta vaatii asiakkailta paljon omatoimista kokonaisarkkitehtuurin hallintaa, ja eri tuotteiden välisiin integraatioihin panostamista.
  2. Tuoteratkaisut on aina optimoitu tiettyyn asiakastarpeeseen tai –tilanteeseen. Tuotteen helpon ostettavuuden kannalta on kehittäjien aina järkevää pyrkiä tekemään toiminnallisuuksia, jotka ovat keskenään samantasoisia ja ratkaisevat samantyyppisten asiakasorganisaatioiden ongelmia. Esimerkiksi SharePointin voisi sanoa olevan optimoitu ratkaisemaan sellaisen organisaation tiedonhallintatarpeita joka on vasta siirtymässä hiljalleen pois verkkolevyjen maailmasta, ja vasta hakee omaa tapaansa hallita tietojaan. Esimerkiksi organisaatiot joilla on ollut aiemmin hyvin kehittyneitä intranetteja ja monimutkaisia dokumenttienhallintajärjestelmiä ovat paikoitellen kokeneet SharePointin perustoiminnot puutteellisiksi ja yksinkertaisiksi. Täten ostajaorganisaatioiden kannattaa varmistaa, että oma taso vastaa käyttöönotettavan tuotteen taustalla olevaa tasoajattelua. Jos tuote on liian kehittynyt, ja sisältää esimerkiksi liikaa toimintoja, niin tästä voi seurata muutosvastarintaa käyttäjiltä, joilta monipuolinen tuote vaatii liian suurta tasohyppäystä omissa taidoissa. Vastaavasti jos tuote on liian alhaisella tasolla omaan käyttöön, niin räätälöintipaineet ovat suuria ja käyttäjissä syntyy tyytymättömyyttä tuotteen “huonoja suunnitteluratkaisuja” kohtaan.
  3. Tuotteilla on aina jokin filosofia – tapa ajatella täydellistä tiedonhallinnan maailmaa. Osa tuotteista näkee tiedonhallinnan tulevaisuuden olevan vapaamuotoisessa, wikityyppisessä muokkaamisessa (esim. Atlassian Confluence), kun taas toiset ovat enemmän strukturoidun, jopa prosessiohjatun tiedonhallinnan kannattajia (esim. Microsoft SharePoint). Erittäin sosiaalista intranet-palvelua haluavan organisaation taas kannattaa tutustua nimenomaan yhteisöllisistä lähtökohdista ponnistaviin intranet-ratkaisuihin (ja esimerkiksi SharePointin laajennuksiin). Organisaation on tunnettava oma tapansa suhtautua tiedonhallintaan, koska jos tuotteen tapa on liian erilainen, niin vastarinta ottaa käyttöön uusia välineitä voi olla erittäin aktiivista. Monilla pitkälle viedyistä tuotteista on myös hyvin tiukasti tuotteeseen koodattu tapa määritellä millainen on hyvä intranet. Tähän tapaan kannattaa tutustua ennenkuin päättää omaksua kyseisen tuotteen ajattelutavan.

Kaikki tämä vahvistaa sitä tarvetta, että organisaation on tunnettava erityisen hyvin omat vaatimuksensa ja tilanteensa ennenkuin organisaatio voi tehdä tietoisen tuotevalinnan – esimerkiksi intranettiinsa. Hyvän tuotevalinnan voi tehdä karkeasti kahdella eri tavalla:

  1. Perinteisesti omien vaatimuksien tunnistaminen tapahtuu tekemällä vaatimusmäärittely oman organisaation tarpeista keskittyen niihin vaatimuksiin/kipupisteisiin joita organisaatio osaa tunnistaa itsenäisesti.
  2. Vaihtoehtoisesti hyvän tuotevalinnan voi tehdä myös kokeilemalla useita tuotteita rinnakkain, ja määritellen omat tarpeensa näiden kokemuksien perusteella.

Jälkimmäinen vaihtoehto on kenties nopein, mutta vaatii myös tiukkaa ohjausta, koska vaarana on päätyä vaatimusmäärittelyssään todelliseen joulupukin lahjalistaan jota ei saada lopulta toteutettua millään tuotteella.

Käytännössä nämä eri ääripäät kannattaakin yhdistää ja esimerkiksi intranettien vaatimusmäärittelyvaiheessa on lähes aina järkevää tutustua muutamaan tuotteeseen, jotta konkretia ja mahdollisuudet tulevat määrittelytyöryhmälle tutuksi.

Vaatimusmäärittelyn tärkein tehtävä tulisi kuitenkin olla kaikissa malleissa sama: Vaatimusmäärittelyn tulee aina asettaa tunnistetut vaatimukset järjestykseen liiketoiminta-arvon perusteella. Lopullinen tuotevalinta tulisi aina tapahtua tämän priorisoidun vaatimuslistan avulla. Näin päädytään tuotteisiin ja ratkaisuihin, jotka ratkaisevat organisaatiolle kaikkein tärkeimmät vaatimukset parhaiten.

Todellisia tuotepohjaisia ratkaisuja kun ei voi räätälöidä, vaan ainoastaan konfiguroida, joka tarkoittaa joidenkin toimintojen piilottamista tai yksinkertaistamista. Täten tuotepohjaisen ratkaisun valinta vaatii enemmän asiantuntemusta omista vaatimuksista kuin joustavamman räätälöintialustan kanssa työskentely.

Kärjistetysti vain täysin räätälöity toteutus yhdistettynä ketteriin menetelmiin mahdollistaa vaatimusmäärittelyn ohittamisen tietojärjestelmähankkeissa – ja silloinkaan sitä ei suositella (ei edes ketteriin menetelmiin kaikkein pahiten hurahtaneiden toimesta). Mitä enemmän halutaan tuotepohjaisia ratkaisuja, niin sitä paremmin omat vaatimukset on tunnettava etukäteen.