Üdv,

Én nagyon cinikus vagyok, szerintem az ilyesmi többnyire nem működik, mert a vevő minden kifizetett óráért konkrét munkát - oktatást vagy fejlesztést - szeretne kapni.

Úgy értem, ezeket a módszertanokat és sajnos az ERP egész kulturáját nagyon nagy világcégeknek találták ki a nyolcvanas évek körül, ahol egyrészt megvenni még ötven napot abszolút nem volt nagy tétel, ezen nem vesztek össze, másrészt a nagy cégek hierarchiájában a fedezd-a-segged bürokratikus módszerek teljesen elfogadottak voltak.

Ma a jellegzetes ERP ügyfél egy 100 fős cég, aminek van egy tulajdonosa és kb. még a székek beszerzéséről is az dönt. Egy agy, sok kéz. Ez nem csak kis magyar cégekre jellemző, ismerek ilyenből viszonylag komoly multit is, azért tud így működni, mert a raktártól a bérszámfejtésen át még részben az üzletkötésig is (külsős ügynökök) mindent outsourcol.

Ez a típus gyakorlatilag két dologért hajlandó fizetni, oktatásért és fejlesztésért. Innen kezdve sok módszertan nincs, felváltva oktatunk meg az oktatás közben felmerült igényeket lefejlesztjük, amíg mindenki nem hepi, vagy el nem fogy a budget, akkor meg szkanderozás lesz.

Minden módszertan úgy kezdődik, hogy igények felmérése. Ezen a ponton meg is bukott, ugyanis az emberek csak azokat az igényeiket ismerik, amiket az előző szoftver nem tudott kielégíteni. Fogalmuk sincs, hogy mennyi olyan feature van, ami az előzőben volt, ebben meg majd nem lesz. Ez gyönyörű balhékhoz vezet, főleg ha egy rugalmas Nagy Machinátor szerű rugalmas dologról térnek át mondjuk egy Navira, és hirtelen rájönnek, hogy basszus, itt ha elrontasz egy címet egy számlán jóvá kell írnod, nincs utólagos javítás stb. stb.

(Én Ukrajnában szoktam hozzá, hogy azzal kezdem, hogy nincs utólagos javítás csak jóváírás, meg hogy kb. ugyannnak kell lennie egy számlán mint a megrendelésen volt, nincs ilyen, hogy felét számlázd ki ennek a cégemnek, felét meg annak de tök mást írjál már rá és ilyenek mert akkor a reportok nem fognak érni semmit, ezen a ponton mindenki rögtön eldönteni, hogy jó akkor Navit csak Nyugat-Európában használunk azt' Ukrajnában maradunk a helyi szoftvernél, és kész.)

Úgyhogy végső soron nincs más megoldás, mint felváltva mutogatni a szoftvert meg módosítani rajta, addig ismételgetve, amíg használni is tudják meg nem is utálják csak max. egy kicsit.

Kapcsolódik még ehhez a következő problémakör. A cégtulajdonos bizalma nem egyenlően oszlik meg belsősök és külsősök között. Szívesebben fizet egy alkalmazottnak évi 20 ezer eurót, hogy adatot rögzítsen, de ha kap egy külsős cégtől egy ajánlatot, hogy ötezer euróból ezt automatizálni lehetne, akkor azt drágának tartja. Nyilván a bizalom eltérő foka miatt, az alkalmazott kb. családtagnak minősül, a külsős cég gyanús pumpolónak.

Valahol, eredetileg azt a fogalmat, hogy tanácsadás vagy consulting, arra találták ki, úgy értelmezték, hogy a bevezetés munkájárt a belsősök, a belsős IT végzi és a külsősök csak segítenek nekik, tanácsokat osztogatnak.

Valahol egy ponton ez megváltozott, ma az ERP tanácadócéget úgy tekintik, mint egy építőipari céget, aki megrendelésre leszállít egy testreszabott rendszert és alig kell tenni valamit érte. Ezért erőltetik a fixáras projekteket, ezért nem szeretnek másért fizetni, mint fejlesztésért és oktatásért és ezért nemigen lehet ilyen módszertanokat használni ma. Mert senki nem fizet egy doksiért.

Azt eléggé világosan tudjuk, hogy ez nem működik jól, érdekellentétekhez vezet és így tovább, és ennek végül is egy megoldása van: annál jobban működik egy projekt, minél jobban a belsősök, jellemzően IT végzik, ha egy cégvezetés a belső IT felelősségének tartja a sikeres bevezetést és a külsős tanácsadócég csak segít ebben, akkor az rendben lesz. És akkor valóban lehet módszertanokat használni.

Nekem is azóta lett kevésbé idegbajos az életem, amióta átmentem belsősnek. Teljesen más úgy dolgozni, hogy ha kell egy új report, akkor nem azt mondjuk rá, hogy jó két nap, kétszázezer azt' kösszöm'szépen, aztán két hétig vitatkozunk rajta, hogy de mos' mé' annyi, a régi programba' a józsigyerek megcsinálta csokiér' vébészkriptbe', hanem mindenféle időbecslés nélkül csak leülök és megcsinálom. És nem is nagyon specifikálunk mert nincs védendő fenék, ha nem jó, majd legfeljebb módosítva lesz. Ha nem kell szerződni egy munkára, akkor specifikálni is kevésbé kell.

És így, ha a favágómunka nagy része a belsősöké, már jobban el tudom képzelni a módszertanok használhatóságát.

Nagyon sok igazság van abban, amit írsz, egy részével egyetértek egy részével nem :) de ez nem gondolom hogy baj. Igazából a bevezetés módszertanok a bevezető cégnek fontosabbak, így ezekért a dokumentációkért nem is igen kérhetnek pénzt a megrendelőtől. Ezek a módszertanok arra kellenek, hogy a cég képes legyen a saját rendszerét bevezetni a megrendelőnél.

A megrendelők valóban nem szeretnek fizetni semmiért, még oktatásért sem, bár azt már nehezen lehet védeni, hogy azért miért nem. A fejlesztések nagy részét ingyen akarják, mert egy "ERP rendszertől ez elvárható".

Az igényfelmérésekről nekem is elég kemény véleményem van és azt hiszem osztom a tiedet. Persze a módszertanok így kezdődnek, de ez pénztbe kerül. A megrendelő választhat:
1. Megnézi az új rendszert és ő több bemutató alkalmával meggyőződik arról, hogy neki jó lesz, minden funkció, ami kell nekik az megvan. Általában ez van, és ez olcsó, nagyjából ingyen van, benne van az árban.
2. Vagy csinálunk egy előprojektet, ahol felmérjük a céget, ez persze megint annyi, mint maga a rendszer bevezetése. Ezt senki nem kéri.

És éppen ez (is) okozhatja a sikertelen ERP bevezetések egy részét.