Amikor eldöntjük, hogy szeretnénk egy webáruházat, akkor lényegében egy befektetésnek szavazunk bizalmat. A befektetés mértéke természetesen minden esetben egyedi, kinek-kinek a pénztárcájához szabva, egy dologgal azonban mindenképpen tisztában kell lenni, ez pedig az, hogy mi magunk mit szeretnénk, pontosabban mit szeretnénk, hogy a webáruház tudjon. A tudáson kívül azonban még nagyon sok dolog van, amit végig kell gondolnunk, ezeket próbálom meg most összegyűjteni fejlesztői szemmel, de ügyfél fejjel.
A lassan 4 év alatt hozzám beérkezett ajánlatkérések jó része pár mondatos volt, többsége 20-30 soros és volt egy nagyon kis réteg akik komplett modul listára kértek ajánlatot, hogy nekik ezek a modulok kellenek és ez mennyibe kerül. Sajnos komplett modul listára sem lehet konkrét árat mondani, egészen egyszerűen azért mert a modulokon kívül egy webáruházban még vannak termékek, vannak felhasználók és vannak egyéb szöveges tartalmú oldalak, hírek stb. amelyek feltöltése igenis módosítja az árat.
Érdemes már az ajánlatkérést is megtervezni, pontosítani hogy mit is szeretnénk valójában
Természetesen lehet mondani, hogy az ügyfél miért írjon két oldanyi modul listát, amikor pont a webáruház készítésével foglalkozó cég feladata az, hogy modulokat ajánljon, vagy éppen gondolkozzon azon, hogy milyen modulokkal lehetne növelni a webáruház forgalmát. Ugyanakkor, ha az ügyfél szemszögéből vizsgáljuk meg a problémát és szeretnénk minél több félreértést elkerülni, akkor minél pontosabb és konkrétabb az ajánlatkérés, annál valószínűbb, hogy a két fél nem beszél el egymás mellett és mondjuk feleslegesen nem rabolják egymás idejét. Ezt pedig itt ezen a blogon csak nagyon hallkan jegyzem meg, de tapasztalom magamon, hogy egészen egyszerűen komolyabban veszem, jobban ráfókuszálok azokra az ajánlatkérésekre amelyek nem csak két sort tartalmaznak, hanem konkért elképzeléseket is, akár a fent említett két oldalas modul lista formájában.
A négy év alatt egyetlen egyszer kaptam olyan levelet amelyben a 6-7 konkurensünk ott volt még a másolat mezőben, az ajánlat kérője sajnos arra sem vette a fáradtságot hogy külön-külön 7 levelet megírjon és megcímezzen mindenkinek, így erre a levélre azóta sem válaszoltam.
Az sem jó megoldás, amikor az ügyfél rámutat egy áruházra, hogy olyan webáruházat szerétnék, mint az xyz.hu, az mennyibe kerül? Egyrészt ilyenkor nekünk (ajánlat adónak) át kell néznünk az adott áruházat, de sok funkció kívülről nem látszik, nagyon sok funkció pedig belül teljesen rejtve van, pl. ilyen esetben azt nem látjuk a webáruház adminisztrációs felületén milyen funkciók vannak, vagy éppen azt sem, hogy az áruház milyen módon kommunikál mondjuk egy ERP rendszerrel a háttérben, és egy ERP rendszerrel való kommunikáció viszonylag magas plusszköltséggel jár. Ebben az esetben a fejlesztőknek ki kell találni, hogy mi kellhet igazából az ügyfélnek és arra kell ajánlatot adnuni.
Elsősorban most azonban nem a modul listára szeretnék fókuszálni! Mert általában minden cég azt hirdeti magáról, a saját vagy általa testreszabott nyílt forráskódú megoldásról, a pontos árajánlathoz azonban ez még általában nem elegendő, és ilyenkor szokott az lenni, hogy a megrendelő úgy gondolta, hogy ez benne van az árban a kivitelező pedig azt, hogy nem. Pontosan ezért most megpróbálom összefoglalni, hogy milyen információkat célszerű még hozzávenni egy árajánlatkéréhez azaz mit szeretne a megrendelő azon kívül mondjuk, hogy legyen cross-sell modul, vagy intelligens kosár.
Néhány cég kiírja a weboldalára, hogy ez a modul ennyi, ez a modul pedig annyi, és amikor néhány tárgyalás és pontosítás után kiküldik a tényleges ajánlatot, akkor az nagyjából dupla akkor összeget tartalmaz, mint amit a leendő megrendelő magának kiszámolt a modulok alapján. Itt nem a dupla akkor összeggel van a probléma, de véleményem szerint az ügyfeleknek is félrevezető lehet, mert úgy tűnteti fel a webáruházakat, mintha csak ezek lennének a költségek. Nézzük most végig, hogy általában miyen dolgok maradnak ki egy ajánlatkérésből amelyek ugyanakkor nem elhanyagolható költséget jelenthetnek.
Ha megkapjuk örülhetünk, de ha nem akkor sem kell búslakodni
Forráskód kérdése:
Az elkészült szoftvert nyilvánvalóan a megrendelő használhatja, de sok esetben az harmadik fél által nem módosítható állapotban van, ami bizonyos szempontból érthető, mert az adott szoftver ezen cég terméke amelyet másoknak is értékesít és ezen szoftver forráskódja nem kerülhet mondjuk a konkurencia kezébe. Ha az árajánlatkérésben még nem is, de minél előbb tisztázni kell, hogy az adott szoftver forráskódjával kapcsolatban a kivitelező hogyan jár el. Nyílt forráskódra épülő szoftverek esetében szinte kivétel nélkül ragaszkodhatunk a forráskód teljes átadásához mindenféle korlátozás nélkül, egyedi fejlesztésű szoftverek esetében általában csak felhasználási jogot kapunk egy példányra. Van olyan cég is, aki ezt a jogot külön díjazás ellenében feloldja, ilyenkor jó előre tisztában lenni azzal, hogy ennek milyen anyagi vonzata van.
Dokumentáció, projekt dokumentáltsága, felhasználói kézikönyv:
Tipikusan a dokumentáció szokott kimaradni a legtöbb ajánlatból. Dokumentáció esetében is többféle dokumentációról beszélhetünk, a megrendelőnek lényegében mindegyik fontos lehet. Az egyik a felhasználói dokumentáció amely a szoftver használatát mutatja be a megrendelő részére, ha mondjuk jön egy új kolléga a céghez, akkor oda lehet neki adni mielőtt ténylegesen módosítana és esetleg elrontana valamit a működésben. A fejlesztői dokumentáció főleg akkor hasznos, ha úgy akarunk egy projektet kiviteleztetni, hogy már előre tudjuk azt, hogy más cégek is fognak fejleszteni valamit rajta. Érdemes észben tartani, hogy egy jó dokumentáció a költséges, tehát a projekt költségvetésének igen nagy százaléka lehet.
Termékek feltöltése, szöveges tartalmak feltöltése:
Mind az ügyfél, mind pedig a kivitelező számára fontos előre leszögezni, hogy ki tölti fel mondjuk az ÁSZF-et vagy éppen a Kapcsolat oldalt. Webáruházak esetében pedig kulcs fontosságú kérdés a termékek feltöltése is. Tisztázzuk le előre, hogy körülbelül hány terméket hány fotóval és milyen paraméterekkel kell feltölteni, ezt ki végzi, és az adatokat milyen formátumban kell előállítani. Az egyszerű feltöltés szempontjából a fejlesztőknek általában az XLS, CSV vagy XML formátumok felelnek meg, de ilyenkor sem mindegy, hogy 1000 vagy 10.000 termket kell feltölteni. Kérjünk tehát külön ajánlatot a termék feltöltésre és a szöveges tartalmú oldalak feltöltésére, ha ez benne van az árban, akkor pontosítsuk le, hogy hány termékig vagy hány oldalig van benne az árban, nyilván minden nem lehet benne az árban.
Termékek és felhasználók migrációja előző webáruházból:
Ez a pont igazából csak azokra vonatkozik, akiknek már van webáruháza és onnan kell átemelni az adatokat. Itt nagyon sok elméleti és gyakorlati lehetőségünk is van. Azt nem javasolnám, hogy ne emeljünk át semmit sem, mert akkor a felhasználók újra regisztrálhatnak és sokan nem fogják megtenni, tehát a felhasználói adatokat mindenképpen migrálni kell. Ezzel párhuzamosan természetesen a termékeket is valahogyan át kell mozgatni az egyik webáruházból a másikban, ha az új és a régi áruház is mondjuk egy ERP rendszerből kapta a termékeket, akkor mondjuk magukat a termékeket nem kell migrálni. Ha már van áruházunk, akkor mindenképpen kérjünk ajánlatot a migrációra, arra viszont ügyeljünk, hogy annak pontos összegét a régi és új adatszerkezetek ismerete nélkül a fejlesztő cég biztosan nem fogja tudni megmondani, de egy jó becslést látatlan készíthet. Itt szintén nagyon sok extra munka jöhet elő még projekt közben, pl. a régi áruház más karakterkódolással tárolta a termékeket és akkor még az adatmozgatás mellett konverziós költségek is vannak.
Érdemes-e megsprósolni az oktatás költségét?
Betanítás, Oktatás:
Talán az egyik legfontosabb kérdés, hogy az elkészült webáruház használatát a megrendelő hogyan fogja elsajátítani. Tartalmaz-e az ajánlat oktatást és ha igen, akkor hány ember részére, hány órán keresztül és helyileg hol lesz maga a betanítás. A betanításról igazából sokkal többet nem érdemes beszélni, szinte mindenképpen szükséges eleme a webáruház fejlesztésnek és a kész webáruház átadásának az ügyfél részére.
Hibák javítása, garancia:
A hibák kijavtása vagy a garancia sok esetben szintén nem triviális. Meddig és milyen paraméterekkel él a garancia a szoftverre? Vannak olyan cégek akik fél-1 évet adnak garancia címén és kikötik azt, hogy ez a garancia elveszik akkor ha más is hozzányúl a kódhoz. Vannak olyan cégek amelyek lekódolják a kódot, így ahhoz biztosan nem tud más hozzáférni, ezáltal ha hiba van akkor azt orvosolják saját költségükön és vannak olyanok is, akik ki sem engedik a kezükből a kódot így biztosítható lényegében a garancia érvényességé.
Elkészítés határideje:
A projekt árát nagyban tudja módosítani az, hogy mikorra kell elkészteni az adott feladatot, elképzelhető, hogy ha szűk a határidő, akkor emiatt a fejlesztő cég el sem tudja vállalni, vagy éppenséggel egy tág határidővel rendelkező projekt esetében valamivel kedvezőbb árat tud adni a fejlesztésre. Ezért minden ajánlatkéréshez célszerű csatolni az általunk elképzelt projekt befejezési dátumát.
Ajánlatkérésünkben lehetőleg ezentúl jelenítsük meg ezen fenti paramétereket is, és akkor sokkal pontosabb ajánlatot fogunk kapni a projektre vonatkozóan. Úgy gondolom, hogy ha ezeket a paramétereket a felek már az elején tisztázzák, akkor az ajánlattevők pontosabb ajánlatot tudnak készíteni és ezáltal az egyes ajánlatok összehasonlíthatóbbak is lesznek egymással (mert a kérdés dolgok sok cégnél alapvetőek másoknál pedig nem). Sajnos a modulokra és funkcionalitásokra épülő ajánlatkérés csak kiinduló alapnak jó, de semmiképpen sem tekinthető végleges árnak az ez alapján tett ajánlat, aki pusztán a modulok alapján végelegs árat tud mondani, az lényegében ferdít.
