V E S I P U T O U S J A K E T T E R Ä K E H I T Y S

T O I M I T U S M A LL I N A - E R I T Y I S P I I R T E I T Ä

T E R H O N E V A S A L O

Tietojärjestelmän toimitusmallin valinta

Mitä eroa ketterässä ja vesiputousmallissa – hyvät

ja huonot puolet

Mitä huomioida edellä mainituissa

toimitusprojekteissa?

Mistä tulee erityisesti sopia vesiputous- ja agile-

projektissa?

Olennaisia kaupallisia ehtoja toimitusprojekteissa

Mistä yleensä toimitusprojekteissa riidellään?

U L K O I T U S S O P I M U K S E T J A N I I D E N N E U V O T T E L U

E s i t y k s e n s i s ä l t ö

T I E T O J Ä R J E S T E L M Ä H A N K I N N A T - E L I N K A A R I

OPEROINTIVAIHE

• Uudelleenarviointi • Compliance

SUUNNITTELUVAIHE

• Tuki hankinnan kohteen

määrittelyssä

• Toimitus/sopimusmallin suunnittelu

• Reunaehtojen suunnittelu

HANKINTAVAIHE • Toimittajavalinnassa avustaminen

• Sopimusneuvottelut

• Sopimusta koskeva

muutoksenhallinta

Toimitusmallin valintaa ohjaavat tekijät

ASIA VALINTAPERUSTEITA

TOIMITUKSEN KOHDE - Tuote, olemassa olevan ohjelmiston korvaaminen vai

kehitysprojekti

- Projekti kestoltaan lyhyt vai pitkä

AIKATAULU - Vesiputousmallissa kiinteä aikataulu

- Ketterässä sprinttien aikataulutus (julkaisusuunnitelma)

aikatauluarvio

ASIAKKAAN HANKEBUDJETOINTI

- Vesiputouksessa kiinteä hinta / tavoitehinta

(muutoksenhallinta)

- Ketterässä mallissa time&material laskutus

- Ostajan päässä budjetointi haaste (mitä, milloin ja mihin

hintaan?)

TESTAUS JA HYVÄKSYNTÄ

- Ketterässä testaus ja hyväksyntä jatkuvaa

- Vesiputousmallissa testaus vasta kun ohjelmisto ”valmis”

- Asiakkaan näkökulmasta hyväksyntä laukaisee

maksuvelvollisuuden ja virhevastuurajan

ASIAKKAAN ROOLI - Vesiputousmallissa asiakkaan osallistuminen vähäistä

(pl. määrittely)

- Ketterä malli edellyttää merkittävää ajallista

sitoutumista koko projektin ajan (innostuksen

hiipuminen?)

Toimitusmalli – vesiputousmallin hyvät ja huonot puolet

Vesiputousmalli edellyttää huolellista määrittelytyötä

PROS

Tuoteprojektit ja järjestelmien

vaihtoprojektit

Sopimuksellisesti raskaampi

Kohde, kustannus ja aikataulu tiedossa

Sopimus on yksityiskohtainen

oikeuksien ja vastuiden osalta

Kaikki projektin vaiheet määritelty, vaiheistettu,

aikataulutettu ja hinnoiteltu.

CONS

Vaatii paljon määrittelytyötä alussa

(vanhentuu?)

Scopen muutokset voi olla hitaita

muutoksenhallinta-menettely

Asiakkaan näkyvyys projektiin heikko

Toimitusmalli – Agile-mallin hyvät ja huonot puolet

Puhtaimmillaan mahdollistaa nopean ”entry

to market” -mallin

PROS

R&D-kehityshankkeet ja muut vastaavat

innovaatiohankkeet

Sopimuksellisesti suoraviivainen ja kevyt

Nopeat muutokset mahdollisia

Sopimusvastuut kevyitä

Toimituksessa ei erillistä hyväksymismenettelyä

Dokumentaatiota ei synny tai se on puutteellista

projektin ja ylläpidon siirron haasteet

CONS

Määrittelyn ollessa kevyempi, riski

lopputuloksesta voi kasvaa

Kohde, kustannus ja aikataulu ei ole

tiedossa

Vaatii asiakkaalta aikaa ja resursseja

Asiakkaalla vastuu toimituksesta

SUOSITUKSET AGILE-PROJEKTEIHIN

Mitä huomioida ennen projektin aloitusta?

SUOSITUKSET / HUOMIOITAVAT ASIAT

