Sitoumusten hallinta ohjelmistoprojektisopimuksissa

Koko: px
Aloita esitys sivulta:

Download "Sitoumusten hallinta ohjelmistoprojektisopimuksissa"

Transkriptio

1 Luonnos artikkeliksi oikeustieteelliseen julkaisuun Olli Pitkänen, Sari Kela, Jyrki Kontio, Reijo Sulonen Sitoumusten hallinta ohjelmistoprojektisopimuksissa 1 JOHDANTO Kirjoitetun lain ja oikeustapausten kautta muotoutunut sopimusoikeus ei riittävästi pysty vastaamaan niihin käytännön kysymyksiin, joiden kanssa keskenään sopimuksia tekevät yritykset joutuvat nykyisin painiskelemaan. Sopimusoikeuden oppikirjojen mukaisesti laaditut sopimukset ovat kyllä päteviä ja niiden avulla tuomioistuin pystyy yleensä löytämään laillisen ratkaisun osapuolten välisiin riitoihin. Nykyiset sopimukset eivät sen sijaan tarpeeksi tue menestyvää yritystoimintaa, projektien etenemistä sekä taloudellisesti ja liiketoiminnallisesti järkevien toimintatapojen muotoilemista. Erityisesti ongelma korostuu nopeasti kehittyvillä aloilla, kuten ohjelmistoteollisuudessa. Ulkomailla sopimusoikeuden uudistamisen tarvetta on jonkin verran käsitelty (esim. [38]). Suomessa sen sijaan keskustelu perinteisten ajatusmallien muutostarpeesta on ollut tähän asti vähäistä. Viitteitä uudesta ajattelusta sopimusoikeudessa on ollut havaittavissa esimerkiksi Wilhelmssonin ja Pöyhösen teoksissa, mutta vasta Nystén-Haaralan väitöskirjassa [34] ja artikkelissa Sopimusoikeus ja sopimusten hallinta [35] on selkeästi tuotu esiin uudistuksen tarve. Teknillisessä korkeakoulussa ohjelmistotuotannon tutkimusryhmässä (SEG) on jo usean vuoden ajan tutkittu, minkälaisilla sopimuksilla tai muilla sitoumuksilla voitaisiin nykyistä paremmin auttaa ohjelmistoprojekteja onnistumaan. Tutkimuksessamme pyrimme ottamaan huomioon sekä oikeudelliset, taloudelliset että tekniset näkökulmat. Tämän vuoksi emme voi soveltaa yksinomaan perinteisiä oikeustieteellisiä tutkimusmenetelmiä, vaan käytämme runsaasti myös case-tutkimuksen ja muun empiirisen tutkimuksen menetelmiä. Tutkimuksen tuloksena on rakennettu artikkelissa esitettävä sitoumusten hallinnan malli. Sen tarkoituksena on erityisesti tarjota parempaa tukea ohjelmistotuotannon sopimusten määrittelyyn. Mallin avulla voidaan valita toimintasuunnitelma sitoumusten määrittelemiseksi ja niihin liittyvien riskien tunnistamiseksi. Mallin kehittäminen jatkuu edelleen, mutta jo tutkimuksen tässä vaiheessa on selvästi todettavissa, että sopimusten ja sitoumusten hallinnan muiden osa-alueiden kehittäminen auttaa ohjelmistoprojekteja menestymään nykyistä paremmin. Viime aikoina tutkimuksemme painopiste on siirtynyt muihin kuin tässä artikkelissa esitettäviin sitoumuksen hallinnan osa-alueisiin, muun muassa

2 sitoumusten dokumentointiin, näkyvyyteen ja hierarkiaan sekä verkostoitumiseen liittyviin kysymyksiin. Lisäksi osallistumme tutkimustyöhön, jota Teknillisen korkeakoulun ja Helsingin yliopiston yhteinen tutkimuslaitos, Helsinki Institute for Information Technology (HIIT) tekee Internetiin liittyvien aineettomien oikeuksien hallinnasta [37] professori Jukka Kemppisen johdolla. 2 SITOUMUSTEN HALLINTA Ohjelmistoprojektiin voi osallistua ihmisiä monista organisaatioista ja oikeushenkilöistä. Ohjelmistoalalla tyypillisissä alihankintaverkostoissa osallistuvien yritysten määrä voi olla suurikin. Yhteistyö ohjelmiston kehittämiseksi vaatii aina sitoumuksia kaikilta projektin osapuolilta: esimerkiksi ohjelmiston käyttäjien on sitouduttava esittämään vaatimuksia ja antamaan palautetta sekä rahoittamaan projekti, kehittäjien puolestaan on tarjottava työpanoksensa, taitonsa ja muut tarpeelliset resurssit projektin toteuttamiseksi sovitussa aikataulussa. Ohjelmistoprojektit ovat tyypillisesti monelta osin vaikeammin ennakoitavia kuin ns. perinteisten teollisuudenalojen projektit. Sitoutuminen on siten yleensä tehtävä jo siinä vaiheessa, kun projektiin vielä liittyy huomattavia epävarmuustekijöitä. Hyviä malleja ja ohjeita, jotka auttaisivat ohjelmistoammattilaista sopimusten ja muiden sitoumusten tekemisessä ei juurikaan ole. Nykyiset sopimuskäytännöt ja mallit eivät riittävästi huomioi muun muassa ohjelmistotuotantoon liittyvää epävarmuutta. Sitoumuksilla tarkoitetaan tässä kaikkia niitä sitoumuksia, joita projektin osapuolet tekevät riippumatta siitä tuleeko niitä oikeudellisesti arvioida esimerkiksi sopimuksina. Kirjallinen projektisopimus ja siihen liittyvä projektisuunnitelma ovat luonnollisesti selkein ja suositeltavin tapa käytännössä tuoda julki osapuolten väliset sitoumukset. Sitoumusten hallinta tarkoittaa prosessia, jolla määritellään projektin osapuolten sitoumukset sekä ylläpidetään ja päivitetään näitä sitoumuksia projektin kuluessa. Kyseessä on projektijohtamisen osaalue, jossa tietyillä toimenpiteillä, prosesseilla ja taidoilla varmistetaan, että osapuolten sitoumukset ovat tiedossa, että ne on tehty tietoisesti ja että niitä ylläpidetään koko projektin ajan. Sitoumusten määrittely on osa sitoumusten hallintaa. Se viittaa joko dokumentoituun joukkoon sitoumuksia tai prosessiin, jolla sitoumukset määritellään. Tämän artikkelin näkökulmasta katsottuna sitoumusten määrittely tarkoittaa projektin alussa suoritettavaa joukkoa toimenpiteitä, joiden tarkoituksena on määritellä projektissa tarvittavien sitoumusten laajuus ja taso. 3 SITOUMUSTEN HALLINTAAN LIITTYVÄ AIKAISEMPI TUTKIMUS JA AINEISTOT Tämä artikkeli perustuu 20:nnessa International Conference on Software Engineering konferenssissa (ICSE 98) Kiotossa, Japanissa julkaistuun artikkeliin [30] sekä sen jälkeen Teknillisessä korkeakoulussa jatkettuun tutkimustyöhön. Aikaisemmin sitoumusten hallintaa ei ole juurikaan käsitelty tästä näkökulmasta. Sekä henkilöstön (esimerkiksi [10, 19]) että johdon (esimerkiksi [9, 12, 26, 31]) sitoutumista on korostettu monissa projekteja ja muita hankkeita käsittelevissä teoksissa. Sen sijaan sitoumusten määrittelyä osapuolten tasolla projektin alkaessa ei juurikaan ole käsitelty. 2

3 Ohjelmistoprojekteja koskevat sopimukset ja projektisuunnitelmat tarjoavat perusmallit ja ohjeet projektin sitoumusten määrittämiselle. Joitain standardeja ja esimerkkejä on olemassa siitä, mitä tällaisten sopimusten ja suunnitelmien tulisi sisältää. Nämä eivät kuitenkaan kata kaikkia sitoumusten hallinnan osa-alueita. Projektisuunnitelmamallit korostavat lähinnä aikatauluun ja kustannuksiin liittyviä tavoitteita, määrittelevät jossain määrin käytettävän prosessin ja edellyttävät joidenkin riskienhallintaan liittyvien perustoimintojen määrittelyä. Ne eivät sen sijaan tuo esiin projektin taustalla olevia motiiveja eivätkä projektien ongelmien hallintaan liittyviä kysymyksiä [20]. Ne eivät myöskään mitenkään esitä sitoumusten hallinnan prosessia. Edellä mainitut lähestymistavat ja aineistot eivät auta konkreettisesti päättämään, miten projektista tulisi sopia, mihin asioihin pitäisi sitoutua ja miten kaikkien projektin osapuolten tekemiä sitoumuksia voisi hallita. Vaikka parhaatkaan nykyiset käytännöt eivät juurikaan anna tukea, on kaikissa ohjelmistoprojekteissa kuitenkin pakko tehdä ja hallita sitoumuksia. 4 OHJELMISTOPROSESSI Tietokoneohjelmiston tekeminen on monivaiheinen prosessi. Jotta ohjelmistoprojektia koskevia sitoumuksia ja sopimuksia voisi tehdä, hallita ja tulkita oikein, on ymmärrettävä ohjelmiston valmistusprosessia. Alla esitetään sitoumusten hallintaan liittyvien piirteiden ymmärtämisen pohjaksi yksi mahdollinen ohjelmistotuotannon malli. Ohjelmistotuotanto on varsin nuori teollisuuden ala. Sen sanotaankin elävän vielä esiteollista aikaa: ohjelmistoteollisuudessa ei ole toistaiseksi pystytty kehittämään samanlaisia teollisia valmistusmenetelmiä ja prosesseja kuin perinteisemmillä teollisuuden aloilla. Käytännössä tämä näkyy siten, että tuotanto tapahtuu hyvin pitkälle käsityönä: ohjelmistojen suunnitteluun, ohjelmointiin ja testaukseen ei ole vielä saatavissa kovin paljoa automaattisia apuvälineitä. Seurauksena valmistusprosessin kesto ja kustannukset vaihtelevat suuresti aikatauluissa ja budjeteissa pysyminen on suorastaan harvinaista. Myös laatuongelmat saattavat olla merkittäviä. Tähän vaikuttaa myös merkittävästi se, että ohjelmistotuotannossa suunnittelun ja kehitystyön osuus on erittäin suuri kun taas lopputuotteen valmistaminen vaatii vain erittäin vähän resursseja. Niinpä ohjelmistotuotantoa olisikin monessa suhteessa paras verrata muiden alojen tuotekehitystoimintaan, jossa epävarmuudet myös ovat suuria. Ohjelmiston tuotantoprosessia voi mallittaa monella eri tavalla. Tähän on valittu jonkinlainen mukaelma klassisesta vesiputousmallista. On kuitenkin korostettava, että kyseessä on vain yksi tapa tulkita tuotantoprosessia. Esimerkiksi niin kutsuttu spiraalimalli antaa vesiputousmallia todellisemman kuvan siitä, miten tuotannossa usein toistetaan samoja vaiheita ja palataan edellisiin vaiheisiin tarkentamaan ja korjaamaan niiden tuloksia. [5, 6] Tällaiseen prosessiin pyrkivät muun muassa monet ohjelmistotuotteita valmistavat yritykset. Yksittäisen sovelluksen valmistaminen projektiluonteisesti sen sijaan on usein järkevää mallittaa vesiputouksena. Lisäksi on syytä huomata, että kuvattu malli on pitkälle idealisoitu. Käytännössä yrityksissä esiintyvät prosessit vain harvoin ovat yhtä selviä ja jakautuvat yhtä siististi eri vaiheisiin kuin kuvattavassa mallissa. Varsin usein ohjelmiston tuotantoprosessi muistuttaa enemmänkin kaaosta: prosessiin osallistuvat henkilöt koheltavat edestakaisin eri vaiheiden välillä tajuamatta jatkuvasti itsekään, mitä 3

4 vaihetta parhaillaan suorittavat. Tilanne lienee tässä suhteessa muuttumassa ja ohjelmistoprosessit ovat selkiytymässä ja kypsymässä. Mallin osalta on myös huomattava, että samat henkilöt yhdestä organisaatiosta voivat osallistuvat ohjelmiston tekemiseen kaikissa vaiheissa. Usein kuitenkin ohjelmiston tekemiseen osallistuu eri vaiheissa eri ihmisiä eri organisaatioista. ongelman analysointi määrittely suunnittelu ohjelman koodaaminen testaus käyttöönotto ja koulutus ylläpito Kuva 1 Ohjelmistoprosessi vesiputousmallin mukaisesti Prosessi alkaa asiakkaan ongelman analysoinnilla. Asiakas on yleensä tiedostanut jonkin osan ongelmastaan ja pyytää vaikkapa konsulttia selvittämään, miten ongelma voitaisiin ratkaista. Konsultti ammattitaitonsa ja kokemuksensa avulla pyrkii selvittämään ongelman ja sen syyt kokonaisuudessaan. Toisessa vaiheessa määritellään uuden järjestelmän tarve: minkälaisia palveluja tietokoneohjelmiston olisi tarjottava, jotta se voisi auttaa ongelmassa. Tässä vaiheessa ei vielä suunnitella ohjelmistoa lainkaan, vaan ainoastaan sitä, minkälaisia palveluja ohjelmiston tulisi tarjota käyttäjälleen. Tarpeiden määrittelyssä voidaan käyttää apuna erilaisia kuvausmenetelmiä ja kaavioita. Kolmannessa vaiheessa suunnitellaan ne toiminnot, jotka tietokoneohjelmistossa täytyy olla, jotta se täyttäisi edellisessä vaiheessa tehdyt määrittelyt. Tässä vaiheessa suunnitellaan yksityiskohtaisesti tulevan ohjelmiston ulkoinen ja sisäinen rakenne: tarvittavat algoritmit kehitetään tai valitaan olemassa olevista, tietorakenteet määritellään yksityiskohtaisesti, ohjelma jaetaan pieniin moduuleihin, jotka sitten kuvataan täsmällisesti. Vaiheen tuloksena on käytettävissä täsmälliset yksityiskohtaiset kaaviot ja kuvaukset, joiden perusteella atk-alan ammattilainen voi yksiselitteisesti ymmärtää, minkälainen ohjelmistosta on tulossa. Varsinaista ohjelmointia koodausta ei siis ole vielä tehty lainkaan. On huomattava, että edellisessä vaiheessa näkökulma oli vielä ongelmassa ja tarpeessa, tässä vaiheessa siirretään katse laadittavaan ohjelmaan. Niinpä edellisen vaiheen perusteella voitaisiin vielä suunnitella lähes äärettömän monta erilaista ohjelmaa, jotka kaikki täyttäisivät määritellyn tarpeen. Sen sijaan tässä vaiheessa tehdään ne valinnat, jotka johtavat yhteen tiettyyn ohjelmaan. Neljännessä vaiheessa ohjelma kirjoitetaan jollain ohjelmointikielellä. Ohjelmointi vaatii paljon taitoa ja huolellisuutta, mutta jos edelliset vaiheet on tehty oikein ja huolellisesti, tämä vaihe voi olla varsin 4

