Mitä on muutostenhallinta järjestelmäkehityksessä oikeudellisesta näkökulmasta?

Järjestelmäkehitysprojekteissa käyttäjien alun perin selittämät asiat muuttuvat usein työn edetessä. Tästä syystä myös työn suorittajana toimivan palveluntarjoajan on joskus tarpeen suostua muuttamaan jo solmittua sopimusta.

Tässä artikkelissa käsitellään, kuinka juridisesta näkökulmasta tulisi suhtautua “muutoksiin”, jotka tapahtuvat jälkikäteen, kun järjestelmäkehitysprojekti ei etene suunnitellusti.

Miksi järjestelmäkehitysprojekteja muutetaan jälkikäteen?

Järjestelmäkehitys on toimittajan ja käyttäjän yhteistyötä

Järjestelmäkehitys yleensä alkaa suunnittelu- ja ehdotusvaiheella, minkä jälkeen kehityksen vaatimukset määritellään ja sopimus tehdään. Sopimuksen tekemisen jälkeen prosessi etenee erilaisten suunnitteluvaiheiden kautta, jossa suunnitelman mukainen toteutus tehdään, ja päättyy lopulliseen testaukseen. Koko prosessissa toimittaja, joka ottaa työn vastaan, kantaa laajasti vastuuta järjestelmäkehityksen asiantuntijana, mutta myös käyttäjältä odotetaan tiettyä yhteistyövelvollisuutta. Erityisesti prosesseissa, kuten järjestelmän vaatimusten määrittely (eli vaatimusten määrittely), käyttöliittymän ulkonäkö ja käyttökokemus (eli perussuunnittelu) sekä vaatimusten mukaisen tuotteen tarkistaminen (eli testaus tai hyväksyntä), käyttäjän yhteistyö on tärkeää. Yleinen selitys käyttäjän velvollisuuksista järjestelmäkehityksessä on käsitelty yksityiskohtaisesti seuraavassa artikkelissa.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Yhteistyövelvollisuus on olemassa, mutta käyttäjät pyytävät usein muutoksia

Kuitenkaan järjestelmäkehityksen asiantuntija ei ole aina käyttäjä, joka pystyy aina suunnitelmallisesti ja kattavasti välittämään tarvittavat tiedot toimittajalle. Todellisuudessa, koska kyseessä on yksityiskohtainen ja tarkka työ, käyttäjä ei usein pysty ennustamaan, millaiset seikat voivat olla ratkaisevia myöhemmissä vaiheissa. Ironista kyllä, mitä tärkeämpi tosiasia on, sitä todennäköisemmin se tulee esiin pienissä paloissa myöhemmin. Tästä syystä todellisissa projekteissa, vaikka ihanteellista olisi “läpivienti ylävirrasta alavirtaan”, on oletettavaa, että jälkikäteen tehdään erilaisia muutoksia. Tästä syystä “muutosten hallinta” ja sen toteuttaminen on tärkeää.

Mikä on muutosjohtamisen dokumentti?

Milloin muutosjohtamisasiakirjaa käytetään

Muutosjohtamisasiakirja on asiakirja, jota käyttäjät käyttävät pyytäessään toimittajalta muutoksia tai lisäominaisuuksia aiemmin annettuihin selityksiin. Kuten aiemmin mainittiin, käyttäjillä on velvollisuus tehdä yhteistyötä toimittajan kanssa vaatimusten määrittely- ja perussuunnitteluvaiheissa, mutta on mahdollista, että he esittävät erilaisia vaatimuksia myöhemmissä vaiheissa.

Esimerkkejä tilanteista, joissa muutosjohtamisasiakirja on tarpeen, ovat esimerkiksi:

• Vaatimusten määrittely- tai perussuunnitteluvaiheessa on jäänyt jotain huomioimatta, ja lisäominaisuuksia pyydetään jälkikäteen
• Kehityksen aikana liiketoiminnan suuntaa tarkistetaan, ja tarvitaan muutoksia eritelmiin

Nämä ovat vain muutamia esimerkkejä.

