Hankinta-ansa yritysten tekoälyssä
Demodemo voitti tarjouskilpailun
Voittanut demo oli siisti. Käyttäjä esitti kysymyksen, järjestelmä vastasi lähdeviitteineen, käyttöliittymä ehdotti seuraavaa toimenpidettä ja kojelauta näytti ennustetut säästöt sellaisella itsevarmuudella, joka yleensä varataan lentokenttäarkkitehtuurille. Hankintatiimi oli tehnyt työnsä prosessin määrittelemällä tavalla. Vaatimukset kerättiin, toimittajat pisteytettiin, tietoturvakyselyt täytettiin, juridiset ehdot neuvoteltiin ja valittu ratkaisu vaikutti kyvykkäimmältä vaihtoehdolta. Jokainen saattoi osoittaa tiedostoa ja sanoa, että menettelyä oli noudatettu.
Kuusi kuukautta myöhemmin menettely oli edelleen oikea ja toiminta väsynyttä. Tietoyhteydet toimivat esimerkkilähteillä, mutta takkuilivat oikean arkiston kanssa. Vastausten laatu oli hyvä toimittajan ympäristössä ja epätasaista sisäisessä työnkulussa. Manuaalinen tarkistus vei odotettua kauemmin, koska kukaan ei ollut hinnoitellut näyttövelvoitteen taakkaa. Toimittajalla oli tiekartta, ostajalla poikkeuksia ja operatiivisella puolella jono ongelmia, jotka eivät sopineet alkuperäiseen vaatimusluetteloon. Mikään ei ollut vilpillistä. Mikään ei ollut järkyttävää. Hankintaprosessi oli ostanut tekoälykyvykkyyden ja vain osittain ne edellytykset, joilla kyvykkyydestä saattoi tulla toimivaa työtä.
Tämä on yritystekoälyn hankintaloukku. Ostoprosessi on rakennettu vertailemaan tuotteita, vähentämään juridisia riskejä, hallitsemaan hintaa ja dokumentoimaan tasapuolisuutta. Nämä ovat oikeutettuja tavoitteita. Mutta tekoälyn arvo syntyy tuotteen ja organisaation välisessä sotkuisessa välimaastossa: dataan pääsyssä, työnkulkujen uudistamisessa, todisteiden keräämisessä, käyttäjäkoulutuksessa, poikkeusten käsittelyssä, mallipäivityksissä, tietoturvatilassa, integraatiovelassa, auditointivaatimuksissa, palautesilmukoissa ja vastuussa lopputuloksista. Jos hankinta pisteyttää näkyvän tuotteen mutta kohtelee toimintaedellytyksiä toteutuksen yksityiskohtina, organisaatio ostaa lupauksen ja saa projektin.
Loukku ei ole siinä, että ostajat olisivat tyhmiä. Useimmat ostajat työskentelevät perittyjen mallipohjien ja aidon paineen alla. Heidän odotetaan mahdollistavan innovaation, vähentävän riskiä, toimivan nopeasti, hallitsevan kustannuksia, täyttävän tietoturvavaatimukset, kunnioittavan sääntelyä ja välttävän myöhemmän syytöksen, tiivis työnkuva, jonka tunnepiiri vastaa nitojaa. Loukku on rakenteellinen: yritystekoäly hankitaan kuin ohjelmisto, mutta se käyttäytyy kuin toimintamalli.
Tuotoksen ostaminen ei ole lopputuloksen ostamista
Yritysostajat kysyvät usein, pystyykö järjestelmä tuottamaan tuloksen: yhteenvedon, luokittelun, suosituksen, poiminnan, luonnoksen, riskilipun, hakutuloksen, analyysin tai työnkulun toimenpiteen. Tämä on järkevä kysymys, mutta myös pieni kysymys. Suurempi kysymys on, pystyykö organisaatio muuttamaan tuon tuloksen lopputulokseksi, johon liittyy vastuu. Kuka sen vastaanottaa. Mitä he sillä tekevät. Mitä näyttöä he näkevät. Milloin he saavat hylätä sen. Mitä tapahtuu, kun se on väärin. Miten virhe korjataan. Kuka omistaa mittarin, kun toimittaja on poistunut huoneesta.
TeKOäly-yhteenveto ei ole lopputulos. Asiakastyöntekijä, joka käyttää varmennettua yhteenvetoa nopeampaan ja paremmin dokumentoituun päätökseen, voi olla lopputulos. Riskipisteet eivät ole lopputulos. Työnjakoprosessi, joka ohjaa tapaukset oikeudenmukaisesti, kirjaa perustelut ja käsittelee poikkeukset, voi olla lopputulos. Chatbotin vastaus ei ole lopputulos. Vähentynyt tukikuorma ilman harhaanjohtavia asiakkaita, kadonneita eskalointipolkuja tai näkymätöntä vastuuta voi olla lopputulos. Hankinnan on ostettava polku tuotetusta tuloksesta institutionaaliseen käyttäytymiseen.
Tämä polku ylittää osastorajat. Lakiasiat välittävät toimivallasta ja vastuusta. Tietoturva välittää pääsystä ja eristämisestä. Dataosastot välittävät alkuperästä ja laadusta. Operatiivinen toiminta välittää jonoista ja henkilöstöstä. Talous välittää kustannuksista ja hyötyjen toteutumisesta. Henkilöstöhallinto voi välittää työn suunnittelusta. Vaatimustenmukaisuus välittää näytöstä. Käyttäjät välittävät siitä, auttaako järjestelmä vai tekeekö se heistä hiljaa vastuullisia koneen arvauksista. Tarjouspyyntö, joka kohtelee näitä huolenaiheita hyväksyntäruutuina suunnittelun lähtökohtien sijaan, tuottaa tyylikkään paperityön ja hauraan käyttöönoton.
Erottelu muuttaa myös hinnoittelua. Halpa työkalu, joka vaatii kallista tarkistusta, manuaalista datan valmistelua, räätälöityä integraatiota, lisää hallintoa, epäselvää näyttöä ja paljon tukea, voi olla kallis. Kalliimpi työkalu, jossa on vahvempi vienti, seurattavuus, roolisuunnittelu, datan sopimukset ja päivitysten hallinta, voi olla halvempi käyttää. Hankinta ei näe tätä, jos se vertailee lisenssihintaa ja kutsuu muuta käyttöönotoksi. Käyttöönotto on se, missä teKOäly-projektit pitävät laskunsa.
Tarkistuslista kasvaa väärän keskipisteen ympärille
Yrityshankinta rakastaa tarkistuslistoja, koska tarkistuslistat luovat järjestystä ja puolustettavuutta. Tukeeko järjestelmä kertakirjautumista. Salaako se datan. Tarjoaako se auditointilokit. Tukeeko se meidän kieltämme. Integroituuko se dokumenttijärjestelmiin. Tarjoaako se roolipohjaisen pääsyn. Onko sillä mallinhallintakertomus. Tukeeko se raportointia. Nämä kysymykset ovat hyödyllisiä. Ongelma on, että kyllä voi piilottaa suuren pinta-alan.
Kyllä auditointilokeihin voi tarkoittaa raakoja teknisiä lokeja, jotka vaativat asiantuntijatulkintaa, ei tapauskohtaista näyttöä, jota vaatimustenmukaisuus voi käyttää. Kyllä integraatioon voi tarkoittaa, että API on olemassa, ei sitä, että ostajan sekava sisältömalli on ymmärretty. Kyllä roolipohjaiseen pääsyyn voi tarkoittaa rooleja tuotteessa, ei linjausta organisaation toimivaltamallin kanssa. Kyllä vientiin voi tarkoittaa, että data poistuu tasatiedostoina ilman alkuperää. Kyllä ihmisen valvontaan voi tarkoittaa hyväksymispainiketta. Yritys-teKOälyssä monen kyllä-vastauksen jälkeen pitäisi sanoa näytä minulle hankalissa olosuhteissa.
Tarkistuslistan pitäisi kasvaa toiminnallisten kysymysten ympärille. Minkä näytön on säilyttävä. Mitkä datalähteet ovat auktoritatiivisia. Mitkä kentät ovat liian vanhentuneita. Mitkä käyttötapaukset vaativat deterministisiä tietueita. Mitkä toimenpiteet vaativat ihmisen hyväksynnän. Mistä virheistä on ilmoitettava. Mitkä muutokset vaativat uudelleenarvioinnin. Mitkä toimittajariippuvuudet ovat hyväksyttäviä. Mitkä poistumisoikeudet ovat neuvoteltavissa. Minkä tiimien on muutettava käyttäytymistään. Mitä hallintakeinoja testataan ennen käyttöönottoa. Tuotetarkistuslista ilman toimintamallia on ostoslista keittiöön, jota kukaan ei ole mitannut.
Epämääräisissä vaatimuksissa on outoa mukavuutta. Ne pitävät tarjouspyynnön laajana, vähentävät ristiriitoja ja antavat kaikkien kuvitella, että heidän huolensa on huomioitu. Valitettavasti epämääräiset vaatimukset eivät katoa sopimuksen solmimisen jälkeen. Ne syntyvät uudelleen muutospyyntöinä, viiveinä, riitoina ja ohjausryhmän kalvoina, joissa verbit ovat yhä varovaisempia. Tarkkuus tuntuu hitaalta ennen sopimusta. Usein se on paljon nopeampaa sen jälkeen.
Riskin siirtäminen on usein teatteria
Hankintaprosesseilla pyritään siirtämään riskiä. Sopimukset, takuut, vahingonkorvausvastuut, palvelutasot, sertifikaatit, vakuutukset, tietojenkäsittelyehdot. Näillä on merkitystä. Kypsä ostaminen tarvitsee niitä. Mutta yritys-AI luo riskejä, joita ei voi täysin siirtää, koska ne elävät ostajan kontekstissa. Toimittaja voi tarjota työkalun, suojatoimet, tuen ja todisteet. Ostaja omistaa datan, työnkulun, valtuudet, käyttäjien käyttäytymisen, eskalaatiopolun ja päätöksen, joka ottaa tuotoksen käyttöön. Sopimus ei voi ulkoistaa harkintaa, joka tapahtuu instituution sisällä.
Tässä jotkut organisaatiot tulevat liian itsevarmoiksi. Toimittaja läpäisi tietoturva-arvioinnin. Mallilla on dokumentaatio. Ehdot kattavat tietosuojan. Palvelulla on käytettävyyssitoumukset. Hyvä. Mutta kuka päättää, saako matalan luottamuksen vastausta käyttää vaikutukseltaan suuressa tapauksessa. Kuka huomaa, kun käyttäjät lakkaavat tarkistamasta. Kuka hoitaa asiakkaan haasteen. Kuka varmistaa, että koulutusesimerkit vastaavat todellista työtä. Kuka pysäyttää järjestelmän, kun toimintatapa muuttuu. Jos vastaus on toimittaja, ostaja saattaa ostaa hallintofantasiaa. Jos vastaus on ei kukaan, ostaja on ostanut tulevan välikohtauksen.
Riskin siirtäminen luo myös vääriä kannustimia, kun ostajat pyytävät toimittajia ottamaan vastuuta asioista, joita vain ostaja voi hallita. Toimittaja vastaa poissulkemisilla, varovaisella konfiguraatiolla, paisutetuilla hinnoilla tai epämääräisillä sitoumuksilla. Ostaja vastaa lisää lausekkeilla. Lopulta sopimuksesta tulee pehmustettu huone työnkulun ympärillä, jota kukaan ei ole suunnitellut. Paperilla hyvin turvallista. Vähemmän hyödyllistä tiistaina.
Parempi lähestymistapa on riskin kohdentaminen. Nimeä riski. Kohdista se osa, jonka toimittaja voi hallita. Kohdista se osa, jota ostajan on operoitava. Määrittele yhteiset testit. Määrittele todisteet. Määrittele eskalaatio. Määrittele pysäytysoikeudet. Määrittele muutostenhallinta. Tämä on vähemmän tyydyttävää kuin teeskentely, että riski on viety zip-tiedostossa. Se on myös lähempänä todellisuutta, joka on menestyksekkään toiminnan itsepäinen ominaisuus.
Pilotti ei ole hankintayksikkö
Monet yritysten tekoälyhankinnoista alkavat pilottivaiheella. Se on järkevää. Pilotti vähentää epävarmuutta ja auttaa tiimejä oppimaan. Hankinnan ansa tulee esiin, kun pilotista tulee todistamisen yksikkö. Pilottia suojaavat usein asiantuntijakäyttäjät, kuratoitu data, suora toimittajan huomio, kevennetyt integraatiot, väliaikainen hallintamalli ja yleisö, joka on valmis antamaan anteeksi keskeneräisyyden. Tuotanto on erilaista. Tuotannossa on volyymiä, henkilöstövaihtuvuutta, auditointeja, reunatapauksia, tietoturvarajoitteita, tukipyyntöjä, säilytyssääntöjä, muuttuneita prioriteetteja ja käyttäjiä, jotka eivät olleet mukana innostavassa aloitustilaisuudessa.
Pilotin pitäisi siis testata tuotantoon liittyviä oletuksia, ei vain tuotteen toimivuutta. Pystyvätkö tavalliset käyttäjät suorittamaan työnkulun. Pysyykö vastausten laatu oikealla datalla. Kuinka paljon tarkistusaikaa tarvitaan. Mitkä tietueet tarvitaan auditointia varten. Mitkä poikkeukset ovat yleisiä. Mitkä integraatiopisteet ovat hauraita. Mitä tapahtuu, kun lähde on vanhentunut. Pystyykö järjestelmä kieltäytymään asianmukaisesti. Pystyykö organisaatio tukemaan sitä ilman, että toimittajan insinöörit ovat chatissa koko päivän. Jos näitä kysymyksiä lykätään siihen asti, kun mittakaava on jo hyväksytty, pilotti on teatteria, jossa on paremmat tarjoilut.
Hankinnan yksikön pitäisi olla hallittu toimintasiivu. Siivu sisältää käyttötapauksen, tietolähteet, valtuudet, käyttäjät, tarkistusmenettelyn, näytön, tukimallin, muutosprosessin ja poistumispolun. Se on strategiaa kapeampi ja demoa laajempi. Sitä voi arvioida mielekkäästi, koska se sisältää sekä arvoa tuottavat että kustannuksia aiheuttavat asiat. Jos siivu toimii, mittakaava tarkoittaa tunnetun kaavan toistamista ja mukauttamista. Jos vain työkalu toimii, mittakaava tarkoittaa organisaation löytämistä yksi riippuvuus kerrallaan.
Siksi pilottimittareihin pitäisi kuulua tylsiä lukuja. Tarkistusminuutit tapausta kohden. Korjattujen tulosteiden osuus. Tapaukset, jotka on hylätty puuttuvien todisteiden vuoksi. Lähdedatan tuoreusvirheet. Eskalaatioiden määrä. Käyttäjien erimielisyyden syyt. Viennin kattavuus. Häiriöt, jotka vaativat toimittajan tukea. Aika, joka kuluu haastetun tuloksen selittämiseen. Nämä mittarit eivät ole yhtä hohdokkaita kuin tuottavuuden kasvu. Ne ovat myös niitä lukuja, jotka ratkaisevat, säilyykö tuottavuus.
Datan käyttöoikeus ei ole liitännäisluettelo
Hankinta-asiakirjoissa kysytään usein, mihin järjestelmiin tuote yhdistyy. Se on välttämätöntä mutta riittämätöntä. Liitäntä on ovi. Se ei kerro, onko huoneessa merkittyjä hyllyjä, ajantasaisia tietueita, laillista käyttöoikeutta, yhtenäisiä tunnisteita, käyttökelpoisia asiakirjoja, säilytettyä kontekstia tai lattiaa. Yritysdata harvoin odottaa siististi. Siinä on perittyjä kenttiä, päällekkäisiä tietueita, salaisuuksia sisältäviä PDF-tiedostoja, SharePoint-arkeologiaa, osastokohtaisia luokituksia, omistajattomia tiedostoja ja tiedostoja, joiden nimeen on lisätty final, koska optimismi on uusiutuva luonnonvara.
Ostajan on ymmärrettävä, mitä tekoälyjärjestelmä tarvitsee datasta, ei vain sitä, missä data sijaitsee. Tarvitseeko se kokonaisia asiakirjoja vai poimittuja kenttiä. Tarvitseeko se nykytilaa vai historiallisia tilannekuvia. Tarvitseeko se käyttöoikeustietoisen haun. Tarvitseeko se alkuperäketjua. Tarvitseeko se jäsenneltyjä tunnisteita. Tarvitseeko se poistojen levittämistä. Tarvitseeko se datan laadun kynnysarvoja. Tarvitseeko se ihmisen tekemää korjausta. Jokainen tarve muuttaa integraation kustannuksia ja hallintaa. Liitäntä, joka jättää nämä tarpeet huomiotta, on vain letku. Letkut ovat hyödyllisiä. Ne ovat myös syy siihen, miksi kellarit tulvivat.
Datan käyttöoikeudella on juridisia ja sosiaalisia ulottuvuuksia. Järjestelmä voi teknisesti lukea lähdettä, mutta silti siltä voi puuttua oikeus käyttää sitä mallin koulutukseen, analytiikkaan, työntekijöiden seurantaan tai automatisoituun päätöksenteon tukeen. Käyttäjät voivat luottaa tietovarastoon yhteen tarkoitukseen ja vastustaa, kun sen sisällöstä tulee polttoainetta toiseen. Hankinta, joka kysyy voimmeko yhdistää ennen kuin se kysyy saammeko käyttää, luo tulevaisuudessa yllätyksiä. Yllätys on huono suostumuksen mekanismi.
Hyvään tekoälyn hankintaan kuuluu siis datan due diligence ennen sopimuksen tekemistä tai ainakin ennen laajentamista. Tutki sotkuinen aineisto. Testaa poimintaa. Tarkasta käyttöoikeudet. Mittaa päällekkäisyys. Tunnista vanhentuneet kentät. Nimeä datan vastuuhenkilöt. Tarkista säilytys ja suostumukset. Ymmärrä, mitä dataa ei voi siirtää. Hinnoittele siivous. Jos tämä tuntuu ostoksen viivyttämiseltä, muista, että ostos olisi löytänyt saman sotkun myöhemmin, vain sopimus mukanaan.
Muutoshallinta on tuote
Yritystason tekoäly ei pysy paikallaan. Mallit päivittyvät. Kehotteet muuttuvat. Hakemistot rakennetaan uudelleen. Käytännöt vaihtuvat. Datalähteet siirtyvät. Käyttäjät löytävät reunatapauksia. Tietoturvasäännöt tiukkenevat. Uusia säädöksiä tulee. Järjestelmä, joka läpäisi hankinnan, ei ole se järjestelmä, jota organisaatio käyttää vuotta myöhemmin. Muutoshallinta ei siis ole hallinnollista lisätaakkaa tuotteen ympärillä. Se on osa tuotetta.
Hankinnan tulisi kysyä, miten käyttäytymisen muutoksia ehdotetaan, testataan, hyväksytään, viestitään, peruutetaan ja todistetaan. Voiko ostaja viivyttää mallipäivitystä. Voidaanko kehote-muutokset versioida. Voidaanko hakumuutoksia vertailla. Voidaanko käytäntökokonaisuuksia lukita. Voiko toimittaja tarjota julkaisutiedotteita, jotka liittyvät operatiiviseen riskiin eivätkä markkinointipuheeseen. Voidaanko vaikutuksiltaan suuria tapauksia testata regressiolla ennen käyttöönottoa. Voiko organisaatio nähdä, mihin tapauksiin muutos vaikutti. Ilman näitä oikeuksia ostaja ei ole ostanut järjestelmää. Se on tilannut liikkeen.
Sisäinen muutos on yhtä tärkeää kuin toimittajan muutos. Osasto muuttaa lomaketta. Käytäntötiimi tarkistaa ohjeistusta. Datatiimi muuttaa kentän nimeä. Esimies muuttaa henkilöstöä. Lakituikinta muuttuu. Tekoälyjärjestelmät toimivat näiden rajojen yli, joten pienet sisäiset muutokset voivat siirtää tuloksia. Hankinta ei voi ratkaista tätä yksin, mutta se voi vaatia toimintamallin, joka havaitsee ja hallitsee liikkeen. Jos jokaista muutosta kohdellaan jonkun muun paikallisena parannuksena, tekoälytyönkulusta tulee käytävä, jossa ovet aukeavat ihmisiin.
Hyvä muutoshallinta antaa innovaatiolle reitin. Se ei estä päivityksiä. Se tekee päivityksistä luettavia. Tiimit voivat parantaa malleja ja työnkulkuja nopeammin, kun ne tietävät, miten testata, hyväksyä ja palauttaa. Muutoshallinnan vastakohta ei ole ketteryys. Se on hallitsematon ajautuminen julkaisukalenterin kanssa.
Käyttäjät eivät ole käyttöönoton kohteita
Hankinnassa käyttäjiä kohdellaan usein käyttöönoton kohteina. Kouluta heitä, viesti hyödyistä, mittaa käyttöä, juhli edelläkävijöitä, poista kitkaa. Osa tästä on hyödyllistä. Mutta käyttäjät ovat myös valvontapisteitä, asiantuntijoita ja varhaisia varoitusjärjestelmiä. Jos he eivät luota järjestelmään, he saattavat vastustaa muutosta. He saattavat myös havaita, että työnkulusta puuttuu näyttö, auktoriteetti, aika tai korjausmahdollisuus. Hankintaprosessi, joka näkee käyttäjät lähinnä vakuutettavina, jättää huomiotta heidän mukanaan kulkevan tiedon.
Ennen ostamista puhu niille, joiden työhön tekoälyn tuotokset sulautuvat. Kysy, mitä näyttöä he tarvitsevat toimiakseen. Mitkä tapaukset ovat vaarallisia. Mitkä tietokentät ovat epäluotettavia. Mitkä poikkeukset vievät aikaa. Mitä päätöksiä he eivät delegoisi. Mitkä virheet olisivat noloja, haitallisia tai laittomia. Mitkä osat nykyisestä prosessista ovat epävirallisia, koska virallinen järjestelmä ei ole koskaan oppinut todellisuutta. Nämä vastaukset eivät ole muutosvastarintaa. Ne ovat vaatimuksia, joissa on sormenjäljet.
Oston jälkeen käyttäjäpalautteen tulisi ohjata muutoksenhallintaa ja näytön keräämistä. Korjauksia, ohituksia, eskalaatioita ja kieltäytymisen syitä tulisi mitata ja käsitellä. Jos käyttäjät ohittavat järjestelmän, selvitä, onko se väärässä, hidas, epäluotettu, huonosti sijoitettu, kannustimien vastainen vai yksinkertaisesti vähemmän hyödyllinen kuin hankintakertomus antaa ymmärtää. Pelkkä käyttö on huono arvon mittari. Ihmiset käyttävät huonoja järjestelmiä pakotettuina ja välttävät hyviä järjestelmiä, kun ympäröivä prosessi rankaisee heitä harkinnan käytöstä.
Käyttäjät ansaitsevat myös selkeyttä. Jos tekoälyn tuotos on neuvoa-antavaa, sano se. Jos se on pakollista, kerro, kuka omistaa päätöksen. Jos ohitukset ovat tervetulleita, älä rankaise niitä poikkeamina. Jos näyttö on pakollista, anna aikaa sen tarkistamiseen. Yritystekoäly epäonnistuu, kun käyttäjistä tulee inhimillisiä puskureita itsevarman työkalun ja epäselvän organisaation välillä. Se ei ole käyttöönottoa. Se on eristämistä.
Poistumistesti tulisi tehdä ennen sisäänpääsyä
Poistuminen on laiminlyötyin hankintavaatimus, koska kukaan ei halua keskustella lopusta alussa. Silti poistuminen on se kohta, jossa ostajan valta konkretisoituu. Voiko organisaatio lähteä datan, metadatan, kehotteiden, konfiguraatioiden, arviointitietojen, auditointilokien, käyttäjäpalautteen, mallituotosten, korjauspolkujen ja poistotodisteiden kanssa ehjinä. Voiko se sammuttaa järjestelmän menettämättä kykyä selittää aiempia päätöksiä. Voiko se siirtyä toiseen työkaluun ilman, että henkilöstön täytyy kuvakaapata organisaation muisti sivu kerrallaan.
Poistumistestin tulisi olla käytännöllinen. Ennen laajamittaista käyttöönottoa vie edustava osa tiedoista. Palauta se jonnekin muualle. Tarkista tunnisteet, aikaleimat, alkuperä, käyttöoikeudet, liitteet, korjaukset ja päätöstietueet. Varmista, että näyttö pysyy luettavana. Tarkista, vastaako sopimuskieli teknistä todellisuutta. Jos vienti on hidasta, tietoa menettävää tai riippuvaista toimittajan räätälöidystä työstä, hinnoittele se riippuvuus. Toivo ei ole poistumisstrategia. Se on mielentila, jossa versionhallinta on heikkoa.
Poistumisoikeudet parantavat myös nykyistä suhdetta. Kun data ja tietueet ovat siirrettäviä, toimittajat kilpailevat palvelulla ja arvolla vangitsemisen sijaan. Ostajien ei tarvitse pelätä rehellistä arviointia. Sisäiset tiimit voivat suunnitella vaihdettavuus mielessä. Arkkitehtuurista tulee puhtaampaa, koska merkityksen on oltava eksplisiittistä. Poistuminen ei ole pessimismiä. Se on hygieniaa.
On olemassa hankintasananlasku, joka odottaa kirjoittamistaan: älä koskaan osta tekoälyjärjestelmää, jota et voi jättää unohtamatta, miksi käytit sitä. Se on liian pitkä mukiin, mikä on luultavasti hyvä. Mukeilla on jo tarpeeksi vastattavaa toimistokulttuurissa.
Ansoista irti
Hankinta-ansasta irti pääseminen ei vaadi sankarillista uudelleenkeksimistä. Se vaatii ostamisen painopisteen siirtämistä tuotteesta työjärjestelmään. Määrittele käyttötapaus tarkasti. Testaa oikeaa dataa varhain. Hinnoittele arviointityö. Vaatimus: todisteita, jotka vastaavat institutionaalisiin kysymyksiin. Kohtele muutoksenhallintaa ensisijaisena vaatimuksena. Osta poistumisoikeudet. Ota käyttäjät mukaan toimialueen todistajina. Nimeä vastuuhenkilö lopputulokselle. Mittaa korjausten ja poikkeusten taakka. Vaadi toimittajia esittelemään järjestelmä hankalissa olosuhteissa, sillä hankalat olosuhteet ovat niitä, joissa yritysohjelmistot viettävät suurimman osan aikuiselämästään.
Tämä tekee hankinnasta aluksi vähemmän siistiä. Se tuo pintaan ristiriitoja, jotka tarkistuslistat aiemmin piilottivat. Datan omistajat huomaavat velvoitteensa. Lakiosasto tarvitsee operatiivisia yksityiskohtia. Tietoturva vaatii todisteita. Operatiivinen toiminta kysyy henkilöstöä. Talous näkee kustannuksia, jotka aiemmin odottelivat pensaissa. Hyvä niin. Piilotettu kustannus on silti kustannus, vain omahyväinen sellainen.
Tavoitteena ei ole hidastaa ostamista ikuisesti. Tavoitteena on tehdä ostamisesta niin rehellistä, että käyttöönotto voi edetä. Selkeä operatiivinen sopimus vähentää myöhempää kinastelua. Testattu datapolku vähentää integraatioyllätyksiä. Todellinen arviointimalli vähentää käyttöönottoteatteria. Toimiva poistumistie vähentää pelkoa. Hankinnasta tulee tapa luoda edellytykset arvon syntymiselle sen sijaan, että se olisi rituaali, joka valitsee vakuuttavimman lupauksen.
Alkutarinan voittava demo ei ollut väärässä. Se oli puutteellinen. Se näytti vastauksen, ei vastauksen ympärillä olevaa instituutiota. Yritys-AI:n hankinnassa on opittava ostamaan se instituution puoli: tylsät oikeudet, asiakirjat, roolit, testit ja poistumistiet, jotka muuttavat kyvykkyyden hallituksi työksi. Muuten tarjouskilpailu valitsee edelleen järjestelmiä, jotka näyttävät valmiilta sopimuksen solmimishetkellä ja alkavat muuttua todellisiksi vasta, kun kaikki ovat jo sopimuksellisesti sitoutuneita. Se on kallis tapa oppia se, minkä parempi kysymys olisi voinut paljastaa aiemmin.