Ak chcete robiť skutočný online biznis, nepoužívajte hotové riešenia

Vo svete web aplikácií nastal boom s webmi, ktoré sa dajú rýchlo, s minimálnymi nákladmi a pomerne príťažlivým dizajnom vyklikat za pár hodín a za pár Eur. Prípadne podobné platí pre rozsiahlejšie aplikácie, ktoré je možné prenajať si a následne cez konfiguračný nástroj prispôsobiť funkcionalitu Vašim potrebám. Takáto ponuka je lákavá a v počiatočných úvahách snáď aj postačujúca. Problém nastáva v okamihu, keď od takejto aplikácie začneme vyžadovať zmeny, na ktoré nie je pripravená.

Rozoberme si veľmi jednoduchý príklad firemnej stránky. Počiatočné požiadavky sú tieto: príťažlivý dizajn, niekoľko stránok so statickým obsahom, kontaktný formulár, jednoduchý zoznam s dynamickým obsahom (napr. správy) a jednoduchá galéria pre prezentáciu produktov, kde sa zoznam obrázkov zobrazí na stránke produktu. Takýto web sa dá za nízkych nákladov vyklikať v priebehu pár dní. V prípade že si zaplatíte dodávateľa, ktorý tento systém ovláda, funkčný web máte online za dva dni.

Na prvé problémy pri použití takéhoto riešenia obyčajne narazíte už pri záverečnej fáze realizácie, a to pri konečných dolaďovaniach, prípadne drobných dodatočných požiadavkách či už na dizajne, alebo na funkcionalite. Často ich realizácia nie je podľa Vašich predstáv, prípadne je Vám povedané, že sa to nedá. Zároveň zistíte, že nahrávanie obsahu do galérie produktov, ktorých je síce iba pár desiatok, ale fotiek je niekoľko stoviek, je časovo zdĺhavé, keďže je potrebné nahrať každú fotografiu samostatne.

Časom chcete rozšíriť galériu produktov o kategorizáciu a vyhľadávanie. Tiež by ste radi prehľadnú navigáciu, aby mal návštevník prehľad, kde sa v kategóriách nachádza, prípadne ďalšie drobné vychytávky. A problém je na svete... Je niekoľko scenárov, ktoré sa väčšinou stále opakujú. 1. dodávateľ s Vami prestane komunikovať, 2. dodávateľ Vám oznámi, že táto zmena si vyžaduje použitie iného riešenia (napr. použije externú aplikáciu pre vytváranie galérií, ktorá by teoreticky mala vyhovovať zadaniu), 3. pustí sa do úprav, avšak výsledok je prinajmenšom rozpačitý.

V prvom spomínanom prípade máte problém v tom zmysle, že buď si to dorobíte svojpomocne (nevýhody tejto alternatívy určite nie je potrebné uvádzať), alebo to zadáte inému dodávateľovi, čo iste nebude práve lacné riešenie.

V druhom prípade budete mať pocit, že je to výborné riešenie. Dodávateľ je rozumný, pretože nevymýšľa koleso a tešíte sa na skvelý výsledok. Avšak skončí to Vašim zistením, že aj tie najdrobnejšie úpravy sú zrazu veľký problém, prípadne stoja nepomerne viac peňazí ako celá doterajšia aplikácia a Vy pochopíte, že ak ešte v budúcnosti budete chcieť systém rozširovať, alebo si musíte pripraviť slušný obnos peňazí, alebo máte smolu. Alebo dodávka produktu sa bude oddiaľovať a oddiaľovať až zistíte, že Váš prípad je prvý spomenutý.

V treťom prípade zistíte, že výsledný produkt síce zodpovedá Vašim predstavám, avšak jeho dodanie trvalo príliš dlho a bolo problematické, alebo máte nedorobok a po opakovanom dožadovaní sa nápravy sa dodávateľ zatají a Váš prípad je prvý spomenutý.

Podobné platí aj pre rozsiahlejšie aplikácie na prenájom. Iste nájdeme aj také, ktoré sú určite svojou funkcionalitou postačujúce. Avšak ak ide o aplikáciu, ktorou sa riadia procesy vo firme, prípadne poskytujú služby a produkty, vzniká rozpor vo funkcionalite, ktorú poskytuje aplikácia a funkcionalitou, ktorá je požadovaná vnútropodnikovnými procesmi alebo spôsobom interakcie so zákazníkmi. Zoberme si napríklad e-shop, kde firma dováža tovar z Ázie a predáva ho na Slovensku. Takýto scenár hravo pokryjú dostupné riešenia. Dokonca niektoré aj dynamicky odzrkadľujú legislatívne zmeny. Najčastejšie ale problém vzniká vo chvíli, keď chce obchodník obchodné stratégie premietnuť aj do správania sa systému. Nehovoriac o prípade, kedy chce obchodník z jedného systému predávať do viacerých krajín s rôznymi cenotvornými stratégiami.

