Úkoly jsou často považovány za pomocný objekt obchodních procesů. Jde však o zcela nezávislý objekt obdařený mnoha vlastnostmi. Pokud jsou úkoly prováděny správně, mohou být účinným mechanismem plánování a řízení času. Tento článek je určen k ukázce příkladu propojení mezi úkoly a obchodními procesy, pro přidělování automaticky generovaných úkolů konkrétním vykonavatelům obchodních procesů.

Autor článku: GROOVY | Redakce: Wizard, Kind Nejnovější vydání č. 13 z 6. 4. 2006 | Příběh URL:

Klíčová slova: úkoly, oslovování, obchodní proces, akční bod, skupinové oslovování

Výchozí situace.

Jak bylo zmíněno v dříve popsaném článku (), vlastnosti adresování objektu „Task“ jsou velmi důležité. V tomto článku se pokusím na jednoduchém příkladu ukázat, jak lze pravidla adresování aplikovat v kontextu úloh vytvořených trasovacími body obchodních procesů.

Počáteční struktura metadat je:
Adresáře: Účinkující, Oddělení. Obojí bez dalšího nastavení, bez hierarchie a bez předdefinovaných prvků.

Výčet rolí se dvěma hodnotami: Manažer a Soukromý zaměstnanec.

Parametr relace "CurrentExecutor", typ: DirectoryLink.Executors.

Informační registr "Pravidla adresování" se třemi rozměry: Performer (vedoucí, zákaz prázdných hodnot, typ: DirectoryLink.Executors), Oddělení (nevedoucí, zákaz prázdných hodnot není nastaven, typ hodnoty: DirectoryLink.Departments) a Role (nevedoucí , nejsou nastaveny zákazy prázdných hodnot, typ hodnoty: EnumerationRef.Roles).

Úloha "BP Tasks" se třemi podrobnostmi adresování: Performer (hlavní detail adresování, typ: DirectoryLink.Executors), Department (typ hodnoty: DirectoryLink.Departments) a Role (typ hodnoty: EnumerationLink.Roles). Vlastnost "Addressing" specifikuje informační registr "Pravidla adresování", "Hlavní atribut adresování" - "Exekutor", "Aktuální exekutor" - odkaz, který není parametrem relace "Aktuální exekutor".

Nastavení mechanismu úloh je klasické. Záměrně nebyl vytvořen žádný další detail úkolu, protože nás zajímá fungování obchodních procesů ve spojení s úkoly.

Pár slov o vlastnostech podnikových procesů

Popis algoritmu obchodního procesu je mapa trasy. Body trasy na mapě obchodního procesu spadají do dvou hlavních kategorií:

1. Trasové body, které generují úkoly. Jak obchodní proces prochází těmito body, jsou vytvářeny úkoly a před jejich dokončením se obchodní proces zastaví.

2. Trasové body, které nevytvářejí úkoly. Když obchodní proces prochází těmito body, obvykle se provádějí určité kontroly a zpracování.
Ve vlastnostech bodů trasy, které vytvářejí úlohy, můžete přiřadit parametry adresování ve fázi konfigurace úloh. Ale zpravidla se nejedná o konkrétního interpreta, ale pouze o parametry nepřímého adresování.

Trasové body, které vytvářejí úkoly, mají obvykle schopnost popisovat události interakce s uživatelem. Body trasy, které nevytvářejí úkoly, takové události nemají (!).
Jednou z vlastností business procesu (BP) je propojení s objektem „Task“, ve kterém se vytvářejí úlohy pro body trasy tohoto BP.

K jednomu objektu „Task“ lze přiřadit několik BP.

Co je v praxi?

Vytvořme jednoduchý napájecí zdroj. No, například BP interního auditu společnosti.

Mapa cesty obchodního procesu bude obsahovat tři akční body. Toto jsou hlavní body mapy trasy obchodních procesů. Tyto body vytvářejí úkoly a mají interaktivní události.

Kromě akčních bodů musí každý obchodní proces zahrnovat alespoň jeden počáteční a koncový bod. Tyto body nevytvářejí úkoly, ale slouží pouze k popisu neinteraktivních událostí „Před zahájením“ a „Na konci“.

Nás ale nyní zajímají především akční body a úkoly, které vytvářejí.

Podívejme se podrobně na vlastnosti každého akčního bodu.

1. Spusťte audit. Kromě názvu pro akční bod můžete nakonfigurovat adresování (Addressing je skupina vlastností akčního bodu). Bohužel nebude možné uvést konkrétního dodavatele ve fázi vývoje obchodního procesu, protože se jedná o prvek referenční knihy - jeden a pro každý obchodní proces může zjevně existovat jiná osoba odpovědná za vedení audit - dva. V našem konkrétním případě nemá smysl přiřazovat vlastnosti nepřímého adresování, protože iniciátor tohoto obchodního procesu určí odpovědnou osobu (to bude další vlastnost obchodního procesu). Jak přiřadit vykonavatele úkolu generovanému akčním bodem? Docela jednoduché. Pomocí tohoto akčního bodu musíte zachytit událost vytvoření úkolu. To lze provést ve dvou obslužných rutinách události: „BeforeTaskCreation“ – tato obslužná rutina události se volá, když úkoly ještě nebyly vytvořeny, můžete vytvořit nový úkol a zcela vyplnit jeho vlastnosti; „When CreatingTasks“ – zde úkoly již byly vytvořeny a lze je upravovat.

V našem případě je lepší použít obslužnou rutinu události "When CreatingTasks", protože stačí zadat exekutor a není třeba měnit všechny ostatní vlastnosti úlohy.

Postup zahájení auditu při vytváření úkolů (bod trasy obchodního procesu, vytvořené úkoly, odmítnutí) Pro každý úkol Z vytvořených úkolů Cyklus Vykonavatel = Zodpovědný za provedení. //Zodpovědný za provádění – podrobnosti o BP. EndCycle; EndProcedure

Otázka: Proč cyklus? Není úkol vytvořen sám? Ale tohle nikdo neví. Akční bod může tvořit tolik úkolů, kolik chcete.

Mimochodem, pokud nastavíte vlastnost „Completed“ na hodnotu True v události „When CreatingTasks“, úkol bude dokončen, ale postup obchodního procesu se nepohne kupředu.

V zásadě jsme udělali vše, co souvisí s prvním akčním bodem. Nyní bude úloha generovaná tímto bodem přiřazena konkrétnímu vykonavateli uvedenému v detailech obchodního procesu.

2. Připravte dokumentaci pro podávání zpráv. Ve vlastnostech adresování tohoto akčního bodu nastavte hodnotu na „Role“ – Manažer. A vlajka "Skupina".

Co nám to dá? Podle pravidel adresování uvedených v registru informací budou vytvořeny úkoly pro každého vykonavatele, který je vedoucím zaměstnancem. Protože (možná) bude vytvořeno několik úkolů, bude bod trasy považován za dokončený pouze v případě, že budou dokončeny všechny úkoly.

