JIT2015 ja IT2015 sopimusehdot ja ketterät periaatteet

Olin tiistaina 2.2.2016 puhumassa ketterien periaatteiden näkymisestä uusissa ketterissä vakiosopimusehdoissa Lakimiesliiton koulutuksen ja Talentum Eventsin IT2015 ja JIT2015 – uudet vakioehdot -seminaarissa. Alla Slideshare-esitykseni seminaarista.

Tärkeimpänä viestinä uusien IT2015 että JIT2015 ketterien sopimusehtojen suhteen on, että ne ovat molemmat jonkinasteisia kompromisseja perinteisen riskikeskeisen sopimusajattelun ja luottamukseen rakentuvan ketterän hankeohjausfilosofian välillä. Hyppäys puhtaaseen ketterään malliin on monelle vakioehtoja käyttävälle asiakkaalle suuri. Niinpä sopimusehdoissa on tuotu perinteisestä sopimusmaailmasta turvakäytäntöjä asiakkaiden tueksi samalla, kun on tehty tutuiksi ketterän tilaamisen tärkeimpiä asioita kuten sitä, että asiakkaalla on oltava varattuna projektiin ihmisiä jotka pystyvät olevan päätöksenteossa päivittäin läsnä.

Yhteenvetona IT2015 ja JIT2015 ketterät ehdot suhteutuvat ideologialtaan ja rakenteeltaan “perinteisiin” ketteriin sopimuksiin seuraavasti:

“Perinteiset” ketterät sopimukset: asiakkaan ohjausvastuu, lyhyt irtisanomisaika, koodi talteen

Ketterissä piireissä perinteinen ja radikaalein sopimusmalli on perustunut time and materials -tyyliseen hinnoitteluun, jossa asiakas ostaa ketteriä kehittäjiä omaan hankeohjauksensa alle. Toisin sanoen asiakas vastaa täysin siitä, että projektissa syntyy liiketoiminnalle arvokkaita asioita tarvitussa aikataulussa. Näissä sopimuksissa riskejä on hallittu lyhyellä irtisanomisajalla (esim. yhden projektin iteraation kuten sprintin pituus). Kun lisäksi on huolehdittu, että jokaisen sprintin lopussa tuote on ehjä ja lähdekoodi tallennettuna jossakin minne asiakkalla on pääsy, asiakas voi ongelmien eskaloituessa periaatteessa jatkaa tuotteen kehitystä uuden tiimin kanssa heti seuraavan iteraation alusta.

IT2015: asiakkaan ohjausvastuu, nimetty menetelmä ja takuu

