Asiakas vs. Toimittaja - TKO?
•Télécharger en tant que PPTX, PDF•
0 j'aime•690 vues
Niina Tirrin ja Jarno Malapraden puheenvuoro korkeakoulujen valtakunnallisilla IT-päivillä 30.-31.11.2012. Aiheena asiakkaan ja toimittajan välisen suhteen haasteet ja menestyksen avaimet. Miten voit tuhota jo kilpailutusvaiheessa tulevan projektisi? Mikä on ratkaisun ja tuotteen ero? Mitkä ovat IT-hankkeiden onnen oikotiet ja epäonnistumisen ABC? Millä tavalla LUC ja Tietotalo ratkaisi näitä haasteita...
Recommandé
Recommandé
Contenu connexe
Plus de Jarno Malaprade
Plus de Jarno Malaprade (11)
Asiakas vs. Toimittaja - TKO?
- 1. Asiakas vs. Toimittaja – TKO? IT2012 – 30.10.2012 Niina Tirri | Jarno Malaprade
- 2. Asiakas • Lapin korkeakoulukonserni (LUC) – Kemi-Tornionlaakson kuntayhtymän (LAPPIA), Rovaniemen koulutuskuntayhtymän (REDU) ja Lapin yliopiston (LAY) muodostama strateginen yhteenliittymä – Korkeakoulukonsernin strategiasta johdettu yhteisen tietohallinnon linjaukset ja toimintasuunnitelma sekä tavoitteet
- 3. Toimittaja • Tietotalo – Perustettu 1995 – 29 ammattilaista – Liikevaihto 3,2 M€ – Toimipisteet: Keilaranta, Espoo ja Napapiiri, Rovaniemi – Liiketoiminnan alueet • Sisällönhallinta ja verkkoviestintä • Projektinhallinta (EPM) • Matkailun verkkoliiketoiminta ja toiminnanohjaus
- 4. Infoweb-järjestelmähanke • Yhteinen www-julkaisujärjestelmä Lapin korkeakoulukonsernille (LAPPIA, LAY, REDU) • Aikaisemmin toteutettu saman toimittajan vanhemmalla versiolla (SevenWeb), jokaisella osapuolella oma järjestelmänsä • Järjestelmää ei kilpailutettu – Eri osapuolet olivat päivittämässä järjestelmän uutta versiota • Päätettiin yhdistää kaikki samaan järjestelmäratkaisuun
- 5. Järjestelmähankkeissa ongelmia? • ”Järjestelmätoimittajan valinta on kuin bingoa” • ”Työmäärät arvioidaan pieleen; toimittaja arvioi alakanttiin tarjouskilpailuun, asiakas ei osaa arvioida välttämättä ollenkaan” • ”Asiakkaalla ei ole aikaa järjestelmän määrittelyyn ennen kilpailutusta” • ”Huonosti tehty työ on toimittajalle tuottavampaa” • ”Ihmiset, joilla on toimialaosaamista, mutta harvemmin minkäänlaista ohjelmistoteknistä osaamista, testaavat järjestelmiä. Tämä ei ole ammattimaista testaamista, koska sanavarasto ei riitä ohjelmiston kuvaamiseen” • ”Eniten testaamisessa tuottaa ongelmia vääntäminen siitä, onko kyseessä bugi vai muutospyyntö. Ja saako vääntämisestä laskuttaa.” • ”Arvioilta 90% maailman hankinnoista tehdään toimittajia kilpailuttamalla, joka on vasta toimitusketjujen hallinnan ensimmäinen vaihe.” • ”Usein syyllinen ei ole kilpailuttaminen, vaan asiakkaan puolelta huonosti suunniteltu tai organisoitu hankinta.”
- 6. Asiakas vs. Toimittaja MEILLÄ MENI NÄIN...
- 7. Nykytila Reklamointi LAO Tarjous Ongelman MTI selvitys LKYO Kirjasto Laskutus SoleNovo LUC RAMK REDU Sole Avoin Kieli- OPS AMK KTI keskus Järjestelmien MKKK Tilaus integrointi Avoin Tietotalo Me- YO AOL teor Sininen Räätälöinti meteoriitti LAY Lappia Tukipyyntö TKI KTAMK Käyttäjähallinta Arktinen Barents- keskus Sivujen info IT- perustaminen palvelut
- 12. Asiakas vs. Toimittaja MITEN NYKYTILASTA SELVITTIIN?
- 13. Ratkaisun toteutus • Perustettiin pääkäyttäjäverkosto – Valittiin/päätettiin jokaiselle organisaatiolle oma pääkäyttäjä sekä lisäksi LUCin koordinoiva pääkäyttäjä – Sovittiin pääkäyttäjien tehtävät ja vastuut • Ylläpitosopimus – Sovittiin ylläpitosopimuksessa siitä, miten oikeasti toimitaan, ei pelkästään sopimusteknisistä asioista – Laadittiin tukipalvelu- ja kehitysprosessi
- 14. Tavoitetila Pääkäyttäjä LAY Pääkäyttäjä Pääkäyttäjä LAPPIA REDU koordinoiva Pääkäyttäjä LUC IT-palvelut Tietotalo
- 15. Pääkäyttäjien tehtävät • Organisaatioiden pääkäyttäjät – Jatkoivat omissa vanhoissa tehtävissään, mutta lisäksi toimivat verkostossa • Koordinoiva pääkäyttäjä – Kehittelee yhteisiä asioita ja toimintatapoja • Kokoukset, laskutus, käyttäjähallinta, prosessit, sopimus, järjestelmän kehitys, yhteistyö.... • Opettelee ymmärtämään eri osapuolia • ”Diplomaatin tehtävänä on ylläpitää kontaktipintaa ja keskusteluyhteyttä, kun taas voimakkaat reaktiot ovat poliittisen päätöksenteon alaisia ratkaisuja” –Wikipedia-
- 16. Pääkäyttäjän paikka Pääkäyttäjä Toimit- taja Toimit- Asiakas taja Asiakas IT- palvelut IT- palvelut
- 17. Nykytilasta.... Reklamointi LAO Tarjous Ongelman MTI selvitys LKYO Kirjasto Laskutus SoleNovo LUC RAMK REDU Sole Avoin Kieli- OPS AMK KTI keskus Järjestelmien MKKK Tilaus integrointi Avoin Tietotalo Me- YO AOL teor Sininen Räätälöinti meteoriitti LAY Lappia Tukipyyntö TKI KTAMK Käyttäjähallinta Arktinen Barents- keskus Sivujen info IT- perustaminen palvelut
- 18. ... tavoitetilaan LKYO AOL LAO KTAMK RAMK Arktinen TKI keskus REDU Barents- info MTI LAY Lappia MKKK KTI LUC Kieli- keskus Avoin Avoin AMK YO Kirjasto IT- Sole Me- palvelut OPS teor Tietotalo Sininen SoleNovo meteoriitti
- 21. Asiakas vs. Toimittaja KILPAILUTUS- JA TOTEUTUSMALLIT
- 22. Kilpailutus ja projektityö Epäonnistumisen ABC - toimivia oikoteitä epäonnistumiselle: 1. Kilpailuta projekti hengiltä. 2. Kilpailuta kaikki projektit samalla mallilla. 3. Tilaa ”tuote” ratkaisemaan toimintamallin tai -kulttuurin ongelma. ‒ Älä kehitä ratkaisua ja toimintatapoja yhdessä (ihmisiä on hankala motivoida ja sitouttaa!). 4. Vaadi valmis, virheetön ”tuote” - älä varaa tilaa ratkaisun kehittämiselle. 5. Ulkoista vastuu - vastuun voi aina ulkoistaa koska sen kantaminen ja jakaminen on haasteellista. Kyllä toimittajasta pääsee kyllä eroon jos se ei itse keksi. 6. Ulkoista operationaalinen taso - palkkaa organisaatioon ulkopuolinen konsultti vetämään projektia puolestasi. Älä anna konsultille projektin päätäntävaltaa. 7. Aliresursoi - oma suunnittelutyö, sisällöntuotanto, toimintamallien muutos hoituvat kyllä kunhan toimittaja toimittaa ensin toimivan ratkaisun. 8. Strategiattomuus - katsotaan projektin jälkeen, miten sen ratkaisut voi perustella. ‒ Palvelustrategia, viestintästrategia, sisältöstrategia... 9. ”Leuka rintaan ja reippaasti kohti uusia pettymyksiä!” ‒ Katselmoi projektit avoimesti, tunnista virheet ja opi (myös) yhdessä toimittajan kanssa. Epäonnistunut projekti ei tee tilaajasta tai tuottajasta välttämättä ”huonoa”.
- 23. Kilpailutus ja projektityö 1. Kaikkea ei kannata kilpailuttaa - kilpailutuksen kulut vs. saavutettu säästö. – Julkisen sektorin yksi kilpailutettu hankinta vaatii keskimäärin hieman alle 100 työtuntia. (Tieke) – Keskitetystä ratkaisusta kilpailuttamalla hajaannukseen - vaikutukset prosesseihin, toiminnan laatuun ja pitkän aikavälin kustannustehokkuuteen. 2. Kilpailutuksen kulut lisätään tarjoukseen. PK-yritykset tippuvat kilpailusta pois - ei ole varaa osallistua. 3. Millainen projekti muodostetaan? – Tiedämme tarkalleen, mitä pitää tehdä, missä ajassa ja paljon se saa maksaa (Vesiputous) – Uskallamme myöntää, ettei tavoitetilasta ole täydellisen tarkkaa kuvaa (Agile) – Ymmärrämme, että jatkuvalla mittaamisella ja analysoinnilla saavutamme käyttäjien tarpeita palvelevan ratkaisun. 4. Kilpailutetaan määrällisin kriteerein (hinta, aikataulu) vaikka laadulliset tekijät tekevät projektista onnistuneen tai epäonnistuneen. – Ei ole uskallusta, osaamista, näkemystä, tietoa, tapaa kilpailuttaa hankintoja esimerkiksi ketterän mallin mukaan. – Sähköinen huutokauppa (1.10.2011 laki) ja dynaaminen hankintajärjestelmä.
- 24. Kilpailutus ja projektityö Onnistumisen ABC - onnen oikoteitä: 1. Tunne kilpailuttamismallit ja hyödynnä niistä opittu - tavoitehinta, tavoiteaikataulu, laatukriteerit, käänteinen kilpailutus. Pyydä rohkeasti konsultilta tai ”luottotoimittajalta” tukea. 2. Tunne projektimallit, niiden edut ja ansat - käytä niitä rohkeasti soveltaen ja sovi yhteiset toimintatavat. 3. Sovi ja tunne roolit - kehitä osaamista tavoitteellisesti ja roolipohjaisesti. 4. Kommunikointi ja verkosto - ei toteuteta ”irrallisia juttuja”. 5. Projektin ”omistajaksi” henkilöt, joilla on valta, Aika vastuu ja osaaminen. – Projektin omistaja toimii ”tulkitsevana liisterinä”, ymmärtää toimittajan ja oman organisaation tekemisen, mittaa ja analysoi ennen päätöksiä ja kantaa vastuun päätöksistään. 6. Ymmärrä, mikä on ”tuotteen” ja ”ratkaisun” ero projektin aikana ja sen jälkeen.
- 25. Toimittajan ratkaisuja • Jatkuvan kehityksen toimintamalli - palvelukumppanuus. – Toimittajan kokemus ja liiketoimintaymmärrys – Parhaimmillaan ymmärrystä juuri sinun organisaatiosi liiketoiminnasta ja operatiivisesta toiminnasta • Tietopääoman ja yhteisen ymmärryksen rakentamisen työkaluja – ”Kroppaa likoon” - palvelukumppanuus – Säännölliset tapaamiset ja executive brief – Kehityspolku, kehityksen vuosikello – Webinaarit • Responsiivinen design vs. mobiilisivusto • Digitaalinen markkinointi ja -kauppa Venäjällä • Mobiili- ja pilvipalvelut työssä
- 26. Asiakas vs. Toimittaja MITÄ TÄSTÄ ON OPITTU JA MITEN TOIMITAAN SEURAAVALLA KERRALLA?
- 27. Opetus • On opittu, että – pitää ajatella miten toimintaa halutaan kehittää, ei sitä, mihin järjestelmä pystyy – asiakkaan ja toimittajan väliin tarvitaan tulkki – pelkkä verkoston luominen ei riitä – kehityksen tulee olla avointa – pitää opetella paljon asioita • Seuraavalla kerralla osataan huomioida kokonaisuus paremmin ja kysyä oikeammanlaisia kysymyksiä
- 29. Yhteenveto • Oman ymmärrystason nostaminen – Opetellaan kysymään oikeita kysymyksiä – Opetellaan ymmärtämään eri osapuolten osaamisalueita • Avointa yhteistyötä ja vastuunjakoa palkanmaksajasta riippumatta Yhteistyö kehittää toimintaa Toiminta kehittää järjestelmää Toimiva järjestelmä tehostaa yhteistyötä, toimintaa ja lisää käyttäjätyytyväisyyttä Olemme parempia asiakkaita ja toimittajia
- 30. Kiitos.
Notes de l'éditeur
- Asiakkaan ja toimittajan suhteen sekä järjestelmän hankinnan/käyttöönoton hankaluus, mikä meni pieleen ja miten siitä on yritetty selvitä?Mietin eilen esityksiä kuunnellessa, että voinko puhua tässä yhteydessä kokonaisarkkitehtuurista, se kun kuulostaa olevan niin vaikea, raskas, monimutkainen johtamisen asia. Mutta kyllä tässä on kyse arkkitehtuurityöstä, vain eri tasolla, käytännön tasolla.
- Eilen Markku Tarvainen tarkemmin esitteli konsernia ja sen tavoitteita, - Palvelun kustannustehokkuuden kasvattaminen ja laadun parantaminen - asiakkaan hankintojen koordinointi yhdenmukaisesti -> tietojärjestelmäkirjon vähentäminenNäitä tavoitteita yritetään toteuttaa
- Omaan esittelyyn:Koulutukselta kasvatustieteiden maisteri eli katsoo kokonaisuutta ”kovan teknologisen ytimen” ulkopuolelta.Vastuulla sisällönhallinta ja verkkoviestintäratkaisut, asiakkuuksia: LUC, Seinäjoen korkeakoulukonserni, Kajaanin AMK, Jyväskylän koulutuskuntayhtymä
- Lyhyt esittely järjestelmästä ja sen hankintapäätöksestä, 2min.Kaikkien konsernin osapuolten pääasialliset www-sivut samassa järjestelmässä.Järjestelmää ei kilpailutettu, vaikka halukkuutta olisikin ollut. Järjestelmäratkaisun yhdistämisen haasteet olivat riittävän suuret ilman kilpailutuksesta mahdollisesti seuraavaa kokonaan uutta järjestelmää ja toimittajaa.Jos järjestelmä olisi kilpailutettu, kehitys ja ylläpidollinen hallintamalli olisi mennyt täysin uusiksi -> liian iso muutos kilpailutuksen jälkeen jos olisi tullut kokonaan uusi järjestelmä ja toimittaja. (Ratkaisu sisältää myös työtavat)
- Mitä aiheesta (tämän päivän järjestelmähankkeet) yleensä sanotaan. Kommentit on kerätty nettikeskusteluista ja blogeista, niin asiakkaan kuin toimittajan näkökulmista. Ongelma ei ole vain meillä vaan samat ongelmat kuulostavat toistuvan järjestelmästä/asiakkaasta/toimittajasta riippumatta. Kaikki mainitut ovat todellisia ongelmia, meillä myös. Työmääräarviot, määrittelyt, osaamattomuus, testaaminen...Mutta näihin on osaan löydetty ratkaisu tai vähintäänkin helpotusta.Toimittajan näkökulma?1min.
- Lähtötilanne eli ka:n mukaisesti kuvattu nykytilaTavoitetilaa ei tässä vaiheessa edes kuvattu. Tavoite oli selvitä tästä hengissä...Paperilla olimme yksi asiakas, LUC, mutta todellisuudessa jokainen projekti ja osaprojekti toimi omalla tavallaan, ilman minkäänlaista tolkkua. - osalla projekteista oli vetäjät, osalla ei, jne. lähtökohdat olivat kaikilla erilaiset....josta seurasi.... Seuraava dia (sarjakuva). Seuraavassa lyhyt kuvaus käytännössä.Toimittajan kommentti?
- Kaikki asiakkaan osapuolet aloittivat projektit innokkaina, oman alansa asiantuntijoina, määrittelyt tehtyinä. Toimittaja oli hyvin perillä järjestelmän vaatimuksista ja tekniikasta.IT-palveluita ei juuri huomioitu, eikä juuri ymmärretty, miten heidät olisi pitänyt huomioida. Kenelläkään ei ollut yhteistä kieltä. Osaamistasot olivat erilaiset. Vaatimuksia oli paljon.
- Hämmennystä aiheuttavia tilanteitaAsiakkaan määrittelyssä puutteita; määrittely on yksiselitteinen asiakkaalle, toimittajalla on toiminnosta eri versioita. Toimittaja ottaa ilon irti huonosti määritellystä työstä ja tekee mielellään uuden kalenterin, lisähintaan.Asiakkaan eri osapuolet huomaavat järjestelmässä puutteita/bugeja/määrittelemättömiä asioita, ja pyytävät niitä jokainen erikseen, vaikka asia olisi voitu hoitaa kerralla, yhdellä tukipalvelupyynnöllä. Toimittaja ottaa ilon irti huonosti määritellystä työstä ja yhteistyön puutteesta ja tekee mielellään lisäykset, lisähintaan.
- 1. Asiakas ei hallinnut omia toimintojaan, eikä kyennyt selvittämään mikä johtui mistäkin, usein vika oli asiakkaan oma.2. Toimittajan on toimittanut kaiken määrittelyn mukaan ja haluaa siitä maksun, mutta asiakas on ajatellut asian toisin omasta näkökulmasta eikä ymmärrä toimittajan ratkaisuja, ts. ei yhteistä kieltä. Kukaan ei ole tehnyt väärin, mutta mikään ei silti toimi.
- Tilanne kärjistyi
- Ensin pääkäyttäjäverkosto, pääkäyttäjien tehtävät, pääkäyttäjäverkoston toiminta käytännössä 5min.Päätettiin jokaiselle organisaatiolle oma pääkäyttäjä Organisaatioiden olemassa olevat www-ylläpitäjät jatkoivat samoissa tehtävissä, omien sivustojensa vastaavina, lisäksi valittiin koordinoiva pääkäyttäjä, joka vastaa myös konsernin sivustoista.MITÄ (tavoite): Yhteiset palvelut, yhteistyö, voimavarojen tuloksellinen käyttöMITEN(osatavoite): Miten käytännössä on kehitetty verkostossa hyviä käytänteitä ja työtapoja (käyttäjähallinta (oikeudet, ryhmät), vikatilanteiden käsittely, kehitys, sivustojen/ylläpidon periaatteita...), palveluiden ja työtehtävien sekä vastuiden määrittelyMILLÄ (työtehtävä): Jalkauttamalla käytänteitä normaaliin arkeen, määrittelemällä ja pelkistämällä asiat ylläpitosopimukseen –> sopimuksessa kuvattu, miten asiat tehdään oikeassa arjessa. Karsittu kustannuksia jakamalla työtehtäviä (vastuista), kehittämällä ja yhtenäistämällä käytäntöjä sekä toimintatapojaKokonaisarkkitehtuuriperiaatteet: ”Tietojärjestelmäkehitys on avointa” = Kehitysehdotukset käydään läpi verkostossa -> yhtenäistäminen”Tieto on yhteiskäyttöistä” = kaikilla pääkäyttäjillä samat oikeudet kaikkiin tietoihin”Tieto on reaaliaikaista” = tiedotettavat asiat kaikille pääkäyttäjille kerralla, yhteydenpito jatkuvaa, ei rajoitu vain kuukausitapaamisiin.
- Tässä vaiheessa verkoston perustamisen jälkeen tavoitetila selkiintyi.Verkosto toimii koordinoivan pääkäyttäjän vetämänä ja kaikki liikenne kulkee pääkäyttäjien kautta. Kaikki tukipalvelupyynnöt ja kehitysehdotukset käsitellään ensin pääkäyttäjäverkostossa, ongelman ratkaisu löytyy usein verkostosta, useamman osapuolen ongelmat saadaan kerralla korjattua sen sijaan, että jokainen selvittelee niitä erikseen. Tukipalvelupyynnöt hallitusti yhden kanavan kautta toimittajan tukipalveluun.Lisäksi verkoston tehtävänä on karsia moninaisuutta, määritellä kehitystyötä, vakioida toimintamalleja jne.
- Organisaatioiden pääkäyttäjillä vaihtelevat tehtävänkuvat (entiset www-vastaavat jatkoivat tehtävissään), jotka huolehtivat oman organisaation järjestelmän käytöstä (omat sivustot, käyttäjähallinta jne.).Koordinoivan pääkäyttäjän tehtävät: hoitaa ja suunnittelee yhteisiä asioita ja toimintatapoja. Lisäksi hoitaa kaikki ne tehtävät, mitä muut pääkäyttäjät eivät ehdi. Mietin mikä sana kuvaisi koordinoivaa pääkäyttäjää parhaiten ja se on diplomaatti. Wikipedian määritelmä diplomaatista tiivistää asian hyvin.HUOM! Alun perin koordinoiva pääkäyttäjyys piti toteuttaa oman työn ohessa. Siksi kukaan olemassa olevista pääkäyttäjistä ei siihen alkanut. Aika äkkiä on huomattu, että varsinkin alussa työtapojen ja verkoston ”sisäänajaminen” vie todella aikaa, jos vain mahdollista niin 100% työajasta menee kevyesti.
- Pääkäyttäjä ei tunkeudu kenenkään alueelle, vaan toimii välissä tulkkina ja yhdistävänä tekijänä. Aiemmin eri osapuolet ovat menneet hieman eri tahtiin -> nyt toimivat yhdessä, pääkäyttäjäverkoston avustamanaEilen Antti Syväjärvi puhui sekasikiöistä, hybridimallista. Huomasin, että minäkin olen sellainen sekasikiö. Pääkäyttäjä on juuri sellainen epämääräinen toimija muiden toimijoiden välimaastossa.
- Verkoston luomisen jälkeentästä nykytilasta...
- ... päästiin tavoitetilaanHomma toimii näin. Pääasiassa. Pikku hiljaa toiminta on vakiintumassa.Toiminnan helpottamiseksi on saatu lähes valmiiksi ylläpitosopimus (pieniä sopimusteknisiä asioita vielä muokataan) ja kohtahan se muuttuukin kun KTAMK ja RAMK yhdistyvät Lapin ammattikorkeakouluksi.Mutta sopimuksen tärkein sisältö on se, että sopimus kertoo sen kuinka me toimimme. Sopimukseen on kuvattu tukipalvelu- ja kehitysprosessit, joiden avulla asioiden käsittely on läpinäkyvää ja yksiselitteistä.
- Tukipalveluprosessi.Kuka tekee ja mitä, miten tukipalvelupyynnöt käsitellään, miten voidaan selvittää, onko kyseessä laskutettava työ vai sopimukseen kuuluva työ.Tämä avulla päästään bugeista ja muutospyynnöistä vääntämisestä.
- KehitysprosessiTiedetään kuka maksaa ja mistä maksaa. Kehitysprosessi ohjaa laskutettavien töiden etenemistä, osataan maksaa siitä mitä on tehty + parempi seurantaMahdollisuus myös ketterään kehitykseen.Ymmärryksen muodostaminen:Toimittaja tuo lisätietoja, ideoita, ratkaisuideoitaSuunnitelmallisuus: kuukausittaiset tapaamiset, vuosikellomainen työskentely.
- Moninaisuuden karsiminen, kehitystyön määrittely, vakioidut toimintamallit,
- Esimerkki: “Dynaaminenpoista-nappi”. Asiakashaluaakaikkitoimivannapin, jollavoipoistaaesteet tai sovelluksenosanpalvelusta. Asiakaslähteetekemäänsuunnittelutyön kun projekti on valmis.
- Lyhyt esittely asiakkaasta ja toimittajasta 3min.
- Seuraavalla kerralla, mikä tuleekin varmaan aika pian näiden jatkuvien organisaatiomuutosten takia, meillä on kuviot valmiina. Pääkäyttäjäverkosto ei ole järjestelmäriippuvainen, eikä välttämättä täysin toimintariippuvainenkaan. Meillä on jo nyt yhteisiä käytäntöjä ja toimintatapoja, vastuut ovat selvillä, -> kuka hoitaa ja mitä, kenenToimittajan kommentti?
- Kokonaisarkkitehtuurin ei tarvitse olla vaikea asia, sitä voi soveltaa pienissäkin asioissa -> ensin mietitään omaa toimintaa, miten se hoidetaan nyt, miten sen haluttaisiin toimivan, sitten mietitään miten sitä tehostetaan. Joskus toiminta tehostuu pelkästään prosessin läpikäymisellä.Kilpailutuksen osalta; prosessit ovat kunnossa, asiakas on organisoitunut -> suhde toimittajan suuntaan selkeämpi. Osataan tarkastella kehittämistä oman toiminnan kautta, ei järjestelmän.
- Niin tärkeitä kuin kaikki sopimustekniset ym. asiat ovat, on myös tärkeää muistaa, että niin kauan kuin koneet eivät hoida itse kilpailutusta ja ylläpitoa, ovat myös nämä päivänselvät asiat avaimia toimivaan suhteeseen, ihmisten välillä ja myös suhteessa omaan työhön.Kilpailutuksen jälkeen ei olla enää kilpailutilanteessa.Eri organisaatioilla on oma kulttuurinsa ja niiden yhdistäminen vaatii inhimillistä suhtautumista, kärsivällisyyttä ja kunnioitusta toimintatapoja kohtaan, mitään ei voi survoa kerralla mihinkään muottiin. Avoimuudella ja rehellisyydellä saadaan asioita vietyä eteenpäin ja arvostamalla muiden tekemää työtä pääsee taas omassa työssä eteenpäin. Ja huumoria täytyy olla, usein kiistelyn alla olevat asiat ovat suorastaan naurettavia.Pelkkä verkoston luominen ei riitä. Pääkäyttäjäverkostoa luodessa ja organisoituessa tuli monta tilannetta, että ei luotettu toisen osaamiseen, oli kyräilyä ja kilpailua organisaatioiden välillä, oikeuksia vaadittiin, mutta vastuu vieritettiin muualle. Uskottavuus oli hukassa (eikä sitä vieläkään mainittavasti ole...), oli ylenkatsomista ym. ennakkoluuloa niin pääkäyttäjien, organisaation henkilökunnan, it-palveluiden kuin toimittajankin välillä. Ja huumorin osuutta ei voi korostaa liikaa. Lähes päivittäin tulee tilanteita, jotka ovat suorastaan naurettavia, ei tiedä itkisikö vai nauraisiko...
- Ymmärrystason nostaminen, tekninen, toimialatoiminta, asiakkuus, Ollaan opittu auttamaan asioita eteenpäin, mitä hallinta ja hallinto on käytännössä, osaamisen nosto toisten alueilta/odotuksista.....Käyttäjätyytyväisyys lisäksiJärjestelmä tuodaan kehittämään toimintaa, toiminnasta saadaan hyöty hyvillä työkaluillaJos ei osata, kouluttaudutaan siihen mitä ei osata (opetellaan ymmärtämään osaamisalueita) -> KehityskaariLopputulemana tulee parempi toimittaja/asiakasLuodaan näkemys yhteisistä tavoitteista, kaikille osapuolille, kaikki osapuolet osallistuvat (yhteistyötä, mutta samalla kohdentaa vastuut oikealle taholle, toimituksia ja tuotoksia toimittajalta, siten että ne hyödyttävät, asiakkaana on osattava tilata ne hyödyttävät tuotokset)