Mikä on johtamistavoitteiden ja numeeristen tavoitteiden oikeudellinen merkitys järjestelmäkehitysprojekteissa?

Järjestelmäkehitysprojektit ovat usein tiiviisti yhteydessä yritysten ja työpaikkojen laajamittaisiin liiketoiminnan parannuksiin. Niissä saatetaan vaatia asennetta, joka edistää käyttäjäyrityksen liikkeenjohdollisten ongelmien ratkaisemista tai numeeristen tavoitteiden saavuttamista. Mutta onko sitoutuminen tällaisiin liikkeenjohdollisiin tavoitteisiin todella oikeudellinen velvollisuus? Kysymys tulee olemaan, mikä on numeeristen tavoitteiden ja liikkeenjohdollisten tavoitteiden oikeudellinen merkitys. Tässä artikkelissa käsitellään oikeudellisia kysymyksiä, jotka liittyvät erilaisiin “tarkoituksiin” ja “tavoitteisiin” järjestelmäkehityksessä.

Miksi järjestelmäkehityksen tavoitteet ja päämäärät aiheuttavat konflikteja?

Haasteet sijoittuvat käyttäjän yhteistyövelvollisuuden ja toimittajan harkintavallan väliin

Kaupankäynnin näkökulmasta katsottuna järjestelmäkehitysprojekteilla on useita erityispiirteitä. Yksi niistä on, että järjestelmäkehitysprojekti toimittajan toimesta ei ole mahdollista ilman käyttäjän puolelta tulevaa yhteistyötä. Tämä velvollisuus on olemassa ja se on selkeästi määritelty oikeuskäytännössä nimellä “yhteistyövelvollisuus”. Pääasiassa käyttäjän odotetaan osallistuvan järjestelmäkehitykseen seuraavissa vaiheissa: ① vaatimusten määrittely ② perussuunnittelu ③ tuotosten hyväksyntä.

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

Toinen erityispiirre on, että toimittajalta odotetaan yleensä suurta harkintavaltaa ja aktiivista osallistumista työhön. Tätä toimittajan roolia järjestelmäkehitysprojektissa kutsutaan oikeudellisella termillä “projektinhallintavelvollisuus”. Tästä aiheesta on lisätietoa seuraavassa artikkelissa.

https://monolith.law/corporate/project-management-duties[ja]

Yhteenvetona voidaan todeta, että tässä yhteydessä on kaksi tärkeää seikkaa:

• Käyttäjän odotetaan tarjoavan toimittajalle tarvittavat tiedot ja osallistuvan aktiivisesti toimittajan kehitystyöhön.
• Toimittajan odotetaan ymmärtävän käyttäjän projektin tavoitteet ja päämäärät ja toimivan niiden mukaisesti.

Näiden kahden seikan vuoksi ongelmana on, kuinka pitkälle toimittajan velvollisuus ulottuu saavuttamaan käyttäjän ennalta määritellyt liiketoiminnalliset ja numeeriset tavoitteet. Toisin sanoen, käyttäjän velvollisuus on määritellä toimittajan tehtävät (ei epämääräisiä tavoitteita) vaatimuksina, mutta toisaalta toimittajalla on myös velvollisuus toimia asiantuntijana ja tarjota käyttäjälle sitä, mitä hän todella tarvitsee. Tämä ristiriita molempien osapuolten näkökulmien välillä on tyypillistä järjestelmäkehityksen “tavoitteiden” ja “päämäärien” aiheuttamille konflikteille. Oikeudellisesta näkökulmasta haasteena on tarjota ohjeita molempien osapuolten oikeudenmukaiseen konfliktinratkaisuun.

Käyttäjän tavoitteiden konkreettinen vaikutus projektiin

Järjestelmäkehitysprojektit liittyvät usein yritysten tai työpaikkojen suuriin tehostamis- ja tehokkuustoimenpiteisiin, ja jo suunnittelu- ja ehdotusvaiheessa tehdään usein kuulemisia liiketoiminnan haasteista ja tavoitteista. Tässä yhteydessä voidaan keskustella järjestelmän kehittämisen kustannus-hyöty-suhteesta ja erilaisista numeerisista tavoitteista.

• Henkilöstökustannusten vähentäminen tehostamisen avulla
• Myynnin tai tuoton kasvu
• Työajan lyhentäminen

Esimerkiksi, jos yllä mainitut seikat ovat projektin lopullisia tavoitteita, toimittaja saattaa jo ennen projektin aloittamista toimia konsultin roolissa ja selittää järjestelmäkehityksen investointivaikutuksia ja tehdä myyntityötä.

Mitä oikeustapauksia on ollut, joissa käyttäjän asettamat liiketoimintatavoitteet ovat muodostuneet ongelmaksi?