IT2015 ketterät ehdot (viralliselta nimeltään IT2015 Erityisehtoja toimituksista ketterillä menetelmillä, ks. http://www.it2010.fi/system/files/IT2010_PDF/fi/EsikatseleIT2015_EKT_Suomi2015.pdf) lähtevät perustavasti näistä “perinteisten ketterien ehtojen” lähtökohdista, lyhyttä irtisanomisaikaa (14 pv) myöten. Ehdot kuitenkin olettavat, että asiakas ja toimittaja nimeävät yhdessä käytettävän ketterän menetelmän, jotta käytänteistä voidaan olettaa jotakin. Asiakkaan roolin vaatimuksia opastetaan  velvoittamalla asiakas varaamaan työaikaa hankkeen käyttöön sekä olettamalla että alustava työlista on jo ennen sopimuksen solmimista laadittu. Hankinnan hallintataktiikoita opastetaan esittelemällä mahdollisuus viivästyssakkoihin sekä nimettyihin avainhenkilöihin, joiden vaihtaminen on kielletty. Ainoa varsinainen poikkeama perinteiseen time and materials -ajatteluun on 6 kk takuu projektissa kehitetyille ominaisuuksille.

JIT2015: toimittajan vastuu, avoin lähdekoodi korostuneena

JIT2015 ketterissä ehdoissa (virallisesti Erityisehtoja ketterillä menetelmillä toteutettavista projekteista – JIT 2015 Ketterät menetelmät), ks.
http://docs.jhs-suositukset.fi/jhs-suositukset/JHS166_liite4/JHS166_liite4.html) on tehty enemmän kompromisseja ketterän tilaamisen ja perinteisen IT-projektien sopimusmaailman välillä. Niinpä niitä ei voi käyttää sellaisinaan minkään yleisimmän ketterän metodin (esim. Scrum tai Kanban) kanssa, vaan menetelmään on tehtävä niiden vaatimusten johdosta poikkeuksia tai lisäyksiä.

Draamaattisin ero ketteräksi koettuun toimintamalliin on, että toimituksen sisältö ja aikataulu on toimittajan vastuulla. Lisäksi ketterästä toimintatavasta eroaa, että ehdottomat vaatimukset lyödään lukkoon jo sopimusvaiheessa, vaikkakin niiden sisältöä ja niiden ohelle tulevia valinnaisia vaatimuksia tarkennetaankin yhdessä. Tilaajan etuja suojataan niissä myös takuulla, viivästyssakoilla ja määrittelemällä ketterien metodien ulkopuolisia vastuuhenkilöitä. JIT 2015 ketteriä ehtoja voikin ajatella “my first agile” -tyyppisenä ensimmäisenä tutustumisena ketterään tilaustapaan. Niissä on tuotu erityisesti ilmi esim. tilaajan velvollisuus myötävaikuttaa projektin sujumiseen. Varsinaisen ketteryysteeman ulkopuolelta ehtoihin on tuotu avoimen lähdekoodin lisenssit.

 

Integroituuko sote-uudistus?

Sipilän hallitus julkaisi 10. syyskuuta 2015 asettamispäätöksen sosiaali- ja terveydenhuollon uudistamiseksi. Asettamispäätöksen mukaan Suomeen perustetaan 18 tai 19 itsehallintoaluetta. Niistä 15 tuottaa tai järjestää itse sote-palvelut alueensa asukkaille ja jäljelle jäävät 3 tai 4 yhdessä muiden itsehallintoalueiden kanssa. Itsehallintoalueet voivat myös ostaa sote-palveluita yksityisiltä ja kolmannen sektorin palveluntuottajilta.

Tämän uuden rakenteen myötä seuraavat tavoitteet täyttyvät

sotetavoitteetMA

Horisontaalinen ja vertikaalinen integraatio

Palveluiden vertikaalinen integraatio tarkoittaa perus- ja erikoistason sairaanhoidon integraatiota eli hoitamista samassa organisaatiossa. Horisontaalinen integraatio tarkoittaa sosiaali- ja terveysasioiden hoitamista samassa organisaatiossa. Integraation ja säästöjen lisäksi uudessa sote-mallissa tavoitteena on kansalaisten valinnanvapauden lisääntyminen.

Raha seuraa potilasta

Hallituksen tavoitteena on myös periaatteen “raha seuraa potilasta” toteuttaminen. Kansalaisten valinnanvapaus lisääntyy ja he voivat valita palveluntuottajien joukosta mieluisimman. Kun raha seuraa potilasta, niin potilasta koskevien tietojenkin on seurattava potilasta eri palveluntuottajien välillä. Tietojen on siirryttävä sekä horisontaalisesti että vertikaalisesti.

Rajapintoja tarvitaan monia

ICT-kielellä täydellinen integraatio, rahan ja tietojen siirtyminen itsehallintoalueiden ja eri palveluntuottajien välillä tarkoittaa tietojärjestelmien välisten rajapintojen rakentamista. Kun vaatimuksiin vielä liitetään asettamispäätöksessä mainittu valtion tarve valvoa itsehallintoalueiden toimintaa tarkasti, kasvaa tarvittavien rajapintojen määrä huomattavasti. Koska nykyisin maassamme on käytössä useita eri järjestelmiä kuhunkin tarpeeseen, rajapinnat ovat myös keskenään erilaisia.

Rajapintojen toteuttaminen voi olla vaikeaa

Rajapintojen toteuttaminen saattaa osoittautua hyvin vaikeaksi. Vaikeuteen on monia eri syitä, jotka tulevat vastaan jokaisessa integraatioprojektissa:

  • toisiinsa liitettävien järjestelmien määrä ei ole tiedossa. Niitä voi olla yllättävän paljon, koska kunnat ovat ostaneet kukin omat järjestelmänsä.
  • samankin järjestelmän eri ilmentymät – esimerkiksi eri kunnissa – ovat hyvin erilaisia. Kukin kunta on tilannut ja räätälöittänyt oman järjestelmänsä.
  • järjestelmiä ei ole suunniteltu toisiinsa liitettäviksi eikä niissä ole valmiina rajapintoja. Rajapinnat on siis rakennettava kuhunkin järjestelmään erikseen.
  • jopa samannimisten järjestelmien käsitemallit lienevät kaikesta yhtenäistämistyöstä huolimatta hieman erilaiset.
  • järjestelmissä on ristiriitaista tietoa ja tietojen yhtenäistäminen vaatii paljon käsityötä.

Mikä avuksi?

Onneksi näihin vaikeuksiin voi vastata monin eri keinoin.

  • Osan ongelmista voi ratkaista Kanta-järjestelmällä. Mitä enemmän SoTe-tietoa on Kanta-järjestelmässä, sen helpompaa järjestelmien on keskustella keskenään Kanta-järjestelmän kautta.
  • Kansallinen palveluväylä helpottaa tietojen siirtämistä monin tavoin.
  • Osan ongelmista voi ratkaista yhtenäistämisellä. Valtiohan voi vaatia, että kaikki 19 itsehallintoaluetta käyttävät samoja tietojärjestelmiä – aivan samaan tapaan kuin ison yrityksen osastot käyttävät samoja talous- ja henkilöstöjärjestelmiä. Missään tapauksessa valtion ei pidä sallia itsehallintoalueiden ostaa järjestelmiään toisistaan riippumatta.

Napsahtaako toimittajaloukku?

Yhtenäistämisestä huolimatta nykyisin käytössä olevien järjestelmien integroiminen toisiinsa voi osoittautua erittäin vaikeaksi. Tämä ongelma liittyy järjestelmät toimittaneisiin yrityksiin ja niiden liiketoimintaan. Onko järjestelmien integroiminen järjestelmätoimittajien etujen mukaista vai ei? Jokaisella tietojärjestelmän SoTe-sektorille rakentaneella yrityksellä on tavallaan veto-oikeus sote-uudistuksen integrointiin – tai ainakin melko suuri vapaus hinnoitella rajapintojen kehitystyö.

SoTe-uudistus kaipaa ICT-asiantuntijaa

Asettamispäätöksessä ohjaus- ja projektiryhmään ei ole nimetty yhtäkään ICT-asiantuntijaa. SoTe-uudistuksen tavoitteet toteutuvat vain, jos integraatioihin liittyvät ongelmat otetaan heti alusta alkaen vakavasti. ICT-työhön on varattava riittävästi rahaa, riippumattomia asiantuntijoita ja poliittista tahtoa. Sote-järjestelmien integroiminen ei onnistu vahingossa.

Kuva: Flickr Creative Commons, luonut Maria Boehling opensource.com:lle.

Lisenssit ja avoin lähdekoodi – Codenton uutiskirje 09/2015

Hyvää syyskuuta!

Lisenssit ja avoin lähdekoodi ovat edelleen kuuma keskustelunaihe sekä meillä että maailmalla. Tässä uutiskirjeessä:

  •    IT2015 – Milloin asiakkaan kannattaa omistaa koodi?
  •    Avoimen lisenssin valinta
  •    Gartner: Lisenssioptimointi on hyödyntämätön kilpailuetu
  •    Mitä isot tekevät? Ja mitä asiakkaan kannattaisi siitä päätellä?
  •    Ohjelmistoyritysten avoimen lähdekoodin strategiat
  •    Mitä seuraavaksi?
  •    Opinder – ketterä avoimen lähdekoodin palvelu Helsingin yliopistolle

Milloin asiakkaan kannattaa omistaa koodi? – Uusia ajatuksia luvassa IT2015:ssä

IT2010-sopimusehdot uudistuvat ja julkistetaan 24.9.2015 nimellä IT2015. Uudistuksen varrella on keskusteltu kiivaastikin siitä, kenelle lähdekoodin pitäisi kuulua – asiakkaalle, joka maksaa ohjelmistokehityksestä vai toimittajalle, joka yrittää tehdä siitä liiketoimintaa. Lausuntokierroksella näytti, että uudet ehdot kannustavat asiakasta tunnistamaan, milloin koodin omistaminen on liiketoiminnan kannalta oleellista. Omistuksen jääminen toimittajalle oli tarjolla oletusvaihtoehdoksi, jolloin sopimusehdot helposti ohjaavat hinnoittelemaan asiakkaan omistuksen erikseen.

Codenton toimitusjohtaja Petri Aukia pohtii aihetta julkisen puolen JIT2015-ohjeiden suhteen. JIT2015-ehtojen julkaisuhetki oli vielä kirjeen lähetyshetkellä epävarma.

Avoimen lisenssin valinta

Tarttuva vai salliva lisenssi? GPL, BSD, MIT? Otso neuvoo kalvosarjassaan, mitä lähdekoodin lisenssin valinnasta on tärkeää ymmärtää. Näkökulma on erityisesti julkishallinnon. Kuinka valita avoin lisenssi?

Gartner: Lisenssioptimointi on hyödyntämätön kilpailuetu

Miksi lisensointiin ja ohjelmistojen omistusmalliin kannattaa edes käyttää energiaa? Gartnerin uusi IT Market Clock for ITSM 2.0 -raportti toteaa, että kun laajennetaan ajattelua ohelmistojen omistamisesta koko IT:hen, lisenssioptimointi on tärkeä kilpailuedun lähde. Toistaiseksi se on vain hyvin vajavaisesti hyödynnetty.

Lisenssioptimointia myyvä Flexera pohtii Gartnerin analyysiä blogissaan, ja Software Development Timesin hyvä artikkeli taas pistää Flexeran pohdinnat kontekstiinsa.

Mitä isot tekevät? Ja mitä asiakkaan kannattaisi siitä päätellä?

Yksi avoimen lähdekoodin maailman kohuttu tulokas on pilvifirma Salesforce, joka on vetänyt lisensointikeskustelusta omat johtopäätöksensä ja ryhtynyt tarjoamaan UI-rakennustyökalu Auraansa osittain avoimena lähdekoodina ja ilmaiseksi. Videopilvi Netflix on näyttänyt tietä ja kulkenut avoimen lähdekoodin polkua jo pitkään ja maineikkaasti.

Petrin blogisarjassa avataankin sitä, millaisia strategioita ohjelmistoyrityksillä avoimen lähdekoodin suhteen on. Lukiessa kiinnostavaa on pohtia, millaista strategiaa oma kumppaniverkosto mahdollisesti edustaa.

Avointen ekosysteemien strategiat
Suljettujen ekosysteemien strategiat

Mitä seuraavaksi?

codento-ohjelmiston-haltuunoton-vaiheet

Mitä siis järjestelmien ostajan pitäisi seuraavaksi lisenssien suhteen tehdä? Petrin kalvosetti lisensoinnin kokonaiskuvasta ja kartoittamisen ensi askelista ehdottaa tehtävälistaa ensi maanantaille. Ohjelmistojen omistaminen – haltuunoton vaiheet.

Opinder – avoimella lähdekoodilla ja joukkoistuksella mainiota jälkeä

Loistava esimerkki onnistuneesta avoimen lähdekoodin ketterästä projektista ja asiakkaan vahvasta omistusotteesta on Opinder eli ’opiskelijoiden Tinder’, jonka kautta voi etsiä opiskeluseuraa. Meillä on ilo ja kunnia olla mukana toteuttamassa palvelua Helsingin yliopistolle. Lue lisää Opinderista.

Mahtavaa syksyä kaikille!

Petri ja koko Codento-tiimi

Haluatko tutustua muihin uutiskirjeisiimme?

Jos haluat vilkaista muita uutiskirjeitämme, tässä linkit muutamaan niistä.

Leanillä tehoa liiketoimintaan (12/2015)
Aamiaisseminaarin antia: tietojärjestelmien omistusoikeudet (06/2015)
Tiedolla johtaminen tuo parempia tuloksia (08/2014)
Inspiraatiota uuden IT:n päättäjille (06/2014)
Uutiset IT:n päättäjille (03/2014)

Jos taas haluat saada tulevat uutiskirjeemme ensimmäisten joukossa suoraan sähköpostiisi, voit liittyä uutiskirjeemme tilaajaksi vaivattomasti blogimme sivupalkissa olevalla lomakkeella.

***

Kuva: Flickr Creative Commons, opensource.com.

Avoimen lähdekoodin strategiat ohjelmistoyrityksille, osa 3

Tämän sarjan edellisessä osassa kävimme läpi viisi tapaa rakentaa kannattava ohjelmistoyritys avoimen lähdekoodin avulla siten, että tuotettu koodi leviää laajalle. Viimeisessä osassa käymme läpi vastakkaisia vaihtoehtoja. Sarjan aiemmat osat näet täältä: 1. osa, 2. osa.

Nämä mallit ovat pahojen poikien liiketoimintamalleja monien avoimen lähdekoodin kannattajien ja puolestapuhujien mielestä. Koodin laajaa leviämistä yritetään estää erilaisin keinoin, sinänsä koodiin liittyviä lisenssiehtoja kuitenkaan rikkomatta.

Asiakkaalle myös tällaiset yritykset voivat olla ihan mainioita kumppaneita, mutta heidän ympärilleen ei pääse muodostumaan ekosysteemiä, eikä ekosysteemin mukana tulevaa yritystä suurempaa kehittäjäjoukkoa.

Itse asiakkaana suhtautuisin tällaisiin alihankkijoihin pienellä varauksella ja heidän puheisiinsa erityisen varauksellisesti.

1. Hyvän palvelun lempikonsultti

Helpoin tapa pitää kiinni hyvistä asiakkaista ja kerätä uusia asiakkaita on hyvän palvelun kautta. Julkishallinto haluaa ihan yksityisen puolen tavoin hankkeensa onnistuvan ja nauttii siitä, kun saa tehdä töitä sellaisten ammattilaisten kanssa, jotka ymmärtävät ja arvostavat heidän työtään.

Alan huonommin tuntevat luulevat helposti, että julkisella puolella on pakko valita halvin toimittaja. Tämä ei pidä paikkaansa missään määrin. IT-alan kilpailutuksissa, joita asiakkaan on järjestettävä aika ajoin, käytössä on useimmiten kokonaistaloudellisesti edullisimman valinta.

Kun asiakas on tyytyväinen tuttuun konsulttiin, valitaan kilpailutuksen kriteerit niin, ettei muilla alan toimijoilla ole osaa eikä arpaa tulla valituiksi; “Montako vuotta yrityksellä on kokemusta Liekki-järjestelmän ja ministeriön IT-kehitysmallin käytöstä?” Tyytyväistä asiakasta ei julkishallinnossakaan saa vaihtamaan toimittajaa, eikä avoin lähdekoodi juuri pääse tähän vaikuttamaan.

Malli on tavallaan neutraali. Ostaja ja myyjä avaavat koodin, mutta liiketoimintamallin kannalta tuo on ihan samantekevää, kun kilpakumppanit eivät kuitenkaan pääse tähän väliin vaikuttamaan.

2. Viime vuoden vuosimalli

Lähdekoodi on JIT-ehdotusten vedoksen mukaan avattava vasta hankkeen päätyttyä. Pitkissä julkishallinnon hankkeissa on mahdollista tehdä töitä olympiaadi tai pitempään myöhemmin avattavan koodin kimpussa ilman, että tuota koodia tarvitsee vielä näyttää muille asiakkaille tai kilpakumppaneille. Viiden vuoden etumatkan aikana yritys voi luoda niin vahvan otteen alasta, että avoimellakaan lähdekoodilla on vaikea kilpailla kaikkien kaverien ja jokaisen projektin osaajan kanssa.

Tässä ei välttämättä ole kyse aina edes piinkovasta strategiasta. Vain harvat kehittäjät nauttivat koodinsa julkistamisesta, ennen kuin se on ihan loppuun saakka tehty. Kehittäjien introversio voi tuottaa kaupallisen mahdollisuuden.

3. Omintakeiset työkalut

Hyviä järjestelmiä voi kehittää mitä ihmeellisimmillä työkaluilla, ja usein paras vaihtoehto ei vielä ole kovin laajalti tunnettu. Erlang, Cassandra ja Freebsd-pohjainen järjestelmä tuskin muuttuu kilpakumppaneiden lempilapseksi, sillä siihen oppimisen investointi olisi huimaa.

Joskus yritykset onnistuvat tässä vähän liiankin hyvin. Siinä missä tavallisesti yritykset valitsevat samat ohjelmointikielet kuin muutkin alalla, saattaa avoimella puolella olla suurempi intressi valita työkaluja tai niiden yhdistelmiä, joiden käytössä juuri kyseinen firma on kokeneempi kuin muut. Näin jatkokehityksessä yrityksellä on etulyöntiasema työkaluja vasta opetteleviin verrattuna.

4. Ei avata kaikkea

JIT-ehdot mahdollistavat avoimen lähdekoodin teon suljetun ytimen ympärille. Se, mikä on jo valmiina jaetaan ihan tavallisella ohjelmistolisenssillä, ja vain uusi osuus joudutaan avaamaan avoimena lähdekoodina. Tällaisista avauksista voi toki olla hyötyä, mutta jos toimittaja haluaa tahallaan pitää avoimen koodin hyödyttömänä, ei tuo kovin vaikeaa ole.

5. Patentoidaan ja tavaramerkitään kaikki, mikä liikkuu

Avointa lähdekoodia ei voi käyttää työn pohjana, jos sen ydin on onnistuneesti patentoitu, tai jos on edes uhka siitä, että koodissa on patentoituja kohtia. Patentointi on toki vaikeaa ja kallista, mutta ei suinkaan mahdotonta, varsinkaan laajoissa ja kalliissa julkishallinnon sovelluksissa.

Helpompaa on toki hankkia tavaramerkki sovelluksen nimelle. Muutkin voivat käyttää koodia, mutta muut joutuvat jatkuvasti tekemään turhaa työtä muuttaessaan sovelluksesta niitä osia, joiden käyttö sellaisenaan on tavaramerkein kiellettyä.

6. Siirrytään SaaS-malliin

Jos tuote on lähes sama kaikilla asiakkailla, voi olla helpompaa siirtyä lisensointimaailmasta verkon kautta tarjottavien ohjelmistojen maailmaan. Julkishallinnolla on omat SaaS-sopimuksensa, joiden kautta ohjelmistoja hankittaessa oikeudet lähdekoodiin jätetään toimittajalle.

SaaS-palvelussa samaan sopimukseen on niputettu sovellus, palvelimet ja niiden käyttöpalvelu. Joskus pakettiin kuuluu jopa järjestelmän käyttämien tietoaineistojen osittainen luonti tai ylläpito.

Aamiaisseminaarin antia: tietojärjestelmien omistusoikeudet – Codenton uutiskirje 06/2015

Hei!

Jos et päässyt osallistumaan aamiaisseminaariimme, joka käsitteli tietojärjestelmien omistusoikeuksia, tai jos olit paikalla ja kaipailet jotain tiettyä esitystä, pääset tutustumaan seminaarin antiin jälkikäteen! Tässä uutiskirjeessä:

  • Petri Aukian (Codento) ja Kerkko Vanhasen (HSL) puheenvuorot videolla sekä SlideSharessa
  • Video: Mitä IT-ostajan pitää ymmärtää tietojärjestelmien omistusoikeuksista?
  • Uusia ajatuksia ohjelmistojen omistamisesta

Petri Aukian (Codento) ja Kerkko Vanhasen (HSL) puheenvuorot videolla sekä SlideSharessa

Tietojärjestelmien omistusoikeuksissa kannattaa panostaa strategisesti tärkeimpiin, kilpailukykyä luoviin järjestelmiin, sanoi Petri Aukia (Codento) puheenvuorossaan. Kerkko Vanhanen (HSL) taas esitteli uutta, avoimeen lähdekoodiin perustuvaa Reittiopasta. Nämä puheenvuorot ovat nähtävissä kokonaisuudessaan. PowerPoint-diat Aukian esitykseen löydät täältä, ja Vanhasen esitykseen taas täältä.

Video: Mitä IT-ostajan pitää ymmärtää tietojärjestelmien omistusoikeuksista?

Kannattaa myös vilkaista puhujien tiivistykset esitystensä parhaista opeista, sekä kävijöiden kommentit ja mielenkiintoisimmat oivallukset.

Uusia ajatuksia ohjelmistojen omistamisesta

Konsulttimme Matti Kinnunen kirjoittaa huomioitaan seminaarin sisällöstä blogissamme. Blogiartikkelissa kerrotaan mm. siitä, miten tärkeää on pitää olennainen arkkitehtuuriosaaminen omissa käsissä ja ostaa useilta eri toimittajilta toimittajaloukun välttämiseksi. Tämä huomionarvoinen poiminta on Hannu Kokon (Basware) puheenvuorosta, jonka diat näet täällä.

Jos seminaarin aiheista herää kysyttävää, ota rohkeasti yhteyttä Petri Aukiaan (petri.aukia@codento.com, puh. 0400 438 610).

Mukavaa kesän jatkoa!

Petri ja koko Codento-tiimi

Haluatko tutustua muihin uutiskirjeisiimme?

Jos haluat lukea muita uutiskirjeitämme, tässä linkit muutamaan niistä.

Leanillä tehoa liiketoimintaan (12/2015)
Lisenssit ja avoin lähdekoodi (09/2015)
Tiedolla johtaminen tuo parempia tuloksia (08/2014)
Inspiraatiota uuden IT:n päättäjille (06/2014)
Uutiset IT:n päättäjille (03/2014)

Jos taas haluat saada tulevat uutiskirjeemme ensimmäisten joukossa suoraan sähköpostiisi, voit liittyä uutiskirjeemme tilaajaksi vaivattomasti blogimme sivupalkissa olevalla lomakkeella.