Typická výchozí situace
V praxi je to většině případů analogie "údivu" z knihy o telefonování - "... nevěřili byste tomu, ale opravdu se stává, že se to dělá pokaždé jinak ..." (osobně se tomu už moc nedivím).
- Přijde poptávka (skutečně se jedná o situaci, kdy poptávky chodí - v situaci, kdy jsme šanci předložit nabídku získali vlastním přičiněním, je situace drasticky horší, ale vypadá mnohem lépe - o tom pravděpodobně někdy jindy někde jinde). Rozumí se poptávka po standardním produktu (nebo poptávající si alespoň myslí, že je standardní).
- Není úplně zaručeno, že se dostane do "správných rukou", ale to je spíše komplexní důsledek toho, že chybí definované procesy. Pomíjíme také situaci, kdy se na ni zapomene a žádná nabídka se nepošle.
- Obvykle se vytváří jako textový dokument, popř. pomocí naprosto šílené hračky v Excelu, ve které polovina z toho, co je potřeba napsat, stejně nejde.
- Co hůř - většinou jsme moc pohodlní na to, abychom se od poptávajícího pokusili získat optimální množství informací o něm či doplnit nepřesné informace v poptávce (popř. v organizaci fungují takové vztahy a pravidla, že je to technicky nemožné).
Obvyklý postup
- Takže podle nálady a pocitů toho, kdo tuto poptávku vyřizuje, vznikne nejspíše dokument, ve kterém je více či méně to, co poptávající chce vědět a co by tam mělo být. Protože je potřeba hodně dávat pozor, jde to hodně pomalu. Navíc se při přemýšlení nad tím, co tam asi mělo být (vzhledem k tomu, že chybí pravidla), dá strávit klidně celý den.
Myslím, že každému se - v případě, že to dělá tímto neformalizovaným způsobem - čas od času stane, že zapomene na některou důležitou součást - např. na platnost nabídky nebo na aktualizaci telefonního čísla ... popř. když nabídky vytváří z nějaké již existující, tak tam zapomene některé údaje vztahující se k té výchozí. Obvykle to děláme tak, že nejširší nabídku promazáváme, jenže je škoda, že když náhodou do nového znění zapracujeme nějakou zkušenost, kdy jsme si natloukli nos, při dalším promazávání se může stát, že o tuto zkušenost přijdeme.
- Měla by obsahovat (a ve skutečnosti by měla být velmi striktně regulována v zájmu věrohodnosti firmy a dalších aspektů)
- Hlavičkové informace (identifikace předmětu, identifikace poptávajícího, klíčové údaje typu datum/-y a místo realizace apod.)
- Zadání (konverze požadavků poptávajícího do standardní terminologie a struktury ... záleží na branži).
- Specifikaci nabízeného plnění. Popř. samostatně ceny, pokud není součástí rozpisu položek plnění - většinou to asi budou dvě (či více) různé sekce, protože často bude potřeba nabízet varianty, navíc popis "vlastností" plnění je lepší oddělit od cen.
- Harmonogram plnění. Popř. u některých komplexnějších řešení dodatečné informace typu realizační tým či klíčové osobnosti a jejich kvalifikace.
- Návrh / předpokládaný další postup. Výhrady, vymezení platnosti (zejména termínů a cen).
- Identifikaci nabízejícího. Certifikace a vyžadovaná oprávnění.
- Reference (relevantní nabídce/produktu), pokud jsou vyžádány nebo je to zvykem.
- U obvyklého postupu se dokument odešle a když to máme v podstatě dobře zorganizováno, tak se někam (minimálně do knihy odeslané pošty) zapíše, že nabídka odešla.
- Ve většině případů se o tuto záležitost dál už nikdo nestará ...
[Samozřejmě pokud právě nejste v období zakázkového nedostatku.]
Občas se stává, že se jedná o neformální kontakt se zákazníkem, na jehož konci je slib "Podívám se, co by se dalo vymyslet a pošlu nabídku, abyste si to mohli promyslet." ... většině z nás se dost často stává, že žádnou nabídku nevytvoříme a nepošleme.
Inteligentní dokument
Nabídka standardního produktu je plně automatizovatelná záležitost. Standardním produktem se rozumí takový výrobek nebo služba, která existuje v ceníku. Může existovat v různých variantách či může mít řadu volitelných součástí či specifických vlastností (tzn. je parametrizovatelná), ale v principu existuje jednoznačná množina variant. Dobrým příkladem může být nabídka školení či počítačové aplikace, popř poradenské či kombinované služby.
Např. nabídka na trvalou službu typu vedení účetnictví. Inteligentní dokument by podporoval (umožňoval, lépe vynucoval) následující postup:
- Získá data o klientovi z databáze kontaktů. Která je aktualizována jednak průběžně, jednak podle přijaté poptávky a veřejných informačních zdrojů. Tvorba nabídky by si měla vynutit zodpovězení určitých otázek týkajících se nového zájemce - na základě kterých by byly uloženy údaje, které se využijí při tvorbě nabídky, ale především mají vztah k danému subjektu, nikoli ke konkrétní nabídce. Např. mohou obsahovat zdůvodnění, proč je klient málo/hodně atraktivní (a proč tedy třeba nabídka bude mít takovou cenu, jakou bude mít).
- Potom si vyžádá údaje z poptávky. Na základě těchto dat provede (resp. navrhne) ve standardní nabídce (pravděpodobně formou průvodce, také se záznamem zdůvodnění) potřebné úpravy (znění, hodnot). Tím se (pokud jsou místa, na kterých se provádějí modifikace, dobře připravená a promyšlená) lze vyhnout tomu, že by bylo nezbytné celou nabídku znovu číst/kontrolovat (neřkuli psát).
- Jak je zřejmé, podstata nespočívá v tom, že by nějaký robot vytvořil nabídku sám, ale že máme možnost a povinnost udělat to "pořádně". Cílem je snížit chybovost a zrychlit zpracování, především uložit všechny získané a použité údaje v datové podobě, tedy odděleně od dokumentu.
Povinností (uživatelů systému, zde konkrétně garanta nabídkového portfolia - typicky manažer obchodní administrativy) musí být vytvoření (a schválení) nové šablony pro každý nový typ nabídky (do té doby, než zjistí, že se dají všechny typy nabídek pokrýt jedinou šablonou). Tedy korektně a v potřebném rozsahu stanovit (tzn. promyslet) vlastnosti - oddělit "zrno od plev" (co je pevná a co parametrizovatelná součást). Čas od času všechny existující šablony revidovat (sloučit či přenést užitečné prvky).
- Samozřejmě musí být dostatečně jednoduché, aby když něco ne ideálně vyhovuje, tak byla provedena právě na úrovni oné standardní nabídky modifikace.
- Když je potřeba změnit strukturu šablony, změnu musí schválit (byť následně) oprávněná osoba (potřebné změny se provádějí vždy na úrovni šablony, nikdy přímo v jednotlivé nabídce). Případně vznikne nová šablona.
- Změna musí zachovat všechny standardní (původní, uvažované) kontexty a současně umožní přidat do výčtu možných variací dané části nabídky nové znění, které lépe odpovídá aktuální kombinaci údajů.
- Pro sestavení standardní nabídky je k dispozici šablona dokumentu, databáze alternativních znění těch částí nabídky, které je (dosud bylo) žádoucí měnit a algoritmus (pokud možno uživatelsky nastavitelná pravidla), který říká, za jakých podmínek má být použita (resp. nabídnuta) ta která hodnota (resp. množina hodnot).
- Výsledkem je sada "platných" hodnot uložených v XML struktuře propojených na daný dokument, které je velmi jednoduché projít, popř. modifikovat a následně uložit.
- Samozřejmostí je převedení dokumentu (tzn. vytvoření dočasné instance sloučením šablony a dat) do standardního formátu (např. PDF), odeslání s průvodní zprávou dle odpovídající šablony patřičnému příjemci a vytvoření termínu/připomínky/úkolu, která se bude vztahovat k přijetí / potvrzení nabídky či její expiraci.
- Současně by se takováto nabídka měla přiměřeným způsobem promítnout do správy kapacit atd. atd..
Co z toho plyne | Závěry
- Který scénář je logičtější? Efektivnější?
- Co ve skutečnosti brání tomu používat ten lepší?