Pirátská strana
facebook LinkedIN LinkedIN - follow
Tematické sekce
 
Branžové sekce
Přehledy
 
Tematické seriály
 

GDPR

General Data Protection Regulation zásadně mění zpracování osobních údajů a zavádí nové povinnosti...

články >>

 

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 

Komplexní svět eIDAS

O nařízení eIDAS již bylo mnoho řečeno i napsáno. A proto jediné, o čem...

články >>

 

Trendy v CRM

Systémy pro řízení vztahů se zákazníky (CRM) prochází v posledních letech výraznou změnou. Zatímco dříve...

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 
Partneři webu
Navisys
IT SYSTEMS 10/2006 , ITIL – Řízení IT

Jak definovat poptávku po softwarovém řešení

Radim Vongrej


Pamatuji si na období, kdy jsem začínal programovat a psát své první, zpočátku jednoduché, programy. Krátce na to jsem byl osloven zástupcem jedné výrobní firmy, který mi sdělil, že firma potřebuje napsat program. Ukázal mi dokument, kde byly sepsány požadavky, a zeptal se mne, do kdy jsem schopen mu poslat nabídku. „Nabídku ? Nikdy jsem žádnou nabídku nepsal. Vždy jsem podepisoval jenom smlouvy.“ Načež mi zástupce odpověděl: „Kontaktovali jsme ještě další programátory a chceme si vybrat toho, který nám bude nejvíce vyhovovat.“ Ve snaze tuto větší zakázku získat, jsem akceptoval všechny požadavky na program, připsal šibeniční termín a cenu, která korespondovala s termínem dodání. Radost, kterou jsem měl, když jsem zakázku nakonec získal, začala postupně s vývojem programu vyprchávat. Akceptované požadavky byly natolik obecné, že se postupně musely zpřesňovat, a tudíž objem práce rapidně narůstal. Nakonec jsem strávil s vývojem programu několikanásobně více času, ale to hlavní, co jsem si ze zakázky především odnesl, nebyly pouze peníze, nýbrž jedna velká zkušenost. Když jsem se ve své profesní kariéře poprvé setkal s dokumentem RFP (Request for Proposal), má předcházející zkušenost mě ujistila, že obezřetnost je zde určitě na místě.


V případech, kdy firma potřebuje řešení, které má být kompletně zajištěno externí firmou, vytváří formální dokument RFP. Dokument popisuje projekt, který vzniká pro dané řešení, definuje způsob, jakým by měli přizvaní dodavatelské na dokument odpovídat, jak budou tyto odpovědi vyhodnoceny a případně, jaké budou informace o budoucím kontraktu s vybraným dodavatelem řešení.
Přizvané firmy si pak RFP přečtou a napíší nabídku (návrh), kde vysvětlí, jak by systém řešily, do jakého termínu jej implementovaly a kolik peněz by za vyvinutý systém chtěly. Nabídka by měla dodržovat stanovená pravidla uvedená v RFP, jinak hrozí riziko, že dodavatelská firma by mohla být z výběrového procesu vyloučena.
Je však třeba zmínit, že zpracování dokumentu RFP je pouze jedna z fází výběrového procesu a samotný dobře zpracovaný dokument RFP nám ještě nemusí zajistit požadovaný výsledek. Zvláště v případech, kdy se jedná o skutečně komplexní řešení, musí zadavatel před vydáním RFP nastavit pravidla samotného výběrového procesu.
Vlastní výběrový proces tvoří následující fáze:
  • sestavení interního týmu lidí, který bude definovat základní požadavky na systém,
  • sestavení vyhodnocovacích kritérií pro jednotlivé požadavky, na základě kterých budou nabídky posouzeny,
  • vypracování dokumentu RFP,
  • výběr dodavatelských firem, kterým bude zaslán dokument RFP,
  • vyhodnocení odpovědí na RFP od zúčastněných dodavatelů, v případech velkých komplexních projektů nejsou výjimkou prezentace návrhu řešení jednotlivých dodavatelů,
  • výběr finálního dodavatele systému,
  • příprava a sepsání kontraktu mezi vítězným dodavatelem a zákazníkem.