Teraz sa naskytajú otázky. Všetci, čo pracujú s hotovými riešeniami sa mýlia? Softvér, ktorý zodpovedá predstavám zákazníka je potrebné zakaždým programovať nanovo? A ako je to s opätovným vymýšľaním kolesa? Môj známy má web postavený na hotovom systéme a je nadmieru spokojný..., atď.

V prvom rade je potrebné si ujasniť, kedy dochádza k problému. Je to práve vtedy, ak systém neobsahuje potrebnú funkcionalitu vôbec, alebo v postačujúcej miere a podobe. Túto funkcionalitu je vtedy potrebné dorobiť, alebo doplniť/ upraviť existujúcu, a to v takej miere, v akej to dovoľuje návrh samotného systému, alebo jeho časti (či je navrhnutý dostatočne abstraktne a robustne, aby ho bolo možné rozšírovať - často spomínaná modulárnosť).

Pozrime sa na príklad s rozšírením galérie. Systém obsahuje funkcionalitu galérie, avšak spomínanú kategorizáciu s vyhľadávaním nie. Bez ohľadu na to, ako je systém dobre navrhnutý, je potrebné túto funkcionalitu naprogramovať. A úspech záleží práve na tom, do akej miery sa funkcionalita čo rieši produkty a k nim pridružené obrázky dá dopĺňať a ohýbať/ upravovať. Prípad z e-shopu je trochu iný. “Naučiť” e-shop rôzne cenotvorné stratégie v rôznych regiónoch by bolo zrejme finančne náročnejšie ako kompletné riešenie šité na mieru. Na druhej strane, ak príliš nešpekulujeme, kvalitný softvér ako služba nám poskytne plne postačujúci e-shop.

Dostávame sa teda do bodu kedy zisťujeme, že na niečo je vhodné použiť hotové používateľské riešenia, na iné zas funkcionalitu na mieru. A práve rozhodnutie, čo urobiť na mieru a na čo použijeme hotovú funkcionalitu je kľúčové z hľadiska nie len dlhodobých nákladov na systém, ale často krát aj na jeho počiatočnú cenu. Inými slovami či počiatočne nízke náklady na vyklikaný web, ktoré sa v prípade akýchkoľvek ďalších požiadaviek na zmenu zvýšia a zvýšia sa aj z dôvodu časovej, prípadne procesnej neefektívnosti, nepresiahnu celkové náklady na vytvorenie projektu presne na mieru práve pre Vás, pre Vaše požiadavky, predstavy a postupy. Tento proces rozhodovania nie je jednoduchý a často musí zohľadňovať viacero faktorov špecifických pre daný projekt. Platí však niekoľko základných pravidiel, ktoré sa dajú aplikovať na každý z nich.

Je potrebné si ujasniť, ktoré z funkcionalít budú riešiť procesy Vám vlastné. Inými slovami, čo bude treba prispôsobiť Vašim podmienkam. Napríklad spôsob prezentácie produktov môže zohľadňovať obchodnú stratégiu so spomínanými podobnými produktami zobrazenými v detaile produktu.

Ďalším kandidátom na funkcionalitu na mieru sú tie časti systému, ktoré sa môžu v budúcnosti upravovať alebo rozširovať. Opäť môžeme použiť príklad s funkcionalitou na prezentáciu produktov. Ak vieme, že táto časť sa môže v budúcnosti meniť, určite je potrebné tento fakt zohľadniť pri samotnej realizácii. Je možné, že prvotné požiadavky existujúca funkcionalita zvládne, avšak je na mieste otázka, že do akej miery je možné ju upravovať a dopĺňať o ďalšie vlastnosti. Pretože ak to nie je zohľadnené, skončíte s obrovským, nemotorným, pomalým a neefektívnym systémom, ktorému aj jednoduché operácie budú trvať neúmerne dlho.