Lisäksi, kun puhutaan lisäominaisuuksista ja eritelmien muutoksista, työn vastaanottajalle tärkein kysymys on, sallitaanko lakisääteisesti tarjoushinnan muutos. Tätä aihetta käsitellään yksityiskohtaisesti toisessa artikkelissa.

https://monolith.law/corporate/increase-of-estimate[ja]

Muutosjohtamisasiakirja on perusta, joka auttaa arvioimaan tarjouksen sisällön oikeudenmukaisuutta, kun tarjoushinta korotetaan jälkikäteen. Muutosjohtamisasiakirjan laatiminen on tärkeää, jotta ei synny erimielisyyksiä laskutettaessa korotettua tarjoushintaa myöhemmin ja jotta omat argumentit ovat vakuuttavia, jos erimielisyyksiä ilmenee.

Muutosjohtamisasiakirjan sisältö

Mitä asioita tulisi lain mukaan sisällyttää muutosjohtamisasiakirjaan? Muutosjohtamisasiakirjan käyttö, joka vastaa eritelmien muutoksiin ja toimintojen lisäyksiin, on jo yleisesti tunnustettu. Siksi, tarkistamalla viranomaisten, kuten talousministeriön mallisopimuksen, sopimusehtojen malleja, voimme ymmärtää, mitä asioita tulisi säilyttää kirjallisesti.

(Muutosjohtamisprosessi)
37 § Jos A tai B saa muutosehdotuksen 34 §:n (järjestelmän eritelmien muutos), 35 §:n (käyttäjän hyväksyntä väliaineille) tai 36 §:n (epävarmojen asioiden käsittely) perusteella, heidän tulee antaa toiselle osapuolelle kirjallinen asiakirja, jossa on seuraavat tiedot (jäljempänä “muutosjohtamisasiakirja“) ○ päivän kuluessa vastaanottopäivästä, ja A ja B neuvottelevat muutoksen hyväksymisestä 12 §:n mukaisessa yhteydenottoneuvottelukunnassa.
① Muutoksen nimi
② Ehdotuksen vastuuhenkilö
③ Päivämäärä
④ Muutoksen syy
⑤ Muutoksen yksityiskohtaiset tiedot, mukaan lukien eritelmät
⑥ Jos muutos vaatii kustannuksia, niiden määrä
⑦ Muutostyön aikataulu, mukaan lukien harkinta-aika
⑧ Muun muassa muutoksen vaikutus tämän sopimuksen ja erityissopimuksen ehtoihin (työaika tai toimitusaika, palkkio, sopimusehdot jne.)

Lisäselityksiä ei tarvita, jos luet suoraan pykälän ja tarkistat suositellut kirjaukset. Tärkeää on, että muutosten kulku kirjataan yksityiskohtaisesti ja konkreettisesti, jotta myöhemmin ei synny “sanoin – en sanonut” -tilanteita.

Kun nämä tiedot on kirjattu selkeästi ja ne on yhdistetty toimittajan ja käyttäjän vastuuhenkilöiden tai päätöksentekijöiden allekirjoituksiin tai leimoihin, niillä on sama merkitys kuin sopimusasiakirjoilla, vaikka jouduttaisiin oikeudenkäyntiin.

Mitä sinun tulisi tietää muutosjohtamisesta

Muutosjohtaminen tulisi yleensä suorittaa yhdessä tehtävienhallinnan kanssa

Muutosjohtamisasiakirjan luomisen tarkoituksena on ohjata projekti kohti sen saavuttamista (tai välttää epäoikeudenmukainen vastuunpakoilu, jos sitä ei saavuteta) hallitsemalla muutoshistoriaa. Käytännössä muutosjohtamisasiakirjan luominen tapahtuu usein yhdessä tehtävienhallintaluettelon luomisen ja päivittämisen kanssa. Toisin sanoen, kun muutoshistoria on hallittu muutosjohtamistaulukossa, sovitut muutoskohdat otetaan huomioon tulevina tehtävinä tehtävienhallintaluettelossa.