Zadavatel musí popsat požadavky takovým způsobem, aby dodavatel poznal jeho skutečné potřeby.


Jeden z nejdůležitějších cílů ze strany zadavatele ve výběrovém řízení je schopnost identifikovat řešení, které nejlépe odpovídá požadavkům a potřebám jeho vlastního businessu. Dále musí zadavatel popsat požadavky takovým způsobem, aby dodavatel poznal skutečné potřeby zákazníka. Přestože zadavatel dokáže formulovat své skutečné potřeby, nemá ještě stále vyhráno. Uvedu příklad toho, co se skutečně může stát. Představme si situaci, kdy zadavatel obdrží nabídky od oslovených dodavatelů na jedno RFP a každá tato nabídka popisuje zcela rozdílné řešení. Zadavatel pak není schopen tato řešení porovnat, vyhodnotit a v neposlední řadě toho správného dodavatele vybrat. K čemu takové případy vedou? K reformulaci RFP, k novému výběrovému řízení, což znamená jediné: vysoké náklady a značné časové prodlevy.

Pokud se zaměříme na dodavatele, je jeho nejpodstatnějším cílem rychle identifikovat rozsah systému a nalézt cenově přijatelné řešení, které pokryje jeho požadavky.
Nemělo by se však zapomínat i na další cíle řešení, jako jsou minimalizace rizik, nákladů a samotného úsilí spojeného s vytvořením takového řešení.

Výběr vhodných kandidátů na dodávku systému bývá prováděn na základě dostupných informací. Mezi tyto kandidáty patří především dodavatelé, se kterými zadavatel již minulosti spolupracoval, kteří jsou úspěšní ve své oblasti poskytovaných služeb, kteří jsou doporučováni svými zákazníky, případně ti, kteří vykazují tendenci růstu ve svém oboru, se silným potenciálem pro úspěch.

Typy poptávkových dokumentů

RFI (Request for Information) – Jde o určitou variantu dokumentu Request for Propsal, avšak ve zjednodušené podobě. Hlavním účelem je zjistit, zda jsou na trhu dostupné produkty či služby, které splňují očekávání a požadavky ze strany zadavatele. V některých případech výsledek RFI slouží jako podklad pro samotné zpracování dokumentu RFP.
RFQ (Request for Quotation) – Zde se jedná o další variantu dokumentu RFP, kde specifické otázky a jejich odpovědi od dodavatelů nejsou vyžadovány (především v případech, kdy specifikace produktu nebo služby jsou již známy). Klíčová doména těchto dokumentů je především cena a ta je hlavním faktorem pro výběr úspěšného dodavatele.
RFP (Request for Propsal) – Tento dokument je podstatně detailnější, než výše uváděné dokumenty RFI a RFQ. Je komplexní, podrobný a obsahuje celou řadu informací s cílem v maximální míře informovat přizvané dodavatele o cílech zamýšleného projektu.
Struktura takového dokumentu obsahuje nejčastěji čtyři základní charakteristiky:
  • průvodní informace o zadavateli, soupis potřeb, požadavků na řešení i na systém, dále jsou zde uvedeny informace o termínu odevzdání nabídky, kontakty na zúčastněné osoby a další informace týkající se projektového plánu,
  • část popisující veškeré informace, které všechny nabídky musí obsahovat, a jakým způsobem budou vyhodnocovány,
  • očekávání ze strany zadavatele, termíny, cenové požadavky,
  • popis požadavků, potřeb, případně problémů zadavatele, které vedly zadavatele k vypsání výběrového řízení.

Úskalí RFP