Postupným prechádzaním vlastností požadovaného systému nám po zohľadnení hore uvedených pravidiel vznikne zoznam funkcionalít, o ktorých môžeme predpokladať, že pre ich realizáciu bude potrebné vytvoriť vlastné riešenia. Práve tento zoznam by mal byť hlavnou témou vstupných diskusií s možnými dodávateľmi. Zároveň, skúsený dodávateľ by mal na základe Vášho prvotného zadania a znalosti Vašich obchodných činností vedieť väčšinu týchto oblastí identifikovať sám.

Pre ucelený pohľad na problematiku uvediem dva prípady z reálneho života.

V prvom prípade klient predával prístup k online službe. Získanie prístupu spočívalo v zaplatení poplatku a následnom poskytnutí id kódu klientovi pre prístup. Zároveň bolo treba zaznamenať dátum vypršania prístupu k službe do externej databázy. Klient uprednostnil riešenie postavené na Magento platforme pred funkcionalitou na mieru. Problémy na seba nenechali dlho čakať a prvé prišli už počas prvotnej realizácie, kedy bolo treba UI Magenta vložiť do už existujúceho webu. Ďalšie nastali pri napojení sa na slovenské platobné brány. Systém sa nakoniec spustil. Došlo však k zmenám v obchodnej stratégii, ktoré sa mali premietnuť aj do systému predaja. Tam však nastal problém, pretože požadované riešenie nie je klasický predaj produktov alebo služieb a to vyžadovalo značné ohýbanie Magenta vo veci ako narába s položkami na predaj. Okrem toho, že Magento neposkytlo potrebnú funkcionalitu, z jeho vlastnej funkcionality bolo využitých iba približne 5%. Tento nepomer zároveň vedie ku konštatovaniu, že používanie systému administrátorom je zrejme ťažkopádne, keďže mu rozhranie poskytuje funkcie ktoré vôbec nepotrebuje, prípadne postupy sú zbytočne zložité. Naviac, každá ďalšia zmena bude opäť vyžadovať ohýbanie Magenta, čo bude nákladnejšie ako iba samotná realizácia požadovaných zmien pri použití riešenia na mieru.

Pre tento prípad bolo určite vhodné použiť vlastné riešenie, ktoré by vzhľadom na rozsah požadovanej funkcionality nebolo veľmi nákladné, na druhej strane by ho bolo možné podstatne efektívnejšie upravovať a rozširovať ako Magento. Vzhľadom na náklady spojené s použitím, úpravami a zaškolením na Magento by vlastné riešenie bolo cenovo na rovnakej úrovni. Vlastné riešenie by naviac bolo hotové skôr, malo by nižšie prevádzkové náklady, v budúcnosti by sa lepšie a ľahšie prispôsobovalo novým požiadavkam a hlavne by bolo presne podľa predstáv klienta.

V druhom prípade ide o e-commerce riešenie pre online rezerváciu krátkodobých prenájmov. Okrem hlavnej funkcionality systém obsahuje aj pomocné nástroje, ako blacklist nežiaducich zákazníkov s automatickým identifikovaním nových registrácií, mailing list, integráciu na fakturačný systém, a.i. Ako CMS bol použitý Drupal. Drupal bol tiež do istej miery využitý ako web framework. Pre urýchlenie prác boli použité aj rôzne nástroje zo ZendFrameworku. Avšak celá business logika aplikácie bola programovaná ako vlastné riešenie, keďže hlavná požiadavka bola, aby bol celý systém do poslednej bodky optimalizovaný na potreby zákazníka. Realizácia sa tým samozrejme predĺžila, pretože bolo treba programovať aj veci ako mailinglist, integrácia na platobné brány, atď. Na druhej strane, každý aspekt systému je plne prispôsobený a dodatočné požiadavky zákazníka, dokonca aj tie, ktoré mali vplyv na dátový model, boli realizované vo veľmi krátkom čase. Výsledkom bol systém, ktorý nielen umožnil online rezervácie pre širokú verejnosť, ale aj automatizoval množstvo procesov, čo významne znížilo náklady na potrebnú pracovnú silu. To umožnilo rýchlu návratnosť počiatočnej investície do systému a znížilo mzdové náklady.

Je neštandardné aby sa vytváral vlastný mailing list, prípadne sa nepoužili existujúce implementácie platobných brán. Na druhej strane klient má systém, ktorý je presne šitý na mieru a na jeho pracovné postupy, kde je každá možná časť týchto procesov automatizovaná.

Záverom by som chcel zdôrazniť, že úspech projektu v prvom rade závisí od schopností dodávateľa vybrať najvhodnejšie postupy a zrealizovať jednotlivé funkcionality tak, aby bol zákazník s výsledným produktom plne spokojný.