5 mekaaninen. Kyse on pääasiassa tehtyjen suunnitelmien koodaamisesta. Formalismi on eri kuin edellisessä vaiheessa, mutta uutta tietoa järjestelmästä tässä vaiheessa syntyy enää vähän tieto lähinnä muuttaa muotoaan. Viidennessä vaiheessa tehty ohjelma testataan virheiden löytämiseksi. Tämä vaihe edellyttää suurta huolellisuutta ja kurinalaisuutta, mutta on tehtävissä valmiiden periaatteiden mukaan. Testausmenetelmiä ei siis tarvitse keksiä joka kerta uudestaan. Riittää, että huolellisesti suunnitellaan, miten valittuja menetelmiä tällä kerralla sovelletaan. Itse asiassa testauskin kannattaisi yleensä suunnitella samalla, kun ohjelmisto suunnitellaan. Tällöin testausvaiheeseen ei jää edes suunnittelutyötä, vaan ainoastaan mekaanista testauksen suorittamista. Testattu ohjelmisto asennetaan asiakkaalle, asiakkaan henkilöstö koulutetaan käyttämään ohjelmistoa ja ohjelmisto voidaan ottaa käyttöön. Jatkossa ohjelmistoon tehdään muutoksia ja korjauksia sopimuksen mukaan. Tätä kutsutaan ohjelmiston ylläpidoksi. Siihen saattaa liittyä myös uusien ominaisuuksien lisäämistä ohjelmistoon, mikä puolestaan saattaa vaatia jopa erillisen projektin käynnistämistä. Näin ylläpitoon saattaa sisältyä kaikkia edellä kuvattuja vaiheita uudelleen ja uudelleen. Muutosten ja lisäysten tuloksena ohjelmistosta syntyy uusia versioita (engl. version, revision jne.). Siirtymistä uudempaan versioon kutsutaan päivitykseksi (engl. update, upgrade). Eri yrityksillä on varsin erilaisia tapoja nimetä tai numeroida tuoteversioitaan. Usein yritykset käyttävät sisäisessä kehitystyössään erilaista versiointia kuin asiakkaille suuntautuvassa markkinoinnissaan. Paitsi ajallisesti peräkkäisiä versioita, ohjelmistotuotteista tuodaan toisinaan markkinoille myös rinnakkaisia versioita. Esimerkiksi ilmaiseksi tai erittäin edullisesti asiakkaille tarjottavat kevytversiot on tarkoitettu tutustuttamaan asiakas tuotteeseen ja saamaan tämä myöhemmin siirtymään laajemman version käyttöön. Erilaisia alfa-, beta- ja muita esiversioita käytetään paitsi testaukseen myös asiakkaiden sitouttamiseen jo ennen varsinaisen tuotteen markkinoille tuomista (lock-in -ilmiöstä katso esim. [42]). Usein myös erotetaan toisistaan suuremmat ja pienemmät päivitykset (engl. major update, minor update). Suuren päivityksen tarkoituksena on yleensä tuoda ohjelmistoon oleellisia lisäominaisuuksia, kun taas pieni päivitys saattaa lähinnä korjata ohjelmistossa olleita virheitä. Esimerkiksi sopimustekstissä saattaa olla tarve erottaa nämä päivitykset toisistaan, mutta yksikäsitteisen määrittelyn kirjoittaminen ei ole helppoa. Ohjelmiston elinkaari päättyy, kun ohjelmisto poistetaan käytöstä. 5 SITOUMUSTEN MÄÄRITTELY Sitoumusten hallinnan mallissa osapuolten väliset sitoumukset on jaettu neljään eri sitoumusaiheeseen. Jaottelu pohjautuu case-tutkimuksiin sekä alan sopimusten analysoitiin. Sitoumusten tarkastelu mallin avulla auttaa osapuolia hahmottamaan projektin kannalta keskeiset sitoumusaiheet sekä ohjaa osapuolia kommunikoimaan oleellisista sitoumusaiheista. Samalla sitoumusaiheet muodostavat mallin, jota voidaan käyttää tarkistuslistana projektin sitoumuksia määriteltäessä. Taulukossa kuvataan yhteenveto sitoumusaiheista sekä kuhinkin sitoumusaiheeseen liittyviä sitoumuskohteita. 5

6 Sitoumusaihe Taustamotiivit Miksi projekti tehdään? Tavoitteet Mitä projektin tuloksena syntyy, milloin ja millä hinnalla? Prosessi Miten projekti tehdään? Riskien ja ongelmien hallinta Mitä jos jotain menee pieleen? Kuva 2 Sitoumusaiheet Sitoumuksen kohteita Liiketoiminnalliset tavoitteet Strategiset suunnitelmat ja aikomukset Yrityksen visio ja missio ja niiden liitynnät projektiin Projektin lopputulos Aikataulu Kustannukset Muut tavoitteet (uudelleenkäyttö, osaamisen kehittäminen jne.) Hallinnolliset menettelytavat Ohjelmistoprosessin vaatimukset Muutoksenhallinta Hyväksymismenettely Prosessimallit ja standardit Riskienhallintaprosessi Osapuolten välinen kommunikointi ja tiedonhallinta Oletukset Osapuolten yhteiset oletukset Riskien hallinta Riskienhallinnan ala Hyväksyttävät riskit Riskien vastuunjako Ongelmien hallinta Sopimusrikkomukset Vahingonkorvausvelvollisuus ja vastuunrajaukset Oikeuspaikka, sovellettava laki Seuraavassa tarkastellaan yleisesti eri sitoumusaiheita sekä yksityiskohtaisesti niitä sitoumusaiheisiin liittyviä sitoumuksen kohteita, joihin on havaittu liittyvän ohjelmistoprojektien yhteydessä erityisiä ongelmia. Tällaisia ovat ennen kaikkea aineettomia oikeuksia, riskienhallintaa ja vahingonkorvausta koskevat seikat. Ennen sitoumusaiheiden tarkastelua kuvataan lyhyesti ohjelmistoprojektin kannalta olennaisten sitoumusaiheiden valintaa. 6 SITOUMUSAIHEIDEN PAINOPISTEEN VALINTA Useimmissa projekteissa ei ole mahdollista etukäteen määritellä tyhjentävästi kaikkia sitoumuksia. Yleensä käytettävissä olevat tiedot ja resurssit riittävät vain osittaisen sitoumusmäärittelyn tekemiseen. Esimerkiksi jo projektin alkaessa voi olla selvää, että projektin tulokset, aikataulu tai menettelytavat muuttuvat useaan otteeseen projektin edetessä. Myöskään taloudellisesti ei ole mielekästä uhrata liikaa aikaa sellaisten asioiden määrittelyyn, jotka eivät ole projektin kannalta tärkeitä. Sitoumusmäärittelyssä 6

7 onkin keskityttävä niihin sitoumusaiheisiin, jotka ylipäätänsä ovat määriteltävissä ja jotka ovat projektin kannalta tärkeimpiä. Yksittäisellä projektilla voi olla paljon erilaisia ominaisuuksia, jotka vaikuttavat siihen, mitkä sitoumusaiheet tulisi määritellä. Määrääviä ominaisuuksia ovat muun muassa projektin koko, osapuolten lukumäärä, käytettävä prosessimalli, ohjelmiston osien uudelleenkäytön määrä, uusien teknologioiden käyttö sekä projektin luonne siinä mielessä, onko kyse organisaation sisäisestä projektista vai esimerkiksi asiakasprojektista. Projektin alussa kaikkein keskeisin ominaisuus on kuitenkin projektin yleinen riskitaso. Niinpä sillä tulisi olla eniten merkitystä valittaessa määriteltäviä sitoumusaiheita. Projektin yleisellä riskitasolla tarkoitetaan tässä osapuolten subjektiivista käsitystä siitä, miten vakavia riskejä kyseiseen projektiin liittyy verrattuna muihin projekteihin. Hyvin riskialttiissa projektissa, jossa riskit saattavat tehdä tavoitteet saavuttamattomiksi, saattaa olla turhaa sitoutua tiukasti tavoitteisiin. Parempi olisikin sellaisessa tilanteessa yleisesti kuvata taustamotiiveja, miksi projektiin ollaan ryhtymässä, ja keskittyä sitten siihen, miten projekti viedään läpi. Voidaan esimerkiksi sitoutua säännöllisiin tapaamisiin, muutostenhallintakäytäntöihin, raportointiin, tiedon vaihtoon ja niin edelleen. Keskitytään tavoitteisiin (tuotteeseen, täsmällisiin määrittelyihin jne.) ongelmien hallintaan Keskitytään motiiveihin prosessiin (muutosten hallintaan yms.) riskienhallintaan matala Riskitaso korkea Kuva 3 Riskitason vaikutus sitoumusaiheiden valintaan 7 TAUSTAMOTIIVIT Taustamotiiveilla tarkoitetaan muun muassa liiketoiminnallisia tavoitteita, joiden vuoksi osapuolet ylipäätään osallistuvat projektiin. Esimerkkinä voisi olla vaikkapa pystyä tarjoamaan parempaa asiakaspalvelua ja sen avulla saavuttaa parempi kilpailukyky, lisätä tuottavuutta tai vähentää 7

8 kustannuksia. Taustamotiivit kuvaavat siten lähinnä sopimuksen henkeä, kun taas tavoitteet määrittävät sopimuksen kirjaimen. Taustamotiivien kirjaamisella sopimukseen on kaksi tarkoitusta. Ensinnäkin ne auttavat osapuolia ymmärtämään toistensa todelliset motiivit ja edut, joita tavoitellaan. Näin projektin tavoitteet tulevat ymmärrettävämmiksi ja projektia voidaan suorittaa osapuolten edun kannalta tarkoituksenmukaisimmalla tavalla. Toinen taustamotiivien dokumentoinnin tarkoitus on tarjota ohjeita sen tulkitsemiseen, mihin osapuolet ovat projektin alussa sitoutuneet. Perinteisimmillään taustamotiivien dokumentointi auttaa sopimuksen tulkintatilanteissa. Erityisesti silloin, kun ulkopuolinen, vaikkapa tuomioistuin, joutuu tulkitsemaan sopimuksen sisältöä, voidaan hyödyntää kirjattuja taustamotiiveja sen selvittämiseksi, mikä on ollut osapuolten todellinen tahto sopimusta laadittaessa, sekä reaalisten argumenttien etsimiseksi. [16, 34, 35, 40] Monissa tilanteissa osapuolten saattaa olla vaikeaa kuvata muille osapuolille kaikkia taustamotiivejaan. Jotkut niistä saattavat olla luottamuksellisia, toiset muuten vain hankalia määritellä. Tutkimuksissamme onkin käynyt ilmi, ettei taustamotiiveja usein tuoda selvästi esille toiselle osapuolelle, saati kirjata sopimuksiin. Taustamotiivien mahdollisimman laaja ja avoin dokumentointi, joko sopimuksissa tai vähintäänkin muissa projektiin liittyvissä dokumenteissa on kuitenkin suositeltavaa. Näin erityisesti ohjelmistoprojektien yhteydessä. Edellä todetulla tavalla ohjelmistoprojektit ovat usein vaikeasti ennakoitavia projekteja. Tästä johtuen projektin tavoitteiden ja prosessinkin yksityiskohtainen kirjaaminen sopimuksiin voi olla vaikeampaa kuin on perinteisten teollisuudenalojen yhteydessä. Ohjelmistoprojektien yhteydessä on myös täysin mahdollista, etteivät osapuolet projektia aloittaessa ole vielä selvillä siitä mitä konkreettisia lopputuloksia projektissa pitäisi syntyä. Toisin sanoen lopputulokset hahmotuvat vasta projektin edetessä. Vastaavasti on tavallista, että projektin edetessä osapuolet muuttavat lopputuloksia koskevia tavoitteitaan. Kirjatut taustamotiivit toimivat edellä kuvatun kaltaisissa muutos- ja epävarmuustilanteissa perustana, jota vasten sopimusmuutoksista on helpompi päästä yhteisymmärrykseen. Erikseen on huomattava, että sopimustekstin muotoilulla on tehtävä selväksi, ettei taustamotiivien saavuttamatta jääminen sinällään aiheuta vahingonkorvausvelvollisuutta. Jos esimerkiksi tilaajan tuottavuuden lisääntyminen on määritelty taustamotiiviksi, toimittaja ei ole korvausvelvollinen, vaikkei tuottavuus lisääntyisikään, kunhan tavoitteet ja muut sopimusvelvollisuudet on tullut täytettyä. Sopimusta laadittaessa onkin kiinnitettävä huomiota siihen, mitkä asiat määritellään tavoitteiksi ja mitkä taustamotiiveiksi. 8 TAVOITTEET Jokaisessa projektissa tulisi ensi alkuun päästä yhteisymmärrykseen projektin tavoitteista. Niihin kuuluvat projektin lopputulokset (esimerkiksi vaatimusmäärittelyn mukainen ohjelmisto ja siihen liittyvät aineettomat oikeudet), laatutavoitteet, aikataulu, kustannukset ja muut vastaavat projektin ominaisuudet. Tavoitteiden luokittelemiseen voidaan tarvittaessa käyttää vaikkapa Riskit-menetelmän mukaista jakoa päämääriin (objective), pyrkimyksiin (driver) ja rajoitteisiin (constraint). [28] Päämäärällä tarkoitetaan saavutettavissa olevaa, hyvin määriteltyä tavoitetta, kuten ohjelmiston on pystyttävä suorittamaan toiminto X. Pyrkimys on sellainen tavoite, joka kertoo mihin päin pyritään ilman, että voitaisiin yksikäsitteisesti todeta, milloin tavoite on saavutettu. Pyrkimys voi olla esimerkiksi 8

