Josef Basl Text článku vznikl za podpory projektu GA CR 201/08/0663. Odkazy
Raději od začátku - co je to BPM?
Business Process Management (BPM) jako vědecká i manažerská interdisciplína a zároveň i technologie trpí chybějící obecně přijímanou ontologií. Její vymezení se pohybuje od pohledu na BPM jako na systém správy komplexních interakcí mezi podnikovými entitami [1], přes její pojímání jako formy řízení či manažerské filosofie [2] a vnímání BPM jako inženýrského nástroje managementu [3], formy firemní kultury [4] až po označení BPM jako řízení cyklu podnikání prostřednictvím jeho procesů. [5]
Do teoretických pohledů na systémy řízení podniků navíc vstupují zájmy komerční, neboť BPM je a ještě bude veliký byznys. V letošním roce dosáhne pouhý prodej nástrojů, kterého ho podporují, objemu 2 mld. USD a poroste ročně 40% tempem, [6] přitom služby s BPM přímo spojené činí odhadem sedminásobek prodeje produktů. Ve vnímání klíčových hráčů trhu je BPM buď technologie, která umožní lépe využít technologii (k automatizaci), pak jen opatrně připouštějí nutnost zahrnutí lidské dimenze řízení. Nebo je informatickým nástrojem informační společnosti a management znalostí je redukován na kvalitativní zpracování informací. Čest výjimkám, které podnikový svět netechnokratizují (např. IBM [7] ).
V češtině je akronymu BPM sémanticky nejbližší slovní spojení procesní (systém) řízení (podniku a jeho podnikání). Použité závorky naznačují, že překlad či použití termínu musí vždy vycházet z jeho kontextu v textu. A protože pojem procesní řízení má v naší zemi už patnáctiletou tradici, je dobré se ho přidržet, i když se dnes na něj nabaluje související vrstva nástrojů (BPM Suite) a ta je technologicky i základním prostředkem systémové, aplikační a potažmo i procesní integrace.
Jedno však mají všechny úhly pohledů na BPM společné – vždy je jejich základem strukturované uchopení řízení firmy a jejího podnikání, opření tohoto řízení o model těchto struktur a jeho účinná podpora informačními systémy. [8] A o tom je téma tohoto měsíce.
Vymezení tématu Architektura podnikání
Přímo s pojmem architektura podnikání (Enterprise Business Architecture) přišel v roce 2005 Ralph Whittle [9], když se pokoušel sladit odlišný pohled na struktury podniku z hlediska logiky jeho řízení (Business Architecture) a jeho informačních struktur (Enterprise Architecture). Dodnes se však používá i obou dílčích pojmů se značným významovým překrytím až zaměnitelně. [10] Přesnější vymezení pojmu včetně specifikace nezbytných standardů se očekává od OMG, která na sklonku loňského roku založila pro tento účel zvláštní pracovní skupinu. [11] Tématu se trvale věnuje i BPM Institute. [12] Ten definuje architekturu podnikání takto: „A formal blueprint of governance structures, business semantics and value streams across the extended enterprise".
I český překlad tohoto pojmu má opět potíže, protože podnikání (Business) jako důvod existence jakéhokoliv podnikatelského subjektu je některými IT odborníky překládáno chybně jako obchod (a tak najdeme ještě dost často slovní spojení obchodní procesy ve významu všech procesů firmy), naštěstí dnes už v odborných IT textech většinou zůstává jen počeštěno (byznys). A termín Enterprise není vnímán jako organizační vymezení podnikatelského subjektu nebo entity (podnik, firma, organizace), ale je zužován na soubor informačních systémů a technologií podniku (pro vymezení firmy je pak používáno adjektivum Corporate). Pokud se chceme vyhnout výše uvedeným významovým zúžením a posunům, můžeme pojem Architektura podnikání definovat takto:
Business model
Velmi zjednodušeně můžeme říci, že architektura podnikání je to, co dnes v podniku z hlediska jeho struktur umíme popsat modelem a inženýrsky řídit[13]. Práce s modelem reality je v samém jádru celého BPM a čím lépe dokážeme model podnikání realizovat prostředky IS, tím důležitější bude jeho úloha. S transformací monolitických uzavřených aplikací vzájemně propojených šílenou sítí přímých vazeb do dílčích služeb s vysokoúrovňovým rozhraním (SOA) propojených jedinou sběrnicí (ESB) se otevírá zcela jiná možnost promítnout model podnikání do chování informačních systémů. Model se stává vykonavatelným. Včetně zpětné vazby, tedy možnosti analyzovat v modelu skutečná data, dokonce v reálném čase. Vzniká tak nové prostředí reálné simulace reality[14], možnosti ovlivňovat chování systému v reálném čase na základě reálných výsledků.
Záměrně hovořím o podnikání obecně, ne pouze o procesech, které vytváří jeho hodnotu. Ty jsou samozřejmě základem takovýchto systémů a mají proto v architektuře podnikání čestné místo. Pozor – modely procesů, tedy průběhu tvorby přidané hodnoty, ne souhrny aktivit podle odborností a už vůbec ne podle organizačních útvarů. Tato samozřejmost vůbec samozřejmá není. Je totiž znovu a znovu provázena velkým neporozuměním jak u manažerů, kteří vidí svůj podnik jedině organizační optikou, přes kterou řídí lidi, tak u informatiků, zvláště těch, kteří si v posledních letech konečně osvojili objektové vidění světa[15].
Průběhy procesů jsou ovšem jen málokdy striktně sekvenční, většinou obsahují řadu větvení a tedy i bodů rozhodování. Jednoduchá rozhodování lze automatizovat podle pravidel. Ale i pro ta složitější, svěřená výhradně lidem, je vhodné pravidla formalizovat. [16] Dobrými pravidly se výrazně zjednoduší nutný procesní popis[17], jasně se deklarují odpovědnosti[18]. Dokumentaci rozhodování včetně jeho podkladů lze analyzovat, poučit se z ní, ba dokonce nalézt závislosti nové, nepredikované. Systémy Business Intelligence (BI) toho využívají a stroje pro řízení pravidel se stávají součástí BPM platforem, protože rozhodování má smysl jedině v kontextu, tedy v procesech[19].
Čím méně je možné předem předepsat, jaký má průběh procesu přesně být, tím více je proces znalostně (ne jen informačně) náročný. Vstupy do aktivit procesu, které se transformují na přidanou hodnotu, už pak nejsou materiální, dokonce už nemusí stačit ani znalosti jedince a vlastní transformace musí probíhat formou sdílení, sociálně. [20] I tento rozměr musí umět architektura podnikání zachytit, aby mohla management znalostí účinně podpořit.
Organizační uspořádání podniku je základem a formalizací jeho řízení. Nakolik se odchyluje kanonizovaná organizační struktura a její řídící vazby od skutečného mocenského uspořádání podniku, natolik vzniká ve firmě řídící schizofrenie a roste nejistota pracovníků. [21] Proto je jedním z cílů BPM vyloučit nebo alespoň omezit tuto ditochomii a proto…
Firmy podnikají kvůli přidané hodnotě, veřejně prospěšné organizace státní nevyjímaje, jen u firem je snáze vyčíslitelná finančně. Jenže potřeba a forma této hodnoty se dynamicky mění a čím dál tím rychleji. Schopnost zacílit úsilí podniku a měnit jeho struktury tak, aby prosperoval i v budoucnosti a přitom dosahoval potřebnou dnešní výkonnost tvoří strategický rozměr BPM. [22]
Velká část procesů ve firmě je dnes alespoň částečně podpořena informačními systémy, v některých oborech (třeba ve finančních službách nebo u mobilních operátorů) jsou to dokonce velmi významné části. BPM ve spojení se SOA aspiruje na to, aby přemostil propast, která se rozevřela mezi byznysem a jeho informatickou podporou tím, že ze strany jedné udělá potřeby podnikání srozumitelné IT, čili je strukturovaně popíše, ze strany druhé vytvoří tak flexibilní strukturu komponent, že bude možné na běžné změny reagovat jen jejich parametrizací, přenastavením či alespoň částečným znovupoužitím. A že služby na sebe budou navazovat v byznysem definovaném hodnotovém řetězci, že budou procesně integrované a bude tak možné měřit i dosahované procesní parametry (KPI’s). Proto dnes tolik dříve dílčích řešení se postupně integruje, proto probíhá v oblasti podpůrných manažerských nástrojů tak silná integrace trhu. Cílová BPM platforma (BPMS) má totiž sdružit nástroje řídící průběhy procesů (workflow) i prostředky kolaborace, znalostní systémy včetně business intelligence a ECM (Enterprise content management), celou škálu dnešních analytických i budoucích monitorovacích nástrojů typu BAM (Business activity monitoring) a poskytnout manažerská rozhraní či tabla (MIS) včetně podpory benchmarkingu na přehledové i podrobné úrovni. [23] Na straně druhé bude tato platforma schopná snadno integrovat nové služby včetně externích nejen webových služeb a řešení poskytovaných formou SaaS (software as a service). A bude kontinuálně podporovat cyklus vývoje funkcionality služeb nových bez ztráty zpětné vazby k požadované byznys funkcionalitě.
K uvedeným požadavkům je třeba dodat, že všechny zmíněné objekty a součásti podnikové reality musí business model zachycovat ve vzájemných souvislostech.
Co k řízení architektury podnikání potřebujeme
Architektura podnikání se od architektury klasické, která má poměrně statický charakter, přece jen liší. Musí totiž zvládat i dynamiku času – řízení své vlastní změny. To je úkol nejtěžší. Pak teprve můžeme mluvit o holistickém řízení.[24]
Výše naznačená složitost podnikových struktur, které potřebujeme uchopit a řídit, dává tušit, že business model není možné od určité velikosti podnikatelské jednotky udržet v souvislostech v hlavě manažera a budovat tak mrakodrap podle ústních pokynů stavitele. [25] Pokud připočteme jejich proměnlivost, nelze je účinně zachycovat ani technikou tužka – papír, zejména pokud chceme změny přímo promítnout do nastavení IS. K řízení architektury podnikání potřebujeme proto ještě dvě věci – sémantiku kódování či zachycování těchto objektů a jejich vztahů, čili notaci pro business model. A pak potřebujeme samozřejmě také nějaký nástroj či prostředí, které nám to umožní, a vhodné postupy.
Obrázek 1: Věcný obsah architektury podnikání
Standardní notace? Ještě dlouho ne!
Pokud člověk sleduje jen radostné vyhlídky BPM v ekonomických magazínech, snadno podlehne dojmu, že BPM má první podmínku, totiž mít k dispozici metodu, dávno vyřešenu. Opak je pravdou. Přestože pro řízení architektury podnikání se vyvíjí frameworky už dobrých dvacet let, ani jeden z nich se nestal průmyslovým standardem. Většinou proto, že byly příliš složité na široké uplatnění nebo si je výrobce tak dlouho držel jako svou konkurenční výhodu pod pokličkou, až si ostatní našli cestu vlastní.
BPMN jako dnešní standard vznikl v roce 2005 naopak z minimální nezbytné množiny objektů a vazeb, které jsou zapotřebí k popisu procesů. A proto slavil okamžitý komerční úspěch. Dnes se k němu hlásí všichni velcí BPMS hráči, i když někteří značně neradi. V BPMN totiž popíše pouze procesy, a to ještě bídně a ne zcela jednoznačně. Takže si stejně každý dodavatel doplňuje tuto notaci o vlastní objekty a jejich atributy, zejména ty, které vážou na jeho specificky doplněný BPEL. Bohužel BPMN dodnes nemá oficiální XML schéma, podmínku to portability sine qua non, takže celý standard jazyka pro business modelování se najednou stává pouhým pidgin-process.
Pokud pro správu architektury podnikání využijete pokročilých frameworků, které vše výše řečené umí, vystavujete se nebezpečí věčného uzavření do svého nástroje. A to by integrující platforma v samém srdci podnikání i IT být neměla.
[1] Howard Smith, Peter Fingar; Business Process Management: The Third Wave; 2003; ISBN 0929652339; kniha
[2] Roger Burlton; Search Of BPM Excellence: Straight From The Thought Leaders, chapter III; 2005; ISBN 0929652401; kniha
[3] Paul Harmon; Business Process Change – 2. vydání; 2007; ISBN 0123741521; kniha
[4] Andrew Spanyi; Business Process Management is a Team Sport; 2003; ISBN 0929652029; kniha
[5] August-Wilhelm Scheer; ARIS - Business Process framework; 2000; ISBN 3540658343; kniha
[6] Ken Vollmer, Colin Teubner; Forrester Research: BPMS Market; 2007; excerpt
[7] Douglas W. McDavid; Standard for business architecture description; IBM Journal of Research and Development, Volume 38, Number 1; 1999; článek
[8] Josef Basl, Roman Blažíček; Podnikové informační systémy – 2. vydání; 2007; ISBN 8024722795; kniha
[9] Ralph Whittle, Conrad B. Myrick; Enterprise Business Architecture: The Formal Link between Strategy and Results; 2006; ISBN 0849327881; kniha, doplňující informace.
[10] Wikipedia, srov. heslo Business architecture a heslo Enterprise Architecture, úplné heslo Enterprise Business Architecture Wikipedia neobsahuje. Wikipedia v této oblasti není spolehlivý zdroj, řada hesel je zpracována profesionály z řad velkých dodavatelů hlavně IT.
[11] OMG Business Architecture Working Group (BAWG); stránka pracovní skupiny
[12] Business Architecture Section of BPMInstitute.org, domovská stránka sekce
[13] Jeanne W. Ross, Peter Weill, David Robertson; Enterprise Architecture As Strategy: Creating a Foundation for Business Execution; 2006; ISBN 1591398398; kniha
[14] Sebastien Stadil; Process Simulation versus Real Run Technology; 2007; blog
[15] Martin van den Berg, Marlies van Steenbergen; Building an Enterprise Architecture Practice; 2006; ISBN 1402056052, kniha
[16] Markus Schacher; Moving from Zachman Row 2 to Zachman Row 3: Business Rules from an SBVR and an xUML Perspective; 2006; whitepaper
[17] Barbara Von Halle, Larry Goldberg; Business Rule Revolution: Running Business the Right Way; 2007; ISBN 1600050131; kniha
[18] BPM portál; Vymahatelnost pravidel - součást tématu 01/2007; 2007; ISSN 1802-5675; článek
[19] Tom Debevoise; Business Process Management with a Business Rules Approach: Implementing The Service Oriented Architecture; 2007; ISBN 1419673688; kniha
[20] Tojo Joseph Thatchenkery, Dilpreet Chowdhry; Appreciative Inquiry and Knowledge Management: A Social Constructionist Perspective; 2007; ISBN 1845425901; kniha
[21] John Schermerhorn, James G. Hunt, Richard N. Sborn; Core Concepts of Organizational Behavior; 2003; ISBN 0471391824; kniha
[22] David Parmenter; Key Performance Indicators: Developing, Implementing,and Using Winning KPIs; 2007; ISBN 0470095881; kniha
[23] Aberdeen Group; BPM Convergence; 11/07; studie
[24] Marc Lankhorst; Enterprise Architecture at Work: Modelling, Communication and Analysis; 2005; ISBN 3540243712; kniha
[25] James F. Chang; Business Process Management Systems: Strategy and Implementation; 2005; ISBN 0849323102; kniha
Klíčová slova (anglicky): Business Process Management; BPM; BPM Suite; Enterprise Architecture; Business Architecture; Business Modeling; Knowledge Management; SOA; ESB; Business Intelligence; Business Framework; BPMN; Enterprise Governance.
Shrnutí: Business Process Management (BPM) je manažerská disciplína i technologie opřená o uchopení struktur firmy – její architektury - a její řízení prostřednictvím business modelu. Ten musí zachytit základní rozměry podnikání – jeho cíle, hodnototvorné procesy, jejich organizační, znalostní i IT zajištění ve všech jejich vazbách a dynamice změn. pro tento business model není dnes k mání notace, která by byla jak dostatečná, tak obecně přijímaná.
Standardní citace tohoto příspěvku: Josef Basl; Architektura podnikání; BPM portál – téma měsíce, 1/2008; ISSN 1802-5675; URL: http://bpm-tema.blogspot.com/2008/01/architektura-podnikani.html
Příspěvky
32 Comments:
Nikdy mě nenapadlo, že BPM je vlastně striktně vymezeno tím, že používá inženýrský základ - MODELOVÁNÍ. To je výborný postřeh!
Je škoda, že se standardem nestal hodně propracovaný framework ARIS, asi bychom už byli o kus dál.
Problémem ARISU byly po mém soudu dvě věci - jednak byl německý a nikoliv americký, jednak byl příliš spojen s nástrojem a to drahým. Možná tam byl ještě třetí problém - byl na svou dobu příliš dokonalý. Možná kdyby býval včas (tak před 5 lety) vznikl nějaký LEAN aris, mohlo to být jinak.
Máte asi pravdu, protože jak tu píše prof. Basl ten dnešní primitivní BPMN je opravdu jen společným průnikem komerčních zájmu a proto minimalistický, což je i jeho zásadní výhoda. Bohužel tím se stává tak obecným, že se špatně lidem z praxe vysvětluje.
Jsem hodně překvapen, jaký důraz kladete na modely a že mají zahrnovat nejen procesy, ale i organizaci, cíle a další. Bral jsem zatím otázku diagramů jako spíše okrajovou a pomocnou a za leitmotiv procesního řízení jsem bral změnu řídícího přístupu. To je opravdu hodně velká změna a pokusím se jí vstřebat.
Pane profesore, netroufnete si taky na definici pojmu BPM či procesní řízení, když už je to tak nakousnuto. Ode mě ji ve škole chtějí!
Skoro bych řekl, že definice BPM je daná uvedeným obrázkem.
Pomóóc - ode mě ale ve škole chtějí definici slovní...
Tak se naučte zpaměti 3 úvodní odstavce:) Nebo jim řekněte tohle: BPM = Manažerská disciplína opřená o zásady procesního řízení a byznys model.
Definici BPM máte napsanou ve shrnutí. Musíte, Jiřino, číst až do konce!
Pánové, díky (za aroganci, aspoň nezapomenu, že jsem žena).
Já ale taky - a četla jsem až do konce!
Je pěkné vědět, co všechno má v byznys modelu správně být, ale běžný modeler umí jen ty procesy a částečně organizaci. Co s tím ostatním? Zatím to držíme přes hyperlinky.
Kupte si aris. Ten umí všechno.
ARIS není zadarmo. Oni ani ty nástroje zadarmo nejsou tak úplně zadarmo, protože přinejmenším se je musíte naučit ovládat a to něco stojí. Procesy a jejich průnikem organizačními strukturami je třeba začít vždycky.
Tohle nemá chybu!! Škoda, že nepíšete ještě víc o vztahu k SOA, ale věřím, že v dalších tématech měsíce se ještě dočkám.
Myslíte si, že definice BPM uvedená ve shrnutí, je úplná?
Měl jsem obrovský zmatek v tom, co je enterprise architecture a business architecture. Jestli jsem to správně pochopil, enterprise architecture je podmnožinou business architecture, která zachycuje pouze struktury IS/IT.
Zmatky v pojmech ohledně EA byly opravdu obrovské. Z pohledu IT je EA opravdu jen uspořádanou množinou funkcionality a z hlediska byznysu byl tento pojem rozmazaný. Velmi dobré definice.
pro Kolert: EA je vnímána jako celistvá (ucelená) architektura podniku. Pokud je dobře provedena, tak v sobě obsahuje i BA ve všech aspektech z článku pana profesora. EA je nejšiřší formou popisu organizace, často je přirovnávána k územnímu plánu města. Rozhodně nelze zaměňovat architekturu IT a EA.
Mojí oblíbenou definicí EA je Gartner:
„EA je proces popisu a výsledek popisu toho, jak očekávaný budoucí stav business procesů, technologií a informací organizace, nejlépe podpoří její business strategii. EA je definice potřebných kroků, standardů a návodů, jak se dostat ze současného stavu k očekávanému cílovému stavu.
ad Pavel: Tak a mám v tom zase zmatek. EA, jak píšete - je vlastně totožná s BA - přesněji s jejím TO-BE stavem. OK?
pro Kolert: Pro mne je BA nedílnou součástí EA, společně s architekturou IS (členěnou na aplikační a datovou) a s architekturou technologické infrastruktury. Z uznávaných metodik jsou mi nejbliší TOGAF, IAF, FEAF a LEA.
Tvorba kterékoli z architektur je vždy snahou o nalezení cesty k naplnění rozdílů mezi výchozím a cílovým stavem.
Všechny složky EA, včetně BA, tedy mají vždy As-Is i To-Be, jinak to nedává smysl.
Téma je mi velice blízké, rád bych o něm hodiny diskutoval, ale zdá se mi, že přesahuje možnosti tohoto blogu, kam jsem se dostal dost pozdě a víceméně náhodou.
ad Pavel: Bohužel nejsem tak vzdělán v oblasti frameworků, znám víc je Zachmanův a pracovně jsem byl nucen používat DoDAF, což je příšerně složitá úprava Zachmana pro US armádu resp. celou státní správu. Ale ty nesplňují požadavek na úplnou BA - mají sice modely aktivit, stavů, pravidel, organizace - ale chybí jím to nejdůležitější. Modely procesů - nikoliv souborů aktivit, ale toků přidané hodnoty.
Většina EA konceptů je postavena právě na informatickém pohledu a dimenze, které jsou zapotřebí k řízení podnikání, opomíjí. Teď volně cituji Scheera, ale nemůžu to najít.
Myslím, že speciálně TOGAF má přímo procesní-byznys vrstvu a to úplně nahoře. Teprv pod ní je aplikační architektura a datová a technologická. DODAF neznám.
K Pavlovi: Myslím, že by víc lidí tady zajímalo, jak vypadají jednotlivé frameworky EA a který je vhodný k čemu použít. Určitě by i redakce nějaký článeček na tohle téma vzala!? Já osobně se přimlouvám.
Redakce říká URČITĚ - pokud je Pavel (Jindřich / Kolert) schopen něco pěkného a čtivého dodat.
P.S. Jen každý příspěvek musí projít redakční radou (oponenturou).
Taky se za něco takového přimlouvám. Líbí se mi komentáře Pavla - jestli by byl ochoten?
Děkuji za důvěru. Jsem poprvé v životě v diskusním fóru a hned po mě chcete článek. Domluvím se s Adminem a během jara zkusím něco připravit.
Nyní přiznávám, že jsem Enterprise Architect přicházející z oblasti informatiky. Současně jsem také "proceso-skeptik", něco jako Euro-skeptik". Zažil už jsem spousty situací, kde nepovedené procesní modelování bylo naobtíž zdravému rozumu a manažerskému rozhodování. Jinak jsem ale raději, pokud podnik procesní model má a věří mu.
Při návrhu EA je mi jedno, jestli je fungování podniku zachyceno pomocí funkcí, business služeb (mají SLA) nebo procesů, obecně pracuji nejraději s pojmem Capability. Potřebuji ale, aby byly sladěny s dalšími entitami metamodelu EA jako jsou org. jednotky, lokality, aktéři, role a zejména motivační část BA, tedy externí drivery, strategické cíle, konkrétní úkoly a jejich metriky.
K tomuhle všemu, pokud je to k dispozici, již je "hračka" navrhnout smysluplnou aplikační, datovou a technologickou architekturu.
Na rozdíl od Vás ostatních tedy nezbytně k životu potřebuji Business Architekturu, ale nepotřebuji procesy.
Úplně lapidárně řečeno potřebuji, aby moji klienti věděli, co chtějí v businesu a já jim mohu pomoci se tam dostat.
Formálněji řečeno architektuře musí předcházet strategie(zejména ta podnikatelská, ale také informační a strategie informačních systémů, bezpečnostní a další). Ale o tom všem jsou předchozí články na tomto webu.
Ve Vašem příspěvku, Pavle, je možná jádro dnešní neveselé situace v řadě podniků. Chápu, že za sebou můžete mít řadu neveselých zkušeností s "procesními" modely o ničem. Přesto si trvám na tom, že procesy - toky vytváření hodnoty v podniku - musí být jádrem modelu, protože jinak nemáte osotatní entity k čemu smysluplně připojovat. Se vším ostatním souhlasím.
Tahle debata bude o ničem - akorát flamware modelovat procesy ano / ne.
Bojím bojím, Petro, že mírně vzrušené debatě již zabránit nelze - "slovo meče již vyřčeno bylo."
Capability a procesy jsou od sebe na míle vzdáleny. Rozumím tomu, že služnou IS architekturu lze navrhnout i na základě business services. Přesto v takové architektuře chybí jádro - orchestrace těchto služeb do value chainu, protože teprve na něj lze připojit většinu cílů, jinak plavou ve vzduchu.
Také jsem původní procesní skeptik, jenže prozřelý praxí tříletého zavádění SOA/komponent a dnes velký stoupenec middleware, který obsahuje process engine. BPEL ale nenapíšete, pokud nad tím nemáte nějaký high level business model, o kterém se můžete s uživateli bavit.
Sdílím Pavlův skpeticismus ohledně procesních modelů - už jsem jich také pár viděla, které byly zralé leda do koše. A těším se na slíbený článek o EA. Pozor - u nás už jaro začalo, sněženky kvetou...
Post a Comment