Analýza potřeb

Známe své potřeby?

Nebo jenom máme pocit, že by bylo potřeba "něco" jinak. Když přijde řeč na procesní analýzu, měla by úvaha stát na soudržnosti poznaných potřeb (jejich podoby a intenzity), podnikové strategie (jako "směřování úsilí") a důkladné znalosti současné podoby toho, co - jak - proč se v organizaci děje.

Předpokládejme, že lze považovat za nesporné, že pro "řízení změn" (rozvoj) organizace potřebujeme správně chápat její chování (procesy) a její omezení (v nejširším slova smyslu - v jakých podmínkách funguje). Konfrontace strategických zájmů (to možná nejsou "potřeby", pokud ano, tak ve velmi vrcholové podobě) právě s realitou prostředí představuje neustále se proměňující soubor toho, co by bylo žádoucí pro ideální provoz. 

Tyto neoptimální prvky prostředí představují omezení (co brání organizaci efektivněji realizovat své záměry).  Analogicky existují příležitosti (dohromady strategické faktory úspěchu). Takže je dobré se jimi zabývat. Zejména pokud plánujeme optimalizaci pracovních postupů nebo nasazení jakýchkoli technologií.

Jak potřeby identifikovat

Při každé příležitosti se vynořuje nutnost srozumitelně a jednoznačně popsat žádoucí podobu...

Při konsolidaci publikovaných textů jsem na několika místech narazil na téma, jak významnou překážkou "všeho" je, když neumíme udělat smysluplnou analýzu potřeb.

Pozor - potřebami se nemyslí "požadavky".

Viz též registr legislativních (nejen) požadavků… to nejsou ty "požadavky" z registru námětů…

Požadavky jsou obvykle změny, které vyplývají z nedostatečně vyjasněných (poznaných, promyšlených... daných do souvislostí) reálných potřeb. "Potřeba" je něco na základní systémové úrovni. Např. potřebujeme vzduch k dýchání. Provozní prostory pro výkon našich (produktivních i administrativních) činností. Případně stroje. Zákazníky. Spolupracovníky.

Hierarchicky - každá vrcholová potřeba se rozpadá na haldu dílčích jevů/dějů...

Nejsou to nakonec činnosti, které tak zoufale hledáme?

Probůh - přece potřeba nemůže být totožná či jinak odpovídat činnosti (procesu)? To jsou přece dvě úplně rozdílné "škatulky". Je sice spousta pojetí procesů, podstatou by mělo být, že definují povinnosti lidí. Tak jak by mohla být povinnost potřebou? Či naopak...

Nebo?

Co jsou to potřeby

Příklady:

• Koupěschopná poptávka po našich produktech.
• Spolehlivé dodávky vstupů.
• Fungující technologie.
• Produktivita... kompetentní lidé se zájmem... atd. atd.

Něco konkrétnějšího (viz předchozí rozpaky nad definicí procesů ~ viz komentář).
Servis průmyslových zařízení. Návštěva/zásah u zákazaníka.

• Technik má předat na centrálu dohodu (např. oprava na dílně).
• Udělat si pro sebe poznámku, na co se má podívat při příští návštěvě.
• Musí mít rozpis standardních úkonů servisu (vědět, co má dělat).
• Zadat, co udělal a jaké jsou hodnoty kontrolního měření.
• Nechat si (pokud možno) od zákazníka potvrdit, že tam byl a něco dělal.

Je toho víc.

Je jasné, co je to ta potřeba?

Ty "velké" (komplexní) potřeby musíme rozpadnout na elementární. U těch je vidět, že se fakticky jedná o požadavky na podobu reálných činností (např. u této servisní divize firmy byl nekompromisní požadavek, aby technik měl plánované návštěvy v kalendáři v telefonu včetně termínu, adresy zásahu, telefonu na kontaktní osobu, historie instalovaných zařízení; k tomu přidružené požadavky, za jakých okolností lze sjednanou návštěvu přeplánovat atd.)

Zkoušeli jsme to popisovat pomocí User Stories & Use Cases.

S využitím sofistikované (fakticky "návodné") metodiky.

Nefungovalo.

Nejenže zadavatel (klíčoví uživatelé) nebyl schopen žádným způsobem "začít" (konzistentně) popisovat, co se jak dělá (zato bez záznamu fantazírovali o tom, jak by bylo skvělé, kdyby to s těmi zákazníky domouval nějaký agent a servisní zásah režírovala "AI" v telefonu), ale ani si přečíst to, co na základě analýzy vyšlo nám. Natož to připomínkovat.

Co je příčinou?

• Možná částečně procesní nezralost (některý další příspěvek).
• Neochota / obtížnost zvládnout nový způsob myšlení.
• Potřeby totiž téměř jistě musí být "součástí" procesního modelu.

Máme další agendu, na kterou bychom měli uplatnit "jednoduché" rozhraní.

Analogie kontrol.

Potřeby a činnosti

Co mají "potřeby" společného s procesními činnostmi (povinnostmi lidí). Když se to vezme naprosto formálně...

...potřebujeme, aby lidé věděli, co kdy jak mají dělat a dělali to.