V zásadě je příznak "Skupina" zodpovědný za vytváření více úloh podle vhodných pravidel adresování. Není-li příznak nastaven, bude vytvořen jeden úkol, který se však zobrazí všem účinkujícím v jejich seznamu úkolů (více o tom níže).

Standardní chování systému při vytváření úkolů lze každopádně zakázat a můžete si popsat vlastní pravidla pro vytváření a přidělování exekutora.

Pojďme se ale podívat, jak se chová standardní mechanismus.

Pro kontrolu budete muset inicializovat parametr relace. Samozřejmě by bylo hezké to udělat při spuštění systému, ale pro pohodlí při kontrole chování úkolů lze inicializaci provést ve formě seznamu v adresáři „Executors“. Vytvořil jsem formulář seznamu (beze změny nastavení, které návrhář formulářů standardně nabízí) a v panelu akcí formuláře jsem popsal nové tlačítko "InstallPS" (PS je parametr relace). Zde je postup, který je spojen s akcí tohoto tlačítka:

Procedure SetPS(Button) Executor = FormElements.DirectoryList.CurrentData.Link; SessionParameters.CurrentExecutor = Exekutor; Varování(" Parametr session je nastaven na exekutor" + Umělec,60); Koncový postup

Do adresáře "Executors" již v režimu 1C:Enterprise zadám několik uživatelů.

A vyplňte informační rejstřík „Pravidla adresování“ následovně:

Mám trochu moc vedoucích :)

Je čas vytvořit a spustit obchodní proces. Jako odpovědnou osobu označíme Petrova.

Doufám, že parametr session byl nastaven před spuštěním BP, jinak se objeví hláška, že nebyl inicializován. Je to proto, že při spuštění BP se vytvoří první úkol a systém náhodou zkontroluje, zda ho má splnit současný vykonavatel? Za tímto účelem systém analyzuje hodnotu parametru session, a pokud se vykonavatel shoduje a úloha má popsanou událost interaktivní aktivace (více o tom později), je provedena.

BP tedy začal, první úkol musel být vytvořen s vykonavatelem uvedeným v BP.

Dokončíme úkol. Podle pravidel adresování by měl druhý akční bod vytvořit tři úkoly:

To znamená, že bez ohledu na to, ve kterém oddělení se manažer nachází, je pro něj vytvořen úkol. Takto se pravidla adresování vztahují na úlohy s příznakem „Skupina“.

Mohu předpokládat, že u některých byl místo tří úkolů vytvořen jeden bez vykonavatele, pouze se zadanou rolí „Manager“. Důvodem je skutečnost, že ve vlastnostech úlohy „Úkoly BP“ adresní detaily neodpovídají dimenzi informačního registru „Pravidla adresování“.

Paradoxně si na konci tohoto článku rozebereme nejklasičtější vytvoření úlohy s určením vykonavatele na základě vlastností nepřímého adresování.

3. Zpracovat dokumenty. Na tomto bodu akce není nic neobvyklého. Ve vlastnostech adresování nemůžeme specifikovat charakteristiky adresování (vzhledem k tomu, že data nejsou dostupná v konfigurátoru). V detailech obchodního procesu vytvoříme dva nové detaily hodnoty, které budou sloužit jako hodnoty parametrů adresování při vytváření úlohy.

V naší konfiguraci není žádný formulář BP, takže uživatel bude mít nové podrobnosti automaticky.
Analogicky k prvnímu akčnímu bodu popíšeme vyplnění podrobností o adresování v události „When CreatingTasks“:

Postup Procesní dokumenty při vytváření úkolů (bod trasy obchodního procesu, vytvořené úkoly, odmítnutí) Pro každý úkol Z vytvořených úkolů Cyklus Úkol.Oddělení = Oddělení auditu; Task.Role = AuditorRole; EndCycle; EndProcedure

Pro vizuální přiřazení úkolů vytvoříme formulář seznamu. Ve formuláři seznamu zajistíme přepnutí do režimu zobrazení úlohy „Podle účinkujícího“. Pro tyto účely v panelu akcí formuláře vytvoříme nové tlačítko „Podle umělce“ s nastavenou vlastností „Označit“.

Ve formulářovém modulu popíšeme dva postupy.

Procedure By Artist(Button) Form Elements.Form Actions.Buttons.By Artist.Mark = NOT Form Elements.Form Actions.Buttons.By Artist.Mark; If Form Elements.Form Actions.Buttons.By Contractor.Mark Then Form Elements.TaskList.Task Display = TaskList Mode.By Contractor; ElseFormElements.TaskList.TaskDisplay = TaskListMode.AllTasks; endIf; Konec procedury při otevírání prvků formuláře. EndProcedure

Tzn., že po otevření se otevře formulář se všemi úkoly a po kliknutí na nové tlačítko zůstanou ve formuláři pouze úkoly s vlastnostmi adresování, které jsou vhodné pro aktuálního vykonavatele.

Při kontrole nezapomeňte v adresáři „Zaměstnanci“ nastavit aktuálního dodavatele. Po dalším stisknutí se formulář přirozeně vrátí do původního stavu.

Formulář úlohy v režimu zobrazení „Podle exekutora“, analyzující parametr relace, ve kterém je indikován aktuální exekutor, a pravidla adresování v informačním registru, zobrazuje ty (aktivní!) úlohy, které jsou podle pravidel adresování přiřazeny současnému exekutorovi.

Nyní můžete zkontrolovat. Pro kontrolu zadám dalšího interpreta „Kamensky“ a v informačním registru nastavím nové pravidlo adresování: Kamensky, oddělení oprav, řadový zaměstnanec.
Ve spuštěném BP uvedeme hodnoty detailů „Oddělení auditu“ - Oddělení oprav a „Role auditora“ - řadový zaměstnanec.

Dokončeme tři úkoly, které byly vytvořeny druhým akčním bodem.

Ve třetím bodě trasy byla vytvořena jedna úloha bez určení konkrétního vykonavatele, ale se dvěma dokončenými adresnými detaily.

Podle pravidel adresování, která jsou uvedena v registru informací, by se vytvořená úloha měla zobrazit v režimu zobrazení „By Performer“ pro dva zaměstnance: Kamenského a Sidorova. Pro Ivanova, přestože je v registru informací uveden jako připojený k oddělení „Oddělení oprav“, úkol se nezobrazí, protože role nesplňuje pravidla adresování.

Konkrétního vykonavatele můžete určit např. při otevírání úkolu (kdo ho otevřel jako první, ten jej provádí) nebo pro účely ukládání historie při provádění.

Kromě toho se událost "On Execution" ("Before Execution") spouští nejen pro úlohu, ale také pro bod trasy, který ji vygeneroval!

V našem příkladu to udělám. Popíšu událost "Při provedení" akčního bodu "Zpracovat dokumenty". Událost nastane po události se stejným názvem samotného úkolu.

