Posted by Martin Dostál
Původně se projekt jmenoval „Implementace CVM nástroje XY“, ale postupně se ukázalo, že technologie je jen špička ledovce. Poznejte, jak 4 úrovně požadavků a trasovatelnost podle BABOK® Guide pomohly odhalit skutečné byznysové potřeby v oblasti B2B CVM automatizace a jak tento přístup uplatnit ve vlastní praxi.
 

Znáte ten moment, kdy projekt dostane název podle softwaru, který se má koupit a nasadit? Na stůl přistane zadání typu „Implementace CVM nástroje XY“ a všichni mají tendenci okamžitě řešit integraci, obrazovku a parametry nového systému.

Jenže role business analytika spočívá v tom nezůstat na povrchu. Postupným rozkrýváním se z původního „nasazení nástroje“ stala hluboká diskuse o tom, jak přesně identifikovat obchodní potenciál B2B zákazníků, jak zefektivnit akvizici a jak systematicky řídit cross-sell a up-sell.

Aby se z komplexního zadání nestala jen nepřehledná halda ticketů v Jira, přichází na řadu Requirements Classification Scheme a trasovatelnost (Traceability) podle BABOK® Guide (IIBA®) .

4 úrovně požadavků: Příběh z B2B CVM Automation

Rozdělení požadavků do čtyř vrstev pomáhá udržet jasnou hranici mezi tím, co potřebuje byznys, co potřebují uživatelé a jak to udělá systém na pozadí :

  • Business požadavky (Business Requirements) – CÍL:

    Ukazují vyšší smysl a měřitelnou hodnotu pro organizaci. Odpovídají na otázku Proč projektujeme?

    • BRQ-01: Dosáhnout celkového zvýšení výnosů v B2B segmentu o 15 % během 12 měsíců od nasazení.

    • BRQ-02: Zvýšit konverzní poměr cross-sell a up-sell kampaní u stávající B2B báze o 10 %.

    • BRQ-03: Zvýšit zákaznickou spokojenost (B2B NPS) o 8 bodů díky doručování relevantních nabídek na míru.

  • Požadavky stakeholderů (Stakeholder Requirements) – POTŘEBA UŽIVATELE:

    Popisují, co konkrétní roli potřebuje pro dosažení cílů, nezávisle na technickém provedení.

    • STK-01 (B2B KAM): Key Account Manager potřebuje mít před jednáním s klientem přehled o jeho skrytém potenciálu a doporučených rozvojových produktech (akvizice/cross-sell/up-sell).

  • Požadavky na řešení (Solution Requirements) – VLASTNOSTI SYSTÉMU:

    Konkrétní chování IT infrastruktury a aplikace, které naplňuje potřebu KAMa ( STK-01).

    • Funkční požadavky (functional / FREQ):

      • FREQ-001 (Detekce potenciálu): Systém automaticky vyhodnocuje využití služeb klienta a identifikuje kandidáty vhodné pro cross-sell nebo up-sell.

      • FREQ-002 (Generování nabídky): Systém na základě definované matice produktových pravděpodobností vygeneruje v CRM konkrétní doporučenou nabídku pro klienta.

      • FREQ-003 (Založení úkolu): Systém automaticky vytvoří v CRM úkol typu „CVM Příležitost“ přiřazený dedikovanému KAMovi 14 dní před plánovanou schůzkou.

    • Nefunkční požadavky (non-functional / NFR):

      • NFR-001 (Dostupnost dat): Výpočet analytických modelů a zápis CVM příležitostí do CRM probíhá denně v nočním zpracování a úkoly jsou dostupné nejpozději do 06:00.

  • Přechodové požadavky (Transition Requirements) – CESTA K OSTRÉMU STARTU:

    Dočasné potřeby nutné pro úspěšné zavedení do provozu.

    • TRN-01: Provedení jednorázového obohacení dat o oborové klasifikaci firemních zákazníků v CRM před spuštěním produkčního provozu.

    • TRN-02: Zaškolení 80 B2B obchodníků na práci s novým kampaňovým modulem.

Trasovatelnost: Spojovací kód celého projektu

Když jsou požadavky takto konkrétně označené a roztříděné, můžeme z nich snadno sestavit matici trasovatelnosti (Traceability Matrix) :

BRQ-02 (Revenue uplift) ➔ STK-01 (Potřeba KAMa) ➔ FREQ-002 (Generování nabídek) ➔ TEST-04 (Akceptační test)

Trasovatelnost funguje dvěma směry:

  • Pohled zhora dolů (Forward Traceability): Ověřuje, že byznysový cíl zvýšit up-sell ( BRQ-02) má svou odezvu v konkrétní funkčnosti ( FREQ-002) a je pokryt akceptačním testem. Nic podstatného tak ve vývoji nevypadne.

  • Pohled zdola nahoru (Backward Traceability): Pokud vývojový tým navrhuje novou funkci nebo úpravu datového modelu na backendu (např. FREQ-089), trasovatelnost prověří, zda tato práce navazuje na některý z BRQ. Pokud spojka chybí, jde o kandidáta na zařazení z rozsahu (Scope Creep).

Vyzkoušejte si to na svém projektu

Až příště začnete projekt, který má v názvu jméno konkrétního nástroje nebo technologie, zkuste se na prvním workshopu zastavit a projít si tyto kroky:

  1. Pojmenujte skutečné Business Requirements ( BRQ): Odsuňte technologii stranou a ptejte se: „Jaké konkrétní obchodní ukazatele (zvýšení tržeb, konverze, NPS) se zlepší, až tento nástroj nasadíme?“

  2. Očíslujte a propojte požadavky ( FREQ): Dbejte na to, aby funkční požadavky byly konkrétní a měly jasné ID. Zkontrolujte, zda každá položka v backlogu navazuje na vyšší obchodní cíl.

Právě v tom spočívá síla klasifikace podle IIBA®. Pomáhá posunout roli analytika od pouhého „zapisovatele přání na systém“ k partnerovi, který pomáhá doručovat skutečnou byznysovou hodnotu a využívat obchodní potenciál.

Stáhněte si náš Metodický list: Klasifikace požadavků a matice trasovatelnosti, který vám poslouží jako praktický tahák při strukturování zadání na vašich projektech.