Do skupiny sociálního softwaru spadají nástroje, jako jsou diskusní fóra, blogy, wikipedie atd., které podporují vytváření rozmanitých informačních celků. Na jejich tvorbě se podílí velké množství uživatelů, aniž by jim někdo nebo něco předurčovalo, jakým způsobem to mají dělat. Tímto způsobem vznikla a dále roste například nám dobře známá Wikipedia. Ohromujících výsledků zde bylo dosaženo bez jakéhokoliv centrálního plánování a organizace. Nutno říci, že nejde jen o tvorbu obsahu, ale i jeho ohodnocení. Mnoho typů sociálního softwaru podporuje tvorbu kontextových informací ve formě tagů, linků nebo bookmarků. Rozlišujeme tři základní typy kontextových informací – anotace, důvěryhodnost a sociální vazby. Anotace neboli poznámky pomohou čtenáři porozumět, najít nebo vyhodnotit obsah dané informace. Důvěryhodnost vyjadřuje, do jaké míry ostatní uživatelé mohou věřit prezentovaným informacím. Sociální vazby poskytují informace o propojení mezi lidskými bytostmi a vytvářejí sociální sítě.
V praxi jsou tyto vlastnosti sociálního softwaru využívány zejména pro podporu konceptů, jako je Enterprise 2.0 ve snaze podpořit spolupráci zaměstnanců, partnerů, dodavatelů a zákazníků. Ti jsou díky tomu zapojeni do nově vzniklých sítí lidí. Tyto lidi spojuje jediná potřeba – přístup k podobným informacím. Principem úspěchu sociálního softwaru je tedy přístup odspodu, kdy na sebe vzájemně působí jednotliví přispěvatelé a je využívána jejich „kolektivní inteligence“. Uživatelé se přitom nemusí vůbec znát a nemusí být organizováni v žádné hierarchii. Z pohledu kompetencí a odpovědností jednotlivých členů organizace se v sociálním softwaru využívá jednoduchý rovnostářský přístup. Rozhodnutí nejsou v rukou menšinové elity. Jsou řízena na základě vstupů od několika uživatelů, a vzniká tak obsah, který je dále průběžně získáván a shromažďován a stává se okamžitě viditelným na internetu. Následně je průběžně posuzován velkým množstvím uživatelů, kdy každý může opravovat případné nedostatky v obsahu, aniž by byl vázán nějakou formalizovanou procedurou schvalování změn. Důvěra a dobrá pověst hrají v tomto ohledu klíčovou roli. Na základě reputace a hierarchických struktur mohou být definovány role řízené obsahem namísto organizačních hierarchií definovaných top managementem organizace. Říkáte si, že jde o přesný opak BPM systémů? A není to náhodou přesně to, co nástrojům na řízení workflow chybí?

Úskalí tradičního pojetí BPM systémů

Systémy BPM jsou implementovány, aby podporovali efektivitu pracovních činností v přesně popsaných procesech za účelem naplnění specifických cílů v opakujících se pracovních situacích. Je to dáno už samotnou podstatou BPM, která je založena na velmi specifických předpokladech. Procesy jsou jednou navrženy, implementovány v BPM a uživatelé podle nich pracují. V drtivé většině případů jde o rutinní a neustále se opakující pracovní procedury, které mohou být standardizovány pro celou organizaci. Vhodným příkladem je práce na výrobní lince. Pracovníci jsou rozmístěni podle předem daného plánu na konkrétní pozice, aby každý z nich splnil svoji specifickou pracovní činnost na určitém produktu. Jakmile jeden svou práci dokončí, předá produkt dalšímu, ideálně bez nutnosti komunikace nebo jakéhokoliv jiného „zbytečného zdržování“. BPM je v tomto případě výrobní linka a jejím hlavním účelem je dopravovat surový produkt mezi jednotlivými stroji a lidmi, koordinovat tak jejich práci a přivést produkt do finální podoby. Zde BPM přesvědčivě plní svoji roli.

Kde však BPM pokulhává, jsou ty pracovní situace, když jednotlivé pracovní úkoly nejsou přesně strukturovány a je vyžadována vysoká míra individuálních zkušeností k jejich splnění. Příkladem může být jakákoliv zakázková výroba nebo úprava produktu. Pracovníci upravují produkt přesně podle požadavků zákazníka tak, aby naplnili jeho očekávání. Samozřejmě mezi jednotlivými úkoly existují vazby a úkoly jsou přidělovány podle určitých pravidel, ale nic z toho není tak striktní jako při práci na výrobní lince. Často je od pracovníků vyžadována vlastní iniciativa, vzájemná komunikace a kreativní přístup k dosažení ideálního výsledku. Klasické BPM většinou nejsou dobře navrženy pro tyto druhy aktivit, protože mají celou řadu nedostatků:

• Nedostatek kontextových informací. Workflow systém se zaměřuje hlavně na vazby mezi jednotlivými aktivitami v rámci jednoho běhu procesu. Kontextové informace, které se týkají procesu a jeho běhu jako celku jsou přitom někde na pozadí a jsou spolupracovníkům procesu přístupné buď obtížně, nebo vůbec.
• Neflexibilní dekompozice jednotlivých pracovních aktivit. Aby bylo možné řídit distribuci práce v rámci procesu, workflow systém dekomponuje práci na jednotlivé úkoly, které jsou potom systémem považovány za atomické. Bohužel často nejsou atomické pro uživatele, kteří musí práci v rámci takového úkolu rozdělit na mnohem menší úkoly a v některých případech i dále distribuovat.
• Žádné rozdělení mezi distribucí práce a autorizací. Workflow systémy používají stejná pravidla, jak pro rozdělování pracovních úkolů, tak pro rozdělení oprávnění na daných úkolech pracovat. V důsledku toho není uživateli umožněno vykonávat jiné úkoly než ty, které mu byly explicitně přiděleny. Tato funkčnost je ale často nedostačující, protože nadřízení mnohdy potřebují nakládat s úkoly původně distribuovanými na jejich podřízené.
• Nátlakový přístup. Díky přiřazování úkolů zaměstnanci přesně vědí, co mají dělat, ale systém jim už neříká, co by „mohli“ udělat v dané pracovní situaci.

Pokud se budeme chtít výše zmiňovaným problémům vyhnout, nebo je přinejmenším alespoň omezit, je zřejmé, že BPM musí být vhodně doplněno nebo rozšířeno dalším typem softwarových systémů. Jedním ze slibných řešení se jeví kombinace BPM právě se sociálním typem softwaru. Důkazem takovéhoto vhodného využití v pracovních procesech je například vývoj open source softwarových projektů, i přesto, že pro většinu jiných pracovních aktivit orientovaných na splnění konkrétního cíle jsou možnosti sociálního softwaru značně omezené. Právě odlišné způsoby práce s technologiemi BPM a sociálního softwaru jsou velkou výzvou a nelehkým úkolem jejich integrace.

Informační zdroj:
Erol, S., Granitzer, M., Happ, S. et al. 2010. Combining BPM and social software: contradiction or chance? Journal of Software Maintenance and Evolution: Research and Practice 22 (6-7): 449–476.

Jan Dancinger
Autor působí jako produktový manažer ve společnosti AspectWorks.