IT paslaugų teikėjas susideda iš darbo sluoksnių, kurie tarpusavyje mažai susiję. Yra kodo kūrimas ir priežiūra, yra bilietų ir incidentų sprendimas, yra architektūra ir projektavimas, yra projektų valdymas kliento atžvilgiu, ir yra ikipardavimo veikla: pasiūlymai, koncepcijų patvirtinimai (proof of concept), techninis konkurso pagrindimas. Šiose kategorijose darbo valandos labai skiriasi priklausomai nuo užsakymo. Palaikymo skyrius veikia apimties ir pasikartojimo principu. Architektūros komanda veikia su nedideliu skaičiumi labai patyrusių žmonių. Sandorio rezultatą lemia tai, kuriam iš šių sluoksnių klientas teikia didžiausią svarbą, o tai skiriasi priklausomai nuo konkurso, kliento ir projekto etapo.
Trys kategorijos, kurios pasireiškia visur — DI perima užduotį, DI atlieka darbą, o žmogus patvirtina arba atmeta, arba darbas išlieka žmogaus rankose — kerta IT sektorių skersai, ir netolygiai. Bilietų sprendimas dėl žinomų problemų dalinai gali būti automatizuojamas; pirminė peržiūra, dėsningumo atpažinimas, sprendimo pasiūlymas remiantis ankstesniais atvejais. Kodo generavimas rutininėms programinės įrangos dalims persikelia link DI su recenzentu, kuris patvirtina rezultatą. Architektūriniai sprendimai, neaiškaus kliento poreikio pavertimas veikiančia sistema ir pasitikėjimo su užsakovu palaikymas kol kas išlieka žmogaus darbu, nes tam reikalingas vertinimas, kurio negalima gauti iš esamų duomenų dėsningumo.
Pokytis, kurį tai sukelia, nėra apie tai, ar DI gerai koduoja. Jis yra apie tai, kas atsitinka tiekėjų palyginimui, kai dalis to darbo atliekama savarankiškai. Atsako laikas palaikymo srityje anksčiau buvo darbuotojų skaičiaus ir planavimo rezultatas; jei pirminė peržiūra didžia dalimi automatizuota, greitis nebeliudija apie gerą komandą, o apie gerai sukonfigūruotą sistemą, o tokią sistemą konkurentai gali lygiai taip pat nusipirkti arba pasistatyti. Kas tuomet išlieka skiriamuoju bruožu, nėra pats greitis, o tai, kas vyksta tais atvejais, kai sistema neišsprendžia problemos — kas tuomet vis tiek suranda sprendimą, o kas priverčia klientą laukti.
Toks pats modelis matomas ir pasiūlymų procesuose. Techninio pasiūlymo sudarymas iš esamų komponentų yra darbas, kurį dalinai galima automatizuoti. Kai tai vyksta keliose šalyse, dalyvaujančiose konkurse, pasislenka tai, kur klientas vis dar mato skirtumą: ne pasiūlymo greityje, o tame, ar pasiūlymas tinka tai konkrečiai situacijai, ir kas tai gali paaiškinti nesiremdamas šablonu.
Ar IT įmonė tai jau taip organizavo, priklauso nuo to, kur ji skiria savo žmones. Įmonė, kuri savo patyrusius architektus vis dar didžia dalimi skiria standartinio kodo rašymui, turi mažai pajėgumų pokalbiui su klientu, kur sprendžiamas sandoris. Įmonė, kuri tą darbą jau perkėlė — DI rutininiam darbui, žmonės vertinimui — tas valandas atlaisvino tiksliai tai daliai, kuria dabar laimima. Tai nėra sprendimas, priimamas per ketvirtį; jis kyla iš ankstesnių sprendimų dėl priemonių, dėl to, kas atlieka kokį darbo tipą, ir dėl to, kiek organizacija pasitiki automatizuoto rezultato priežiūra. Ką darbdavys su tuo daro savo darbuotojų atveju, priklauso nuo darbdavio; tam taikomi atskiri teisiniai reikalavimai, nepriklausomai nuo klausimo, kuris darbas techniškai gali būti perduotas.
Ši dinamika nėra unikali IT sektoriui. Tas pats pokytis — nuo apimties ir greičio prie vertinimo ir paaiškinimo — kitaip vyksta finansinių paslaugų sektoriuje, kur svarbiausia yra konsultacijos ir rizikos vertinimas, ir vėl kitaip statybų sektoriuje, kur planavimas ir sąmatų sudarymas persikelia, tačiau darbai statybvietėje išlieka žmogaus darbu. Klausimą, kuris darbas šioje konkrečioje įmonėje jau perkeltas, o kuris ne, galima atsakyti naudojant [darbo analizę, kuri kiekvienai užduočiai įvertina, ar DI ją perima, dalinai perima su priežiūra, ar ne](https://ftetoai.nl) — tai atskiras žingsnis, nesusijęs su palyginimu su konkurentais.
Šio pokyčio rizika nėra ta, kad tiekėjas praranda, o ta, kad jis nežino, kuo. Pasiūlymas, kuriame sakoma, kad esate greitesnis, svetainė, žadanti stabilumą, pardavimo pristatymas, besiremiantis kompetencija — tai visi teiginiai, o teiginiai tampa pranašumu tik tada, kai juos galima pagrįsti lyginant su tuo, ką klientas mato kitur. Nustatęs atsilikimą vienoje dimensijoje, galite pasinaudoti metodika, skirta atsilikimo konkrečioje dimensijoje panaikinimui ir sužinoti, kokios yra galimybės, o kas nori pagrįsti teiginį prieš klientui apie tai paklausus, savo kokybės teiginių patikra dėl pagrindimo rasite, kaip tai daryti sistemiškai.
Įvardinkite, kuo, jūsų nuomone, jūsų įmonė laimi — greičiu, kaina, kompetencija, patikimumu — ir patikrinkite, kuriuos iš šių teiginių šiandien galite pagrįsti įrodymais lyginant su konkurentu. Tai tiksliai tai, ką atlieka nemokamas dimensijų patikrinimas: ne visapusiška lyginamoji analizė, tačiau pirmas įspūdis, kurie teiginiai yra tvirti, o kurie kol kas kabo ore. Visapusiška konkurencinė lyginamoji analizė su įrodymų matrica kiekvienai dimensijai yra kūrimo stadijoje.