Postup Dokumenty procesu během provádění (bod trasy obchodního procesu, úkol, selhání) TaskObject = Task.GetObject(); TaskObject.Executor = SessionParameters.CurrentExecutor; TaskObject.Write(); EndProcedure

Na základě toho, co bylo popsáno výše, můžeme dojít k následujícímu závěru.
Pro akční body můžete při popisu trasy BP přiřadit parametry adresování, ale pouze pokud jsou hodnoty adresování dostupné v režimu „Konfigurátor“ (předdefinované detaily adresáře, hodnoty výčtu atd.).

Pokud jsou při vytváření úkolu v akčním bodě známy vykonavatel nebo jiné parametry adresování, můžete je nastavit v události „When CreatingTasks“ nebo „Before CreatingTasks“ se zaměřením na detaily BP nebo jiná data.

Body trasy s atributem „Group“ vytvářejí tolik úloh, kolik je počet vykonavatelů, které odpovídají pravidlům adresování, a pravidla adresování jsou v tomto případě interpretována podle zadaných hodnot adresování v bodě trasy vůbec nebere v úvahu.

Body trasy bez atributu „Group“ tvoří jednu úlohu (pokud není v příslušné události bodu trasy uvedeno jinak), adresování takových úloh je standardní.

To je vše. Doufám, že tento článek někomu pomůže pochopit souvislost mezi úkoly a obchodními procesy. Příklad byl záměrně považován za primitivní, ale odhaluje všechny možné standardní možnosti vytváření úloh podle bodů obchodního procesu.

Pavel Chistov aka GROOVY
Ústav podpůrných technologií.
1C: Certifikované školicí středisko, St. Petersburg.
www.its-spb.ru
its(at)its-spb.ru

1C, 1C:Enterprise, 1C:Enterprise 8.0 jsou registrované ochranné známky společnosti 1C CJSC, Moskva.
Všechny prezentované snímky obrazovky, fragmenty uživatelského rozhraní a vývojářského rozhraní jsou prezentovány pro informační účely a v žádném případě nejsou určeny k získání jakéhokoli komerčního zisku. Žádná část těchto obrázků nesmí být reprodukována bez souhlasu držitele autorských práv (ZAO 1C).

Šablony podnikových obchodních procesů umožňují rychle a efektivně upravit formu obchodního procesu podle potřeb uživatele. Při vytváření obchodního procesu podle šablony se mění nejen vzhled obchodního procesu, ale také jeho prvotní naplnění daty. Chcete-li pracovat se šablonami obchodních procesů, použijte speciální referenční příručku „Šablony podnikových procesů“. Obrazovky tohoto adresáře byly vytvořeny s ohledem na všechny možnosti spravovaných formulářů platformy 1C:Enterprise 8.3 / 8.2.

Šablony podnikových podnikových procesů lze podle uvážení uživatelů EDMS „Corporate Document Flow“ kombinovat do skupin podle libovolných funkčních charakteristik. V seznamu obchodních procesů můžete kliknutím na tlačítko „Vytvořit obchodní proces“ vytvořit a automaticky vyplnit podrobnosti nového podnikového obchodního procesu. Obrázek níže ukazuje příklad vytvoření podnikového obchodního procesu založeného na šabloně.

Uživatelé mohou také vytvořit nový obchodní proces a poté vybrat požadovanou šablonu obchodního procesu v pravé horní části formuláře na obrazovce.

Formulář šablony obchodního procesu obsahuje několik záložek.

• Záložka „Trasa obchodního procesu“ obsahuje seznam zaměstnanců, kteří budou zkopírováni do seznamu vykonavatelů vytvořeného obchodního procesu. Seznam směrování může používat jak přímé adresování, označující konkrétní interprety, tak i adresování na základě rolí, označující roli a adresovací objekty.
• Záložka „Název podrobností“ obsahuje názvy podrobností pro formulář obchodního procesu.

Šablona obchodního procesu definuje následující názvy podrobností:

• Název tlačítka „Start“.
• Název skupiny účinkujících
• Název skupiny dokumentů
• Název textu procesu

Názvy uvedené v těchto detailech se používají ve formách podnikových obchodních procesů, což umožňuje zvýšit efektivitu práce zaměstnanců s obchodními procesy.

Záložka „Procesní parametry“ obsahuje seznam parametrů.

Zadané parametry se nastavují při vytváření nového podnikového procesu založeného na této šabloně. Šablona obchodního procesu také obsahuje odkaz na požadovaný výsledek a také textové pole procesu. Tyto parametry se zkopírují do podnikového obchodního procesu vytvořeného na základě šablony.

Důležité! V šabloně podnikového obchodního procesu můžete určit typ trasy: a) seznam účinkujících nebo b) jediný účinkující.
Pokud vyberete možnost „Jediný vykonavatel“, změní se formulář šablony obchodního procesu a zpřístupní se karta „Vykonavatel“.

Na záložce „Exekutor“ můžete zadat účinkujícího pomocí adresování na základě role nebo přímého adresování. Při vytváření podnikového obchodního procesu založeného na šabloně, která specifikuje typ trasy „Sole Executor“, se mění i forma obchodního procesu.

V podnikovém obchodním procesu se místo seznamu účinkujících objeví pole označující jednoho účinkujícího. Příklad je znázorněn na obrázku výše.

Důležité! Kromě přímého použití šablon obchodních procesů při ručním vytváření obchodních procesů se šablony podnikových procesů používají k automatickému vytváření pravidelných úloh a také k provádění akcí po vypršení platnosti dokumentu.

Business Process Engine (BPE) se objevil jako součást 1C:Enterprise na začátku roku 2005 a lze tvrdit, že jde o velmi slibnou a užitečnou inovaci platformy. Jeho podstatou je automatizace řetězců souvisejících operací zaměřených na dosažení společného cíle, obvykle v kontextu organizační struktury, která definuje funkční role a vztahy. Automatizace podnikových procesů umožňuje zlepšit kvalitu organizace práce a efektivitu řízení.

• · Zlepšená kvalita. Obchodní procesy formulují a implementují pravidla pro provádění jednotlivých operací a jejich vzájemnou provázanost, což umožňuje výrazně omezit nebo i zcela eliminovat chyby způsobené lidským faktorem z podnikového procesu. Jednoduchý seznam úkolů umožňuje zaměstnancům soustředit se na své bezprostřední povinnosti.
• · Zvýšená účinnost. Pomocí mechanismu business process lze formalizovat organizační činnosti a přiřadit funkce řízení spolupráce zaměstnanců aplikačnímu řešení, což vede k efektivnějšímu využití pracovní doby.
• · Poskytování nových příležitostí. Údaje o plnění úkolů a průběhu podnikových procesů mohou sloužit jako základ pro optimalizaci organizační struktury podniku, identifikaci úzkých míst a skrytých zdrojů. Metodika procesního řízení je tak plně implementována.

