Názory k článku Řízení podnikových procesů pomocí open source

Obávám se, že člověk, který dokáže napsat tohle:

Zpátky k podnikovým procesům. Jsou to modely, které mají více cílů, ale hlavním z nich je zvýšit efektivitu organizace, která je nasadí. Každá organizace používá nějaké procesy. Ať už v podobě nějaké směrnice nebo ústně dohodnutých postupů. Podnikové procesy se snaží tyto firemní postupy formalizovat a popsat je elektronicky v počítači.

nemá o tématu vůbec tušení...

Fajn, zkuste to napsat lepeji a radostneji, ale tak, aby to bylo srozumitelne i laikovi.

Me to pripada OK, byt je znat nemala davka zjednoduseni.

Pro nejmenovane hyperinteligenty: Podotykam, ze nejsem autor :-P

Pokud je to článek pro neznalce oboru, pak se domnívám, že důraz na korektnost je obzvláště důležitý... Podnikový proces není model (ani směrnice - což je ještě více mimo), podnikové procesy nevznikly (jak je dále možné se v článku dočíst). Toto není zjednodušení, ale buď lež, nebo nepochopení problematiky (podnikových) procesů autorem článku.

Jako čtenář-laik, bych uvítal opravu pojmů do správného významu. Jinak je váš komentář jen výkřik do tmy a plevel, který není nijak užitečný. Na rozdíl od článku.

Podnikový proces je (jedna z možných definic) po částech uspořádaná množina činností, které přeměňují vstupy na výstupy za užití zdrojů. Model je jen zjednodušený obraz reality - procesu - který zdůrazňuje v daném kontextu jeho důležité atributy, zatímco ostatní ignoruje. Existuje tedy mnoho modelů konkrétního procesu - v závislosti na kontextu a účelu, pro který je model tvořen. Směrnice (dejme tomu, ať použiji něco z textu článku) případně schéma procesu vytvořené např. pomocí BPMN není ani model - je to jen jeho textový popis resp. vizualizace.

Stejně tak není pravda, že by "procesy vznikly", jak autor píše. Už z definice je zřejmé, že nějaké činnosti vždy nějakým způsobem (v nějakém pořadí) v podnicích probíhali. Co je (zde je nutné říct relativně, protože koncept BPM je starý několik desítek let) nové je to, že jsou procesy do určité míry řízeny, v procesně řízených organizacích jsou pak v ústředí zájmu, neboť takové organizace si uvědomili, že to jediné, co ve firmě přidává hodnotu pro konečného zákazníka (ať vnitřního, nebo vnějšího) jsou právě podnikové procesy.

Tak to jen k těm dvěma věcem, které jsem konkrétně kritizoval. Pokud jsou další dotazy, rád odpovím.

Předpokládám, že p. Sviták má v RedHatu na starosti implementace těchto projektů pro korporátní zákazníky, tudíž předpokládám, že píše o tom, čím se přímo živí a za co mu je někdo ochoten pravidelně platit. Ale třeba předpokládám špatně.

Ano, problemem je, ze je to napsane srozumitelne (trebaze zjednodusene), tudiz naprosto neakceptovatelne pro mnohe procesni vyzirky :)

Osobne to chapu jakozto lehky uvod do cele problematiky.

Zmrdspeak jak vyšitej... Já věděl, proč to nemám číst...

Business Process Maping je velmi rozsáhlý pojem. Je to jako "kreslicí program". Máme GIMP a Inkscape. Oba jsou to kreslicí programy, ale vlastně každý dělá něco úplně jiného.

Podobně je to s BPMN2 a podobnými. Je to velice úzce zaměřený nástroj, který neumí skoro nic z oblastni mapování business procesů, ale tu malou specifickou věc umí výborně. Pokud potřebujete popsat obsluhu nějaké události, klidně velmi komplexní, tak tenhle nástroj je na to ideální. Na cokoliv jiného už drhne a jakmile se dostanete na úroveň podnikových procesů, tak je to jen zbytečné závaží.