9 parannetaan hakutoiminnon käytettävyyttä. Pyrkimykset ovat ongelmallisia, jos joudutaan arvioimaan sitä, ovatko osapuolet täyttäneet sitoumuksensa. Niinpä pyrkimyksiä tulisi välttää ja mieluummin muotoilla ne päämääriksi. Rajoite puolestaan ilmaisee, missä rajoissa projektissa saadaan liikkua. Tyypillisiä rajoitteita ovat muun muassa aikatauluun ja budjettiin liittyvät tavoitteet. Tosin päämäärän ja rajoitteen välinen ero saattaa olla vain näkökulmassa ja sanamuodossa: toinen osapuoli näkee saman tavoitteen päämääränä, toinen rajoitteena. Tavoitteet tulisi yleensä pyrkiä ilmoittamaan selkeästi toiselle osapuolelle. On kuitenkin huomattava, että toisen osapuoleen tavoitteet voivat sitoa myös toista osapuolta, vaikkei niistä olisi erikseen sovittu. Esimerkiksi jos toimittaja on ymmärtänyt, mihin tarkoitukseen tilaaja aikoo ohjelmistoa käyttää, toimittajan voidaan katsoa olevan sitoutunut toimittamaan tarkoituksenmukaisen ohjelmiston laajemminkin kuin mistä on erityisesti sovittu. [40] Usein asiakas tilaa toimittajalta erikseen osaprojekteja ohjelmistoprosessin eri vaiheisiin. Tällöin yksittäisen osaprojektin osalta saatetaan sopia varsin suppeista tavoitteista. Jos viimeisen osaprojektin tuloksena syntyvä ohjelmisto ei vastaakaan tilaajan tarkoitusta, vaikka se onkin osaprojektia koskevan sopimuksen kirjaimen mukainen, voidaan toimittajan vastuuta laajentaa sillä perusteella, että toimittaja on myös edellisten osaprojektien yhteydessä saanut tietoonsa tilaajan tavoitteita. Molempien osapuolten edun mukaista onkin ilmoittaa toiselle osapuolelle tavoitteistaan mahdollisimman selkeästi ja yksityiskohtaisesti ja toisaalta kertoa heti, jos jotkut toisen osapuolen tavoitteet eivät vaikuta saavutettavilta. 9 AINEETTOMAT OIKEUDET PROJEKTIN TAVOITTEINA Tietokoneohjelmisto on aineeton olio, jota suojaavat aineettomat oikeudet. Meillä ohjelmistojen keskeisin oikeudellinen suojamuoto on luovaa työtä yleisesti suojaava tekijänoikeus. Yhdysvalloissa ja monissa muissa maissa patentti on viime aikoina lisännyt merkitystään ohjelmistojen suojana. Euroopan unionin piirissä on parhaillaan käynnissä vilkas keskustelu siitä, tulisiko ohjelmistojen patentointi sallia täälläkin nykyistä laajemmin. On korostettava sitä, ettei tämä kehitys ole yksinomaan myönteistä, mutta juuri nyt patentin vahvistuva asema näyttää varsin vääjäämättömältä. [1, 13, 32, 33, 37, 41] Teknisestä näkökulmasta ohjelmistoprojektin tavoitteena on yleensä tuottaa tietyt vaatimukset täyttävä ohjelmisto määräajassa, sovituilla kustannuksilla. Valmiilla ohjelmistolla ei kuitenkaan oikeudellisesti ole paljoa merkitystä elleivät sitä koskevat oikeudet ole järjestetty osapuolten tarpeiden mukaisesti. Hieman kärjistäen voisi sanoa, että on saman tekevää valmistuuko ohjelmisto vai ei, jos tilaaja ei saa ohjelmistoon tarvitsemiaan oikeuksia. Näin ollen kysymys aineettomien oikeuksien järjestämisestä tulisi nähdä keskeisenä osana projektin tavoitteita. Eri osapuolilla saattaa olla varsin erilaiset tarpeet valmiin ohjelmiston osalta. Joku haluaa ehkä vain käyttää sitä itse, joku myydä käyttöoikeuksia myös muille, joku tehdä ohjelmistoon muutoksia ja joku käyttää sitä osana muiden ohjelmistojen kehitystyössä. Varsin tyypillisesti ohjelmistoprojektin alkuvaiheessa kaikki osapuolet haluavat kaikki oikeudet lopputulokseen itselleen. Tarkempi analyysi omista tarpeista voi kuitenkin paljastaa sen, ettei kaikkia oikeuksia suinkaan tarvita eikä niistä siis myöskään kannata maksaa (katso myös [42, s ]). Oikeaan win-win-tilanteeseen päästään, kun tunnistetaan omat ja muiden osapuolten todelliset tarpeet ja jaetaan ohjelmistoon kohdistuvat aineettomat oikeudet näiden tarpeiden mukaisesti. Usein saattaa unohtua esimerkiksi, että tilaajalle saattaa olla hyvinkin edullista, jos ohjelmistolla on käyttäjiä muissakin organisaatioissa. Tällöin muun 9

10 muassa ohjelmiston ylläpito ja jatkuvuus tyypillisesti paranevat merkittävästi ja tilaaja pääsee hyötymään laajemmasta käyttäjäverkostosta [42]. Toisaalta ohjelmisto itsessään tyypillisesti koostuu useanlaisista osista eli komponenteista, joihin saattaa kohdistua erilaisia aineettomia oikeuksia. Tätä ei yleensä sopimuksissa osata ottaa huomioon, vaan ohjelmistoa sekä siihen kohdistuvia oikeuksia ja vastuita käsitellään yhtenä kokonaisuutena. Edes ohjelmistoalalla yleisesti käytössä olevissa vakioehdoissa ei ole kunnolla osattu tehdä eroa erilaisten ohjelmiston osien välillä. Käytännössä komponentteja on kolmenlaisia. Ensinnäkin kyseisessä projektissa erityisesti tätä ohjelmistoa ja tätä tilaajaa varten luodut komponentit. Toiseksi saman tekijän luomat komponentit, joita ei ole luotu yksinomaan tätä tilaajaa varten, vaan joita on tarkoitus käyttää myös muiden projektien toteutuksessa. Kolmanneksi ohjelmistoissa käytetään kolmannen osapuolen luomia valmiita komponentteja. Ensimmäisen ryhmän komponentit, jotka siis on luotu kyseisessä projektissa erityisesti tätä ohjelmistoa ja tätä tilaajaa varten, ovat yleensä oikeudellisesti helpoimpia käsitellä. Niitä koskevista oikeuksista on tavallisesti mahdollista sopia varsin vapaasti. Voidaan vaikkapa sopia, että kaikki oikeudet näihin komponentteihin siirretään tilaajalle. Käytännössä tietysti esimerkiksi toimittajan pyrkimys ohjelmakoodin uudelleenkäyttöön tai tilaajan halu itse hallita käyttämiään ohjelmistoja lähdekooditasolla saattavat tosiasiassa vähentää neuvotteluvaraa. Tällainenkin komponentti saattaa kyllä loukata vaikkapa kolmannen patenttioikeutta, mutta etenkään tekijänoikeuden loukkauksesta ei yleensä ole pelkoa, jos komponentti on todella luotu kyseisessä projektissa. Edelleen toimittaja voi näiden komponenttien osalta esimerkiksi sitoutua varsin laajaan vastuuseen virheistä sekä takuuseen ja ylläpitovastuuseen, koska toimittaja tuntee nämä komponentit hyvin. Toisen ryhmän komponentteja ovat siis ne, jotka ovat saman tekijän luomia, mutta tarkoitettuja käytettäviksi myös muissa ohjelmistoissa. Niihin ei luonnollisestikaan voida antaa kaikkia oikeuksia tilaajalle. Toisaalta näidenkin komponenttien osalta toimittaja voi sitoutua samankaltaiseen vastuuseen virheistä, takuuseen ja ylläpitoon kuin ensimmäisenkin ryhmän komponenttien osalta. Käytännössä toisen ryhmän komponenttien ylläpito ja esimerkiksi uusien versioiden toimittaminen kaikille tilaajille, jotka käyttävät jotain tietyn komponentin versiota, on varsin hankalaa. Toimittajan ei pitäisi sopimuksessa sitoutua liian kevyesti kovin tiukkoihin ehtoihin tässä suhteessa selvittämättä ensin, millaisia tuotteenhallinnallisia ongelmia siitä voi aiheutua. Kolmannen ryhmän komponentit eivät ole toimittajan itsensä tekemiä. Niinpä niiden käyttöä säätelevät kolmannen kanssa sovitut ehdot. Toimittaja ei tietenkään voi antaa asiakkaalleen parempaa oikeutta näihin komponentteihin kuin mitä on itse saanut kolmannelta osapuolelta. Myös vastuun virheistä, takuun ja ylläpidon osalta on otettava huomioon se, mihin komponenttien tekijä on suostunut sitoutumaan. Tämä ei tarkoita sitä, etteikö ohjelmiston toimittaja voisi komponenttien osalta ottaa laajempaakin vastuuta kuin komponenttien tekijä on suostunut ottamaan, jos se liiketoiminnallisesti nähdään järkeväksi. 10

11 10 PROSESSI Prosessi määrittelee sen, miten tavoitteet aiotaan saavuttaa, miten osapuolet toimivat yhteistyössä ja miten ohjelmisto kehitetään. Tähän sisältyy toisaalta hallinnollisia menettelytapoja, kuten projektikokousten aikataulujen ja työjärjestysten määrittelyt. Toisaalta siihen kuuluu itse ohjelmistokehitysprosessin määrittely. Tässä voidaan viitata esimerkiksi erilaisiin ohjelmistojen elinkaarimalleihin, viitekehyksiin ja standardeihin, kuten ISO [22] tai SEI:n CMMkypsyysmalliin [36]. Voidaan myös sopia esimerkiksi, että käytetään prototyyppilähestymistapaa ja että käyttöliittymän ensimmäinen prototyyppi toteutetaan projektin ensimmäisen vaiheen aikana. Ohjelmistoprojekteissa yhteydessä erittäin tärkeitä prosessiseikkoja ovat myös muutosmenettelyä sekä lopputulosten hyväksymismenettelyä koskevat seikat. Muutosmenettelyn osalta on tavallista sopia, että sopimusta voidaan muuttaa ainoastaan molempien osapuolten kirjallisella sopimuksella. Tällainen muutosmenettely lauseke on sinällään tarpeellinen. Lauseke ei kuitenkaan yksinään anna tukea sille, kuinka muutokset käytännössä olisi toteutettava. Ainakin sellaisten projektien yhteydessä, jossa jo projektia aloitettaessa on selvillä, että projektia joudutaan oleellisilta osin täsmentämään, esimerkiksi lopputuloksia koskevat tavoitteet muuttuvat projektin edetessä, on syytä harkita sopimista muutosmenettelyn yksityiskohdista. Muutosmenettelyn osalta voidaan esimerkiksi sopia, kenen aloitteesta muutoksia tehdään, onko osapuolilla tietyissä tilanteissa velvollisuus ehdottaa muutosta, missä aikataulussa toisen osapuolen muutosehdotukseen on vastattava ja mitä vaikutuksia sillä on, jos osapuoli ei hyväksy muutosehdotusta, ja miten muutostyö hinnoitellaan. Yksi keskeinen osa prosessia on osapuolten välinen kommunikointi. Tutkimuksissamme on erityisesti korostunut projektin lopputulokseen vaikuttavana tekijänä se, miten osapuolet antavat toisilleen tietoja, mitä tietoja annetaan ja missä vaiheessa projektia mitäkin tietoja annetaan. Yleistäen ei voida todeta, että aina on hyvä antaa mahdollisimman paljon tietoa. Paitsi että jotkut tiedot on tarpeellista säilyttää luottamuksellisina, toista osapuolta ei ole syytä rasittaa sellaisilla tiedoilla, joita se ei tarvitse. Siirrettävien tietojen laatuun ja määrään vaikuttaa monia tekijöitä, kuten projektin luonne, osapuolten toimintatavat ja kypsyys sekä niiden luottamus toisiaan kohtaan. Oleellista sen sijaan onkin, että osapuolet tarpeeksi ajoissa pohtivat, mitä tietoja ja missä projektin vaiheessa niiden on syytä sitoutua antamaan muille osapuolille. Erityisesti on kiinnitettävä huomioita siihen, että ongelmien korjaaminen saattaa olla hyvin työlästä myöhäisemmissä vaiheissa, jos projektin alussa on annettu puutteellisia tietoja. 11 RISKIEN JA ONGELMIEN HALLINTA Riskien ja ongelmien hallinta käsittää velvollisuuden ennakoivasti tunnistaa ja välttää mahdollisia ongelmia sekä määritellä, miten toimitaan, jos ongelmia kuitenkin syntyy. Projektin oletusten avulla pyritään dokumentoimaan sellaisia osapuolten yhteisiä käsityksiä, joilla on vaikutusta projektin onnistumiseen. Ne saattavat liityä esimerkiksi käytettävään teknologiaan, ohjelmiston toteutettavuuteen ja ulkoisiin tapahtumiin. Kirjoittamalla keskeiset oletukset näkyviin osapuolet voivat varmistautua, että niillä on samanlainen käsitys oletuksista ja että niiden sitoumukset perustuvat tietoisuuteen näistä oletuksista. 11