Obecně použití mechanismů podnikových procesů v aplikovaných řešeních umožní podnikům, včetně malých, přejít od tradičního funkčního modelu řízení k modernímu schématu orientovanému na procesy, kvalitativně zlepšit své činnosti prostřednictvím reengineeringu a automatizace podnikových procesů.

Základní informace o mechanismu podnikových procesů v 1C

Obchodní procesy v 1C:Enterprise jsou potřebné ke spojení jednotlivých operací (vystavení faktury, přijetí hotovostních plateb, výdej zboží ze skladu atd.) do řetězců vzájemně souvisejících akcí vedoucích k dosažení konkrétního cíle (například prodej produktu). v hotovosti). Účast zaměstnanců v životním cyklu obchodního procesu je dosažena prostřednictvím směrování na základě rolí.

Mechanismus obchodních procesů v 1C poskytuje několik konfiguračních objektů najednou: obchodní procesy, úkoly, registr informací a parametr relace. Typy detailů adresování úkolů a dimenze informačního registru jsou zpravidla přiřazeny odkazy na odpovídající adresáře, takže ke čtyřem výše uvedeným typům jsou přidány další adresáře.

Hlavními objekty mechanismu obchodních procesů jsou obchodní procesy a úkoly. Používají jeden druhého a další tři pomocné objekty – parametr session, registr informací a adresáře. Pomocné objekty nepoužívají sebe navzájem ani hlavní objekty.

Úloha je určena k vyúčtování úkolů a popisuje způsob jejich rozdělení mezi vykonávající s přihlédnutím k organizační struktuře podniku. Adresování úkolů zaměstnancům je dáno detaily, ve kterých lze zajistit vícerozměrné směrování rolí, např. rolemi, pracovními skupinami, odděleními, provozovnami, pobočkami atd. V tomto případě mohou být úkoly vytvářeny nejen obchodními procesy, ale také jinými objekty informační základny a přímo uživateli. Navíc v obecném případě může být vykonavatelem úkolu nejen zaměstnanec, ale také jakýkoli externí systém, například jiný účetní systém.

Pojem úkol ve skutečnosti definuje pouze rozhraní interakce mezi obchodním procesem a úkolem, jehož provádění obecně nemusí souviset s prováděním operací v systému samotném. Například obchodní proces v průběhu jeho realizace může vyžadovat koordinaci nějaké záležitosti s vedoucím společnosti. Takto formulovaný úkol bude například adresován sekretářce, která jej vyřeší jakýmikoli prostředky, které má k dispozici: emailem, telefonicky atd. Úkol bude považován za splněný, když systém obdrží informaci o obdržení potřebný souhlas.

Objekt „Business Process“ popisuje logiku provádění operací k dosažení určitého cíle a řídí životní cyklus vytvořených obchodních procesů (jejich instancí) od okamžiku zahájení až po okamžik dokončení. Logika obchodního procesu (vztah a posloupnost procházejících bodů trasy, podmíněné přechody atd.) je jasně popsána ve formě mapy trasy, která umožňuje vizuálně popsat trasu obchodního procesu ve formě připojený graf a umožňuje snadno popsat podmíněné přechodové algoritmy a odezvu obchodního procesu na různé události.

Operace prováděné během obchodního procesu jsou na mapě trasy reprezentovány akčními body, které obsahují informace o tom, kdo by měl co dělat v této fázi. Dodavatele lze určit osobně (Ivanov) nebo s přihlédnutím k směrování rolí („Skladník“, „Vedoucí obchodního oddělení“). Když se obchodní proces přesune do akčního bodu, automaticky vygeneruje úkoly a nastaví je na požadované podrobnosti adresování. Poté, co umělec označí úkol jako dokončený, obchodní proces se automaticky přesune na další bod trasy v souladu s mapou.

V místě akce je také možné přidělovat skupinové a kolektivní úkoly. V prvním případě musí akci provést všichni členové skupiny – například když všichni manažeři potřebují předložit měsíční výkaz. Ve druhém musí akci provést pouze jeden z členů skupiny (například schválit dokument od jednoho z vyšších manažerů). Akční bod může popisovat kontrolu nezbytných podmínek pro splnění úkolu, interaktivní dialog s uživatelem při dalším pohybu po trase a například specifikovat, které dokumenty se mají otevřít při aktivaci úkolů spojených s tímto bodem na trase obchodního procesu.

Mechanismus obchodních procesů v 1C umožňuje několik typů směrování.

• Tvrdý. Obchodní proces má mapu, která neobsahuje podmíněné a paralelní přechody s přesně definovanými cíli pro každý bod trasy. Odchylky od takových obchodních procesů nejsou povoleny.
• Volný, uvolnit. Cíle bodů na mapě trasy obchodního procesu nejsou nastaveny a jsou určeny programově nebo interaktivně během životního cyklu obchodního procesu.
• Podmiňovací způsob. Mapa trasy umožňuje kontrolu podmínek a pohyb po příslušných větvích. Přechody mohou být buď binární (podmínka) nebo více (výběr z možností)
• Paralelní. Mapa tras umožňuje rozdělení obchodního procesu do paralelních větví s možností následného slučování (čekání). Obchodní proces postupuje podél každé z paralelních větví nezávisle, jak jsou dokončeny odpovídající úkoly.

Všechny tyto typy směrování se zpravidla nacházejí v mapách skutečných obchodních procesů.

Obecné schéma pro vytvoření obchodního procesu v 1C

1. Vytvořte registr adres

• A. Vytváření formulářů

2. Vytvořte úkol

• A. Vyplnění záložky adresování
• b. Údaje vyplníme detaily přenášenými mezi úkoly a samotným obchodním procesem.
• C. Vytváření formulářů

3. Vytvořte obchodní proces

• A. Vyplňte úkol, detaily, vytvořte formuláře
• b. Kreslení mapy trasy

Funkce adresování

Adresování obvykle odkazuje na objekt, kterému je přiřazena konkrétní úloha. Adresování může být buď rigidní, kdy je adresovací objekt přiřazen při jeho vytváření, nebo libovolné, kdy úkolu není přiřazen konkrétní adresovací objekt, ale například jeho role, pozice nebo jiná hodnota, nepřímo indikující rozsah adresovacích objektů, pro které je úloha tvořena.

Informační registr se používá k popisu pravidel adresování. Při přidělování adresování se systém spoléhá na měření tohoto registru a detaily sám systém nepoužívá k adresování, i když mohou být v registru přítomny. Jednou z dimenzí registru by měla být dimenze ukládající konkrétní exekutory budou použity pro náhodné adresování. V současné době není na systémové úrovni podporována periodicita adresování. To znamená, že informační registr uchovávající pravidla adresování musí být neperiodický.

