A saját folyamataira építve
Kevesebb lépés, kevesebb kerülőút
A rendszer az Öné
Egyedi szoftverfejlesztés
Szoftver a cége valós működésére
A dobozos szoftvereket a lehető legszélesebb piacra tervezik. Ez a gyártónak jó üzlet, a felhasználónak viszont azt jelenti, hogy a termék az átlagos cégre készül. Átlagos cég pedig nincs: a különbség pont ott van, ahol a maga működése zajlik.
Az egyedi szoftverfejlesztés ezt a rést zárja be. A rendszerben lévő folyamat megegyezik azzal, ahogy a csapata dolgozik, az adat egy helyen van, nem háromban, és nincs olyan funkció, amit azért nem kaphat meg, mert a gyártó nem építette meg.
Vállalati rendszereket, belső platformokat és üzleti alkalmazásokat fejlesztünk olyan cégeknek, ahol a szoftver nem mellékes eszköz, hanem maga a munkavégzés. Nyolc éve, több mint ötven átadott projekttel a hátunk mögött.
Ahogy dolgozunk
Miért válasszon minket?
Azokkal dolgozik, akik építik
Nincs account manager, és nincs átadás egy junior csapatnak, akiket sosem látott. Öten vagyunk: akik felmérik a projektet, azok írják meg. A csapat évek óta ugyanaz, és ez az oka, hogy a 2019-ben épített rendszereink ma is működnek.
Heti láthatóság
Betanítás és támogatás
Elvégezzük a teljes betanítást azoknak, akik nap mint nap használni fogják a rendszert, és az átadás után is elérhetők maradunk karbantartásra, továbbfejlesztésre.
Hova megy el valójában az idő
Dobozos szoftver vagy egyedi fejlesztés?
A kérdés ritkán az, hogy melyik a jobb. Sokkal inkább az, hogy hol van az a pont, ahol a dobozos rendszer körüli kerülőutak többe kerülnek, mint egy saját szoftver.
A költség ugyanis nem költségsoron jelenik meg, hanem súrlódásként. Számolja össze, hány külön programhoz nyúl a csapat egyetlen rutinfeladat során, milyen gyakran ugrálnak közöttük, és mennyi adatot másolnak kézzel egyik rendszerből a másikba. Ez a munka semmit nem termel, viszont időt visz, és a hibák nagy része is itt keletkezik.
Ráadásul csendben halmozódik. Egy kerülőút, ami rendelésenként három percbe kerül, napi negyven rendelésnél évi egy teljes munkahétet jelent. Ez soha nem kerül be egyetlen kimutatásba sem, mégis kifizeti minden hónapban.
Az egyedi szoftver pont ezt a réteget szünteti meg. Ami a munkához kell, egy helyen van, az adat magától mozog a folyamatok között, és a rendszer a cég működését képezi le, nem fordítva.
Néhány jel, ami jellemzően azt mutatja, hogy elérte ezt a pontot: az Excel-táblákat többen szerkesztik párhuzamosan, és senki nem tudja biztosan, melyik a friss; az adat kézzel vándorol a számlázó, a CRM és a raktárkészlet között; a kollégák ideje adminisztrációra megy el ahelyett, hogy a szakmájukkal foglalkoznának; vagy van egy folyamat, amit csak egyetlen ember tud lefuttatni.
Ha ezek közül több is ismerős, valószínűleg nem szervezési problémáról van szó, hanem szoftveresről.
Tulajdon, forráskód és adatkezelés
A rendszer az Öné, nem egy használati jog
A dobozos szoftvernél valójában hozzáférést bérel. A megújítási dátumokat, a felhasználószámot, a csomagváltásokat és az áremeléseket más dönti el, és egy termék, amire a működését építette, az Ön beleszólása nélkül is megszűnhet.
Nálunk a teljes forráskód és a szellemi tulajdon a projekt végén Önhöz kerül. Nincs licencdíj, nincs felhasználónkénti költség, és nincs függés tőlünk sem: ha később házon belülre viszi a fejlesztést vagy más csapathoz megy, minden a kezében van hozzá.
Ugyanez vonatkozik az adataira. GDPR-megfelelő adatkezeléssel dolgozunk, titkosítással, jogosultsági szintekkel és naplózással, és mindezt a tervezéstől kezdve építjük be, nem utólag. Titoktartási szerződést az első beszélgetés előtt is szívesen aláírunk.
Ez megváltoztatja, mi is ez a kiadás valójában. Nem előfizetés, ami örökre megújul, hanem a cég vagyonának része: bővítheti, a céggel együtt eladhatja, vagy odaadhatja bárkinek.
Elavult rendszerek kiváltása
Rendszercsere, ha a régi már visszahúzza a működést
A tíz-tizenöt éve épült rendszerek ritkán állnak le egyik napról a másikra. Egyszerűen lemaradnak. A platform, amin futnak, kiesik a támogatásból, az integrációk elromlanak, ahogy körülöttük minden továbblép, és akik eredetileg megépítették, már rég nincsenek ott.
A költség itt sem látszik számlán. Inkább úgy jelenik meg, hogy van egy gép, amit nem szabad frissíteni, van egy folyamat, amit csak egyvalaki tud lefuttatni, és egyre több olyan dolog, amit a cég azért nem tud megcsinálni, mert a rendszer nem engedi. A kockázat csendben halmozódik, amíg a legrosszabb pillanatban el nem törik valami.
A modernizálás viszont nem feltétlenül jelent nulláról kezdést. Sokszor az az észszerű, ha megtartjuk, ami működik, kicseréljük, ami nem, és szakaszosan migrálunk, hogy a működés közben ne álljon meg. Azzal kezdünk, hogy felmérjük, mi van valójában: az adatok, az integrációk és azok a folyamatok, amikre az emberek nap mint nap támaszkodnak.
Ha a régi rendszerhez megvan a forráskód és a dokumentáció, a bővítés vagy a migráció általában a gyorsabb út. Ha a technológia már nem támogatott, az újraírás gyakran olcsóbb, mint a régi megfelelő minőségű módosítása, mert a mai eszközök hetek alatt lefedik azt, ami korábban hónapokba telt.
És mivel a forráskód Önhöz kerül, a következő modernizálás sem fog tőlünk függeni.
GYIK
Gyakori kérdések az egyedi szoftverfejlesztésről
Három dologtól függ: mennyit kell tudnia a rendszernek, mihez kell kapcsolódnia, és milyen megfelelőségi követelmények vonatkoznak rá. Pontos árat ezek ismerete nélkül senki nem tud mondani, a nagyságrendet viszont meg lehet adni.
A specifikáció elfogadása után pontos árat kap egy meghatározott tartalomra, nem sávot, ami később elmozdul. Ha egy ajánlat messze kívül esik ezeken a sávokon, és nincs tételesen lebontva, az általában azt jelenti, hogy valaki a saját bizonytalanságát árazza be.
Szakaszosan is lehet dolgozni: előbb az készül el, ami a legdrágább problémát oldja meg, éles üzembe kerül, és onnan bővítjük. Így nem kell az első naptól a teljes büdzsét lekötni.
Egy fókuszált belső rendszer 8-12 hét alatt elkészülhet. Egy nagyobb vállalati rendszer integrációkkal, adatmigrációval és több szerepkörrel jellemzően 5-8 hónap.
Reális határidőt adunk, nem optimistát. Inkább mondunk hét hónapot előre, mint ötöt, amiből aztán kilenc lesz.
Jellemzően akkor éri meg, ha több rendszer között kell kézzel adatot mozgatni; ha egy folyamatot csak egyetlen ember tud lefuttatni; ha az iparági sajátosságait egyetlen dobozos megoldás sem fedi le; vagy ha vannak dolgok, amiket a cég azért nem tud megcsinálni, mert a rendszer nem engedi.
Ha a felmérés során az derül ki, hogy az Ön esetében ez a helyzet, meg fogjuk mondani. Egy fél éven át tartó projekt, aminek a végén kiderül, hogy nem kellett volna, mindkettőnknek rossz.
Az Öné. A teljes forráskód és a szellemi tulajdon a projekt lezárásakor átadásra kerül, licencdíj, felhasználónkénti költség és tőlünk való függés nélkül.
Minden forráskód verziókezelő rendszerben van, folyamatos, földrajzilag elkülönített biztonsági mentéssel, tehát semmi nem áll egyetlen helyen. Átadáskor a teljes tárolót és a hozzá tartozó dokumentációt kapja meg.
Ha később házon belülre viszi a fejlesztést vagy más csapathoz megy, minden a kezében van hozzá. A tulajdonjog a szerződésben szerepel, nem feltételezés kérdése.
Ahogy elkészül a munka, úgy fizet, nem előre. A projekt mérföldkövekre bomlik, és mindegyiknek meghatározott tartalma és működő eredménye van, amit meg tud nyitni és ki tud próbálni. Nem előrehaladási jelentést kap, hanem szoftvert.
A számlázás ezeket a mérföldköveket követi, így nincs egy nagy számla a végén, és egyetlen szakaszt sem fizet ki azelőtt, hogy látta volna, mit kap érte.
Általában változik, és ez nem baj, ha időben derül ki. Az igények akkor tisztulnak le igazán, amikor az emberek látnak valami működőt, egy második hónapban felmerülő módosítás pedig sokkal olcsóbb, mint egy hatodikban.
A változást a specifikációhoz mért módosításként kezeljük, a költség- és határidőhatással együtt, még mielőtt bármi megépülne. Nincs meglepetésszámla, és nincs csendben elnyelt többletmunka sem, ami aztán a határidőt tolja.
Igen. Ugyanolyan gyakran viszünk végig egy projektet teljes felelősséggel, mint amilyen gyakran egy belső csapat mellett dolgozunk egy konkrét rendszeren, szolgáltatáson vagy integráción, amíg az Önök fejlesztői máson dolgoznak.
Mindkét esetben közvetlenül azokkal a mérnökökkel egyeztet, akik a rendszert építik, nem egy közvetítőn keresztül.
Jellemzően megoldható, és az első kérdés az, hogy a módosítás vagy a csere a jobb üzlet.
Ha viszont a technológia már nem támogatott, az újraírás gyakran olcsóbb, mint a régi megfelelő minőségű módosítása. Felmérjük, mi van valójában, mielőtt bármelyiket javasolnánk, és a migráció szakaszosan is elvégezhető, hogy a működés közben ne álljon meg.
Igen, és eleve úgy írjuk a kódot, hogy bővíteni fogja. A bővíthetőség és az átlátható szerkezet tervezési döntés, nem olyasmi, amit utólag hozzá lehet adni.
Azzal kezdeni, ami a fő problémát megoldja, és valós használat alapján bővíteni, szinte mindig a jobb út. Azok a funkciók, amiket végül senki nem használ, a legdrágábbak, amiket valaha kifizet.
Segít, és kritikusan fogjuk olvasni, nem csak megvalósítani.
A specifikáció terv, nem kész termék, tehát olcsó módosítani. Ahol valami bonyolultabbnak tűnik, mint amit a feladat megkíván, vagy van rá egyszerűbb megoldás, szólunk, mielőtt megépülne.
Ha nincs specifikációja, az sem gond: az elkészítése része annak, ahogy egy projektet indítunk. A működést először megértjük, és csak utána kezdünk el programozni.
A legtöbb szoftver nem a fejlesztés közben bukik el, hanem egy évvel később, amikor egy függőségben sebezhetőség jelenik meg, egy platform frissül, vagy változik egy folyamat, és már nincs ott senki, aki érti a rendszert.
Maradunk karbantartásra, monitorozásra és továbbfejlesztésre, jellemzően havidíjas keretben. Ez nem kötelező, és nem is bezárás: mivel a forráskód és a jogok az Önéi, bármikor mást is megbízhat vele.