12 Riskien hallinnasta sovittaviin asioihin kuuluvat riskienhallintavastuiden määritteleminen, tiettyjä riskejä koskevien vastuiden jakaminen osapuolten kesken, hyväksyttävien riskien määritteleminen sekä riskien hallinnan kustannusten jakamisen periaatteet. Ongelmien hallinnalla tarkoitetaan niitä sopimusehtoja, joista sovitaan sen tilanteen varalle, että jotain projektissa on jo mennyt pieleen. Tällaisia ovat esimerkiksi vahingonkorvausvastuuta, sopimussakkoja, oikeuspaikkaa ja sovellettavaa lakia koskevat ehdot. Riskienhallinnan tulisi olla jatkuvaa, koko projektin ajan kestävää toimintaa. Tilanteet ja olosuhteet muuttuvat ja osapuolten tieto ja ymmärrys projektista lisääntyy jatkuvasti. Jos projektin kuluessa löydetään uusia riskejä tai riskitekijöitä, on ratkaistava, miten ne vaikuttavat osapuolten sitoumuksiin. Osapuolten tulisi projektin alussa sitoutua sellaiseen riskienhallintaprosessiin, joka mahdollistaa sitoumusten päivittämisen projektin aikana. Useimmissa projektisopimuksissa on pyritty perinteisesti määrittelemään projektin lopputulokset, taloudelliset ja aikatauluun liittyvät reunaehdot sekä menettelytavat ja seuraamukset siltä varalta, ettei tavoiteltua lopputulosta saavuteta. Mallit tällaisiin sopimuksiin on yleensä alunperin saatu muilta teollisuudenaloilta. Koska sopimus on lähtökohtaisesti osapuolia sitova, useimmat sopimukset määrittelevät tietyt staattiset tavoitteet ja toimintatavat aivan kuin voitaisiin olettaa ohjelmistokehityksen etenevän alusta loppuun suunnitellulla tavalla. Tavallisesti käytetään kahta tapaa epävarmuuden hallintaan. Ensinnäkin sopimusrikkomuksia koskevilla ehdoilla voidaan sopia vahingonkorvausten suuruudesta ja laajuudesta siltä varalta, ettei alkuperäisiä tavoitteita saavuteta. Toinen vaihtoehto käsitellä projektiin liittyviä epävarmuustekijöitä on luottaa siihen mahdollisuuteen, että sopimusta voidaan aina muuttaa sopimalla asiasta yhdessä uudelleen. Periaatteessa tällaiset ehdot edustavat reagoivaa, jälkikäteistä riskienhallintaa tai ongelmienhallintaa. Ne eivät välttämättä auta toimimaan ennakoivasti riskien välttämiseksi tai pienentämiseksi [8]. Vaikka tällaiset ehdot periaatteessa muodostavatkin yllykkeen hallita riskejä ennakolta, ehdot ovat kuitenkin luonteeltaan staattisia ja ne laaditaan projektin alussa, kun vielä ei ole käytettävissä riittävästi tietoa oikeista seuraamusten ehdoista, laaduista ja suuruuksista sopimiseen. Staattiset sanktioehdot kääntävät myös helposti projektin osapuolet toisiaan vastaan, vaikka saattaisi olla mahdollista neuvottelemalla päästä tyydyttävämpään ratkaisuun. Edellä todetulla tavalla muutosmahdollisuudesta sopiminen on luonnollisesti käytännöllinen ratkaisu muuttuvassa ympäristössä. Tähän vaihtoehtoon liittyy tietysti myös huomattavia ongelmia: se voi heikentää sopimukseen liittyvien sitoumusten arvoa ja sillä on ylipäätään merkitystä vain, jos osapuolet pystyvät vielä uudelleen sopimaan asiasta. Sama ongelma liittyy myös projektisuunnitelmien malleihin, koska niissäkin on yleensä oletettu, että vaatimukset säilyvät muuttumattomina ja kehitysympäristössä ei tapahdu muutoksia. Ohjelmistoprojektien riskienhallinta liittyy sitoumusten hallintaan ja määrittelyyn. Kuva 4 esittää Riskitmenetelmän [28] mukaisesti, miten riski määräytyy sen toteutumisen todennäköisyyden ja mahdollisen vahingon suuruuden mukaan. Vahinko taas määräytyy sen mukaan, mitä tietty osapuoli on odottanut saavuttavansa. Osapuoli arvottaa odotuksensa omista lähtökohdistaan. Differenssiopin mukaisesti vahingon voidaan sanoa olevan hypoteettisen tuloksen ja toteutuneen tuloksen erotus, vaikkapa positiivisen sopimusedun saavuttamatta jääminen [15]. Sitoumusten määrittelyssä odotukset määritellään selvästi. Niinpä vaikka monet riskienhallinnan menetelmät jättävät erikseen mainitsematta odotusten ja riskien välisen suhteen, riskien perusluonteesta johtuen ne kuitenkin tukevat jossain määrin sitoumusten hallintaa. 12

13 riski osatekijänä osatekijänä todennäköisyys vahinko määräytyy odotukset arvottuu osapuoli Kuva 4 Riskin määritelmä Riskit-menetelmän mukaisesti Kiinnostus ohjelmistotuotannon riskienhallintaa kohtaan on lisääntynyt viime aikoina teollisuudessa. Tästä kehityksestä on raportoitu julkaisuissa [21] ja konferensseissa [42] ja siitä kertoo myös riskienhallinnan ottaminen osaksi ohjelmistoprosesseja koskevia standardeja [22, 43] ja arviointimalleja [23, 36]. Vaikka kirjallisuudessa on esitetty useita riskienhallinnan lähestymistapoja [3, 4, 7, 11, 25, 28] ja monet niistä ovat jopa käytössä, vain harvoissa niistä on erityisesti tuotu esiin osapuolten välistä riskienhallintaa ja sitoumusten määrittelyä. Monet menetelmät kuitenkin epäsuorasti tuovat nämäkin kysymykset esiin. Software Engineering Institute (SEI) on kehittänyt Team Risk Management menetelmän, jossa oletetaan, että osapuolet voivat saavuttaa yksimielisyyden ja että kaikista riskeihin liittyvistä näkökohdista voidaan keskustella avoimesti. Tähän lähestymistapaan liittyy kolme mahdollista ongelmakohtaa. Ensinnäkin on varsin ilmeistä, etteivät kaikki osapuolet ole valmiita avoimesti keskustelemaan riskeistään. Toiseksi osapuolilla saattaa olla varsin erilaisia näkökulmia riskeihin. Pakottamalla heidät olemaan yhtä mieltä riskeistä tai tekemään riskianalyyseissään kompromisseja saatetaan riskejä tulkita virheellisesti. Kolmanneksi SEI:n lähestymistapa ei tuo esiin riskeihin liittyviä sopimuksellisia näkökohtia eikä neuvotteluprosessia. Barry Boehmin kehittämä riskienhallinnan WinWin-malli [5, 6] ottaa huomioon eri osapuolten erilaiset näkökulmat ja neuvotteluprosessin. Boehmin lähestymistapa on tunnetuin menetelmä, jossa otetaan huomioon osapuolten odotukset. Se rajoittuu kuitenkin tavoitteiden määrittelyyn eikä tarjoa ohjeita siihen, miten sitoumukset tulisi täsmentää. Jyrki Kontion Riskit-menetelmä [28, 29] tunnistaa myös erityisesti projektin osapuolet ja heidän mahdollisesti erilaiset odotuksensa projektin suhteen. Riskit-menetelmä sisältää lähestymistavan, jolla voidaan löytää osapuolten riskit, odotukset ja tavoitteet. Riskit-menetelmäkään ei kuitenkaan tuo riittävästi esiin sitoumusmäärittelyn sisältöä eikä siihen johtavaa prosessia. 13

14 12 VAHINGONKORVAUS OSANA RISKIENHALLINTAA Ohjelmistoprojektin osapuolten sopimusrikkomukset, kuten viivästyminen tai ohjelmistossa oleva virhe, saattavat aiheuttaa suuriakin vahinkoja muille osapuolille. Niinpä onkin tavallista sopia vahingonkorvausvastuusta ohjelmistoprojektia koskevassa sopimuksessa. Tavanomainen lauseke on Sopijapuoli ei vastaa välillisistä vahingoista. Muun muassa ohjelmistoprojekteissa melko yleisesti käytetyissä ATK94/YSE-, IT2000/YSE- ja IT2000/PTE-ehdoissa on tämän kaltainen virke. [2, 24] Samansisältöinen ehto on myös monissa niissä sopimuksissa ja vakioehdoissa, joihin ei sovelleta ATK94- eikä IT2000-ehtoja. Syy välillisten vahinkojen rajaamiselle pois korvattavien vahinkojen piiristä on varsin selkeä. Välillisten vahinkojen määrää on vaikeaa ennakoida ja esimerkiksi tilaajalle aiheutuvien välillisten vahinkojen suuruus ei yleensä ole toimittajan kontrolloitavissa. Välillisiä vahinkoja ei kuitenkaan ole erikseen määritelty ATK94- eikä IT2000-ehdoissa sen enempää kuin useimmissa muissakaan ohjelmistoprojekteja koskevissa sopimuksissa. Niinpä saattaa jälkikäteen aiheutua epäselvyyttä siitä, mitkä vahingot ovat välittömiä ja toisen osapuolen korvattavia, mitkä vahingot puolestaan välillisiä. Välittömän ja välillisen vahingon voi käsitteinä ajatella tarkoittavan sitä, että esimerkiksi sopimusrikkomuksesta, viivästyksestä tai tuotteen virheestä aiheutuu toiselle osapuolelle ensin välitön vahinko, josta puolestaan aiheutuu välillistä vahinkoa (Kuva 5). [15, 27] Käytännössä ei kuitenkaan ole lainkaan yksinkertaista määritellä, mitkä vahingot seuraavat välittömästi esimerkiksi sopimusrikkomuksesta, mitkä taas ovat välittömän vahingon seurauksia. Tämä saattaa johtaa välittömien vahinkojen alan suppenemiseen tarpeettomankin pieneksi tai aiheuttaa melkoista tulkinnanvaraisuutta. Viivästys tai virhe Välitön vahinko Välillinen vahinko Kuva 5 Viivästys tai virhe aiheuttaa välittömän vahingon, joka puolestaan aiheuttaa välillisen vahingon. Asiasta ei ole nimenomaista lainsäännöstä. Kauppalaissa tehdään ero välillisen ja välittömän vahingon kesken, mutta kauppalaki ei ensinnäkään ole yleensä suoraan sovellettavissa ohjelmistoprojekteihin. Toiseksi kauppalaissa esitetty määritelmä on itsessään jonkin verran epäselvä ja tulkinnanvarainen. Hemmon mukaan välittömän ja välillisen vahingon määrittelyssä ilmenevät detaljierot saavat aikaan epäselvyyttä. Välillisten vahinkojen ydinsisällöstä vallitsee kuitenkin yksimielisyys. Niiden piiriin kuuluvat ennen kaikkea sopimusrikkomuksen aiheuttama tulon menetys ja sivullisten kanssa tehdyissä sopimuksissa ilmenevät häiriöt [ ] Alaviitteessä Hemmo kuitenkin lisää, että sopimuksen mukainen voitto, joka seuraa suorituksen markkina-arvon ja velkojan maksaman hinnan erotuksesta, ei luonnollisestikaan ole välilliseksi vahingoksi luettavaa tuloa. Tämä sopimusvaihdannan keskeisimpiin kuuluva intressi korvataan aina välittömänä vahinkona. [15] Lukijalle ei täysin selviä, mikä oleellinen ero tässä on tulolla ja sopimuksen mukaisella voitolla. Vaikka asiassa ehkä periaatteessa vallitseekin yksimielisyys, käytännössä ei ole kovinkaan helppoa Hemmon esittämällä tavalla erottaa välitöntä ja välillistä vahinkoa toisistaan. 14

15 Kirjallisuudessa ja kauppalain esitöissä [14] on yleisesti kannatettu välittömien ja välillisten vahinkojen erottamista toisistaan sen mukaan, miten hyvin ennakoitavia ne ovat. Erityisesti tämä on kirjattu näkyviin kauppalain 67 2 momentin 5 kohdassa: [Välillisenä vahinkona pidetään] muuta saman kaltaista, vaikeasti ennakoitavaa vahinkoa. Tällainen adekvanssioppiin perustuva tulkinta ei ehkä kovin hyvin vastaa sanojen välitön ja välillinen yleistä merkitystä, mutta ennalta-arvattavuus muuten antaa kieltämättä järkevän perusteen vahingonkorvausvastuun rajaamiselle. Vahingon ennakoitavuuden eli adekvaattisuuden on yleensäkin katsottu olevan vahingonkorvausvelvollisuuden keskeinen edellytys syy-yhteyden ohella. Täysin ennalta-arvaamaton vahinko ei yleensä ole vahingonkorvausvastuun piirissä. [15, 16, 27, 45] Niinpä voitaisiin hyvin ajatella, että mitä helpommin ennakoitavissa vahinko on, sitä laajempi on korvausvastuu. Helposti ennakoitavien eli välittömien vahinkojen osalta voitaisiin edellyttää vähäisempää tuottamusta tai soveltaa jopa kauppalain tyyliin kontrollivastuuta. Vaikeammin ennakoitavien eli välillisten vahinkojen kohdalla edellytettäisiin suurempaa tuottamusta ja erittäin vaikeasti ennakoitavat vahingot jäisivät adekvanssiopin mukaisesti korvausvelvollisuuden ulkopuolelle. Saarinen on ehdottanut, että sopimuksissa voitaisiin vahingonkorvausvelvollisuutta rajata esimerkiksi seuraavasti: sopijapuolella on oikeus vahingonkorvaukseen [ ] sopimuksen täyttämisen viivästymisestä aiheutuvasta vahingosta, ellei viivästyvä sopijapuoli osoita, että viivästys johtuu hänen vaikutusmahdollisuuksiensa ulkopuolella olevasta esteestä, jota hänen ei voida kohtuudella edellyttää ottaneen huomioon sopimusta tehtäessä ja jonka seurauksia hän ei olisi voinut välttää eikä voittaa. Vahingot, joiden syntymistä, laatua tai määrää sopimusta rikkoneen sopijapuolen on erityisen vaikea arvioida ennalta, hän on velvollinen korvaamaan vain, mikäli ne aiheutuvat tuottamuksesta hänen puolellaan. [39] Saarisen ehdotus tarjoaa hyvän pohjan sopimuksen laatijalle. Se ei kuitenkaan vielä lopullisesti ratkaise välittömien ja välillisten vahinkojen rajanveto-ongelmaa. Vahinkojen ennakoitavuus saattaa olla jälkikäteen varsin hankalaa näyttää toteen. Niinpä olisikin syytä sopimustekstiin kirjata näkyviin selkeämpi määrittely vahinkotyyppien erottelusta, jos välilliset vahingot halutaan sulkea korvausvastuun ulkopuolelle. Tapauskohtaisesti tässä voi auttaa esimerkkiluettelon ottaminen mukaan. Tällöin edellytetään osapuolilta sopimusneuvotteluvaiheessa kohtalaisen hyvää näkemystä siitä, minkälaisia vahinkoja sopimusrikkomuksesta saattaisi seurata. Työväline tämän analyysin tekemiseen saadaan riskienhallinnasta. Tunnistamalla ja analysoimalla projektin riskit ennen sopimuksen solmimista, voidaan luoda perusteltu näkemys siitä, minkälaisia ongelmia saattaa olla odotettavissa ja minkälaisia vahinkoja niistä saattaa seurata. Riski on mahdollisesti tulevaisuudessa sattuva epätoivottu, vahingollinen tapahtuma. Riskillä on syynsä eli riskitekijät. Riski siis on riskitekijöiden seuraus. Tarkasteltaessa sopimussuhdetta, jossa on ainakin kaksi osapuolta, voidaan huomata monien riskien olevan sellaisia, että niiden syyt, riskitekijät ovat yhden osapuolen vaikutuspiirissä, kun taas mahdollinen vahinko aiheutuu toiselle osapuolelle. Tällaiset riskit ovat sopimussuhteen ja vastuunjaon kannalta keskeisiä. Projektissa voidaan yleisen käytännön mukaisesti sopia, että osapuolet vastaavat vain välittömistä vahingoista. Sopimussuhteen alussa suoritettavassa riskien tunnistuksessa osapuolten tulisi pyrkiä mahdollisimman kattavasti löytämään kaikki riskit. Vahingonkorvausoikeudelliselta kannalta on erityisen tärkeää pyrkiä löytämään ne riskitekijät, jotka ovat omassa vaikutuspiirissä, sekä ne riskit, joiden mahdollinen vahinko aiheutuu itselle. Ilmoittamalla näin löydetyt riskitekijät ja riskit toiselle osapuolelle, on mahdollista tehokkaasti ja järkevästi sopia vahingonkorvausvastuusta samalla, kun voidaan mielekkäällä tavalla käynnistää hankkeeseen liittyvä riskienhallinta. Selvyyden vuoksi välitön 15