Takovým testem vhodnosti mapovacího nástroje pro business process analýzu je následující množina otázek: máme sestavu BRQPRD003 (průvodka výrobní zakázky). Kdy vzniká? Jaké informace ke vzniku potřebuje? Kdo ji vytváří? Kdo a od koho dostává kopii? Jaké procesy vyžadují tuto sestavu na vstupu? Kde se fyzicky pohybuje? Kde a jak končí? Vznikají její kopie? Jaké informace na ní kdo ručně připisuje? Poměrně běžné otázky ve chvíli, kdy za vámi přijde vedoucí výroby s tím, že to má 7 stran a oni strany 5, 6 a 7 nepotřebují vůbec, a na straně jedna je nezajímají údaje o produktu a z kusovníku je zajímají jen vychystávané položky a ne kanbanové nebo spotřebák. S dobrým nástrojem během pár desítek minut máte většinu odpovědí a u zbytku víte koho se doptat. Pak se vyvarujete nepřijemného zjištění, že kopii dostává sklad a zásobuje podle toho kanbany. Nebo to alespoň zjistíte dříve, než až se zastaví výroba s tím, že mají v kanbanu na lince krabice na jiný produkt, než který dnes jedou.

Uvádím to jen proto, že jsem se už několikrát střetl s lidmi z IT, kteří žili v domění, že BPMN je nějaký univerzální nástroj. Není. Minimálně nakonec přiznali, že na výše uvedené otázky neodpoví v dostatečném rozsahu, protože na to není dělaný. Respektive že by to tam i napsat šlo, ale bylo by to dost nepřehledné a ještě by to muselo místy porušovat notaci. Zkrátka podnikové procesy s tímhle neuřídíte.

Konečně tuším, o čem byla řeč.

Trochu si rýpnu.

A že např. to Baťa, Ford, Rockfeller vůbec nepotřebovaly, že? A to se jim to podnikalo....

Je to o lidech. Pokud máš na správných pozicích lidi, které sis sám vychoval (Baťa) tak oni nepotřebují přesnou definici toho, co a jak se má dělat (krok po kroku), ale víceméně intuitivně směřují k cíli a případně improvizují. Rozhodně o tom přemýšlí a případně diskutují.

Pokud jsi v nadnárodní firmě a potřebuješ brát lidi jen jako součástky velkého stroje, kdy každá hraje přesně specifikovanou roli a můžeš ji kdykoliv vyměnit, a kdy použití mozku = tragédie, tak potom se vydáš cestou přesné specifikace toho, co mají dělat. V tomto systému může přemýšlet jen "hlavní architekt" a všichni ostatní musí jeho myšlenky vykonávat.

Taylor byl průkopník normování. Dokonce byl prý neprávem osočován, že chce z lidí sedřít kůži :-)

Spis velmi naivni predstava mnoha managoru ... ze to takto muze fungovat. Neexistuje totiz firma (ani jedna) kde by byl zamestnan alespon jeden jediny clovek, ktery by dokazal popsat do detailu veskerou svoji cinnost. On ji casto nedokaze popsat ani zhruba ... a presto ji dokaze bez problemu vykonavat.

Velmi casto se trebas setkavam s tim, ze vidim ze dotycny neco dela, a kdyz se ho na to nasledne zeptam, tak mi klidne rekne, ze nic takoveho ale nedela.

Klidne muzu zcela konkretne ... zadani zhruba ve smyslu "zaklaznik zaplati u kasy a jde si vyzvednou zbozi"

Realita: zakaznik si nekdy uz pri placeni nakup rozmysli, a bud castecne nebo kompletne nakup zrusi. Nekdy si nakup rozmysli cestou do skladu. Nekdy az po te, co dostane zbozi do ruky ... nekdy do toho skladu ovsem trebas vubec nedorazi ... a nevrati se ani ke kase (zajimave, ale je to tak ;D ), pripadne si nakup rozmysli nekde mezi cestou ze skladu a odjezdem ...

Firma propaguje pristup "naz zakaznik nas pan" => vsechny tyto varianty je treba nejak procesne osetrit, pricemz u 1/2 znich mi s klidem bude 80% zamestnancu kteri se toho primo ucastni tvrdit, ze se nic takoveho nikdy nestane. O jejich sefech ani nemluve, ti samozrejme nemaji ani potuchy (zato ale zamestnance servou, kdyz zakaznikovi nevyhovi).