Asiakkaan tavoitteet ja henkilöresurssit – onko realistista?

Aikataulukriittisyyden selvittäminen liiketoiminnan tarpeet

Asiakkaan budjetti vs. tavoitteet tiukka budjetti vs. ”avoin shekki”

Jos tiukka budjetti tavoitteiden selventämien ja niiden huomiointi

backlogissa

Toimituksen hyväksymismenettelystä sopiminen – jatkuva malli vai

erillinen hyväksymismenettely

Jos Product backlogin sisältö ei vähene projektin aikana virheet ja

muut ongelmat kasaantuvat toimitus viivästyy. Asiakkaalle oikeus

päättää sopimus joustavasti

Asiakas yleensä vaatii product backlogiin palautuneiden osioiden

valmistamista toimittajan kustannuksella

IPR:t ja takuu – kenellä oikeudet ja kenen laskuun korjataan virheet?

IPR ei siirry ellei siitä sovita (varo omistusoikeusluovutusta)

SUOSITUKSET VESIPUTOUS-PROJEKTEIHIN

Mitä huomioida ennen projektin aloitusta?

SUOSITUKSET/HUOMIOITAVAT ASIAT

Huolellinen määrittely/suunnitteluvaihe määrittelydokumentti, joka

”lukitsee” toimituksen kohteen

Projektisuunnitelma edellyttää tarkkuutta: milestones,

projektityöskentelyn säännöt, aikataulut, hyväksyntämenettely

Muutoksenhallinnan tarkka määrittely, dokumentoinnin laajuuden ja

tarkkuuden määrittely

Asiakas testaa vasta ”lopullisen” tuotteen toimittaja ei ota vastuuta

tuotteen soveltuvuudesta asiakkaan liiketoiminnan tarpeisiin

Kenelle kuuluu IPR:t ja mitä käyttöoikeuksia luovutetaan? (varo

omistusoikeusluovutusta)

Sopimuksen päättäminen kesken projektin määritellä perusteet

sopimuksen päättämiselle (olennainen sopimusrikkomus, tarvittaessa

määritellä mitä olennaisuus tarkoittaa)

Vastuunrajaukset riippuu neuvotteluasemasta, asiakas usein vaatii IT-

2010 ehtoja korkeampaa vastuuta

Product owner asiakkaalla oikeus valita toimittajan

tulee vaatia että asiakkaan edustajalla riittävä

(business)osaaminen, AIKAA ja päätäntävalta

Asiakkaan intressissä hyväksyä kehitystiimi toimittajalla

oikeus päättää sopimus jos ei päästä yhteisymmärrykseen

Sprint backlogin sisällön sopiminen (kuinka monta asiaa

sisällytetään) ja lukitseminen priorisoinnin jälkeen

”Definition of Done” – miten määritellä hyväksytty

tuote/iteraatio ennalta sovittujen testien läpäisy,

lähdekoodi katselmoitu, dokumentaatio tehty sovitusti jne.

Hinnoittelun määrittäminen kiinteä hinta vs time&material

–hinnoittelu milloin työ on veloituskelpoinen

Voidaan tehdä myös kiinteällä hinnalla pääpaino olennaisten

ominaisuuksien toteuttamisessa

A g i l e - s o p i m u s – m i s t ä p i t ä i s i s o p i a ?

Suunnittelu/määrittelyvaiheessa syntyvä määrittelydokumentti

scope, hinta ja aikataulun tarkka(?) määrittely

sopimukseen exit-ehto

Toteutusvaiheessa muutoksenhallintamenettely aktivoituu

miten muutos tehdään, sovittava mikä vaikutus hintaan ja

aikatauluun (mahdollinen viivästyssakko huomioitava)

Jos sovittu toimituksen milestoneista (välitoimitukset), sovittava

myös niiden testauksesta ja hyväksymismenettelystä sidottu

yleensä maksuposteihin

Hyväksymistestauksen kriteeristö määriteltävä laukaisee

maksupostin, vastuun tulisi siirtyä asiakkaalle, takuu alkaa

Sovittava ylläpitoehdoista samassa yhteydessä

Millä perusteella toimitussopimus voidaan päättää

olennainen sopimusrikkomus, viivästys sekä kvalifioidut virheet

toimituksessa

V e s i p u t o u s m a l l i n s o p i m u s – m i s t ä p i t ä i s i s o p i a ?

Jos asiakkaan käyttöön toimitetaan (räätälöity) SaaS-palvelu,

