Mit veszít egy cég, ha nincs mögötte fejlesztő, aki az üzletet is érti?

01Growth Systems

Nem az a hátrány, aminek látszik

Az elmúlt években minden cég hozzáfért ugyanazokhoz az eszközökhöz. Ez jó hír volt: olyan képességek lettek elérhetők havidíjért, amikhez korábban fejlesztőcsapat kellett.

Van viszont egy következménye, ami csak most kezd látszani. Ha mindenki ugyanazt az eszközt vette meg, akkor amit az eszköz megmutat, az nem előny. A versenytárs ugyanazt látja, ugyanazokat a javaslatokat kapja, és ugyanabban a sávban dönt.

A hátrány tehát nem az, hogy egy cégnek nincs saját fejlesztője. Az, hogy minden döntése addig terjed, ameddig a megvásárolható eszközök határa. Ez a határ jóval beljebb van, mint általában gondolják, és nem ott, ahol a cég problémái vannak.

02Growth Systems

Miért kevés önmagában az IT-tudás?

Ezt érdemes pontosan kimondani, mert a szokásos válasz — „kell egy fejlesztő” — nem oldja meg.

A fejlesztő, aki nem érti az üzletet, jó eszközt épít rossz kérdésre. Technikailag kifogástalan megoldást ad valamire, ami nem az, ami fáj. Ez nem hozzáértés kérdése: a probléma megfogalmazása nem az ő munkája, és nincs is meg hozzá a kontextusa.

Az üzleti ember, aki nem tud fejleszteni, jó kérdést tesz fel, amire nem kap választ. Tudja, mit szeretne megtudni, de nem tudja megítélni, hogy amit kap, az válasz-e vagy csak úgy néz ki. És nem tudja, mi lenne olcsó és mi drága, ezért vagy túl keveset kér, vagy olyat, ami hónapokba kerül.

A hiány tehát nem az egyik vagy a másik, hanem az, hogy a kettő egy emberben vagy egy szoros munkakapcsolatban legyen. Külön-külön mindkettő gyakori. Együtt ritka, és pont ez a ritka rész az, ami eldönti, hogy egy technikai befektetés hoz-e valamit.

03Growth Systems

Hol látszik ez a napi működésben?

Négy helyen, és mind a négy felismerhető anélkül, hogy bárki technikai szót használna.

Adathozzáférés. Ami nincs benne egy rendszer exportjában, arról nem lehet dönteni. Ez elsőre technikai korlátnak hangzik, a következménye viszont üzleti: a kérdés kezd igazodni az eszközhöz. Nem azt kérdezzük, ami érdekes, hanem azt, amire van adat. Egy idő után már fel sem merül a másik kérdés.

Összekötés. Ha két rendszer adatát rendszeresen kézzel másolják egyikből a másikba, az nem elsősorban időköltség. Hibaforrás. A kézi átmásolás időnként elmarad, időnként elcsúszik, és utólag nem derül ki, mikor.

Ismételhetőség. Ami kézzel megy, az annyiszor fut le, ahányszor valakinek van rá ideje. Ez a gyakorlatban azt jelenti, hogy a legterheltebb időszakban marad el — vagyis pont akkor, amikor a legtöbbet érne.

Mérés. Ha a mérőrendszert nem lehet a saját kérdéshez alakítani, akkor a kérdés alakul az eszközhöz. Ez a legnehezebben észrevehető a négy közül, mert semmi nem romlik el látványosan. Egyszerűen olyan döntések maradnak meg, amikhez van kész mutató.

04Growth Systems

Nem minden probléma technikai probléma

Ezt is oda kell írni, különben a fenti lista mindenre ráhúzható.

Sok cégnél a szűk keresztmetszet nem az adat és nem a rendszer. Van, ahol nincs elég jó anyag, amit ki lehetne tenni. Van, ahol az ajánlat nem elég világos. Van, ahol egyszerűen kevés az ember. Ezekre a fejlesztés nem válasz, és ha valaki mégis annak adja el, az drága kitérő lesz.

A megkülönböztetés egyszerű: a technikai korlát ott van, ahol tudod, mit szeretnél megtudni vagy megcsinálni, és a rendszer nem engedi. Ha nem tudod, mit szeretnél, akkor nem technikai korlátod van.

05Growth Systems

Mit érdemes megkérdezni magadtól?

Nem trendekről szól a dolog, és nem is arról, mi lesz néhány év múlva. Három kérdés, ami a mai működésre vonatkozik:

Van-e olyan döntés, amit azért nem hoztok meg, mert nincs hozzá adat — és tudjátok is, hogy melyik az?

Van-e olyan adat, amit rendszeresen kézzel másoltok egyik rendszerből a másikba?

Van-e olyan elemzés vagy riport, ami csak akkor készül el, ha valakinek épp van rá ideje?

Ha mindháromra nem a válasz, akkor ez a cikk nem rólad szól. Ha bármelyikre igen, akkor a korlát megvan — és nem attól fog eltűnni, hogy jobb eszközt vesztek.