Uveďme si jednoduchý příklad: jako adresovací objekty budeme chápat zaměstnance podniku pracující s programem. Pokud při vytváření úkolu předem víme, pro kterého zaměstnance se vytváří, pak je tento zaměstnanec uveden v jeho vlastnostech. Tento typ přiřazení adresovacího objektu se nazývá tvrdé. Pokud při vytváření úkolu nelze z nějakého důvodu specifikovat konkrétního zaměstnance, ale přesto je známo, že tento úkol má provést někdo z obchodního oddělení, je jako předmět adresy uvedeno toto oddělení. Kteří zaměstnanci nakonec dostanou tento úkol, bude záviset na tom, kdo pracuje v jakém oddělení.

Příklad adresování: pokud je konkrétní adresující objekt (zaměstnanec, uživatel systému) určen jako vykonavatel úkolu při jeho vytváření, pak bude v každém případě přidělen. Pokud není specifikován konkrétní interpret, vstoupí v platnost mechanismus náhodného adresování. Systém se zaměřuje na shodu měření registru. Pokud jsou v adresovacím registru dvě dimenze (jedna pro vykonavatele a jedna více pro nějaký atribut adresování - například oddělení), pak bude úloha přiřazena všem vykonavatelům, pro které má registr záznamy s dalším atributem adresování. .

Někdy je důležité mít možnost zadávat úkoly účinkujícím, kteří spolupracují s konkrétními dodavateli a jejich kontaktními osobami. Příklad takového adresování:

Se stanovenými pravidly adresování bude Ivanov jmenován vykonavatelem úkolů pro „Svět“ buď s uvedenou kontaktní osobou „ředitel“, nebo pokud nebude kontaktní osoba uvedena. Při spolupráci s kontaktní osobou „Skladník“ bude vykonavatelem jmenován „Petrov“.

Vzhledem k tomu, že úkoly jsou vytvářeny za účelem jejich přiřazení konkrétním vykonavatelům pracujícím se systémem, je nutné neprodleně upozornit uživatele na výskyt nového úkolu. K tomu musí systém „znat“ přihlášeného uživatele. Odkaz na aktuálního uživatele musí být uložen v parametru relace, jehož hodnota musí být inicializována při startu systému. Navíc, protože adresovací registr může mít několik dimenzí, je důležité, aby systém indikoval, ve kterém z nich je nutné hledat provádějícího uživatele.

Možnost využití Business Process Mechanismu.

Business Process Engine je nedílnou součástí technologické platformy, což znamená, že jeho schopnosti mohou být dostupné všem aplikačním řešením vytvořeným na bázi 1C:Enterprise 8. Obecně je Business Process Mechanism zaměřen na zvýšení efektivity vývoje a údržby aplikačních řešení. Zkušenosti s jeho používáním však ukazují, že překrývání obchodních procesů nad hotovými aplikacemi způsobuje určité potíže: často se musíte na konstrukční řešení dívat novým způsobem a některé věci předělat. To samozřejmě není překvapivé - stejně tak automatizace podniku zpravidla vyžaduje revizi obecného schématu jeho fungování. Pro efektivní využití mechanismu obchodních procesů je žádoucí, aby model řízení procesů byl zpočátku začleněn do aplikačního řešení.

Samotný návrh podnikových procesů vyžaduje nejen znalost základů konfigurace 1C:Enterprise, ale také dobrou znalost předmětné oblasti a specifických potřeb zákazníka. Mechanismus podnikových procesů ve skutečnosti stimuluje zapojení specialistů kvalitativně jiné úrovně do návrhu a konfigurace konkrétních aplikačních systémů – obchodních analytiků, konzultantů i zákaznických manažerů. Pozitivní efekt mechanismu business procesu se navíc pro klienta projevuje i tehdy, když se přímo nepodílí na návrhu business procesů, ale pouze aplikuje schémata vyvinutá někým jiným. Schopnost formálně popsat akce systému a prezentovat jejich strukturu ve vizuální podobě umožňuje zákazníkovi lépe porozumět logice řešení, včetně sledování správnosti úkolu zadaného vývojáři.

Hovoříme tedy o dalším klíčovém směru ve vývoji aplikačních řešení 1C:Enterprise – zvyšování úrovně jejich ovladatelnosti. Využití mechanismu podnikových procesů umožňuje shromažďovat kvalitativně odlišné informace o fungování systému řízení podniku, na jejichž základě mohou manažeři provádět objektivní analýzu efektivnosti fungování jak organizace jako celku, tak její jednotlivých zaměstnanců. Tento mechanismus umožňuje přesunout zaměření z účetních úkolů na řízení podniku jako celku.

Vývojáři a uživatelé se mohou dozvědět více o mechanismu obchodních procesů implementovaném v 1C:Enterprise 8 pomocí demo konfigurace distribuované na disku Information Technology Support (ITS). Je zde prezentováno několik jednoduchých obchodních procesů ("Prodej zboží", "Objednávka" a "Schválení" atd.), které ukazují různé možnosti praktické aplikace tohoto mechanismu.

Poznámka pro programátora.

Objednávka provedení obslužných pracovníků obchodních procesů

1. Forma: před provedením
2. Formulář: před záznamem (nejprve na klientovi, poté na serveru)
3. Modul úlohy: před provedením
4. Obchodní proces: Před provedením
5. Modul úlohy: při spuštění
6. Úkolový modul: před záznamem
7. Úkolový modul: při nahrávání
8. Obchodní proces: během realizace
9. Forma: po záznamu (nejprve na serveru, poté na klientovi)

Interaktivní procedury neprobíhají kontrolovaným způsobem.

Když jsem se setkal s obchodními procesy, připadaly mi stejný temný les jako kdysi kalkulační registry. Díval jsem se tupě na ukázkový příklad z 1C, četl články na internetu a ničemu jsem nerozuměl.

Na obchodních procesech však není nic složitého. Pokusím se vám zprostředkovat tuto křišťálově čistou vizi.

Okamžitě pochopte, že obchodní procesy jsou pouze dva nové objekty v 1C 80: obchodní procesy a úkoly. Úlohy lze navíc používat samostatně a bez znalosti podnikových procesů. Lze je považovat za seznam úkolů pro aktuálního uživatele.

Obchodní procesy jsou v podstatě řízením úkolů. Tito. Uživatel má úkoly, plní je a po jejich dokončení vznikají úkoly nové.

Obchodní proces je v konfigurátoru nakreslen jako vývojový diagram. Tento blokový diagram má počáteční a koncové bloky, prováděcí bloky (obdélníkové) a bloky podmínek. Aby mohl obchodní proces začít, musí mít výchozí bod (jeden nebo více).

Obchodní proces může být umístěn v jednom nebo několika bodech najednou (při paralelním provádění).