huomioi että:

Muutokset sovelluspalveluun pidettävä minimissään (ellei

asiakkaalle tule omaa instanssia)

Käyttöönottoprojektissa määriteltävä vastuu mahdollista

integraatioista ja aineiston siirrosta (toimittaja vastaa yleensä

integraatiosta, asiakas aineiston oikeellisuudesta)

Toimituksen hyväksyminen rakennettava yksinkertaiseksi

kevyimmillään kun palvelu on asiakkaan käytettävissä tai kun

käyttöönottoprojekti päättynyt (esim. 5pv aikaa hyväksyä

projekti)

IPR:t säilyvät toimittajalla vaikka tehtäisiin räätälöintejä

ohjelmistopalveluun

Ei asiakaskohtaisia palvelutasosopimuksia multitenant-

palveluun (= kaikille sama palvelutaso)

Sovi etukäteen maantieteellinen tietojen tallennuspaikka

miten aineisto palautetaan asiakkaalle sopimuksen päättyessä

S a a S - o h j e l m i s t o n t o i m i t u s p r o j e k t i ?

Esimerkkejä hinnoittelumalleista

Time & Material

- Toimittajan kannalta riskittömin vaihtoehto tunti tunnista

veloitus, vastuu työn tuloksesta asiakkaalla

Kiinteä hinta

- Soveltuu projekteihin, joissa kohde on hyvin tiedossa ja

määrittelyt ovat yksityiskohtaiset (vanhan järjestelmän korvaaminen ym.)

Tavoitehinta

- Tavoitehintainen projekti (”Ohjelmisto A:n toimitussopimuksen mukaisen toimituksen tavoitehinta on X euroa. Tavoitehinta voi

ylittyä 15% prosenttia perustellusta syystä. Jos tavoitehinta ylittyy enemmän kuin 15%, on asiakkaalla oikeus purkaa toimitussopimus.”

Hintamuutokset

Tuntihinnat yleensä kiinteät projektin aikana. Sovittava

tuntihintaperusteet (blended rate tai asiantuntijaperusteinen). Oikeus muuttaa kolmannen osapuolen tuotteiden/palveluiden hintoja

O l e n n a i s i a k a u p a l l i s i a e h t o j a

Sopimuksen merkitys

Sopimus ei välttämättä pelasta toimitusta, mutta voi pelastaa

oikeudenkäynnin lopputuloksen

Hyvin laadittu sopimus oikeuksineen, velvollisuuksineen ja

vastuunjakoineen selkeyttää osapuolten roolia toimituksessa

Todistelun kannalta oikeudenkäynnit vaikeita ellei ole mitään

dokumentaatiota projektin kulusta

Hankkeen suunnittelu ollut puutteellinen

Asiakkaalla ei todellista kuvaa hankinnan kohteesta, tarvittavan

työn ja resurssien määrästä

Toimittaja ei havaitse että Asiakas ei havaitse puutteita

tahtotilassaan

Muutosvaatimusten korkea määrä aikataulu ja hinta ylittyy

K o k e m u k s i a I C T - a l a n o i k e u d e n k ä y n n e i s t ä

Muutoksenhallintamenettely

Erimielisyyksiä aiheuttaa epäselvä

muutoksenhallintamenettely kuka saa tehdä muutoksen,

ei sovittu vaikutusta aikatauluun ja hintaan

Testaus ja hyväksymismenettelyt asiakas väittää

toimituksen olevan kesken ja toimittajan mielestä toimitus on

hyväksytty

Selvät määrittelyt hyväksytylle toimitukselle (vain olennainen

virhe estää hyväksymisen olennaisen virheen määrittely)

Virheenkorjauksen kustannustenjako hyväksymistestauksena

aikana sovittava etukäteen

Sopimuksen purkamistilanteet olennaisen viivästyksen tai virheen

johdosta sovittava etukäteen sopimuksen purun seuraukset

suoritusten palautusvelvollisuus, vahingonkorvaus, IPR:t jne

K o k e m u k s i a I C T - a l a n o i k e u d e n k ä y n n e i s t ä

ASIANAJOTOIMISTO HAMMARSTRÖM PUHAKKA PARTNERS OY

BULEVARDI 1 A

00100 HELSINKI

+358 9 47421

www.hpplaw.fi

ERIKOISTUNUT OLENNAISEEN

Terho Nevasalo

Osakas, LL.M

Mobile +358 40 5587581

terho.nevasalo@hpplaw.fi