Kuitenkin, palveluntarjoaja on yleensä vain järjestelmänkehityksen asiantuntija. Jos kaikki vastuu käyttäjän liiketoimintatavoitteista lankeaa heille, se voi olla kohtuutonta.

Tapaus, jossa tavoitteena oli parantaa liiketoiminnan nopeutta

Tässä tapauksessa, alla lainatussa tuomion tekstissä, projektin aloitusvaiheessa laaditussa suunnitelmassa oli kirjattu tavoitteet ja päämäärät, jotka johtivat järjestelmän kehitysprojektin käynnistämiseen. Kuitenkin, kun järjestelmä oli valmis ja sitä alettiin käyttää, sen tavoitteita ja päämääriä ei saavutettu, mikä johti kiistaan. Alkuperäisessä suunnitelmassa oli kirjattu, että järjestelmän valmistuttua ja sen käytön aloittamisen jälkeen pyritään saavuttamaan seuraavat tilat:

• Ihmisen tekemän manuaalisen syötön ajan vähentäminen 50%
• Varmistaa, että IT-järjestelmän avulla tehtävät toimistotyöt voidaan suorittaa määräajassa

Käyttäjät eivät kyenneet saavuttamaan näitä tavoitteita, joten he yrittivät vaatia velan laiminlyöntivastuuta ja virhevastuuta toimittajalta. Kuitenkin oikeus ei hyväksynyt tätä väitettä (alleviivattu ja lihavoitu teksti on kirjoittajan lisäämä).

Ja, (keskeneräinen) koko argumentin ydin on, että ① tämän tapauksen tavoite on “liiketoiminnan tehostaminen”, “CRM:n perustan luominen”, “näkyvän johtamisen toteuttaminen” jne., jotka ovat abstrakteja, ja tavoitteet, kuten “lisätä kosketuspisteitä asiakkaiden kanssa”, “jakaa toimistotyöntekijöiden työ sisäiseen valvontaan ja myynnin tukemiseen”, “tehdä tarkempia myyntiennusteita”, “hillitä liiallista myynnin alennusta” jne., ovat enimmäkseen abstrakteja, ja “vähentää syöttöaikaa 50%”, “vähentää arviointiaikaa 50%”, “suorittaa lakisääteinen ilmoitus lakisääteisen ajan kuluessa” jne. ovat tavoitteita, jotka liittyvät SBO:n käyttöönoton jälkeiseen vastaajan liikkeenjohdon ja liiketoimintatapoihin, eivätkä ne ole sellaisia, joita järjestelmän kehitysyritys, kuten vastaaja, voisi ottaa vastuulleen, ② tämän tapauksen projektin aloituskokouksen jälkeisissä kokousmuistioissa ei ole mainintaa siitä, että tämän tapauksen tavoitteista ja tavoitteista olisi keskusteltu konkreettisesti, ③ tämän tapauksen projektisuunnitelmassa on käytetty ilmaisuja, kuten “tulla listatuksi yritykseksi”, jotka eivät itsessään ole sopimuksen luonteisia, (keskeneräinen) ottaen huomioon nämä seikat, on tunnustettava, että vastaaja laati tämän tapauksen tavoitteiden kuvauksen tämän tapauksen projektisuunnitelmassa vastaajan selityksen perusteella, jotta tämä projekti ei epäonnistuisi, tämän projektin tavoitteiden ja tulosten yhteisen ymmärryksen saavuttamiseksi, eikä voida tunnustaa, että vastaaja olisi antanut vastaajalle tehtäväksi kehittää järjestelmä tämän tapauksen tavoitteiden saavuttamiseksi. (keskeneräinen) Siksi, koska ei voida tunnustaa, että vastaaja olisi ottanut vastaan tehtävän kehittää järjestelmä tämän tapauksen tavoitteiden saavuttamiseksi vastaajalta, (keskeneräinen) velan laiminlyöntivastuun ja virhevastuun väitteillä ei ole perusteita.

Tokion alioikeuden päätös 28. joulukuuta 2010 (Heisei 22)

Mitä oikeustapauksista voidaan päätellä liiketoiminnan tavoitteiden ja numeeristen tavoitteiden oikeudellisesta merkityksestä

Kuten tässä tuomiossa mainitaan, on tavallista, että järjestelmän kehittämisen tavoitteen tai numeerisesti määritellyn tavoitteen saavuttaminen riippuu monista tekijöistä, kuten käyttäjän liiketoiminnan ponnisteluista. Siksi toimittajan vastuun asettaminen on erittäin korkea kynnys. Alun perin, jos toimittajan velvollisuuden laiminlyönti tai virhevastuu tunnustetaan, se tarkoittaa, että “tavoitteen” tai “tavoitteen” saavuttaminen on sisällytetty sopimuksen sisältöön. Kuitenkin tässä tapauksessa “tavoite” tai “tavoite” on,

