A saját cégedre szabott ügyviteli rendszer

Ideális esetben, minden cég életében eljön az a pont, amikor egyre több lesz az ügyfél, egyre több lesz a megrendelés, egyre több folyamatot kell kézben tartania ugyanannyi emberi erőforrásnak. Ez pedig magával hoz különböző természetű problémákat. Ezeket az eseményeket, folyamatokat valahogy kezelni kell. Számos esetben ez ideig - óráig megoldható papír vagy Excel alapú segítséggel, de egy idő után ez már nem elégséges. Ilyenkor érdemes elgondolkodni egy un. ügyviteli rendszer (a cég ügyviteli folyamatait támogató szoftver) használatán.

Ha szépen fejlődik a céged és egyre nehezebben látod át mi történik benne, akkor valószínűleg szükséged van egy ilyen rendszerre. Milyen lehetőségeid vannak? Az interneten számtalan kész un. dobozos megoldást találsz, akár vehetnél is egyet.

Igen, egy ideális világban ez biztosan jól működne. De mi nem ott élünk és dolgozunk. Ahány cég, annyi szokás. Nincs két egyforma cégvezető, mert még szoros értelemben vett iparágon belül is más és más dolgok lehetnek fontosak egy – egy döntéshozónak.

Kisvállalkozásoknak nem lehet univerzális dolgokat készíteni! Nem lehet azt mondani, hogy az, ami az egyik helyen működik, az a másikon is tökéletesen fog. Természetesen vannak bevált alapfogások, amik minden cég esetében szinte biztosan ugyanúgy zajlanak, és erre megvannak a megfelelő funkciók, de az ehhez kapcsolódó egyéb részletek már hiányoznak. A nagyobb cégeknél más a helyzet, de én most nem azokról beszélek.

Egyedi rendszer fejlesztése a nulláról?

Ez megint csak egy elhibázott irány. Egyrészt rengeteg időt vesz igénybe, másrészt pedig irdatlan összegeket emészt fel. Nem beszélve arról, hogy a későbbiekben az egyedileg fejlesztett rendszerek támogatása csak részben megoldott. Éppen ezért több okból sem javasolt ez a fajta megközelítés.

De akkor mégis mi a valódi megoldás?

A legjobb egy olyan stabil alaprendszer továbbfejlesztése, ami a minimális, szükséges dolgokat már tartalmazza. Pl. dokumentumok tárolását, feladatkezelést, jogosultságkezelést, tömeges e-mail küldést, ügyfelek rögzítését – kezelését, CRM folyamatokat.

Ezen felül néhány plusz dolog is jól jöhet még. Ilyen lehet a számlázás, útnyilvántartás, kiküldetési rendelvény generálás, stb. Egy ilyen stabil rendszerre már lehet építeni. Az egészet úgy kell elképzelni, mint egy Lego alapot.

Úgy cserélgethetjük a plusz összetevőket, ahogy éppen szükséges. Mindig annyi és olyan kocka van az alaplapra pakolva, amennyi szükséges. Egyszerűen fogalmazva, egy kész alaprendszerre, azzal együttműködve lehet arra „ráfejleszteni” a szükséges egyedi kéréseket. A későbbi fejlesztések végig kompatibilisek maradnak az eredeti részekkel.

A fejlesztések 90%-a a kukában végzi

A testre szabott egyedi informatikai fejlesztések több, mint 90%-a kudarcra van ítélve. Döbbenetes, ám igaz szám. Tehát 100 elkezdett projektből minimum 90 eleve megbukik, a fennmaradó 10% további 1-2%-a is néhány év alatt megszűnik.

Ezen kudarcok legfőbb oka, hogy a megrendelőt képviselő cégvezető (irodavezető, raktárvezető, gyártásvezető, stb.) vagy akár több személy a cégtől és a szoftverfejlesztő céget képviselő projektvezető vagy programozók egészen egyszerűen elbeszélnek egymás mellett. Nem értik egymás nyelvezetét, nem értik egymás gondolatvilágát.

Két alapeset lehetséges, és van a harmadik, a megoldás. Az első alapeset az, amikor a szoftverfejlesztő cég képviselője a várt projekt megbízásáért mindent megígér a megrendelőnek. A fejlesztőknek nagy szabadságot engedve, rájuk bízva a megvalósítás részleteit. Innen lehet tudni, hogy (általában) kezdő vagy tapasztalattal alig rendelkező fejlesztő cégről van szó.

A második pedig az, amikor minden nagyon mereven, már a kezdetekkor kőbe van vésve. Pontos leírás alapján, komoly szerződésben rögzítik, hogy mi fog elkészülni, az hogyan fog működni és mikorra. A megrendelőre nézve mindkettő nagyon káros!

