Fiksu ohjelmistovalinta perustuu hyvään vaatimusmäärittelyyn

Otathan huomioon, että tämä artikkeli on yli 14 vuotta vanha, joten sisältö ja linkit eivät ole välttämättä ihan ajan tasalla. Tuoreempana lukemisena sinua voisi kiinnostaa vaikkapa jokin näistä artikkeleista:

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.

North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.

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.

Suunnittelemme toimivan intranetin

North Patrolin suunnitteluprojekteissa määritellään toimivimmat työkaluratkaisut kuhunkin intranet-ympäristöön. Lisäksi intranetin palvelumuotoilulla ja prototyypeillä suunnitellaan sellaiset sisältöratkaisut, jotka tukevat sisäistä viestintää, tiedon löydettävyyttä ja arkisista työsuorituksista selviämistä.

Lue intranettien suunnittelupalveluistamme tai varaa suoraan Teams-palaveri Sarin kanssa

PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme: Onnistu verkkopalvelu-uudistuksen läpiviennissä (20.11.2024 klo 10:00). Ilmoittaudu webinaariin

Lue palveluistamme Pyydä tarjous

Perttu Tolvanen

KTM Perttu Tolvanen on digitaalisten palveluiden suunnittelun, arkkitehtuuriratkaisujen ja kumppanivalintojen asiantuntija. Perttu konsultoi asiakkaita hankkeiden valmistelussa ja vaatimusten määrittelyssä sekä tukee asiakkaita teknologia- ja toteuttajakumppaneiden valinnassa.

Pertulla on yli viidentoista vuoden kokemus erilaisista web-, extranet- ja intranet-projekteista mm. projektipäällikön, suunnittelijan ja konsultin rooleissa. Aiemmassa työhistoriassaan Perttu on toiminut tilaajana ja projektipäällikkönä suuressa mediayhtiössä, sisällönhallintajärjestelmien konsulttina isossa IT-alan yrityksessä sekä itsenäisenä, riippumattomana konsulttina omassa yrityksessään. Hän on myös tunnettu kouluttaja ja bloggaaja. Perttu on myös päätoimittaja web-aiheisessa Vierityspalkki.fi -blogissa.

Arkkitehtuurin ja teknologiavalintojen konsultointi

Autamme arkkitehtuurin suunnittelussa, vaihtoehtoisten toteutusmallien tunnistamisessa ja sopivimpien teknologioiden valinnassa. Tavoitteenamme on löytää ratkaisut, jotka vastaavat vaatimuksiin, ovat kestäviä ja täyttävät tarkoituksensa kustannustehokkaasti.

Lue palveluistamme

Pyydä tarjous

North Patrol auttaa onnistumaan

Meitä on kymmenen konsulttia, kaikki kokeneita suunnittelijoita tai teknologia-asiantuntijoita. Joka vuosi viemme läpi yli 50 projektia, joissa autamme hankkeensa eri vaiheissa olevia asiakkaitamme luomaan uusia digipalveluja ja tietojärjestelmiä. Asiakkaamme ovat olleet erittäin tyytyväisiä työhömme (arvosana 9,5/10), ja monet heistä palaavat asiakkaiksi yhä uudestaan.

Olemme apunasi, kun kaipaat puolueetonta näkemystä teknologiavalintoihin, kirkastusta palvelukonseptin ideaan, tarkennusta vaatimusten määrittelyyn, konkreettista tukea tarjouskilpailuun tai ohjausta toteutusprojektin läpivientiin.

Ota selvää firmastamme

Miten erotumme kilpailijoistamme?

  • Digipalveluiden suunnitteluun erikoistuminen

    Olemme erikoistuneet digipalveluiden laadukkaaseen suunnittelutyöhön ja vaatimusmäärittelyyn. Missiomme on auttaa asiakkaita onnistumaan hankkeissaan luomalla mahdollisimman hyvät lähtökohdat toteutusvaiheelle – oli sitten kyse ketterästä toteutuksesta omalla tiimillä tai kumppanin kanssa tehtävästä hankkeesta tai julkisesti kilpailutettavasta urakasta.

  • Emme myy koodausta emmekä lisenssejä

    Moni teknologiakonsultti suosittelee asiakkailleen teknisiä ratkaisuja, joita sama talo myös toteuttaa. Meillä tätä vinoumaa ei ole, koska meiltä ei voi ostaa koodausta tai lisenssejä eikä meillä ole riippuvuuksia teknologiatoimittajiin. Näkökulmamme ohjelmistomarkkinaan on laaja-alainen. Tavoitteena on aina löytää asiakkaalle parhaiten soveltuva ohjelmistoratkaisu, oli se sitten räätälöity ratkaisu, saas-palvelu, avoimen lähdekoodin alusta tai näiden yhdistelmä.

  • Tehokkuus, tavoitteellisuus ja tuloksellisuus

    Toimeksiannoillemme sovitaan aina konkreettinen lopputuotos, jonka avulla asiakas pääsee hankkeessaan eteenpäin. Hioutuneiden menetelmiemme ja kokeneiden konsulttiemme ansiosta pystymme tuottamaan sen tehokkaasti, yllättävän vähäisillä työmäärillä, ja rahallesi syntyy vastinetta.

Siirry takaisin sivun alkuun