- Přehledy IS
- APS (20)
- BPM - procesní řízení (22)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (33)
- CRM (51)
- DMS/ECM - správa dokumentů (20)
- EAM (17)
- Ekonomické systémy (68)
- ERP (79)
- HRM (27)
- ITSM (6)
- MES (32)
- Řízení výroby (36)
- WMS (29)
- Dodavatelé IT slueb a řeení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (39)
- Dodavatelé CRM (33)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (71)
- Informační bezpečnost (50)
- IT řeení pro logistiku (45)
- IT řeení pro stavebnictví (26)
- Řeení pro veřejný a státní sektor (27)
ERP systémy
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údrby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tisk![]() | |
| Přihlaste se k odběru newsletteru SystemNEWS, který kadý týden přináí výběr článků z oblasti podnikové informatiky | |
![]() | |
Agilní dodávka softwaru neznamená černou díru na peníze, je jedinou realistickou volbou u inovativních řeení
U dodávky softwarového řeení inovativních nebo velkých projektů prakticky nikdy nelze stanovit přesnou cenu, protoe není na začátku určen zcela přesný a neměnný obsah dodávky do posledního detailu. Vdy dochází k doplňujícím (původní záměr roziřujícím) nebo změnovým poadavkům, které reagují například na novou legislativu, taktiku konkurenčních firem, úpravu obchodní či marketingové strategie nebo na změnu potřeb uivatelů. Toto ivé zadání lze adresovat agilním způsobem softwarového vývoje.

U firem, které nejsou v jádru technologické, se opakovaně setkáváme s nedůvěrou v agilní způsob dodávky softwaru, ačkoli se nám jeho dopad na efektivitu v praxi mnohokrát osvědčil. Zadavatelé mají občas mylnou představu, e dodavatel nedokáe předem stanovit cenu za realizaci a pak ji garantovat.
Zkuený dodavatel by měl dokázat poskytnout hrubý cenový odhad, za který lze dodat řeení pokrývající definované byznysové potřeby, a stanovit mantinely, v nich je cena platná. Pokud toho není schopen, nemá nejspí zkuenosti s řeením podobné komplexity, a nemůe tím pádem určit cenu srovnávací metodou.
Nezapomínejte se ptát a srovnávat
Je vhodné poptat několik dodavatelů, například formou ádosti o zaslání informací (RFI). RFI je standardizovaný proces, ve kterém jsou dodavatelé zvyklí připravit návrhy, jakým způsobem a za jakých podmínek jsou schopni poptávané řeení doručit. Jejich odhad by se neměl diametrálně liit. Pokud se některý odhad vymyká, je to příleitost ptát se vech zúčastněných: jak je jejich řeení koncipované, co obsahuje a co ne, co je na jejich návrhu nejsloitějí (tím i drahé) a jak by se to dalo řeit jinak. Zároveň se tím můe odhalit, zda dodavatel nemá strategii, jak navýit cenu a v průběhu realizace.
Při těchto diskuzích se ukáe nejen kvalita návrhů, ale také přístup dodavatele ke spolupráci, jeho hodnoty a firemní kultura obecně. Zadavatel se pak můe rozhodnout nejen na základě ceny, ale také pocitu, se kterým dodavatelem se mu bude lépe spolupracovat. Ukazuje se, e vzájemná chemie, ochota spolupracovat a transparentnost jsou klíčové ingredience, které rozhodují o tom, zdali projekt bude úspěný.
Vzájemná chemie pomůe překonat i náročné situace v průběhu realizace
V průběhu realizace bude podobně jako v kadém jiném vztahu nutné projít sloitými situacemi, které nelze předem předvídat. Vzájemné vztahy, přístup a respekt budou rozhodující pro jejich překonání. V některých případech můe mít dodavatel ji hotový produkt, který pro nového klienta přizpůsobí, co můe náklady sníit. Zákazník ovem musí být smířen s tím, e se do nějaké míry bude muset přizpůsobit ji hotové krabici a nezíská exkluzivní licenci na celé dílo. To ve můe být u inovativních projektů zásadní problém.
Dodavatel s reálnou zkueností s agilním vývojem softwaru by měl zákazníka vést k tomu, aby byl rozpočet vynakládán na vývoj zásadních funkcionalit systému přináejících největí byznysovou hodnotu. Společným cílem by pak mělo být spustit nové řeení do ostrého provozu co nejdříve v momentu, kdy bude uivatelům poskytovat aspoň minimální uitečnou hodnotu. A pak iterovat s dalími verzemi. V agilních kontraktech se proto typicky nestanoví výčet konkrétních, technicky popsaných funkcionalit, ale naplnění byznysových poadavků, respektive potřeb, které lze rozřadit do skupin podle důleitosti a priorit.
U inovací nepočítejte pouze s náklady na vývoj
Zvlátě u větích projektů je důleité počítat s tím, e vlastní vývoj netvoří sto procent vech nákladů. Do nich se mohou promítnout licence za pouité technologie, provoz (hosting), monitoring a podpora a obvykle i následný rozvoj řeení. Proto je pro stanovení rozpočtu vhodné vdy uvaovat o tří- a pětiletém horizontu potřebných nákladů nejen na výrobu, ale také na provoz (TCO). A právě toto je částka, kterou by měly cenové nabídky obsahovat, aby je bylo moné porovnat. A současně se jedná o částku, kterou by měl obsahovat agilní kontrakt mezi zadavatelem a dodavatelem.
Firmy si stále více uvědomují, e agilní způsob dodávky softwaru není chaos. Díky tomuto přístupu naopak vznikají uitečná inovativní řeení, která naplňují byznysové cíle. Zejména proto, e agilní způsob je postavený na otevřenosti, partnerství a spolupráci, na aktivním zapojení zákazníka do dodávky, který ji můe na denní bázi ovlivňovat a měnit. Agilní způsob dodávky vede k uitečným řeením, pokud je správně realizován. Ověřte si proto, e partner, se kterým jednáte, agilitu opravdu umí, a spolupráci si zkrátka vyzkouejte.
![]() |
Tomá Páral Autor článku je CEO a spoluzakladatel technologicko-konzultační společnosti MoroSystems. |



