16 vahinko määritellään sopimuksessa ennalta-arvattavaksi vahingoksi. Erityisesti ennalta-arvattavia vahinkoja ovat sellaiset, jotka osapuoli on etukäteen kirjallisesti ilmoittanut toiselle osapuolelle. Näin osapuolen kannattaa tehdä mahdollisimman perusteellinen riskien tunnistus ja ilmoittaa sen tulokset toiselle osapuolelle. Mikäli korvattavista vahingoista jouduttaisiin jälkeenpäin riitelemään, olettamaksi muodostuisi, että osapuoli joutuu korvaamaan aiheuttamansa vahingon, mikäli toinen osapuoli on riskin etukäteen ilmoittanut. Muussa tapauksessa korvausvelvollisuutta ei ole, ellei vahinkoa kärsinyt pysty näyttämään jälkikäteen, että riski oli ennalta-arvattava. Myös omassa vaikutuspiirissä olevat riskitekijät kannattaa ilmoittaa toiselle osapuolelle etukäteen. Tällöin on mahdollista sopia siitä, että toinen osapuoli hyväksyy riskitekijän ja ottaa vastaavan riskin kantaakseen tai että vastuu riskistä jaetaan osapuolten kesken. Jos taas osapuoli ei ilmoita riskitekijän olemassaoloa toiselle osapuolelle, vastuu riskin mahdollisesti aiheuttamista vahingoista on lähtökohtaisesti osapuolella itsellään. Riskitekijöiden ilmoittaminen toiselle osapuolelle ei toki aina ole helppoa. Neuvoteltaessa sopimuksesta, voi tuntua siltä, että sopimuksen syntyminen vaarantuu, jos omia riskitekijöitä tuodaan esille. Tällaista oloa ei voi vähätellä perustuupa se sitten tosiasioihin tai ei. Avoimuus riskitekijöistä ja heikkouksista voi kuitenkin parhaimmillaan lisätä uskottavuutta ja luottamusta sen lisäksi, että samalla oikeudellisesti turvataan selustaa pahimman varalle. 13 PROJEKTIN ETENEMISTÄ TUKEVAT RISKIEN HALLINTAKEINOT Edellä on todettu, että tavallisesti sopimuksissa käytettävät riskienhallintakeinot edustavat lähinnä ns. jälkikäteistä riskienhallintaa, eivätkä siten välttämättä auta toimimaan ennakoitavasti riskien välttämiseksi. Lukuun ottamatta tietenkin keinojen mahdollista epäsuoraa pelote- tai ennalta ehkäisevää vaikutusta. Alihankintaa koskevissa case-tutkimuksissa on selvästi käynyt ilmi, että huolimatta toimittajan ja alihankkijan väliseen sopimukseen kirjatusta vahingonkorvaus-, sopimus- tai viivästyssakkolausekkeesta, ei toimittaja alihankkijan viivästys tai virhe tilanteissa usein ole ollut halukas turvautumaan näihin keinoihin. Toimittajan kannalta tärkeämpää on ollut yhteistyön säilyttäminen alihankkijan kanssa sekä sopimusten lopputulosten saavuttaminen vaikka myöhässäkin tai hiukan muuttuneessa muodossa. Saman voisi arvella koskevan myös monia muita sopimussuhteita. Esitetyt käytännön kokemukset ovat kiinnostavia kahdessa mielessä. Perinteisesti yhtenä tärkeänä sopimusten painopisteenä on ollut jälkikäteiset riskienhallintakeinot. Edellä esitettyjen kokemusten perusteella voidaan kuitenkin ehdottaa, että ennen yksittäisten vahingonkorvaus tai sopimussakkolausekkeiden kirjaamista on syytä tarkoin harkita niiden merkitystä projektin kannalta. Jos on todennäköistä, ettei niihin esimerkiksi viivästystilanteissa haluta turvautua, ei sopimuksen painopistettä kannata siten kohdistaa näihin lausekkeisiin. Vastaavasti vahingonkorvaus- ja sopimussakkolausekkeista ei tällöin ole järkevää tehdä sopimusneuvottelun kynnyskysymystä. Käytännön kokemukset ohjaavat hakemaan myös muita kuin perinteisiä riskienhallintakeinoja. Olisiko olemassa riskienhallinta keinoja, joilla tuettaisiin projektien etenemistä? Yhtenä vaihtoehtona voidaan esittää erilaiset kannustinjärjestelmät, esimerkiksi bonuksen antaminen alihankkijalle hyvin edenneen projektin yhteydessä. 16

17 14 YHTEENVETO Ohjelmistoprojektit epäonnistuvat varsin usein. Nykyiset sopimukset eivät juurikaan tue projektin menestyksellistä läpivientiä eivätkä välttämättä auta edes ratkaisemaan projektista aiheutuvia riitoja. Ohjelmistoprojektin alkaessa osapuolilla on vain rajalliset mahdollisuudet sopia kaikista asioista, jotka mahdollisesti saattavat aiheuttaa ongelmia projektin aikana. On tärkeää keskittää sopimuksen teossa niukat resurssit oikeisiin kysymyksiin. Tunnistamalla projektin riskitaso ja muut oleelliset ominaisuudet, voidaan keskittyä määrittelemään tärkeimmät sitoumukset kunnolla. Riskialttiissa projektissa kannattaa määritellä huolellisesti motiivit, prosessit ja riskienhallinta, kun taas vähemmän riskialttiissa projektissa voidaan yksityiskohtaisemmin määritellä tavoitteet ja ongelmien hallinta. LÄHTEET 1 G. Aharonian. Does the Patent Office Respect the Software Community? IEEE Software, Jul/Aug, ATK94 Tietojenkäsittelyalan sopimusehdot, Keskuskauppakamari ja Tietotekniikan liitto ry, B.W. Boehm. Tutorial: Software Risk Management, IEEE Computer Society Press, s B.W. Boehm, Software Risk Management: Principles and Practices, IEEE Software, vol. 8, s , B.W. Boehm & Bose P., A Collaborative Spiral Software Process Model Based on Theory W, Proceedings of the 3rd International Conference on the Software Process. IEEE Computer Society. Washington, DC. 6 B.W. Boehm & Ross R, Theory W Software Project Management: Principles and Examples IEEE Transactions on Software Engineering, vol. s , R.N. Charette. Software Engineering Risk Analysis and Management, New York: McGraw-Hill, R.N. Charette, Building Bridges over Intelligent Rivers American Programmer, vol. s. 2-9, J.D. Cooper, Corporate Level Software Management IEEE Transactions on Software Engineering, vol. SE-4, T. DeMarco & T.R. Lister. Peopleware: Productive Projects & Teams, Dorset House Publishing Company, R.E. Fairley. Risk Management: The Key to Successful Software Projects. In: Proceedings of the 3rd IFAC/IFIP Workshop, toim. F.J. Mowle and P.F. Elzer. Oxford: Pergamon, 1989.s H. Glover, H.J. Watson, & R.K. Rainer Jr., 20 Ways to Waste an EIS Investment Information Strategy: The Executive's Journal, vol. 8, s , P-L. Haarmann. Tekijänoikeus ja lähioikeudet, Kauppakaari, Hallituksen esitys Eduskunnalle kauppalaiksi, HE 93/1986 vp,

18 15 J. Hellner, Skadeståndsrätt, Juristförlaget, Stockholm, M. Hemmo. Sopimusoikeus I, Kauppakaari Oy, Helsinki, M. Hemmo. Sopimusoikeus II, Kauppakaari Oy, Helsinki, A. Huhtamäki, Luotonantajavastuu, Lakimiesliiton kustannus, W.S. Humphrey. Managing for Innovation: Leading Technical people, Englewood Cliffs, New Jersey: Prentice-Hall, IEEE. IEEE Standard for Software Project Management Plans, Std , New York: IEEE, IEEE, Managing Risk, IEEE Software, vol. 14, no. 3, ISO. ISO , Guidelines for the application of ISO 9001 to the development, supply and maintenance of software, ISO :1991(E), International Standards Organization, ISO. SPICE: Baseline Practices Guide, an unfinished draft of a standard being developed for ISO, version 1.00, (julkaisematon) 24 IT2000. Tietotekniikka-alan yleiset sopimusehdot, Keskuskauppakamari, Suomen Logistiikkayhdistys ry, Tietotekniikan liitto ry ja Tietotekniikan Palveluliitto TIPAL ry, D.W. Karolak. Software Engineering Risk Management, Washington, DC: IEEE, S.P. Keider, Why Projects Fail Datamation, vol T. M. Kivimäki & M. Ylöstalo, Suomen siviilioikeuden oppikirja. Yleinen osa, J. Kontio, The Riskit Method for Software Risk Management, version 1.00, CS-TR-3782, 1997b. Computer Science Technical Reports. University of Maryland. College Park, MD. 29 J. Kontio & V.R. Basili, Empirical Evaluation of a Risk Management Method, Proceedings of the SEI Conference on Risk Management. Software Engineering Institute. Pittsburgh, PA. 30 J. Kontio, O. Pitkänen, & R. Sulonen, Towards Better Software Projects and Contracts: Commitment Specifications in Software Development Projects, Proceedings of the 20th International Conference on Software Engineering, ICSE 98. IEEE Computer Society. Washington, DC. 31 P.L. McDoniel, J. Palko, & T.P. Cronan, Information systems development: issues affecting success J.Comput.Inf.Syst., vol. 34, s , R. Merges, P. Menell, M. Lemley. Intellectual Property in the New Technological Age. 2nd edition, Aspen Law & Business, R. Merges. As Many as Six Impossible Patents Before Breakfast: Property Rights for Business Concepts and Patent System Reform. Berkeley Technology Law Journal, 14:2, S. Nystén-Haarala, The Long-Term Contract, Contract Law and Contracting, Kauppakaari Oyj, Finninsh Lawyers Publishing, Helsinki S. Nystén-Haarala, Sopimusoikeus ja sopimusten hallinta. Lakimies 2,

19 36 M.C. Paulk, B. Curtis, M.B. Chrissis, & C.V. Weber, Capability Maturity Model for Software, Version 1.1. SEI Technical Report. Software Engineering Institute, Carnegie Mellon University, O. Pitkänen, M. Välimäki, Towards A Digital Rights Management Framework, IeC2000 Conference Proceedings, Manchester, UK, Preventive Law Reporter, University of Denver College of Law, T. Saarinen, Sopimusoikeudellisesta vahingonkorvausvastuusta erityisesti kauppalain valossa, Turun yliopiston oikeustieteellisen tiedekunnan julkaisuja, Yksityisoikeuden julkaisusarja B:28, J. Salonen, Tietojärjestelmän hankinta, Tutkimus järjestelmän oikeaa mitoitusta ja toimivuutta koskevasta sopimusvastuusta, Finn Lectura, P. Samuelson. Good News and Bad News on the Intellectual Property Front. Communications of the ACM, vol. 42 no. 3, March C. Shapiro & H. R. Varian, Information Rules, A Strategic Guide to the Network Economy, Harvard Business School Press, SEI. Proceedings of the SEI Conferences on Software Risk Management, Pittsburgh, PA: Software Engineering Institute, 1993, 1994, 1995, SPICE, Software Process Assessment Part 1: Concepts and introductory guide ISO/IEC/JTC1/SC7/WG10/N111, Oct 6, ISO. 45 L. E. Taxell, Skadestånd vid avtalsbrott, Åbo Akademis Förlag,

IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS

IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS 20.4.2015 IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA 1 1.1 SOVELTAMINEN Näitä erityisehtoja sovelletaan ohjelmistojen tai niiden osien toimituksiin ketterien

Lisätiedot

Immateriaalioikeuksien. hyödyntäminen sopimuksin. Aineettomien oikeuksien. hyödyntäminen sopimuksin. Sopimusoikeus. Sopimusvapauden periaate

Immateriaalioikeuksien. hyödyntäminen sopimuksin. Aineettomien oikeuksien. hyödyntäminen sopimuksin. Sopimusoikeus. Sopimusvapauden periaate Immateriaalioikeuksien hyödyntäminen sopimuksin Aineettomien oikeuksien hyödyntäminen sopimuksin 26.2.2004 Teemu Soininen Sopimuksen syntyminen Sopimuksen sitovuus IT-alan sopimukset, erityisesti lisenssisopimukset

Lisätiedot

Tietotekniikkasopimukset. T-76.632 Tietotekniikkaoikeus (2 ov) Olli Pitkänen

Tietotekniikkasopimukset. T-76.632 Tietotekniikkaoikeus (2 ov) Olli Pitkänen Tietotekniikkasopimukset T-76.632 Tietotekniikkaoikeus (2 ov) Olli Pitkänen Tietotekniikkasopimukset Tietotekniikka-alan sopimukset ovat sopimuksia siinä missä muutkin Projektien omaleimaisuus, lakimiesten

Lisätiedot

Rakenta Oy 2407354-6. Helsinki. Sergey Kovalev 044-919 0061