Uživatel vytvoří nový obchodní proces a spustí jej. Jakmile se obchodní proces dostane do exekučního bloku, vytvoří nový úkol a adresuje jej exekutorovi, který je v tomto exekučním bloku registrován. Jakmile umělec dokončí úkol, obchodní proces se posune dále ve vývojovém diagramu. Podmínky jsou kalkulovány programově v jazyce 1C (podrobnosti obchodních procesů jsou analyzovány). To jsou všechny jednoduché mechaniky.

Vidíte, že úkoly se generují při provádění obchodních procesů. Lze je však použít i bez nich, například vytvořené programově nebo ručně. Připomínají úkoly MS Outlook.

Existuje velmi chytrý systémový mechanismus, který umožňuje určit, kterým uživatelům je úkol adresován, takže jeden úkol může provést kterýkoli z uživatelů, který ho zvládá. To se provádí pomocí proměnné relace, která ukládá aktuálního uživatele, informačního registru, který určuje, jaké role může aktuální uživatel vykonávat a tak dále.

Úkol můžete přiřadit celému oddělení a zobrazí se všem uživatelům daného oddělení.

Jak spolu souvisí úkoly a obchodní procesy? Jeden typ obchodního procesu odpovídá jednomu typu úlohy jeden typ úlohy lze použít v několika obchodních procesech. To je zvláštní, protože v různých bodech provádění jednoho obchodního procesu můžeme očekávat různé úkoly. Například úloha schvalování se může lišit od úlohy zadávání primárních dokumentů. Logičtější by bylo spojit různé úkoly s jedním obchodním procesem. V ukázkovém příkladu se vše provádí pomocí jednoho typu úlohy. Pokud přesto chceme používat různé typy úloh, můžeme použít vnořené obchodní procesy.

Jak vidíte, vše je velmi jednoduché.

Pár tipů pro blbce :

· Dívej se PROTI Režim „Konfigurátor“, ukázka obchodních procesů s ITS – informativní. Nemusíte se na to dívat v režimu „Enterprise“ a nebudete vlastně ničemu rozumět.

· Uobchodního procesu, musíte zadat typ úlohy – bez něj se konfigurace neuloží. Nejprve může použít jeden typ úlohy pro všechny obchodní procesy.

· Aby mohl obchodní proces začít, musí mít na mapě trasy alespoň jeden vstupní bod.

· Každému bloku obchodního procesu lze přiřadit vykonavatele. Vybírá se z detailů adresování úkolů, jejichž typ je vázán na obchodní proces. Můžete vybrat vykonavatele, uživatele nebo jakékoli jiné adresné údaje, například přiřadit úkol oddělení. Systémový adresovací mechanismus nemůžete vůbec používat a sami si určovat, které úlohy má aktuální uživatel k dispozici. Systémový mechanismus není univerzální; život může diktovat složitější schéma pro rozdělování úkolů.

· U úkolu musíte nejen vyplnit podrobnosti o adresování, ale také vybrat hlavní podrobnosti adresování, například „Uživatel“, vybrat registr informací pro adresování, proměnnou relace, která bude korelovat s hlavními podrobnostmi adresování a mít jeden typ (!).

· Nezapomeňte také uvést vztahy mezi detaily adresování úlohy a dimenzemi adresovacího registru, aby spojení mezi úlohou a registrem informací fungovalo.

· Pro ovládání seznamu úkolů adresovaných aktuálnímu uživateli můžete použít reportovací konzoli pro tabulku všech úloh „Úkoly“ a virtuální tabulku úloh pro aktuálního (nebo zadaného) uživatele “ TaskTasksBy Performer».

· Pro ladění můžete zakázat znamení, že obchodní proces byl zahájen nebo úloha byla dokončena.

Kde začít

Ve skutečnosti je největší výzvou přijít s obchodním procesem, kde se můžete začít učit mechaniku.Vzít nejjednodušší obchodní proces. Správce vystaví fakturu. Schválit to musí vedoucí oddělení. Po odsouhlasení je dodací list vyvěšen a Skladník expeduje. Pokud faktura není schválena, je označena ke smazání a obchodní proces končí.

Algoritmus je něco takového:

0: Start

A: Provedení: Manažer vystaví fakturu.

B: Provedení: Vedoucí oddělení schvaluje fakturu.

Otázka: Podmínka: Pokud je faktura schválena, pak D jinak E.

D: Plnění: Skladník provádí zásilku. Přejděte na E.

D: Konec: Dokončení obchodního procesu ve stavu „Zrušit“.

E: Konec: Normální dokončení obchodního procesu.

Zaškrtávací políčko „Schváleno“ lze přidat buď na fakturu, nebo do samotného obchodního procesu jako detail.

Co potřebovat šek:

· Když zahájíte obchodní proces, vytvoří se úkoly.

· Když dokončíte úkoly, obchodní proces se pohybuje po mapě trasy (k tomu je třeba zobrazit mapu trasy ve formuláři obchodního procesu).

· Úkoly se zobrazují pouze pro ty uživatele, kterým jsou určeny (zde jsem musel tvrdě pracovat).

Mechanismus obchodních procesů "1C:Enterprise 8"

Andrej Kolesov

Business Process Management (BPM) je termín, který je IT specialistům již dlouho dobře známý, ale zároveň má stále jistý nádech tajemna a nedostupnosti pro „běžné“ uživatele. Téměř všichni přední dodavatelé platforem a podnikového softwaru již dlouho a pravidelně ohlašují své úspěchy v oblasti BPM, ale zároveň někdy vkládají do tohoto konceptu různé významy se zaměřením na specifika vlastních navrhovaných technologií. Ve skutečnosti je obecná myšlenka BMP poměrně jednoduchá - použití procesního modelu pro řízení organizace, kdy jsou jednotlivé obchodní operace propojeny do řetězců. Tento přístup je implementován na metodickém základě konceptu Workflow (řízení pracovního toku), ale pouze v jeho širším pojetí. Pokud je v klasickém Workflow kladen důraz na dokumenty, pak BMP spojuje dokumenty (informace), lidi a aplikace (nástroje pro zpracování informací).

Business Process Engine (BPM) se objevil jako součást 1C:Enterprise na začátku roku 2005 a lze tvrdit, že jde o velmi slibnou a užitečnou inovaci platformy. Jeho podstatou je automatizace řetězců souvisejících operací zaměřených na dosažení společného cíle, obvykle v kontextu organizační struktury, která definuje funkční role a vztahy. Automatizace podnikových procesů umožňuje zlepšit kvalitu organizace práce a efektivitu řízení.

Zlepšení kvality. Obchodní procesy formulují a implementují pravidla pro provádění jednotlivých operací a jejich vzájemnou provázanost, což umožňuje výrazně omezit nebo i zcela eliminovat chyby způsobené lidským faktorem z podnikového procesu. Jednoduchý seznam úkolů umožňuje zaměstnancům soustředit se na své bezprostřední povinnosti.

Zvýšená účinnost. Pomocí IBP je možné formalizovat organizační činnosti a přiřadit funkce řízení spolupráce zaměstnanců aplikačnímu řešení, což vede k efektivnějšímu využití pracovní doby.