On parempi määritellä myös muutosneuvottelujen suorittamistapa

Paitsi muutosjohtamisen tapa, myös muutosneuvottelujen suorittamistapa olisi hyvä määritellä, jotta muutosten käsittely sujuisi odotusten mukaisesti. Tämä on erityisen tärkeää, kun käytetään kehitysmenetelmiä, kuten ketterää kehitystä, jossa oletetaan, että muutoksia tehdään jälkikäteen. Käytännössä on monia esimerkkejä, joissa määritellään, kuinka kauan vastapuolen tulisi vastata muutosjohtamisneuvottelupyyntöön.

Muutosneuvottelut ja vilpittömän mielen velvollisuus

Kun molemmat osapuolet ovat kerran sopineet sopimuksesta ja haluavat muuttaa sitä jälkikäteen, se on käytännössä uuden sopimuksen solmimista. Koska sopimus perustuu osapuolten vapaaseen tahtoon, periaatteessa toimittajalla ei ole velvollisuutta suostua muutossopimukseen. Kuitenkin, jos oikeuksia korostetaan liikaa, on olemassa riski, että järjestelmänkehitysprojekti ei suju sujuvasti.

Siksi käytännössä sopimuksissa mainitaan usein “velvollisuus neuvotella vilpittömästi muutoksista”, ja jos toimittaja ei suostu vilpittömästi muutoksiin, sopimuksessa voidaan mainita, että vahingonkorvausta voidaan vaatia.

Esimerkkinä mainittakoon seuraava lause (seuraavassa on esimerkki pykälästä, lainattu Japanin tietojenkäsittelyn edistämislaitoksen (IPA) virallisesti laatimasta “ff Basic/Individual Contract Model Basic Contract Proposal”).

Artikla 4, kohta 3: Muutosneuvotteluissa tarkastellaan muutoksen kohdetta, muutoksen mahdollisuutta, muutoksen vaikutusta hintaan ja toimitusaikaan, ja molemmat osapuolet neuvottelevat vilpittömästi siitä, tehdäänkö muutos.

Muutoksen toteuttamista koskevat määräykset

Kuten aiemmin mainittiin, on “turvallisempaa” järjestää muutosneuvottelut joka kerta, kun muutos tehdään. Kuitenkin pienemmissä projekteissa ei ehkä tarvitse määritellä muutosneuvottelujen suorittamistapaa. Tällöin voit harkita, että muutokset tehdään vasta, kun käyttäjän ja toimittajan vastuuhenkilöt ovat allekirjoittaneet ja leimanneet muutosjohtamisasiakirjan, vaikka neuvotteluja ei olisi. Jos muutokset voidaan tehdä helposti vain suullisella sopimuksella, on epäselvää, onko muutoksia tehty, mikä voi johtaa suuriin ongelmiin myöhemmin. Tässä mielessä dokumentinhallinta on ehdottomasti toteutettava.

Toisaalta, jos jokaisen muutoksen dokumentointi on liian raskasta ja haluat painottaa joustavuutta, voit harkita muutosten dokumentointia kokouspöytäkirjoissa. Tämä on yksi vaihtoehto. Järjestelmänkehityksen kokouspöytäkirjojen säilyttämistavasta on yksityiskohtainen selostus seuraavassa artikkelissa.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Yhteenveto

On totta, että työpaikoilla, joissa vaatimukset muuttuvat usein, ongelmien ja erimielisyyksien riski on suuri. Kuitenkin, näissä tilanteissa, joissa tarvitaan joustavuutta, on usein vaikeaa toteuttaa käytännön toimenpiteitä vain korostamalla “hallinnon tärkeyttä”.

Kysymys siitä, miten yhdistää liiketoiminnan nopeus ja varautuminen mahdollisiin ongelmiin, riippuu usein yrityksen tilanteesta ja projektin sisällöstä. Vaikka ottaisimme huomioon tämän artikkelin sisällön, on tärkeää, että jokainen yritys ja projekti etsii omaa parasta tapaansa toimia.