Takže "potřebujeme činnosti".

Abych mohl identifikovat, co "potřebuji" (viz definice "User story"), musím to vztáhnout k tomu, proč. Co dělám. Ne k pozici ("...jako nákupčí..."). Jasně, může být, že v tomto okamžiku ještě onu konkrétní činnost nemám přesně definovanou. Což je to stejné, jako u kontroly.

Mohu čekat, až ji někdo nadefinuje.

Nebo ji vytvořit. Ten návrh by měl být validován - potřebujeme činnost. Pokud ji nemáme, tak iniciovat proces, který návrh přezkoumá, doplní, propojí a potvrdí (či zamítně). Když se ten proces zprovoznit nepodaří, tak o nic nejde, jenom je jasné, že tady nemá smysl se o nic snažit.

Prozatím u všech příkladů, které si vybavím, odpovídá potřeba tomu, co bychom měli / chtělit definovat jako činnost / povinnost. Např.
📌 Potřebujeme získat nového zákazníka.
📌 Akviziční obchodník má vyhledat, ověřit, oslovit, ... atd.

Vlastně vždy, když se nám podaří identifikovat, co potřebujeme, následuje logicky otázka, co kdo musí udělat, aby se to stalo. Může se zdát nebo i stát, že se potřeby vyšší úrovně rozcházejí s procesy / procesními oblastmi. Což může být signál, že naše (obvykle uměle vytvořené) procesní oblasti nejsou vymezeny podle faktických "toků" (procesů), ale pod vlivem funkčního pohledu na organizaci. Protože "potřebu" nejspíše může mít jenom vlastník procesní oblasti. Jsou to funkce, které má oblast plnit pro fungování firmy. Takže logika říká, že když nic jiného, tak determinují procesy. Komplexnější potřeba se skládá z dílčích. Může být, že jeden proces uspokojuje několik potřeb a občas bude pro uspokojení jedné potřeby nutno konstituovat více procesů. V takovém případě bude vždy rozumné se zamyslet, jestli je to tak ve skutečnosti.

V podstatě stačí "naučit" potřeby (na vyšší úrovni) rozpadat se na dílčí.

A naopak - hledat, čím je vyvolán požadavek na výkonné úrovni (např. Jinými slovy v rámci správy požadavků (procesů) umožnit analýzu (rozklad) jasných (byť značně obecných) potřeb (např. "zvyšovat bonitu zákaznického portfolia" nebo "zvyšovat výkonnost a stabilitu firmy" či "rychleji inovovat produkty") na cílenější a konkrétnější...

...které téměř jistě vedou k činnostem (povinnostem). Možná k projektům.

Stejně se v architektuře správy podnětů počítá s tím, že musí jít požadavky propojovat (minimálně ve smyslu závislostí, tedy pořadí). Navíc je tu námět, zda by šlo tuto agendu využít pro připomínkování... čehokoli, ale i samotných podnětů. Pokud by tohle fungovalo, tak bezpochyby mohou či spíše musí být i podněty hierarchické, čímž je umožněn onen rozpad (či případně syntéza).

Zmíněný předchozí příspěvek, pozastavující se nad tím, proč nemůžeme s klíčovými uživateli najít společnou řeč. Ona je totiž pravda, že aby si člověk dokázal představit, co s čím souvisí a jak by se měly věci dělat (např. je tam pěkně popsáno dilema, jestli a jak se má vytvářet plán zásahu - seznam úkonů, které by se měly provést... mezi ně patří to, co si u daného zařízení "pro sebe" technik poznamenal minule).

Nástroj pro správu...všeho

Připadá mi (je to přímočaré rozvinutí nápadu s kontrolou), že pokud máme k dispozici relativně použitelný nástroj pro sběr podnětů/požadavků... který ve své podstatě směřuje ke komplexnějšímu pojetí... postupně do primitivní struktury přibyla procesní oblast, aby se dal pokud možno automatizovaně přiřadit garant, který se má podnětem zabývat, následně se tam vnutil i konkrétní záměr (účel práce pro úkoly)... no a teď se ukázalo, že nejen pro potřeby identifikace "kde přesně" se nachází podstata požadavku či námětu, se hodí i procesní aktivita (činnost).

Je neuvěřitelně jednoduché připojit (první nástřel / experiment / prototyp) požadavky do procesního modelu. Což je víceméně výsledek - nacházené požadavky se dají k činnosti přiřadit rovnou a nebo při jejich zpracování. Popř. se v ranných fázích existence stanou podnětem pro definici činnosti. Další způsob, jak může vznikat procesní model.

Pořád jsou to "požadavky/podněty". Nikoli "potřeby".

Ale když to rozumně uchopíme... tak jim možná dáme možnost se "vyvinout"...

To ještě bude zajímavé.

Kdyby to fungovalo, dávalo by to hodně smysl.

Pokud o tomto tématu máte chuť diskutovat, dá se to u výchozí podoby příspěvku na LinkedIn. Pokud se vám budou hodit informace nebo zvažujete spolupráci, ozvěte se. Umíme pomoci se smysluplnou digitalizací a automatizací.