A to se bavime o velmi trivialnim ukonu, ktery je jen naprosto nepatrnou soucasti toho, co se ve firme ve skutecnosti deje.

A ano, pokusy o "zprocesovani" jsem zaznamenal taktez - vysledek jsou stohy papiru popsane nekompletnimi a po par tydnech zcera zastaralymi informacemi.

Je třeba zohlednit mnohem více faktorů. Např. dobu, v které ty společnosti tímto způsobem fungovaly. Konkrétně třeba Ford na toto také doplatil poté, co do USA přišla Toyota.

Zrovna Ford a Baťa to používali. Viděl jsem také "manuál telefonisty" z PBS z dob první republiky.

Že to s počítači jde snáze ještě neznamená, že se to nedělalo i před nimi. Číselníky interních dokumentů, soupisky oběžných dokumentů, pracovní instrukce i matice zodpovědností tu byly už za první republiky. Včetně toho, že se nad tím prováděla primitivní síťová analýza.

A co tak Activiti, ktore vzniklo ako fork jBPM (niekde okolo verzie 3) a pokusalo sa odstranit nedokonalosti jBPM (samozrejme nie vsetky).

Bolo by dobre porovnat API jBPM vs. Activiti. S jBPM 6 som cakal, ze autori precistia kod, pretoze to co bolo vo verzii 5 bolo neuveritelne (paralerna vs. sekvencna exekucia procesu, vlastny !!! nezmyselny skriptovaci jazyk v business ruloch).

Treba sa zamerat na to, ze pri tvorbe procesu sa nevyhnete pouzitiu web modelera a eclipse pluginu (ten bol ale vo verzii 6 prepisany), pretoze "kazdy" vie nieco ine.

Porovnajte REST API jBPM vs. Activiti - skusenemu programatorovi uz len toto udrie do oci.

Tolik prazdnych frazi a floskuli pohromade jsem tu na Rootu uz dlouho nezazil.

Panu autorovi jen preju, aby se umyl, hezky oblekl a nasadil masku zovialniho vystupovani. Nic moc jineho mu IMHO nezbyva.

Jako o podnikových procesech něco málo vim (systém řízení kvality, organizační struktury atd.) Ale zběžně přečtený článek mi moc smysl nedával. Procesy se kreslej standartníma vývojákama. Kromě toho máme řadu nástrojů pro řízení kvality...

Je to tak, že BPMN nástroje slouží ke klikacímu vývoji ERP bez nutnosti použít programátory? A že naklikaný proces se považuje za implementovaný? Jde pomocí toho provádět simulaci systémů? Metriky přínosu tohoto přístupu?

Realne u toho stejne bude muset sedet nejakej programator, a stejne se zmena procesu bude implementovat mesice. Je uplne jedno jestli nekdo pise kod nebo klika nejaky silenosti. Navic u toho klikani driv nebo pozdejs narazi na omezeni - at uz funkcni nebo vykonostni.

Ostatne, "neco na ten zpusob" tu mam ... a pouzivat to pomalu neumi ani dodavatel. Proc? No protoze prave kvuli tem narazum do ruznych omezeni postupne dobastluje dalsi a dalsi uzasnou funcionalitu, az se v tom uz nikdo poradne nevyzna. Takze nakonec se to resi tak, ze pokud se neco potrebuje ... tak se to napise nekde vedle externe (script do SQL/kus .NET kodu/....) a jen se to zavola. Z pohledu spravy je to totiz radove predhlednejsi a jednodussi na upravy.

Je to sice hodně zjednodušená a od technických detailů odstíněná představa, ale v principu je to ta myšlenka, která frčí. Konkrétně BPMN má k tomu v rámci MDA celkem blízko.

Je to tak, že BPMN nástroje slouží ke klikacímu vývoji ERP bez nutnosti použít programátory? A že naklikaný proces se považuje za implementovaný? Jde pomocí toho provádět simulaci systémů? Metriky přínosu tohoto přístupu?

Toto je bezny mytus... v praxi sa bez programatora neobidete - vid. taka trivialita ako perzistovanie dat v procese (napr. perzistovanie schvalenych ziadosti o dovolenku). Vo velkych integracnych rieseniach to uz nie je len o kresleni procesov - tie su sucastou SCA komponentov.