Rakenta Oy 2407354-6. Helsinki. Sergey Kovalev 044-919 0061 SOPIMUS OSOITE- JA POSTITUSPALVELUISTA TILAAJA Toiminimi Y-tunnus Kotipaikka Yhteyshenkilö Osoite Puhelin Sähköposti Maksuehdot 14 pv netto, laskutus 3-12 kk välein, 1. vuosi ennakkomaksu 240 e (hintaan

Lisätiedot

SEUTUKESKUS OY HÄME POIKKEAMAT JULKISEN HALLINNON IT-HANKINTOJEN YLEISIIN SOPIMUSEHTOIHIN (JIT 2007)

SEUTUKESKUS OY HÄME POIKKEAMAT JULKISEN HALLINNON IT-HANKINTOJEN YLEISIIN SOPIMUSEHTOIHIN (JIT 2007) SEUTUKESKUS OY HÄME POIKKEAMAT JULKISEN HALLINNON IT-HANKINTOJEN YLEISIIN SOPIMUSEHTOIHIN (JIT 2007) 1 (5) Yleistä Tämän dokumentin numerointi noudattaa JIT 2007 -ehtojen numerointia ja viittaa näin ollen

Lisätiedot

STT:n yleiset sopimusehdot 1.1.2010

STT:n yleiset sopimusehdot 1.1.2010 YLEISET SOPIMUSEHDOT 1 (5) STT:n yleiset sopimusehdot 1. Käyttöoikeus 2. Käyttöehdot 1 Kappale päivitetty 1.1.2016 alkaen. Asiakkaalla on oikeus käyttää STT:n palvelua ja/tai siihen sisältyviä aineistoja

Lisätiedot

Taiteilijan sopimus- ja vastuukysymyksistä. 15.1.2016 lakimies Anna Nousiainen, Suomen Taiteilijaseura

Taiteilijan sopimus- ja vastuukysymyksistä. 15.1.2016 lakimies Anna Nousiainen, Suomen Taiteilijaseura Taiteilijan sopimus- ja vastuukysymyksistä 15.1.2016 lakimies Anna Nousiainen, Suomen Taiteilijaseura Kun luovutetaan tavaraa tai palvelua korvausta vastaan, on selvitettävä: Kenen tai minkä kanssa järjestän

Lisätiedot

Tik-76.612 Ohjelmistotuoteliiketoiminta

Tik-76.612 Ohjelmistotuoteliiketoiminta Tik-76.612 Ohjelmistotuoteliiketoiminta Luennot ja projekti synty suunnittelu käynnistys ohjaus päätös operointi Ti 12.3 To 14.3 Ti 19.3 To 21.3 Ti 26.3 To 4.4 Ti 9.4 To 11.4 Ti 16.4 Ti 18.4 To 23.4 Kurssin

Lisätiedot

Pk-yrityksen sopimukset ja riskienhallinta

Pk-yrityksen sopimukset ja riskienhallinta Pk-yrityksen sopimukset ja riskienhallinta Marja Välilä Laurea-ammattikorkeakoulu www.laurea.fi Pk-yrityksen sopimukset ja sopimusriskit! Sopimukset kuuluvat olennaisesti kaikkeen yritystoimintaan. Prosessi!

Lisätiedot

Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä

Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä Laajuus Jatkuva laajeneminen sekä maantieteellisesti että sisällön kannalta: Yhdestä

Lisätiedot

Hevoskaupan juridiikka

Hevoskaupan juridiikka Hevoskaupan juridiikka Yleistä Hevonen on irtain esine Virhe hevosessa vaikeampi nähdä kuin tavanomaisessa tavarassa (esim. auto) Myyjän tiedonantovelvollisuus Ostajan tiedonottovelvollisuus 1 Sovellettava

Lisätiedot

REVOLUTION-LISENSSISOPIMUS

REVOLUTION-LISENSSISOPIMUS Lisenssisopimus 1 (5) REVOLUTION-LISENSSISOPIMUS 1 OSAPUOLET Tämä lisenssisopimus ( Sopimus ) on tehty seuraavien osapuolten välillä: 1. Trainer4You Revolution Oy, y-tunnus 2623516 6, Suomessa rekisteröity

Lisätiedot

Riskit hallintaan ISO 31000

Riskit hallintaan ISO 31000 Riskit hallintaan ISO 31000 Riskienhallinta ja turvallisuus forum 17.10.2012 Riskienhallintajohtaja Juha Pietarinen Tilaisuus, Esittäjä Mitä on riskienhallinta? 2 Strategisten riskienhallinta Tavoitteet

Lisätiedot

Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa

Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa 13.05.2015 Terveydenhuollon ATK-päivät Tampere-talo Yleistä Riskienhallintaan löytyy viitekehyksiä/standardeja kuten ISO 31000

Lisätiedot

SalesBooster Nopeuttaa myyntitulosten saavuttamista. Knowledge Investor Comset www.comset.fi www.comset.se www.comset.dk

SalesBooster Nopeuttaa myyntitulosten saavuttamista. Knowledge Investor Comset www.comset.fi www.comset.se www.comset.dk SalesBooster Nopeuttaa myyntitulosten saavuttamista SalesBooster - Mikä se on? Palvelu, joka Nopeuttaa myyntitulosten saavuttamista kiteyttämällä asiakaslupauksen helpommin ostettavaksi ja myytäväksi tuotteeksi

Lisätiedot

Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön

Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön Aikuisopiskelijan viikko tarjoaa mainion tilaisuuden toteuttaa tapahtumia yhteistyössä oman alueen eri organisaatioiden kanssa.

Lisätiedot

Hevoskaupan juridiikka

Hevoskaupan juridiikka Hevoskaupan juridiikka Yleistä Hevonen on irtain esine Virhe hevosessa vaikeampi nähdä kuin tavanomaisessa tavarassa (esim. auto) Myyjän tiedonantovelvollisuus Ostajan selonottovelvollisuus Sovellettava

Lisätiedot

SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY

SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY Anna-Liisa Koskinen SISÄLTÖ Uusi rakenne Uusia määritelmiä Keskeisistä muutoksista 2 ISO 14001 ympäristöjohtamisjärjestelmä ISO 14001 on tunnettu

Lisätiedot

Yhteistyösopimus. Uudenkaupungin kaupungin. Finn Sportsman Oy:n. välillä

Yhteistyösopimus. Uudenkaupungin kaupungin. Finn Sportsman Oy:n. välillä KAU Yhteistyösopimus Uudenkaupungin kaupungin ja Finn Sportsman Oy:n välillä 2 1. OSAPUOLET Tämän yhteistyösopimuksen osapuolina ovat: (1) Uudenkaupungin kaupunki (Y-tunnus: 0144036-6) Välskärintie 2 23500

Lisätiedot

PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS

PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS 10 KEYS TO SUCCESSFUL SOFTWARE PROJECT 1. Clear Vision 2. Stable, Complete, Written Requirements 3. Detailed User Interface Prototypes

Lisätiedot

1/6. LIITE 7 Palvelutaso

1/6. LIITE 7 Palvelutaso 1/6 LIITE 7 Palvelutaso 1. MÄÄRITELMÄT... 2 2. NEUVONTA... 2 3. VIRHEIDEN KORJAAMINEN... 3 4. KIIREELLISYYSLUOKAT VASTEAIKA... 3 5. ALUSTAN YLLÄPITO... 4 6. ALUSTAN KEHITTÄMINEN... 4 7. PALVELUVASTEAIKOJEN

Lisätiedot

Tilaaja: Ylioppilastutkintolautakunta (jäljempänä Tilaaja ) Tilaajan yhteyshenkilö sopimusasioissa: XXX

Tilaaja: Ylioppilastutkintolautakunta (jäljempänä Tilaaja ) Tilaajan yhteyshenkilö sopimusasioissa: XXX Hankinta: USB-muistitikut sähköiseen ylioppilaskokeeseen, dnro 1/221/2016 TARJOUSPYYNNÖN LIITE 1, SOPIMUSEHDOT SOPIMUS USB-MUISTITIKKUJEN TOIMITTAMISESTA 1. OSAPUOLET JA YHTEYSHENKILÖT Tilaaja: Ylioppilastutkintolautakunta

Lisätiedot

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja Versio: 0.9 Julkaistu: n.n.2011 Voimassaoloaika: toistaiseksi 1 Yleistä Palvelun kehitys jakautuu vaiheisiin, joiden väleissä

Lisätiedot

SOPIMUS TAVARAN X HANKINNASTA

SOPIMUS TAVARAN X HANKINNASTA LIITE 5A SOPIMUS SOPIMUS TAVARAN X HANKINNASTA 1. OSAPUOLET JA YHTEYSHENKILÖT Tilaaja: Jyväskylän yliopisto Pl 35 40014 Jyväskylän yliopisto (jäljempänä Tilaaja ) Tilaajan yhteyshenkilö sopimusasioissa:

Lisätiedot

TASEPALVELUSOPIMUS (Balance Agreement) NRO XX [TASEVASTAAVA OY] sekä FINGRID OYJ

TASEPALVELUSOPIMUS (Balance Agreement) NRO XX [TASEVASTAAVA OY] sekä FINGRID OYJ TASEPALVELUSOPIMUS (Balance Agreement) NRO XX [TASEVASTAAVA OY] sekä FINGRID OYJ 2 (7) Sisällys 1 SOPIMUSOSAPUOLET JA SOPIMUKSEN TARKOITUS... 3 2 SOPIMUKSEN VOIMASSAOLO... 3 3 AVOIN SÄHKÖNTOIMITUS... 3

Lisätiedot

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta

Lisätiedot

JÄLLEENMYYNTISOPIMUS HELSINGIN KAUPUNGIN RAKENNUSVIRASTON PALVELUOSASTO INNOFACTOR OYJ

JÄLLEENMYYNTISOPIMUS HELSINGIN KAUPUNGIN RAKENNUSVIRASTON PALVELUOSASTO INNOFACTOR OYJ JÄLLEENMYYNTISOPIMUS HELSINGIN KAUPUNGIN RAKENNUSVIRASTON PALVELUOSASTO JA INNOFACTOR OYJ 16.6.2014 3815172.3 SISÄLLYSLUETTELO JÄLLEENMYYNTISOPIMUS... 3 OSAPUOLET... 3 SOPIMUKSEN TAUSTA JA TARKOITUS...

Lisätiedot

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa

Lisätiedot

Sopimukset yritystoiminnassa. Perusasiaa yrittäjälle

Sopimukset yritystoiminnassa. Perusasiaa yrittäjälle Sopimukset yritystoiminnassa Perusasiaa yrittäjälle Sopimukset yritystoiminnan selkäranka Lähes kaikki vaihdanta modernissa markkinataloudessa perustuu sopimuksiin: myynnit, ostot, vuokraus. Hyvin tehdyt

Lisätiedot

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

PL 6000, 00099 Helsingin kaupunki. ja xxxxxxx (jäljempänä Palveluntuottaja) Osoite: xxxxxxxxxxxx y-tunnus

PL 6000, 00099 Helsingin kaupunki. ja xxxxxxx (jäljempänä Palveluntuottaja) Osoite: xxxxxxxxxxxx y-tunnus 1 SUUN TERVEYDENHUOLLON ANESTESIAPALVELUN HANKINTA 1. Sopijapuolet Helsingin kaupunki (jäljempänä Tilaaja) Osoite: Helsingin kaupungin terveyskeskus PL 6000, 00099 Helsingin kaupunki ja xxxxxxx (jäljempänä

Lisätiedot

OMAVALVONTA ISO 9001 ISO / FSSC 22000 ISO 14001 OHSAS 18001 SATAFOOD KEHITTÄMISYHDISTYS RY 24.9.2015. Marika Kilpivuori

OMAVALVONTA ISO 9001 ISO / FSSC 22000 ISO 14001 OHSAS 18001 SATAFOOD KEHITTÄMISYHDISTYS RY 24.9.2015. Marika Kilpivuori SATAFOOD KEHITTÄMISYHDISTYS RY Laatu- ja ympäristöjärjestelmät 24.9.2015 Marika Kilpivuori OMAVALVONTA ISO 9001 ISO / FSSC 22000 BRC ISO 14001 OHSAS 18001 IFS 1 MIKÄ JÄRJESTELMÄ MEILLÄ TARVITAAN? Yrityksen

Lisätiedot

Julkisen ja yksityisen sektorin kumppanuus innovatiivisten palveluiden mahdollistajana

Julkisen ja yksityisen sektorin kumppanuus innovatiivisten palveluiden mahdollistajana Julkisen ja yksityisen sektorin kumppanuus innovatiivisten palveluiden mahdollistajana Helsingin Yrittäjien seminaari 1.3.2011 Kumppanuus Yritysmyönteistä yhteistyötä mikko.martikainen@tem.fi Mikko Martikainen

Lisätiedot

ESIKATSELUKAPPALE IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERILLÄ MENETELMILLÄ

ESIKATSELUKAPPALE IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERILLÄ MENETELMILLÄ IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERILLÄ MENETELMILLÄ 1 SOVELTAMINEN 1.1 Näitä erityisehtoja sovelletaan ohjelmistojen tai niiden osien toimituksiin ketterien menetelmien projekteilla.

Lisätiedot

Yleiset toimitusehdot Asiantuntijapalvelut

Yleiset toimitusehdot Asiantuntijapalvelut Asiantuntijapalvelut SISÄLLYSLUETTELO 1 YLEISTÄ... 2 1.1 Soveltaminen... 2 1.2 Työmenetelmät... 2 2 TOIMITTAJAN VELVOLLISUUDET... 2 2.1 Yleistä... 2 2.2 Tiedottaminen palvelun edistymisestä... 2 3 TILAAJAN

Lisätiedot

TEHORESERVIN KÄYTTÖSOPIMUS NRO 2015-S-1119 FORTUM POWER AND HEAT OY sekä FINEXTRA OY

TEHORESERVIN KÄYTTÖSOPIMUS NRO 2015-S-1119 FORTUM POWER AND HEAT OY sekä FINEXTRA OY TEHORESERVIN KÄYTTÖSOPIMUS NRO 2015-S-1119 FORTUM POWER AND HEAT OY sekä FINEXTRA OY 2(5) SOPIMUKSEN TARKOITUS Fortum Power and Heat Oy (Kuormanhaltija), y-tunnus: 0109160-2 ja Finextra Oy (Finextra),

Lisätiedot

MONIKANAVAJAKELUA KOSKEVA OLETTAMASÄÄNNÖSEHDOTUS - MONIKANAVAJAKELUA SELVITTÄVÄN TYÖRYHMÄN PUHEENJOHTAJAN ESITYS

MONIKANAVAJAKELUA KOSKEVA OLETTAMASÄÄNNÖSEHDOTUS - MONIKANAVAJAKELUA SELVITTÄVÄN TYÖRYHMÄN PUHEENJOHTAJAN ESITYS MONIKANAVAJAKELUA KOSKEVA OLETTAMASÄÄNNÖSEHDOTUS - MONIKANAVAJAKELUA SELVITTÄVÄN TYÖRYHMÄN PUHEENJOHTAJAN ESITYS 25.6.2008 Sakari Aalto 2 MONIKANAVAJAKELUA KOSKEVA OLETTAMASÄÄNNÖSEHDOTUS - MONIKANAVAJAKELUA

Lisätiedot

Riski = epävarmuuden vaikutus tavoitteisiin. Valtionhallinnossa = epävarmuuden vaikutus lakisääteisten tehtävien suorittamiseen ja tavoitteisiin

Riski = epävarmuuden vaikutus tavoitteisiin. Valtionhallinnossa = epävarmuuden vaikutus lakisääteisten tehtävien suorittamiseen ja tavoitteisiin Juha Pietarinen Riski = epävarmuuden vaikutus tavoitteisiin Valtionhallinnossa = epävarmuuden vaikutus lakisääteisten tehtävien suorittamiseen ja tavoitteisiin - Voiko riski olla mahdollisuus myös lakisääteisten

Lisätiedot

Henkivakuutussopimusten ehtojen muuttaminen vahinkokehityksen tai korkotason muutoksen johdosta

Henkivakuutussopimusten ehtojen muuttaminen vahinkokehityksen tai korkotason muutoksen johdosta Kannanotto 1/2013 1 (5) Henkivakuutussopimusten ehtojen muuttaminen vahinkokehityksen tai korkotason muutoksen johdosta 1 Yleistä 2 Säädöstausta Henkivakuutusyhtiöt solmivat asiakkaidensa kanssa pääsääntöisesti

Lisätiedot

.eu-verkkotunnusta koskevat WHOIS-toimintalinjat

.eu-verkkotunnusta koskevat WHOIS-toimintalinjat .eu-verkkotunnusta koskevat WHOIS-toimintalinjat 1/7 MÄÄRITELMÄT Käsitteet, jotka on määritelty asiakirjoissa Sopimusehdot ja/tai.euriidanratkaisusäännöt, on kirjoitettu isolla alkukirjaimella tässä asiakirjassa.

Lisätiedot

SOPIMUS RAKENNUKSEN NIMI LUOVUTTAMISESTA ADOPTOITAVAKSI

SOPIMUS RAKENNUKSEN NIMI LUOVUTTAMISESTA ADOPTOITAVAKSI Tampereen museot, Pirkanmaan maakuntamuseo Adoptoi monumentti toiminta 12.11.2015 / MH SOPIMUS RAKENNUKSEN NIMI LUOVUTTAMISESTA ADOPTOITAVAKSI 1. Sopimuksen tarkoitus ja osapuolien vastuut Tällä sopimuksella

Lisätiedot

Suomen avoimien tietojärjestelmien keskus COSS ry

Suomen avoimien tietojärjestelmien keskus COSS ry Viisaat hankinnat: Avoimuudet uusissa JIT 2015 -ehdoissa JulkICTLab-seminaari 20.11.2015 Martin von Willebrand, puheenjohtaja Avoin arkkitehtuuri Luo jäsenien menestystarinoita avoimilla ratkaisuilla Avoimet

Lisätiedot

Taiteilijan sopimus-, vero- ja vastuukysymyksistä julkisen taiteen tilausteoksissa

Taiteilijan sopimus-, vero- ja vastuukysymyksistä julkisen taiteen tilausteoksissa 27.2.2015 Taiteilijan sopimus-, vero- ja vastuukysymyksistä julkisen taiteen tilausteoksissa OTM Anne Vilppula Hyvä sopimus Selkeä Jättää mahdollisimman vähän tulkinnanvaraa Riittävän yksityiskohtainen

Lisätiedot

Perintäpalveluiden sopimusehdot (201404)

Perintäpalveluiden sopimusehdot (201404) 1(5) Perintäpalveluiden sopimusehdot (201404) 1. Sopimuksen tarkoitus Tällä sopimuksella sovitaan perintäpalveluista ja sitä koskevista toimenpiteistä. Sopimus toimii myös valtuutuksena perintäpalveluiden

Lisätiedot

Viranomaisen vahingonkorvausvastuu 5.11.2012 Anni Tuomela

Viranomaisen vahingonkorvausvastuu 5.11.2012 Anni Tuomela Julkisoikeus Valtiotieteellinen tiedekunta Viranomaisen vahingonkorvausvastuu 5.11.2012 Anni Tuomela Viranomaisen vahingonkorvausvastuu Viranomaisen vahingonkorvausvastuusta on erilliset säännökset vahingonkorvauslaissa

Lisätiedot

PALVELUKUVAUS järjestelmän nimi versio x.x

PALVELUKUVAUS järjestelmän nimi versio x.x JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen Liite 4 Palvelukuvaus -pohja Versio: 1.0 Julkaistu: 11.9.2009 Voimassaoloaika: Toistaiseksi PALVELUKUVAUS järjestelmän nimi versio

Lisätiedot

Liite 3. Puitesopimusmalli

Liite 3. Puitesopimusmalli PUITESOPIMUS 1. PUITESOPIMUSTOIMITTAJA Pankkiyhteys: Yhteyshenkilö: Yhteystiedot: 2. TILAAJA Oy Helsingin Asuntohankinta Ab Yhteyshenkilö: Yhteystiedot: Tukholmankatu 2, 3. kerros, 00250 Helsinki 3. SOPIMUKSEN

Lisätiedot

Turun yliopisto, oikeustieteellinen tiedekunta: Tutkimus paikallisesta sopimisesta

Turun yliopisto, oikeustieteellinen tiedekunta: Tutkimus paikallisesta sopimisesta 1.2.28 Turun yliopisto, oikeustieteellinen tiedekunta: Tutkimus paikallisesta sopimisesta Tutkimus Turun yliopiston työoikeuden tutkijaryhmä on professori Martti Kairisen johdolla selvittänyt vuosien 25

Lisätiedot

Hankinnan problematiikka

Hankinnan problematiikka Antti Kirmanen Hankinnan problematiikka Toimittajan näkökulma Asiakkaan näkökulma www.sulava.com www.facebook.com/sulavaoy 2 1. Ristiriita www.sulava.com www.facebook.com/sulavaoy 3 Asiakas haluaa Onnistuneen

Lisätiedot

SO 21 KILPAILULAINSÄÄDÄNNÖN HUOMIOON OTTAMINEN STANDARDOINNISSA

SO 21 KILPAILULAINSÄÄDÄNNÖN HUOMIOON OTTAMINEN STANDARDOINNISSA SISÄINEN OHJE SO 21 1 (5) SO 21 KILPAILULAINSÄÄDÄNNÖN HUOMIOON OTTAMINEN STANDARDOINNISSA Vahvistettu :n hallituksessa 2014-09-19 1 Toimintaohjeiden tarkoitus ja soveltaminen Näiden sisäisten toimintaohjeiden

Lisätiedot

Yrityksen sopimukset käytännössä Valinnainen kurssi

Yrityksen sopimukset käytännössä Valinnainen kurssi Yrityksen sopimukset käytännössä Valinnainen kurssi 1 Yrityksen sopimukset käytännössä, valinnainen kurssi Kuulustelu 22.4.2015 1. Yritys A valmisti lastinkäsittelyjärjestelmiä. Se oli kehittänyt lastinkäsittelyjärjestelmän,

Lisätiedot

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät Laatujärjestelmät Ohjelmistotekniikka kevät 2003 Prosessiajattelu Sisään Prosessi Ulos ohjaus mittaus Laatujärjestelmät Laatujärjestelmät määrittelevät sen, mitkä prosessit täytyy olla määritelty ei sitä,

Lisätiedot

Määräaikaiset työsuhteet. - hyviä käytäntöjä esimiehille ja luottamusmiehille

Määräaikaiset työsuhteet. - hyviä käytäntöjä esimiehille ja luottamusmiehille Määräaikaiset työsuhteet - hyviä käytäntöjä esimiehille ja luottamusmiehille 1 2 Määräaikaiset työsuhteet - hyviä käytäntöjä esimiehille ja luottamusmiehille Uuden yliopistolain (558/2009) voimaantulon

Lisätiedot

SOPIMUS TILOJEN VUOKRAUKSESSA NOUDATETTAVISTA YLEISISTÄ PERIAATTEISTA. 1.4 Kauniaisten kaupunki Kauniaistentie 10, 02700 Kauniainen

SOPIMUS TILOJEN VUOKRAUKSESSA NOUDATETTAVISTA YLEISISTÄ PERIAATTEISTA. 1.4 Kauniaisten kaupunki Kauniaistentie 10, 02700 Kauniainen SOPIMUS TILOJEN VUOKRAUKSESSA NOUDATETTAVISTA YLEISISTÄ PERIAATTEISTA 1 Osapuolet 1.1 Helsingin kaupunki PL 1, 00099 Helsingin kaupunki 1.2 Espoon kaupunki PL 5, 02771 Espoo 1.3 Vantaan kaupunki Asematie

Lisätiedot

Plus500CY Ltd. Eturistiriitoja koskevat toimintaperiaatteet

Plus500CY Ltd. Eturistiriitoja koskevat toimintaperiaatteet Plus500CY Ltd. Eturistiriitoja koskevat toimintaperiaatteet Eturistiriitoja koskevat toimintaperiaatteet 1. Johdanto 1.1. Tässä eturistiriitoja koskevassa käytännössä määritetään, kuinka Plus500CY Ltd.

Lisätiedot

Linnala Setlementti ry (Linnala)

Linnala Setlementti ry (Linnala) 1 LUONNOS 6.8.2015 SOPIMUS HENKILÖSTÖPALVELUN MYYNNISTÄ 1. Sopijapuolet Savonlinnan kaupunki (kaupunki) yhteys/vastuuhenkilö Linnala Setlementti ry (Linnala) 2. Sopimuksen tarkoitus Tässä sopimuksessa

Lisätiedot

MÄRKÄTILAKORJAUKSET 27.3. 2013. Kiinteistöliitto Pohjois-Suomi

MÄRKÄTILAKORJAUKSET 27.3. 2013. Kiinteistöliitto Pohjois-Suomi MÄRKÄTILAKORJAUKSET 27.3. 2013 Kiinteistöliitto Pohjois-Suomi Osakkeenomistajan remontit Kunnossapito- tai muutostyö Kunnossapitotyöt: Yhtiön kunnossapitoa on kiinteistön ylläpitoon kuuluva toiminta, joka

Lisätiedot

TeliaSonera CA Asiakkaan vastuut ja velvollisuudet (Subscriber Agreement)

TeliaSonera CA Asiakkaan vastuut ja velvollisuudet (Subscriber Agreement) TeliaSonera CA Asiakkaan vastuut v. 2.0 TeliaSonera CA Asiakkaan vastuut ja velvollisuudet (Subscriber Agreement) Luottavan osapuolen velvollisuudet Varmenteen hakijan ja haltijan velvollisuudet Rekisteröijän

Lisätiedot

PROJEKTIN LOPPURAPORTTI

PROJEKTIN LOPPURAPORTTI TURUN LOPPURAPORTTI AMMATTIKORKEAKOULU Hyvinvointipalvelut Usability of Shopping Centers -projekti 20.12.2008 1 (3) PROJEKTIN LOPPURAPORTTI Usability of Shopping Centers Hyvinvointipalvelut 20.12.2008

Lisätiedot

KUNTOUTTAVAN TYÖTOIMINNAN TUOTTAMISTA KOSKEVA SOPIMUS

KUNTOUTTAVAN TYÖTOIMINNAN TUOTTAMISTA KOSKEVA SOPIMUS KEURUUN KAUPUNKI KUNTOUTTAVAN TYÖTOIMINNAN TUOTTAMISTA KOSKEVA SOPIMUS 1. Osapuolet 1..1Keuruun kaupunki (jäljempänä Kaupunki ) Perusturva / työllisyyspalvelut työllisyyspäällikkö Erja Koivula Multiantie

Lisätiedot

Hostingpalvelujen. oikeudelliset kysymykset. Viestintäviraston Abuse-seminaari 2012. Jaakko Lindgren

Hostingpalvelujen. oikeudelliset kysymykset. Viestintäviraston Abuse-seminaari 2012. Jaakko Lindgren Hostingpalvelujen oikeudelliset kysymykset Viestintäviraston Abuse-seminaari 2012 Jaakko Lindgren Legal Counsel Tieto, Legal jaakko.lindgren@tieto.com Esittely Jaakko Lindgren Legal Counsel, Tieto Oyj

Lisätiedot

INTUSIN TALLETUSTILIEN SOPIMUSEHDOT

INTUSIN TALLETUSTILIEN SOPIMUSEHDOT INTUSIN TALLETUSTILIEN SOPIMUSEHDOT 1. SOPIMUKSEN SISÄLTÖ Määräaikaistalletus on sopimuksessa määriteltyjen ehtojen mukaisesti avattu talletustili. Yhdistys maksaa talletustilille korkoa talletusajan päättyessä,

Lisätiedot

Siilinjärven kunta ja Valtion IT-palvelukeskus

Siilinjärven kunta ja Valtion IT-palvelukeskus Valtiokonttori Palvelusopimus 1 (6) Valtion IT-palvelukeskus 354/23/2009..20 PALVELUSOPIMUS Asiointitili-palvelusta Siilinjärven kunta ja Valtion IT-palvelukeskus Siltasaarenkatu 18 20 A, Helsinki PL 14,

Lisätiedot

PCM-projektiajattelu. Projektipalvelut Tutkimus- ja kehityskeskus

PCM-projektiajattelu. Projektipalvelut Tutkimus- ja kehityskeskus PCM-projektiajattelu PCM = Project Cycle Management / Projektisyklin johtaminen Projekti ja projektoituminen on tullut mukaan osana organisaatioiden toimintastrategiaa enenevässä määrin osoittaen toiminnallisena

Lisätiedot

Punkalaitumen kunta ja. Valtion tieto- ja viestintätekniikkakeskus. Valtori

Punkalaitumen kunta ja. Valtion tieto- ja viestintätekniikkakeskus. Valtori Palvelusopimus 1 / 6 PALVELUSOPIMUS Asiointitili-palvelusta Punkalaitumen kunta ja Valtion tieto- ja viestintätekniikkakeskus Valtori Valtion tieto- ja viestintätekniikkakeskus www.valtori.fi VALTORI Palvelusopimus

Lisätiedot

KIINTEISTÖNHOIDON JA ISÄNNÖINNIN YLEISET SOPIMUSEHDOT 2000

KIINTEISTÖNHOIDON JA ISÄNNÖINNIN YLEISET SOPIMUSEHDOT 2000 KH&I-YSE 2000 26.1.2000 1(6) KIINTEISTÖNHOIDON JA ISÄNNÖINNIN YLEISET SOPIMUSEHDOT 2000 1 Soveltamisala Yleisiä sopimusehtoja sovelletaan kiinteistönhoidossa ja kiinteistöjen isännöinnissä toimeksisaajan

Lisätiedot

Käyttöehdot, videokoulutukset

Käyttöehdot, videokoulutukset Käyttöehdot, videokoulutukset Edita Publishing Oy PL 700, 00043 NORDIC MORNING www.editapublishing.fi Asiakaspalvelu www.edilexpro.fi edilexpro@edita.fi puh. 020 450 2040 (arkisin klo 9 16) 1 Yleistä Tämä

Lisätiedot

Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista. Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015

Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista. Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015 Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015 Sisältö Mistä tietoja koottu? Opit Yhteenveto Mistä tietoja koottu? Nämä tiedot on kerätty

Lisätiedot

PROJEKTIAVUSTUKSEN (C) TOIMINTASELOSTELOMAKKEEN RAY3707 TÄYTTÖOHJE. Yleistä... 1

PROJEKTIAVUSTUKSEN (C) TOIMINTASELOSTELOMAKKEEN RAY3707 TÄYTTÖOHJE. Yleistä... 1 OHJE 1 (5) PROJEKTIAVUSTUKSEN (C) TOIMINTASELOSTELOMAKKEEN RAY3707 TÄYTTÖOHJE Yleistä... 1 1 Projektin perustiedot... 1 2 Projektin toteutus ja eteneminen... 2 3 Projektin seuranta ja arviointi... 3 4

Lisätiedot

Avoin lähdekoodi (Open Source) liiketoiminnassa

Avoin lähdekoodi (Open Source) liiketoiminnassa Avoin lähdekoodi (Open Source) liiketoiminnassa Mikko Amper 12.11.2013 Mitä aloittavan BioICT-yrityksen tulisi tietää IPR:istä, niiden hallinnasta ja patentoinnista? Tässä esityksessä ilmaistut mielipiteet

Lisätiedot

Minna Borg. 2014 Prosenttitaide OTM Janita Korva

Minna Borg. 2014 Prosenttitaide OTM Janita Korva Minna Borg 2014 Prosenttitaide OTM Janita Korva Sopimus mikä ja miksi? Tarjous-vastausmekanismilla syntyvä tahdonilmaus Keino kirjata ylös osapuolten yhteinen tahto ja vastuunjako Keino ennaltaehkäistä

Lisätiedot

Liite verkkopalveluehtoihin koskien sähköntuotannon verkkopalvelua Tvpe 11. Voimassa 1.7.2011 alkaen

Liite verkkopalveluehtoihin koskien sähköntuotannon verkkopalvelua Tvpe 11. Voimassa 1.7.2011 alkaen Liite verkkopalveluehtoihin koskien sähköntuotannon verkkopalvelua Tvpe 11 Voimassa 1.7.2011 alkaen Energiateollisuus ry:n suosittelema LIITE VERKKOPALVELUEHTOIHIN KOSKIEN SÄHKÖNTUOTANNON VERKKOPALVELUA

Lisätiedot

Milloin on syytä ryhtyä selvittämään sisäilman laatua?

Milloin on syytä ryhtyä selvittämään sisäilman laatua? Milloin on syytä ryhtyä selvittämään sisäilman laatua? 1. AsOy vastaa siitä, että huoneistot soveltuvat käyttötarkoitukseensa. 2. Osakkaan, vuokralaisen tai muun huoneiston haltijan ilmoitus heikosta sisäilman

Lisätiedot

Vaihtoehtoinen riidanratkaisu. OKM:n keskustelutilaisuus 10.10.2014 Katri Olmo

Vaihtoehtoinen riidanratkaisu. OKM:n keskustelutilaisuus 10.10.2014 Katri Olmo Vaihtoehtoinen riidanratkaisu OKM:n keskustelutilaisuus 10.10.2014 Katri Olmo Muuttuva tuomioistuinkulttuuri Taustaa: - Siviilijuttujen määrä käräjäoikeuksisissa ja ylemmissä tuomioistuimissa laskee -

Lisätiedot

Testaajan eettiset periaatteet

Testaajan eettiset periaatteet Testaajan eettiset periaatteet Eettiset periaatteet ovat nousseet esille monien ammattiryhmien toiminnan yhteydessä. Tämä kalvosarja esittelee 2010-luvun testaajan työssä sovellettavia eettisiä periaatteita.

Lisätiedot

BUSINESS BREAKFAST Tarvitaanko sopimuksia?

BUSINESS BREAKFAST Tarvitaanko sopimuksia? BUSINESS BREAKFAST Tarvitaanko sopimuksia? Oulu, 4.10.2013 OTK, VT Anu Kangasniemi Agenda Sopimusten hyödyistä ja sudenkuopista Riskienhallinnasta Osakassopimus - tiekartta vai pahan päivän vara? 1 Kirjallisen

Lisätiedot

Esimiehen opas erityisesti vuorotyötä tekevissä yksiköissä

Esimiehen opas erityisesti vuorotyötä tekevissä yksiköissä Työhyvinvointikyselyn tulosten käsittely ja hyvinvointisuunnitelman laatiminen työyksikön hyvinvointipajassa Esimiehen opas erityisesti vuorotyötä tekevissä yksiköissä Lapin sairaanhoitopiirin työhyvinvointisyke

Lisätiedot

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

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma 12.11.2007 Janne J. Korhonen 12.11.2007 Agenda 1. Prosessit ja palvelut, BPM ja SOA 2. BPM-projekteista yleensä 3. Prosessin elinkaarimalli 4. Kokemuksia

Lisätiedot

ASIAKASSOPIMUS. Näyttelijöiden Tekijänoikeusjärjestö -Skådespelarnas Upphövsrättsorganisation FILMEX, myöh. Filmex ja

ASIAKASSOPIMUS. Näyttelijöiden Tekijänoikeusjärjestö -Skådespelarnas Upphövsrättsorganisation FILMEX, myöh. Filmex ja ASIAKASSOPIMUS Näyttelijöiden Tekijänoikeusjärjestö -Skådespelarnas Upphövsrättsorganisation FILMEX, myöh. Filmex ja VIRALLINEN NIMI JA HENKILÖTUNNUS (MYÖS TAITEILIJANIMI, JOS KÄYTÄT SITÄ) myöh. Näyttelijä

Lisätiedot

Taiteilijan sopimus-, vastuu- ja verokysymykset

Taiteilijan sopimus-, vastuu- ja verokysymykset Taiteilijan sopimus-, vastuu- ja verokysymykset Anna Nousiainen Lakimies Suomen Taiteilijaseura Kuinka elää kuvataiteella -hanke Julkisen taiteen tilaustyössä ja muutoinkin toimittaessa taloudellisen vaihdannan

Lisätiedot

OSAKEKAUPPAKIRJA. Lappeenrannan kaupungin. Lappeenrannan Asuntopalvelu Oy:n. välillä. (jäljempänä Kauppakirja )

OSAKEKAUPPAKIRJA. Lappeenrannan kaupungin. Lappeenrannan Asuntopalvelu Oy:n. välillä. (jäljempänä Kauppakirja ) OSAKEKAUPPAKIRJA Lappeenrannan kaupungin ja Lappeenrannan Asuntopalvelu Oy:n välillä (jäljempänä Kauppakirja ) 1. Kaupan osapuolet 1.1 Lappeenrannan Asuntopalvelu Oy (y-tunnus 0433221-3), Valtakatu 44,

Lisätiedot

Aineiston luovuttaminen tilaajalle KSE13 Tietomallit ja sähköinen aineisto. Matti Kiiskinen 12.2.2014/Telu-koulutus

Aineiston luovuttaminen tilaajalle KSE13 Tietomallit ja sähköinen aineisto. Matti Kiiskinen 12.2.2014/Telu-koulutus Aineiston luovuttaminen tilaajalle KSE13 Tietomallit ja sähköinen aineisto Matti Kiiskinen 12.2.2014/Telu-koulutus KSE 2013, keskeiset muutokset liittyen konsulttityön luovutukseen Asiakirjat -> Aineisto

Lisätiedot

KIRJASTOAUTON KORITYÖN HANKINTA

KIRJASTOAUTON KORITYÖN HANKINTA KIRJASTOAUTON KORITYÖN HANKINTA Inarin kunta pyytää tarjoustanne kirjastoauton korityöstä tämän tarjouspyynnön ja sen liitteiden mukaisesti. Kirjastoauto hankitaan Inarin kunnankirjaston käyttöön (www.inari.fi/kirjasto).

Lisätiedot

Nettikasvattajan. käsikirja

Nettikasvattajan. käsikirja Nettikasvattajan käsikirja 5+1 ohjetta kasvattajalle 1 Ole positiivinen. Osallistu lapsen nettiarkeen kuten harrastuksiin tai koulukuulumisiin. Kuuntele, keskustele, opi! Pelastakaa Lapset ry:n nettiturvallisuustyön

Lisätiedot

Ympäristöasioiden sovittelu

Ympäristöasioiden sovittelu Ympäristöasioiden sovittelu Suomen sovittelufoorumin päämääränä on saattaa sovittelu ratkaisumenetelmäksi konfliktien ja ihmissuhdeongelmien käsittelyssä. SSF / T. Brunila / 2008 1 Sovittelijan rooli Sovittelija

Lisätiedot

Opas koulujen VALO-hankintaan. Elias Aarnio Avoimet verkostot oppimiseen -hanke Educoss Innopark Oy

Opas koulujen VALO-hankintaan. Elias Aarnio Avoimet verkostot oppimiseen -hanke Educoss Innopark Oy Opas koulujen VALO-hankintaan Elias Aarnio Avoimet verkostot oppimiseen -hanke Educoss Innopark Oy Mikä ihmeen VALO? VALO = vapaat ja avoimen lähdekoodin ohjelmistot Kyse on siis Open Sourcesta eli vapaista

Lisätiedot

JIK-peruspalveluliikelaitoskuntayhtymä (jäljempänä Tilaaja ) Könnintie 27 B, 60800 ILMAJOKI. Hankinta- ja taloussuunnittelija, p.

JIK-peruspalveluliikelaitoskuntayhtymä (jäljempänä Tilaaja ) Könnintie 27 B, 60800 ILMAJOKI. Hankinta- ja taloussuunnittelija, p. LIITE 2 SOPIMUS SOPIMUS HAMMASLÄÄKÄRITYÖVOIMAN VUOKRAAMISESTA VIIKONLOPPU- JA ARKIPYHÄILTOIHIN 1. OSAPUOLET JA YHTEYSHENKILÖT Tilaaja: JIK-peruspalveluliikelaitoskuntayhtymä (jäljempänä Tilaaja ) Könnintie

Lisätiedot

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta

Lisätiedot

YHDEN YLITYÖN KÄSITTEESTÄ PAIKALLISESTI SOVITTAESSA HUOMIOON OTETTAVIA ASIOITA

YHDEN YLITYÖN KÄSITTEESTÄ PAIKALLISESTI SOVITTAESSA HUOMIOON OTETTAVIA ASIOITA 1 YHDEN YLITYÖN KÄSITTEESTÄ PAIKALLISESTI SOVITTAESSA HUOMIOON OTETTAVIA ASIOITA Mitä yksi ylityö -käsite tarkoittaa? Työehtosopimuksen kohtaan 20.6 on kirjattu ns. yhden ylityön käsitteen malli, josta

Lisätiedot

Skanskan vakiosopimusehdot materiaalihankinnassa

Skanskan vakiosopimusehdot materiaalihankinnassa Skanskan vakiosopimusehdot materiaalihankinnassa 1.9.2015 SISÄLLYSLUETTELO 1. SOPIMUSASIAKIRJAT... 2 1.1 Ehtojen tulkinta... 2 1.2 Tarjous... 2 1.3 Sopimusasiakirjojen pätevyysjärjestys... 2 2. MYYJÄN

Lisätiedot

xxxxxxx (jäljempänä Palveluntuottaja) Osoite: xxxxxxxxxxxx y-tunnus Nimi,osoite, y-tunnus, tehtävä Nimi, osoite, y-tunnus, tehtävä

xxxxxxx (jäljempänä Palveluntuottaja) Osoite: xxxxxxxxxxxx y-tunnus Nimi,osoite, y-tunnus, tehtävä Nimi, osoite, y-tunnus, tehtävä 1 SOPIMUSLUONNOS, AULAPALVELUT 1.1. Sopijapuolet Helsingin kaupunki (jäljempänä Tilaaja) Ympäristökeskus PL 500, 00099 HELSINGIN KAUPUNKI Käyntiosoite: Viikinkaari 2 a, 00790 Helsinki Y-tunnus: 0201256-6

Lisätiedot

Isännöintisopimus kuinka sopia ja pitää sopimus ajan tasalla

Isännöintisopimus kuinka sopia ja pitää sopimus ajan tasalla Isännöintisopimus kuinka sopia ja pitää sopimus ajan tasalla Hallitusseminaari 2011 Anu Kärkkäinen päälakimies Suomen Kiinteistöliitto ry ISÄNNÖITSIJÄN VALINTA Milloin taloyhtiössä on oltava isännöitsijä?

Lisätiedot

Kehitys- ja urakeskustelu urakehitysmahdollisuuksien ja uudelleensijoittumisen edistäjänä

Kehitys- ja urakeskustelu urakehitysmahdollisuuksien ja uudelleensijoittumisen edistäjänä 1 Kehitys- ja urakeskustelu urakehitysmahdollisuuksien ja uudelleensijoittumisen edistäjänä Miten tuloksellisia keskusteluja työurasta käydään? Mistä hyvä työurakeskustelu koostuu? Miksi urakehitysmahdollisuuksista

Lisätiedot

Raahen kaupunki Projektiohjeet luonnos 30.11.2004

Raahen kaupunki Projektiohjeet luonnos 30.11.2004 Raahen kaupunki Projektiohjeet luonnos 30.11.2004 Vastine Kari Pietilän SDP:n valtuustoryhmän aloitteeseen Raahen kaupungin projektiohjeista (KV 25.2.2004) Pertti Malkki (FT, YTM) Kehittämiskonsultti pertti.malkki@yritystaito.fi

Lisätiedot

AEO-Toimijapäivä. Toimitusketjujen uhkien analysointi ja riskienhallinta yhteistyössä sopimuskumppanien kanssa 12.3.2013.

AEO-Toimijapäivä. Toimitusketjujen uhkien analysointi ja riskienhallinta yhteistyössä sopimuskumppanien kanssa 12.3.2013. AEO-Toimijapäivä Toimitusketjujen uhkien analysointi ja riskienhallinta yhteistyössä sopimuskumppanien kanssa 12.3.2013 Sami Hyytiäinen Johdanto Turvallisuus ja vaarattomuus toimitusketjussa Kuljetusketjun

Lisätiedot

Reilun Pelin työkalupakki: Kiireen vähentäminen

Reilun Pelin työkalupakki: Kiireen vähentäminen Reilun Pelin työkalupakki: Kiireen vähentäminen Tavoitteet Tämän toimintamallin avulla opit määrittelemään kiireen. Työyhteisösi oppii tunnistamaan toistuvan, kuormittavan kiireen sekä etsimään sen syitä

Lisätiedot

Mittaaminen projektipäällikön ja prosessinkehittäjän työkaluna

Mittaaminen projektipäällikön ja prosessinkehittäjän työkaluna Mittaaminen projektipäällikön ja prosessinkehittäjän työkaluna Finesse-seminaari 22.03.00 Matias Vierimaa 1 Mittauksen lähtökohdat Mittauksen tulee palvella sekä organisaatiota että projekteja Organisaatiotasolla

Lisätiedot

Luottamusmies, luottamusvaltuutettu ja Suomen perustuslain 13 :n turvaama yhdistymisvapaus

Luottamusmies, luottamusvaltuutettu ja Suomen perustuslain 13 :n turvaama yhdistymisvapaus TAUSTAMUISTIO 1 1 (5) 26.4.2016 Luottamusmies, luottamusvaltuutettu ja Suomen perustuslain 13 :n turvaama yhdistymisvapaus Työntekijöiden edustuksen nykytila Luottamusmies ja luottamusvaltuutettu Luottamusmiehen

Lisätiedot