Attól, hogy egy AI-megoldást meg tudsz építtetni, még nem biztos, hogy érdemes. A saját fejlesztés akkor indokolt, ha olyan üzleti képességet ad, amelyet kész termékkel nem tudsz megfelelően biztosítani. Ehhez az előnyhöz a fenntartás árát is hozzá kell számolnod.
Egy előfizetéses termék bemutatóján minden egyszerűnek látszik. Bekapcsolod, összekötöd az adataiddal, és használod. Az egyedi fejlesztési ajánlat más ígérettel érkezik: pontosan úgy fog működni, ahogyan a cégednek szüksége van rá.
Mindkettő vonzó. És mindkettőből hiányozhat az a rész, amely később a legtöbb munkát adja.
A kész termékhez lehet, hogy át kell alakítanod a folyamatodat. A saját rendszerhez pedig olyan feladatokat kell tartósan vállalnod, amelyeket eddig a szoftverszállító végzett. A döntés ezért arról is szól, milyen munkát veszel a céged nyakába, és mit kapsz érte cserébe.
Miért kellene ezt csak neked másképp végezned?
A „nálunk minden egyedi” drága kiindulópont. Egy cég működésében lehetnek valóban különleges elemek, de sok eltérés pusztán megszokás: egy régi táblázat, egy felesleges jóváhagyás vagy egy kivétel, amelynek már senki nem emlékszik az okára.
Ha ezekhez fejleszttetsz rendszert, a korábbi kerülőutakat tartósítod. Ezért érdemes előbb megvizsgálni, mely eltérésből származik tényleges előny, és melyiket lehetne elhagyni. A Lean és az AI kapcsolatáról szóló cikkben ezt a folyamat oldaláról jártuk körül. A beszerzésnél ugyanennek közvetlen ára van: minden megőrzött kivétel növelheti a fejlesztést, a tesztelést és a későbbi karbantartást.
Kész megoldással indulnék ott, ahol a feladat általános, a termék a fontos követelményeket teljesíti, és a hozzá szükséges alkalmazkodás vállalható. Nem kell saját dokumentumfeldolgozót építened pusztán azért, mert a beérkező dokumentumokon a te céged neve szerepel.
Az egyedi fejlesztés indoka ott kezd erőssé válni, ahol egy kész termék korlátja már bevételt, érdemi kapacitást vagy szükséges ellenőrzési lehetőséget vesz el. Lehet ilyen egy sajátos munkafolyamat, szigorú adatkezelési követelmény vagy olyan használati volumen, amelynél az egyedi megoldás teljes költsége kedvezőbbnek bizonyul. Ezt azonban ki kell számolni és próbálni; az egyediség önmagában nem érv.
Lehet, hogy csak egyetlen részt kell megépítened
A vásárlás és a fejlesztés között nincs éles választóvonal. Vásárolhatsz kész képességet, és köré építheted azt a részt, amely a saját működésedhez kell.
Vegyünk egy szemléltető példát: egy ipari alkatrészeket forgalmazó cég e-mailben kap ajánlatkéréseket. A mellékletek feldolgozása és a kért tételek kigyűjtése olyan feladat, amelyre érdemes kész megoldást keresni és kipróbálni. Az üzleti nehézség viszont máshol lehet: melyik helyettesítő alkatrész ajánlható, melyik raktárból teljesíthető a rendelés, és milyen feltételeket ígérhet az értékesítő?
Ilyenkor indokolt lehet saját rendszerkapcsolatot és ellenőrzött döntési szabályokat építeni a vásárolt feldolgozó köré. Az AI segíthet értelmezni az ajánlatkérést, miközben az árakat, a készletet és a megengedett helyettesítéseket a megfelelő nyilvántartások és szabályok határozzák meg.
Ebben a példában a saját fejlesztés célja az, hogy a cég a saját kínálatából gyorsabban készítsen vállalható ajánlatot. Ehhez nem szükséges saját alapmodellt fejlesztenie. Sőt, az egyedi rész egy része hagyományos szoftver is lehet.
A brit kormány AI Playbookja is több beszerzési utat különböztet meg: kész terméket, meglévő rendszerhez adott AI-képességet és megrendelt vagy közösen fejlesztett megoldást. Közszférának készült útmutató, de a választási helyzet a vállalatok számára is hasznos: előbb határozd meg, mire van szükséged, és ahhoz válassz megvalósítási módot.
A hiányzó funkció súlya fontosabb a funkciók számánál
Egy termék teljesítheti az igényeid hosszú listájának szinte minden pontját, és mégis alkalmatlan lehet a feladatra. Ha az egyetlen hiányossága az, hogy nem tudja elkülöníteni a különböző ügyfelek adataihoz való hozzáférést, azt nem ellensúlyozza tíz kényelmes szerkesztési funkció.
Más hiányosságokkal viszont együtt lehet élni. Egy eltérő képernyőelrendezés vagy másként készülő belső riport ritkán indokol önmagában saját rendszert.
Az értékelésben ezért válaszd külön, ami nélkül nem használhatod a megoldást, attól, amihez a csapat képes alkalmazkodni. A bemutatón mindkettő kívánságnak látszik. A döntésnél egészen más súlyuk van.
Ugyanazt az eredményt árazd be mindkét oldalon
Az előfizetés havidíját nem lehet értelmesen összevetni egy fejlesztési ajánlat végösszegével. Az egyikből hiányozhat a bevezetés munkája, a másikból a következő évek működtetése.
Az összehasonlításhoz ugyanazt a használati mennyiséget, minőségi elvárást és időszakot vedd alapul. A kész terméknél számolj az adatkapcsolatokkal, a használathoz kötött díjakkal és a megmaradó kézi feladatokkal. Saját fejlesztésnél a hibajavítás, a biztonsági frissítés, a modellváltozások utáni ellenőrzés és a támogatás is kerüljön bele. Mindkét oldalon számít a saját munkatársak ideje.
A várakozásnak is lehet ára. Ha az egyedi rendszer csak jóval később használható, addig elmaradhat egy olyan javulás, amelyet kész termékkel már elérhetnél. A gyorsabb indulás értékét ugyanakkor csak akkor érdemes beszámítani, ha a termék tényleg alkalmas a feladatra.
Külön becsüld meg, mi történik nagyobb forgalomnál és több kivételes esetnél. Lehet, hogy a kész termék díja nő meg. Lehet, hogy a saját rendszerhez kell több üzemeltetési munka. A bizonytalan tételeket tartományként kezeld, ne rejtsd el őket egy pontosnak látszó végösszegben.
A saját kód még nem jelent függetlenséget
Egy egyedi rendszer is függhet külső modelltől, felhőszolgáltatótól vagy attól az egy fejlesztőtől, aki érti a működését. A kész termék pedig bizonyos esetekben könnyebben lecserélhető, mint egy rosszul dokumentált saját megoldás.
A váltás lehetőségét konkrétan vizsgáld meg. Ki tudod vinni az adataidat használható formában? Átadhatók másnak a beállítások és a szükséges dokumentumok? Mi történik a saját szabályaiddal, a korábbi eredményekkel és az ellenőrzéshez használt példákkal? Mekkora munkával állhat át a csapat?
A tanácsadó kiválasztásáról szóló cikkben ezt az átadás felől vizsgáltuk. Itt a beruházási döntés része: mennyibe kerül majd, ha az első választásod már nem megfelelő?
A következő megrendelés a bizonytalanságot csökkentse
Ha a döntés még azon múlik, hogy a kész termék kezeli-e a saját dokumentumaidat, ezt kell kipróbálni. Ha az egyedi fejlesztés várható költsége bizonytalan, előbb a nehéz rendszerkapcsolatot kell feltárni. A teljes megoldás megrendelése túl drága módja annak, hogy ezekre választ kapj.
Kérj korlátozott próbát a döntő követelményekre, megfelelően védett, a valós munkát képviselő adatokkal. Legyenek benne hiányos bemenetek, kivételek és olyan helyzetek is, amikor a rendszernek jeleznie kell, hogy nem tud megbízhatóan továbblépni. Előre rögzítsd, milyen eredmény mellett választod az adott irányt.
A megalapozott döntés végére egy mondatban el kell tudnod mondani, melyik képességet veszed meg, mit építtetsz hozzá, és miért éri meg vállalni a különbséget. Ha a saját fejlesztés mellett csak az szól, hogy „pont olyan lesz, amilyet szeretnénk”, még nincs kész az üzleti indoklás.
Ha kész termék és egyedi fejlesztési ajánlat között kell döntened, írd meg, melyik folyamatot javítanád, és hol akadt el az összehasonlítás. Ebből kiindulva tudjuk meghatározni, milyen független szakértői értékelésre van szükséged.