Poskytování nových příležitostí. Údaje o plnění úkolů a průběhu podnikových procesů mohou sloužit jako základ pro optimalizaci organizační struktury podniku, identifikaci úzkých míst a skrytých zdrojů. Metodika procesního řízení je tak plně implementována.

Obecně platí, že použití IBP v aplikovaných řešeních umožní podnikům, včetně malých, přejít od tradičního funkčního modelu řízení k modernímu schématu orientovanému na procesy, kvalitativně zlepšit své aktivity prostřednictvím reengineeringu a automatizace obchodních procesů.

Základní informace o mechanismu obchodních procesů

Obchodní procesy v 1C:Enterprise jsou potřebné ke spojení jednotlivých operací (vystavení faktury, přijetí hotovostních plateb, výdej zboží ze skladu atd.) do řetězců vzájemně souvisejících akcí vedoucích k dosažení konkrétního cíle (například prodej produktu). v hotovosti). Účast zaměstnanců v životním cyklu obchodního procesu je dosažena prostřednictvím směrování na základě rolí.

IBP je vybaven několika konfiguračními objekty najednou: obchodními procesy, úkoly, registrem informací a parametrem relace. Typy detailů adresování úkolů a dimenze informačního registru jsou zpravidla přiřazeny odkazy na odpovídající adresáře, takže ke čtyřem výše uvedeným typům jsou přidány další adresáře.

Hlavními předměty IBP jsou obchodní procesy a úkoly. Používají jeden druhého a další tři pomocné objekty – parametr session, registr informací a adresáře. Pomocné objekty nepoužívají sebe navzájem ani hlavní objekty.

Úloha je určena k vyúčtování úkolů a popisuje způsob jejich rozdělení mezi vykonávající s přihlédnutím k organizační struktuře podniku. Adresování úkolů zaměstnancům je dáno detaily, ve kterých lze zajistit vícerozměrné směrování rolí, např. rolemi, pracovními skupinami, odděleními, provozovnami, pobočkami atd. V tomto případě mohou být úkoly vytvářeny nejen obchodními procesy, ale také jinými objekty informační základny a přímo uživateli. Navíc v obecném případě může být vykonavatelem úkolu nejen zaměstnanec, ale také jakýkoli externí systém, například jiný účetní systém.

Pojem úkol ve skutečnosti definuje pouze rozhraní interakce mezi obchodním procesem a úkolem, jehož provádění obecně nemusí souviset s prováděním operací v systému samotném. Například obchodní proces v průběhu jeho realizace může vyžadovat koordinaci nějaké záležitosti s vedoucím společnosti. Takto formulovaný úkol bude například adresován sekretářce, která jej vyřeší jakýmikoli prostředky, které má k dispozici: emailem, telefonicky atd. Úkol bude považován za splněný, když systém obdrží informaci o obdržení potřebný souhlas.

Objekt „Business Process“ popisuje logiku provádění operací k dosažení určitého cíle a řídí životní cyklus vytvořených obchodních procesů (jejich instancí) od okamžiku zahájení až po okamžik dokončení. Logika obchodního procesu (vztah a posloupnost procházejících bodů trasy, podmíněné přechody atd.) je jasně popsána ve formě mapy trasy, která umožňuje vizuálně popsat trasu obchodního procesu ve formě připojený graf a umožňuje snadno popsat podmíněné přechodové algoritmy a odezvu obchodního procesu na různé události.

Operace prováděné během obchodního procesu jsou na mapě trasy reprezentovány akčními body, které obsahují informace o tom, kdo by měl co dělat v této fázi. Dodavatele lze určit osobně (Ivanov) nebo s přihlédnutím k směrování rolí (“Skladník”, “vedoucí obchodního oddělení”). Když se obchodní proces přesune do akčního bodu, automaticky vygeneruje úkoly a nastaví je na požadované podrobnosti adresování. Poté, co umělec označí úkol jako dokončený, obchodní proces se automaticky přesune na další bod trasy v souladu s mapou.

V místě akce je také možné přidělovat skupinové a kolektivní úkoly. V prvním případě musí akci provést všichni členové skupiny – například když všichni manažeři potřebují předložit měsíční výkaz. Ve druhém musí akci provést pouze jeden z členů skupiny (například schválit dokument od jednoho z vyšších manažerů). Akční bod může popisovat kontrolu nezbytných podmínek pro splnění úkolu, interaktivní dialog s uživatelem při dalším pohybu po trase a například specifikovat, které dokumenty se mají otevřít při aktivaci úkolů spojených s tímto bodem na trase obchodního procesu.

IBP umožňuje několik typů směrování.

Tvrdý. Obchodní proces má mapu, která neobsahuje podmíněné a paralelní přechody s přesně definovanými cíli pro každý bod trasy. Odchylky od takových obchodních procesů nejsou povoleny.

Volný, uvolnit. Cíle bodů na mapě trasy obchodního procesu nejsou nastaveny a jsou určeny programově nebo interaktivně během životního cyklu obchodního procesu.

Podmiňovací způsob. Mapa trasy umožňuje kontrolu podmínek a pohyb po příslušných větvích. Přechody mohou být buď binární (podmínka) nebo více (výběr z možností)

Paralelní. Mapa tras umožňuje rozdělení obchodního procesu do paralelních větví s možností následného slučování (čekání). Obchodní proces postupuje podél každé z paralelních větví nezávisle, jak jsou dokončeny odpovídající úkoly.

Všechny tyto typy směrování se zpravidla nacházejí v mapách skutečných obchodních procesů.

Klíčovým konceptem v mechanismu a úlohách business process v 1C:Enterprise je adresovací systém, který poskytuje možnost nejen osobního, ale i role-based adresování úkolů účastníkům obchodních procesů.

Role-based routing umožňuje přidělovat úkoly nejen konkrétním interpretům, ale také rolím, skupinám, oddělením atd., jak je definováno v aplikačním řešení. Je postaven na interakci objektů „úkol“ a „informační registr“. První určuje skladbu detailů oslovování (role, oddělení atd.) a druhý odráží aktuální, tedy relevantní informace o příslušnosti zaměstnanců k rolím, oddělením, pracovním skupinám atd.

Informační registr lze využít k implementaci mechanismů pro nahrazování nebo evidenci nepřítomnosti zaměstnanců. Pokud například uvádí, že roli hlavního účetního vykonává Ivanov a Ivanov jede na dovolenou a jeho povinnosti jsou převedeny na Petrova, pak se zápis v registru informací změní tak, že se vykonává role hlavního účetního. od Petrova. Po Ivanovově návratu z dovolené jsou příslušné informace obnoveny.

Shrneme-li výše uvedené, můžeme konstatovat, že mechanismus obchodních procesů se skládá z následujících hlavních komponent:

• vícerozměrný systém pro adresování úkolů účinkujícím (role, oddělení, organizace, skupiny atd.),
• vizuální návrh mapy obchodních procesů,
• generování úkolů exekutorem,
• směrování rolí,
• pohyb přes body trasy v souladu s mapou obchodních procesů.

Obecná logika pro provádění obchodních procesů vypadá asi takto:

• obchodní procesy tvoří úkoly nastavením požadovaných hodnot v detailech jejich adresování (role, skupiny, oddělení);
• koncoví umělci jsou definováni pomocí „dereferenční matice“, která například mapuje uživatele k rolím.

Vývoj a provedení

V zásadě by se programování obchodních procesů v 1C:Enterprise dalo dělat dříve, ale pouze na úrovni programovacího jazyka. Nový mechanismus automatizuje tento postup, nabízí nástroje pro vizuální návrh a možnost přizpůsobit program pomocí parametrizačních technik a minimalizovat (nebo eliminovat) ruční kódování. To vše je nyní implementováno na úrovni platformy, která obsahuje metadatové objekty a mechanismy zajišťující jednotnou implementaci obchodních procesů v aplikačních řešeních.

V tomto článku často používáme termín „obchodní proces“, i když někdy znamená různé věci. Na jedné straně se jedná o zobecněný popis sledu akcí při plnění některých obchodních úkolů (například prodej produktu). V tomto případě je takový popis implementován ve formě určitého programu (pouze prezentovaného nikoli v kódech, ale ve formě mapy trasy), který lze podmíněně nazvat soukromým obchodním řešením. Na druhé straně obchodní proces je provádění konkrétních akcí v souladu s tímto popisem (při obsluze konkrétního zákazníka), tj. provádění dříve napsaného programu.

Podle terminologie 1C budeme v prvním případě používat termín „obchodní proces“ (BP), ve druhém - „instance obchodního procesu“ (EBP). BP jsou vytvářeny vývojáři a uživatelé provádějí své akce pomocí EBP. Vývoj napájecího zdroje se provádí v „Konfigurátoru“, realizace elektrického napájení probíhá v prostředí aplikačních řešení („1C:Enterprise“).

„Konfigurátor“ systému 1C:Enterprise poskytuje dostatek příležitostí pro vytváření obchodních procesů, jejichž logika je specifikována pomocí map tras. Zvláštností implementace BMP (ve srovnání s některými BMP mechanismy jiných IT dodavatelů) je, že v důsledku vizuálního návrhu obchodního procesu vývojář neobdrží program se zdrojovým kódem interního jazyka (většina jiného vizuálního návrhu nástroje generují takový kód). S jistou mírou zjednodušení lze tvrdit, že zdrojový kód vytvářeného programu je tvořen právě vizuálním znázorněním jeho logiky (mapou trasy), která je doplněna o jednotlivé fragmenty zapsané v interním programovacím jazyce.

Trasová mapa tedy současně oslovuje systém instrukcemi pro provádění sledu akcí obchodního procesu, popisem struktury těchto akcí ve formě srozumitelné pro uživatele a prostředkem pro zobrazení aktuálního stavu obchodního procesu. .

Provádění obchodních procesů (přesněji instancí obchodních procesů) probíhá v prostředí platformy 1C:Enterprise. V tomto případě lze obchodní proces považovat za objekt informační báze, jako je dokument nebo prvek adresáře. Jeho životní cyklus začíná od začátku (voláním metody „start“ nebo kliknutím na příslušné tlačítko ve formě objektu obchodního procesu) a končí dosažením koncového bodu (samozřejmě, pokud byly dokončeny všechny úkoly).

Úkoly jsou také běžné objekty informační báze, které mohou být generovány jak mechanismem obchodního procesu, tak jinými aplikačními objekty a dokonce i ručně. Úkol má dva stavy – „dokončeno“ a „nedokončeno“. Pokud je v rámci obchodního procesu vytvořen úkol, po jeho dokončení jej o tom informuje, což vede k tomu, že se obchodní proces posune dále po trase (pokud jsou k tomu splněny všechny nezbytné podmínky).

Pro konkrétního uživatele je fungování mechanismu obchodních procesů vyjádřeno pouze tím, že se zabývá seznamem úkolů, které musí splnit. Skladník by například neměl myslet na svou účast v jakýchkoli procesech, jeho úkolem je uvolnit zboží po obdržení úkolu a zaznamenat tuto operaci do systému.

Možnost využití MBP

Business Process Engine je nedílnou součástí technologické platformy, což znamená, že jeho schopnosti mohou být dostupné všem aplikačním řešením vytvořeným na bázi 1C:Enterprise 8. Obecně je IBP zaměřen na zvýšení efektivity vývoje a údržby aplikačních řešení. Zkušenosti s jeho používáním však ukazují, že překrývání obchodních procesů nad hotovými aplikacemi způsobuje určité potíže: často se musíte na konstrukční řešení dívat novým způsobem a některé věci předělat. To samozřejmě není překvapivé - stejně tak automatizace podniku zpravidla vyžaduje revizi obecného schématu jeho fungování. Pro efektivní využití IBP je žádoucí, aby model procesního řízení byl zpočátku začleněn do aplikačního řešení.

Samotný návrh podnikových procesů vyžaduje nejen znalost základů konfigurace 1C:Enterprise, ale také dobrou znalost předmětné oblasti a specifických potřeb zákazníka. IBP ve skutečnosti podporuje zapojení specialistů kvalitativně jiné úrovně do návrhu a konfigurace konkrétních aplikačních systémů – obchodní analytiky, konzultanty i zákaznické manažery. Pozitivní efekt IBP se navíc pro klienta projevuje i tehdy, když se přímo nepodílí na návrhu obchodních procesů, ale pouze aplikuje schémata vyvinutá někým jiným. Schopnost formálně popsat akce systému a prezentovat jejich strukturu ve vizuální podobě umožňuje zákazníkovi lépe porozumět logice řešení, včetně sledování správnosti úkolu zadaného vývojáři.

Hovoříme tedy o dalším klíčovém směru ve vývoji aplikačních řešení 1C:Enterprise – zvyšování úrovně jejich ovladatelnosti. Využití IBP umožňuje shromažďovat kvalitativně odlišné informace o fungování systému řízení podniku, na jejichž základě mohou manažeři provádět objektivní analýzu efektivnosti fungování jak organizace jako celku, tak jejích jednotlivých zaměstnanců. Tento mechanismus umožňuje přesunout zaměření z účetních úkolů na řízení podniku jako celku.

Vývojáři a uživatelé se mohou dozvědět více o mechanismu obchodních procesů implementovaném v 1C:Enterprise 8 pomocí demo konfigurace distribuované na disku Information Technology Support (ITS). Je zde představeno několik jednoduchých obchodních procesů („Prodej zboží“, „Objednávka“ a „Schválení“ atd.), které ukazují různé možnosti praktické aplikace tohoto mechanismu.