Představte si, že jste oslovený dodavatel, RFP jste si přečetli, a přesto si nejste jisti, co vlastně zadavatel skutečně chce. Jaký je vlastně rozsah řešení? A co navíc, žádné další, dodatečné informace nelze od zákazníka získat. I takové situace nejsou ničím neobvyklým. Některé RFP dokumenty jsou extrémně krátké a nejasné. V takových případech mohou být RFP dokumenty distribuovány s primárním cílem, zadavatel skutečně neví, co chce a vydání RFP chápe jako příležitost získat vizi budoucího řešení, případně očekává, že na základě přijatých nabídek si vyjasní skutečný rozsah řešení. Oslovený dodavatel pak může případnou nabídku chápat jako příležitost ke kreativitě a může zadavateli nastínit vlastní představu toho, co zadavatel pravděpodobně chce řešit.
Na druhé straně však nejasný RFP dokument může vést k tomu, že dodavatel odmítne pracovat na nabídce, protože investice a čas vynaložený k tomu, aby zjistil skutečné potřeby zákazníka, se mu prostě nevyplatí. V neposlední řadě mohou nastat i situace, kdy i přes nejasné zadání, dodavatel nabídku vypracuje a přitom ví, že projekt nebude ziskový. Ve většině takových případů dodavatel sleduje dlouhodobý cíl, a to získat zadavatele na svoji stranu s velkou pravděpodobností dalších zakázek.
Obecně se doporučuje u ne zcela jasných RFP postavit nabídku dodavatele na cenově přijatelné úrovni a pak přiložit další, rozšiřující varianty řešení, každá se samostatnou cenou. Dodavatel se tak jistí proti tomu, aby se projekt nevychýlil z rozsahu řešení, a navíc poskytne zadavateli jasné cenové schéma dalších dodatečných úprav systému.



Dodavatel může svoji nabídku chápat jako příležitost nastínit zadavateli vlastní představu toho, co chce zadavatel pravděpodobně řešit.


Pravidla pro psaní RFP

Definujeme potřeby
V prvním kroku při psaní RFP pro informační systém si musíme ujasnit, co od nového systému očekáváme a jaké požadavky musí systém splňovat. Tento krok bývá nejčastěji nazýván analýzou potřeb, případně procesem definování požadavků.
Tato fáze by měla být provedena ve firmě organizovaným způsobem. Znamená to sestavení týmu lidí se znalostmi z daného oboru, kteří dokážou označit současné problémy a mají představu, jak by nový systém měl vypadat a fungovat. Nezbytné je organizovat pracovní schůzky, kde probíhají diskuze jak o současných problémech, tak o novém řešení a požadavky jsou postupně sjednocovány a konsolidovány.

Nastavujeme priority
V okamžiku, kdy jsme spokojení s vytvořeným seznamem požadavků, by měl být každý požadavek označen prioritou, která jasně stanovuje povinné požadavky bezpodmínečně vyžadované a naopak požadavky charakteru „uvítali bychom“.

Formulujeme požadavky
Požadavky by měly být psány jasně a stručně a především proto, aby si tým na straně dodavatele, sestavený pro nabídku, příliš nelámal hlavu s tím, jak je to vlastně myšleno. Na druhé straně však v případech, kdy sloučíme řadu požadovaných funkcí do jednoduché definice, může dodavatel odpovědět „ano, bude podporováno“, a pak můžeme být překvapeni, že systém dělá pouze část toho, co jsme původně zamýšleli.



V jednom finančním domě byl v rámci projektu definován požadavek na vytvoření rozhraní pro příjem dat označujících rizikovost určitého druhu zajištění pro úvěrový produkt. Implementace takového rozhraní znamenala značnou pracnost i investici. Následně se zjistilo, že banka má ve své evidenci pouze dva takové zajišťovací prostředky a implementace takového rozhraní v podstatě neovlivní celkový výpočet rizikových koeficientů. Od požadavku se pochopitelně upustilo.
Na jiném projektu byl jedním z požadavků zákazníka systém centrálního úložiště dat, kde se měly evidovat číselníky. Byla požadována obecná datová struktura, která měla umožnit založení jakéhokoli číselníku s možností kdykoliv změnit strukturu číselníku v čase. Takové řešení v daném prostředí znamenalo termín dodání řádově ne v měsících, ale letech. V rámci analýzy jsme vypracovali seznam dopadů, které popisovaly, co znamená implementovat takové požadavky. Následně zákazník přehodnotil priority jednotlivých požadavků a byl definován rozsah řešení, který odpovídal skutečným potřebám zákazníka.


