Co je třeba implementovat. Firma provozující smluvní autodopravu nezvládá již rozumným způsobem nápor na dispečinku. Dispečink má svoje zaběhané
pracovní postupy, ty se opírají o papírové kartičky, paměť dispečerek a o banální počítačovou evidenci důležitých dat v Excelu.
Pár čísel pro představu. Automobily jsou jak vlastni tak i pronajímané od soukromníků, kteří mají nějaký téměř exkluzivní kontrakt s danou firmou.
Aut je řádově několik desítek, podobně i řidičů. Denně se realizuje cca 150 jízd. Jízdy z valné většiny objednávají velcí odběratelé typu
hotel nebo cestovní kancelář. Klíčových zákazníků je cca tucet.
Co generuje hlavní problémy. Jízd začíná být příliš mnoho. Data pro zúčtování se několikrát přepisují z papírů do různého software, přitom
je zůčtování k dispozici až po několika dnech. Je-li ale zákazníkem hotel, ten by chtěl vědět konkrétní cenu nejlépe ihned po skončení jízdy.
Občas se podaří něco zmotat, kartička zapadne nebo je na ní chybný údaj. Špatně nebo vůbec se zjišťuje pravá přícina toho, proč třeba auto
nebylo přistaveno atd. Data psaná do počítače nemají žádnou "historii".
Přehled evidovaných dat. Několik málo nepříliš dlouhých číselníků. Tedy seznam aut, řidičů, hlavních zákazníků, enumerace notoricky se vyskytujících
situací - třeba důvod pozdního přistavení vozu nebo důvod nespokojenosti zákazníka. To jsou tedy statická data. Dynamická by měla zahrnovat
stále rostoucí databázi objednaných jízd, ty se pomalu přesunou do různých stavů. Tedy hotovo/stronováno/prošvihnuto/ ... Stavů může být z různých pohledů
více - vyfakturováno/zaplaceno/upomínano/rozporováno/ ... Dispečer typicky uvidí aktuální průřez do této databáze, spíš průřezů několik málo.
Tedy jízdy na příštích 24 hodin, všechny objednané jízdy dnes a dále, ... Jeho šéf pak bude chtít sledovat data i retrospektivně. Vedle dat o jízdách
by se měla sledovat detailně historie změn každého záznamu. Tedy kdo, kdy a co do záznamu napsal, aby se dalo zpětně dosledovat, kde případně
začala vznikat chyba.
Technické podmínky provozu. V zásadě se bude jednat o uzavřenou síť LAN, kde bude k aplikaci přistupovat nějaký omezený počet lidí.
Žádoucí ale je, aby do budoucnosti šlo do aplikace přistupovat via Internet a aby se jednalo o tutéž aplikaci, třebas díky konektivitě pomalejší.
Ergonomie. Mělo by se jednat o aplikaci co možná banální, až spartánskou a neumožňující příliš improvizace. Aspoň dispečerům ne. Kvůli snadné migraci
personálu a záskokům je záhodno, aby ovládání bylo zřejmé každému, kdo je zvyklý browsit po Internetu. To hovoří pro nějaké web-like řešení. Prostě
několik "webových" stránek á la GMail. Dispečer si případně v několika tabech pozotvírá svoje tři nebo čtyři náhledy na data a bude mezi nimi
přepínat celou směnu.
Specifikace dat o jízdách. Bude se jednat o cca desítku atributů. Tedy datum a čas jízdy, auto, řidič, zákazník, výchozí destinace, cílová destinace,
snad odkaz na domluvenou cenu, určitě dvě nebo tři stavové proměnné, pár služebních proměnných typu KdoZapsal/KdyZapsal/OdkudZapsal, jedna/dvě proměnné na nějaké
poznámky volným textem. Dispečer možná bude vidět méně položek než případně jeho šéf, který si do nadbytečné položky třeba napíše nějaké poznámky
vzniklé na základě řešení konfliktního stavu, kdy jinak věc vicí zákazník a jinak dispečink a zase jinak hotel.
Typické úkony, scénáře. Moc jich nebude. Několik málo předdefinovaných přehledů dat, tedy dnešek, objednávky do budoucnosti, přehled řidičů a kontaktů na ně, ...
Potom příjem nové objednávky, modifikace, stornování, odbavení/vyřízení. U šéfa pár náhladů na vnitřní data o historii modifikací. Úkony je záhodno popsat
na straně zákazníka, pak se podívat do reálu na dispečink. Určitě bude mnoho drobných nevyřčených detailů a konvencí, o kterých se nikdo nezmíní, které
ale důležitým způsobem ovlivní případné řešení.
První postupný cíl. Upřesnit data o jízdách. Udělat jednoduchou databázi a manipulační formuláře na objednání, storno, upřesnění, odbavení. Všechny položky,
snad s výjimkou těch nejočividnějších výjimek, vyplnitelné z ruky. Až bude jasněji o obsahu číselníků, mohou existovat nad položkami nabídky. nadefinovat
základní pohledy na data a věc postavit do testovacícho režimu k prvním připomínkám. Postavit dovnitř firmy malý servřík, udělat k němu tunel na vzdálenou
správu k nám do JLabs. Přístup přes Internet zvenčí zatím neřešit, ale připravit pro to podmínky.
Mantinely rozpočtu. Nepočítám v to servřík, konektivitu a set-up do podoby, kdy server nedělá nic, ale je přípraven na všechny svoje budoucí úkoly. Je to
jednorazová věc a při dnešních cenách HW není nákladově zajímavá. Uživatel očekává úsporu jednoho pracovního místa, zpřesnění odbavovacího procesu a
i určitý prostor pro zvětšení objemu odbavovaných jízd. Z toho plyne přiměřenost investice v řádu kolem 0.25mio. Provoz, správa, aktualizace a další
indukované náklady je potřeba očekávat v objemu mezi 20 a 30% ročně. Přesná čísla ale není možno teď určit a zatím se spíš odrážim od očekávání investora.
Takže i navrhovaná funkcionalita a předpokládané SW nástroje (systém, databáze, licence, ...) se musejí uvažovat v adekvátní výši.
Předpokládá se další expanze funkcionality, protože teď je zpracování údajů rozptýleno hned na tři nebo kolik různých míst. Prvním a hlavním cílem je ale
rozjet aplikaci sloužící k objednávání a odbavování jízd. Ostatní se uvidí časem. Řešení tedy musí dovolit snadné doplnění dalších pohledů na data,
dalších pracovních scénářů atp.
Praktické poznámky k realizaci. Asi bude vhodné rozdělit věc na provozní infrastrukturu - tedy to, co musí zázkaník pro takovou aplikací mít tak jako tak.
Bez ohledu na to, jak vlastně bude udělána. Tedy servřík, systém, databáze. Bude-li řešení webové, pak set-up webového serveru do podoby, že servíruje
uvítací statickou stránku. Rozumí se, že server je sice webový, ale je shovaný (zatím) uvnitř sítě. Infrastruktura se dá vybudovat, vyexpedovat
a nastavit rychle, je to standardní věc. Zákazník si k ní vybere SLA-čko podle libosti, rozumí se, že dokud nebude provoz pro něj kriticky důležitý,
pak SLA-čko mírné a laciné. Pak sám uváží, jaké bude chtít response-time apod. Až toto bude vyřízeno, je možno přistoupit k iterativní implementaci
dotyčné aplikace a hlavně, bude možno ji na obou stranách drátů vidět. Tedy zkoušet u zákazníka a měnit i vylepšovat v JLabs a to s okamžitou možností se
podívat na případný výsledek úpravy, zase na obou stranách.