• Abstraktien ja epämääräisten asioiden osalta, koska ne eivät sovi oikeudellisen velvollisuuden luonteeseen, on vaikea katsoa niitä sopimuksen osaksi
• Käyttäjän, erityisesti liiketoiminnan itseapuponnistelujen osalta, koska ne eivät kuulu toimittajan hallintaan, on epäasianmukaista syyttää toimittajaa, eikä niitä voida pitää sopimuksen velvollisuuden osana

Tällaisen oikeudellisen arvioinnin se sai.

Lisää huomioita tästä tuomiosta

Tässä tuomiossa on myös useita muita mielenkiintoisia seikkoja.

• Tuomioistuin ottaa huomioon, että ‘tavoitteen’ tai ‘päämäärän’ jakaminen järjestelmäkehitysprojektissa saattaa olla vain osa kommunikaation pyrkimyksiä saavuttaa ‘yhteinen ymmärrys’ käyttäjien ja toimittajien välillä.
• Tuomioistuin ottaa huomioon myös kokousten pöytäkirjat arvioidessaan, kuinka olennaisia nämä ‘tavoitteet’ tai ‘päämäärät’ olivat koko projektissa.

Muistathan, että järjestelmäkehitysprojekteihin liittyvistä oikeudellisista kysymyksistä, kuten dokumenttien hallinnasta ja kokousten pöytäkirjojen merkityksestä, on lisätietoa seuraavassa artikkelissa.

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

Johtamistavoitteiden ja numeeristen tavoitteiden ympärillä olevat oikeudelliset kysymykset

Kuitenkin, kun kyse on tällaisista “tarkoituksista” ja “tavoitteista”, on tärkeää ottaa huomioon myös seuraavat lisätiedot.

Konsultointi voi olla joko maksullista tai maksutonta, ja se voi muuttaa tilannetta

Jos olet solminut maksullisen konsultointisopimuksen järjestelmänkehitysprojektin lisäksi, tilanne voi muuttua merkittävästi. Jos käyttäjäpuoli on laatinut toteuttamiskelpoisen suunnitelman ottamatta huomioon omia johtamisresurssejaan, on mahdollista, että heitä voidaan syyttää sopimusrikkomuksesta maksullisen konsultointisopimuksen osalta.

Tuotteen virheet ja toiminnallisten tai teknisten vaatimusten epäjohdonmukaisuus ovat erillisiä kysymyksiä

Lisäksi, jos koko “kehitys”projektissa on virheitä, eli jos tuotteessa on havaittavissa vikoja tai bugeja, nämä ongelmat on ymmärrettävä erillisinä. Tällöin ei tarvitse keskustella johtamistavoitteista tai -tarkoituksista, vaan keskitytään tuotteen ja vaadittavien toiminnallisten tai teknisten vaatimusten yhteensopivuuteen. Esimerkiksi, jos järjestelmässä ilmenee jälkikäteen virheitä, käyttäjän toimenpiteet on selitetty seuraavassa artikkelissa.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Muita aiheeseen liittyviä aiheita ovat esimerkiksi ne, joita ei ole sisällytetty vaatimuksiin, mutta jotka myyjän on tunnustettu olevan velvollisia toteuttamaan. Tästä aiheesta on yksityiskohtainen selostus seuraavassa artikkelissa.

https://monolith.law/corporate/system-development-specs-function[ja]

Kummassakin tapauksessa “tarkoitus” ja “tavoitteet” liittyvät kiistat tulisi ymmärtää samankaltaisina, mutta erilaisina asioina.

Vastuun ja sopimuksen teemojen perustavaa laatua oleva ymmärrys on välttämätöntä

Olemme käsitelleet yllä olevassa tekstissä järjestelmäkehityksen “tavoitteiden” ja “päämäärien” ympärillä olevia oikeudellisia kysymyksiä. Tällaisissa kiistoissa tuomioistuimet yleensä ymmärtävät, että molempien osapuolten – käyttäjän ja toimittajan – on tehtävä yhteistyötä ja että kommunikaation parantaminen on osa tätä prosessia. Vaikka lopputuloksen oikeellisuuden voi ymmärtää käytännön kokemuksen perusteella, “vastuun” ja “sopimuksen” kaltaisten asioiden perustavaa laatua oleva ymmärrys on välttämätöntä. Tätä aihetta käsitellään tarkemmin seuraavassa artikkelissa.

https://monolith.law/corporate/responsibility-system-development[ja]

On tärkeää ymmärtää, että oikeudellinen vastuu eroaa epämääräisestä moraalisesta vastuusta, ja että molempien osapuolten selkeä “sopimus” synnyttää sopimusvastuun. Tämän ymmärtäminen on olennaista syvemmän ymmärryksen saavuttamiseksi.