Az első esetben a projekt vezetőjének tapasztalatlansága okozza a bukást, a másodikban pedig az, hogy a megrendelő 99%, hogy nem azt kapja, amit elvárt (elmondott, kért). Miért nem? Mert élő ember nem tudja megmondani, hogy az, amit elméletben elképzelt, a gyakorlatban hogyan fog akkor működni, amikor kipróbálja. Ilyenkor jönnek a kínos meglepetések, de már nincs visszaút.

A működő modell

A gyakorlat azt mutatja, hogy leginkább a fejlesztés során derülnek ki a szükséges folyamatok. Tehát az első megbeszélések után a lehető leggyorsabban prezentálni kell működő programfunkciókat. Nem probléma, ha azok nem tökéletesek, mégis támpontot adnak a megrendelőnek.

Akkor, amikor a megrendelő működés közben látja a még kezdetleges szoftver első néhány momentumát, akkor ismeri fel, hogy valójában mi és hogyan támogatná a legjobban a cége működését. Sok (nyugodtan leírhatom, hogy kivétel nélkül szinte mindegyik) cégvezető akkor jön rá, hogy milyen lehetőségei is vannak az egyedi fejlesztésnél.

Tehát nem szabad elkövetni azt a hibát, hogy néhány megbeszélés után, sok – sok idő múlva a fejlesztő megjelenik a szoftver teljesen kész verziójával. Az szinte biztos kudarc.

Hogyan kell nekiállni, mi a folyamat?

Mi olyan sémát alakítottunk ki, amellyel biztosítható, hogy ezen egyedi fejlesztések is nagy biztonsággal megvalósíthatóak legyenek.

Joggal merül fel a kérdés, hogy ez a séma biztosan egy nagyon összetett folyamat, bonyolult és időigényes lépéseket foglal magában. Ám a valóság ebben az esetben jóval egyszerűbb! Csak oda kell figyelni arra, hogy mit akar a megrendelő. Meg lehet –e azt valósítani, és ha nem, akkor milyen alternatívák vannak a működő megoldás létrehozására.

Legfontosabb a közös munka. Együtt kell dolgozni. Csak így lehet egy olyan szoftvert elkészíteni, ami biztosan azt tudja amit elvárnak tőle. A gyakorlatban ez úgy néz ki, hogy megbeszélés, fejlesztés, tesztelés, megbeszélés, fejlesztés és így tovább.

Tehát mindig csak pár lépést kell lefejleszteni, amit után a megrendelő teszteli az elkészült funkciót (akár egy kis programrészletet). Így nagyon szépen korrigálható az irány és a végére mindenki elégedett lesz.

Mi kell ehhez?

Tapasztalt fejlesztő(k), sokat látott projektvezető(k), a jobb megoldások folyamatos kutatása. Nyilván mindig képben kell lenni az adott területtel is, amelyre a fejlesztés történik. Tehát, ha redőnyös cégnek programozunk, akkor illik tudni, hogy mi a lefutó és mi az, hogy osztott redőny, ha pedig pl. jogi esetekkel foglalkozó cégnek, akkor tisztában kell lenni azzal, hogy mi a keresetlevél és az hogyan épül fel. Ezen ismeretek nélkül nem lehet együtt dolgozni. Nem a megrendelőnek kell tisztában lennie azzal, hogy mi is a vízesés modell… neki „tökmindegy”, hogy a szoftvere milyen irányelvek mentén és hogyan készül, őt teljesen jogosan, csak a működő végeredmény érdekli.

Ez lenne a garancia a sikerre?

Valószínűleg igen. Fejlesztői oldalról alapvető, hogy olyan moduláris rendszerben kell gondolkodni, amellyel biztosítható, hogy az elkészült szoftver továbbfejleszthető, később is jelentősebb költségek nélkül módosítható legyen. Sok komolyabb fejlesztő cég sem tartja ezt be, ami persze idővel megint csak a szoftver és a közös együttműködés bukásához vezethet.

Megrendelő pár hónap használat után döbben rá, hogy a már lefejlesztett funkció nem vihető el a kívánt irányba, ezért is nagyon fontos, hogy már az elején megfelelő tudással

Továbbfejlesztés, avagy egy szoftver soha nincs teljesen készen

Klasszikus értelemben véve nincs befejezett szoftver. Azt mindig jobbá, gyorsabbá, optimalizáltabbá lehet tenni, egy jó szoftverre mindig lehet egy újabb szükséges funkciót fejleszteni, de ez már egy másik történet.

Az évek alatt bebizonyosodott, hogy nem a mindent tudó - mindenkinek egy kicsit jó lehet, funkciókkal telezsúfolt dobzos szoftverek megvásárlása a jó irány. Helyette inkább a stabil alapokon nyugvó, testreszabható kisebb rendszerek a jövő kis- és középvállalkozásainak szoftverei.