Vyhodnocujeme nabídky dodavatelů
Samotný proces vyhodnocení nabídek vyžaduje mít definovanou jasnou strategii, která by měla být formulována již během přípravy poptávky RFP. V dokumentu RFP musíme identifikovat všechna důležitá vyhodnocovací kritéria a měli bychom požadovat po dodavateli jasná stanoviska k těmto bodům.
Často je pak pro účely vyhodnocení zhotovena tabulka, tzv. matrix, kde jsou přenesena vyhodnocovací kritéria a nabídka každého dodavatele je pak ohodnocena pomocí stupnic. Takový matrix pak pomůže zadavateli lépe identifikovat dodavatele, který splňuje nejlépe požadavky zadavatele.
Nejčastěji je samotný výběrový proces získaných návrhů od dodavatelů kategorizován do tří základních skupin pro každý specifický požadavek:
  • splňuje požadavek,
  • nesplňuje požadavek,
  • je potřeba získat více informací ze strany dodavatele.
V závislosti na okolnostech výběrového řízení jsou stanoveny obvykle dvě fáze procesu. První fáze znamená vyhodnocení a výběr nabídek na základě nejdůležitějších kritérií. Nabídky, které prošly první selekcí, jsou dále v druhém kroku vyhodnoceny opětovně, avšak v mnohem detailnějším měřítku. Je běžné, že zadavatel si pozve jednotlivé dodavatele na prezentaci svých nabídek.


V případech, kdy je RFP zpracováno příliš obecně, bude zadavatel vystaven řadě doplňujících otázek.


Nepodceňujme RFP

Vytvoření RFP vyžaduje značnou námahu a hodně času. Nezřídka jde o skličující úkol a může se stát, že zainteresovaní lidé zpracování takového dokumentu nevěnují dostatek úsilí. Často také zadavatel nedisponuje kvalifikovanými experty nebo zdroji pro zajištění a řízení většího a komplexního výběrového procesu. V takových případech lze využít služeb nezávislých konzultantských firem, které s přípravou a zpracováním RFP dokumentů mají značné zkušenosti.
V případech, kdy je RFP zpracováno příliš obecně, to bude přinejmenším znamenat velkou výzvu pro dodavatele a pravděpodobně se stane, že zadavatel bude vystaven řadě specifických doplňujících otázek, protože v zájmu dodavatele je v počátku především zjistit, co zadavatel skutečně potřebuje.
Kvalitně zpracované RFP s odpověďmi, které se vrátí od dodavatele, umožní zadavateli provést adekvátní zhodnocení a učinit rozhodnutí, koho si vybrat pro dodání zakázky a vydat se s ním na společnou cestu. Nikdy by zadavatel neměl být v situaci, kdy opakovaně vyžaduje od dodavatele doplňující informace ke konkrétní otázce. Jestliže nelze získat jasnou odpověď z RFP, jak můžete dodavateli věřit, že vám jasně odpoví i v případě, kdy budete požadovat urgentní vyjádření k problému, například při podpoře po nasazení systému?

Závěrem

Proces výběru dodavatelské firmy není jednoduchý a výběrem jakéhokoliv dodavatele je zadavatel postaven do pozice, kdy musí s dodavatelem spolupracovat, a co více, po implementaci řešení musí se zvoleným produktem žít. Proto nepodceňujeme dokument RFP, je to důležitý krok k dosažení očekávaného výsledku.

Autor článku, Radim Vongrej, působí jako Senior Consultant ve společnosti Cleverlance Enterprise Solutions.

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.

Inzerce

Zabijáci produktivity

IT Systems 9/2020V aktuálním vydání IT Systems se poněkud kriticky podíváme na home office, který byl u nás dříve využíván jen sporadicky. S příchodem března jsme se ovšem stali účastníky nechtěného experimentu. Na home office přešli téměř všichni, kterým to povaha práce dovolovala. Internet se brzy plnil články o vysoké efektivitě při práci z domova a starosti nám dělalo jen zabezpečení.