Príklady obchodných procesov pripravené 1s. Obchodné procesy

Pupsen a Vupsen 10. decembra 2013 o 15:54 hod

Mýtus, že 1C:UT má riadenie obchodných procesov (BPM)

"UT" je veľmi dobrý produkt na riešenie úloh, pre ktoré bol navrhnutý. Umožňuje vám riadiť obchodné aktivity podniku. Dobre analyzuje transakcie, nákupy, sklady, financie. Áno, v niektorých prípadoch využíva mechanizmus platformy „Business Processes“. Znamená to však, že obchod je určený na riadenie obchodných procesov alebo logiky podniku? - Nie nie a ešte raz nie. Tento článok je výkrik zo srdca. Pretože ma už naozaj nebaví pozerať prezentácie alebo čítať popisy riešení na rôznych stránkach. Webové stránky spoločností, ktoré sú pripravené predávať akýkoľvek produkt 1C a privierať oči pred tým, čo predávajú klientovi. Príťažlivý len skromný popis produktu a ani nepochopenie podstaty riadenia podnikových procesov. Manažment znamená, že môžete nakonfigurovať systém tak, aby ste urýchlili a optimalizovali procesy, vykonali rôzne analýzy, identifikovali slabé stránky a oveľa viac. Pre tých, ktorí nevidia rozdiel medzi ovládaním a používaním mechanizmu, sa pokúsim vysvetliť na prstoch:

UT. Existujú tri BP, v ktorých nemôžete pridávať alebo odstraňovať úlohy, meniť typ adresovania, logiku, nemôžete robiť nič okrem konkrétnych dokumentov viazaných na úlohy na presun procesu. V skutočnosti to nie je kontrola - je to použitie navrhovanej verzie logiky programu pomocou mechanizmu "BP". Áno, je možné vyvinúť si vlastnú na základe tejto funkcie bez toho, aby ste strácali čas niektorými základmi.
CRM. Toto je skutočne jediný produkt na platforme 1C, kde sa 100% funkcionality platformy využíva na prácu s mechanizmom BP. Toto je riešenie, v ktorom používateľ nezávisle predstavuje všetku logiku práce svojho podniku vytvorením akýchkoľvek máp trás. Môže volať svoje procesy, kedy potrebuje a ako potrebuje. a za čo? A len to všetko zvládnuť. Ak chcete zistiť, aké efektívne sú procesy, zbierajte o nich štatistiky. Aké by boli dobré argumenty na zmenu logiky. Čo všetko by bolo neopodstatnené. Aby ste videli všetko to upchávanie a naťahovanie gumy v etapách. Vyhoďte zbytočné kroky – zvýšte efektivitu práce. To je to, čo je "manažment". A na to potrebujete oveľa viac ako tri karty s niekoľkými blokmi.

A na záver, pre tých, ktorí stále nechápu rozdiel - samotná spoločnosť 1C jasne píše, čo je v konfigurácii z hľadiska napájania -

"Konfigurácia implementuje základnú funkcionalitu automatizácie podnikových procesov - univerzálne mechanizmy pre nastavenie procesov, sledovanie a analýzu ich implementácie, podporu podnikových procesov zabudovaných do štandardného riešenia a umožňujúcu špecifickú implementáciu s cieľom zvýšiť ich zloženie s nižšími mzdovými nákladmi.". (v8.1c.ru/trade/newtech/ štvrtý odsek).

Upozorňujem na slovo "základná" funkcionalita pre automatizáciu.

Toto je veľmi vzdialené od riadenia podnikových procesov. Preto záver: keď vám na prezentácii povedia, že UT obsahuje podsystém riadenia BP – neverte tomu, keď vám na prezentácii povedia, že v UT je CRM – neverte tomu. To sú opäť začiatky a základná funkčnosť. Opakujem ešte raz - UT je veľmi dobrý produkt, ale na iné úlohy - operatívne účtovníctvo a plánovanie obchodných aktivít, na jeho analýzu. Pojem CRM je úplne odlišný. A na platforme 1C existuje len jeden skutočne funkčný produkt, ktorý podporuje koncepciu CRM v podniku - Toto je 1C: CRM. Pre spravodlivosť treba poznamenať, že aj na iných platformách existujú dostatočne funkčné produkty na podporu konceptu „CRM“ v podniku.

Tagy: crm-systémy, riadenie obchodu, 1s, obchodné procesy

statný muž 10. decembra 2013 o 15:54 hod

Mýtus, že 1C:UT má riadenie obchodných procesov (BPM)

CRM systémy

UT. Existujú tri BP, v ktorých nemôžete pridávať alebo odstraňovať úlohy, meniť typ adresovania, logiku, nemôžete robiť nič okrem konkrétnych dokumentov viazaných na úlohy na presun procesu. V skutočnosti to nie je kontrola - je to použitie navrhovanej verzie logiky programu pomocou mechanizmu "BP". Áno, je možné vyvinúť si vlastnú na základe tejto funkcie bez toho, aby ste strácali čas niektorými základmi.
CRM. Toto je skutočne jediný produkt na platforme 1C, kde sa 100% funkcionality platformy využíva na prácu s mechanizmom BP. Toto je riešenie, v ktorom používateľ nezávisle predstavuje všetku logiku práce svojho podniku vytvorením akýchkoľvek máp trás. Môže volať svoje procesy, kedy potrebuje a ako potrebuje. a za čo? A len to všetko zvládnuť. Ak chcete zistiť, aké efektívne sú procesy, zbierajte o nich štatistiky. Aké by boli dobré argumenty na zmenu logiky. Čo všetko by bolo neopodstatnené. Aby ste videli všetko to upchávanie a naťahovanie gumy v etapách. Vyhoďte zbytočné kroky – zvýšte efektivitu práce. To je to, čo je "manažment". A na to potrebujete oveľa viac ako tri karty s niekoľkými blokmi.

A na záver, pre tých, ktorí stále nechápu rozdiel - samotná spoločnosť 1C jasne píše, čo je v konfigurácii z hľadiska napájania -

Upozorňujem na slovo "základná" funkcionalita pre automatizáciu.

Tagy: crm-systémy, riadenie obchodu, 1s, obchodné procesy

Možnosti, ktoré vstavaný regulačný mechanizmus otvára:

Znižuje sa presné poradie prác, riziko chýb alebo preskočenie jednej z etáp práce.
Formalizovaný prístup vďaka vopred stanovenej štruktúre obchodného procesu 1C.
Kontrola v každej fáze.
Určenie, ktoré fázy práce boli najmenej efektívne, a optimalizácia procesu.
Modelovanie štruktúry konkrétnej organizácie.

Na vizuálne znázornenie podmienok, poradia a vlastností každej etapy sa používa mapa trasy. Mapa trasy má fázy, ktoré oddeľujú jeden proces od druhého bodom trasy. V každom bode sú úlohy, ktoré treba splniť, a sú tu uvedené všetky potrebné informácie na kontrolu: vykonávateľ, dôležitosť a termíny.

Ťažká - zmeny v trase nie sú možné;
Podmienené - vykonanie úlohy závisí od množstva podmienok, ktorých môže byť niekoľko. Od toho sa odvíja konečná trasa práce;
Paralelné - dve alebo viac trás, pozdĺž ktorých bude prebiehať realizácia obchodného procesu. V určitom okamihu sa vetvy môžu spojiť;
Voľný - tento typ obchodného procesu nemá trasu a vykonáva sa na základe úlohy.

Zvážte fungovanie programu pomocou príkladu predaja v 1C: UT.

Začína sa proces riadenia obchodného procesu ( BPM) z počiatočného bodu.

Trasové body sú žlté obdĺžniky. Každý rámček označuje, ktorý pracovník alebo viacerí pracovníci by mali vykonávať špecifikovanú úlohu. Dokončené úlohy sú označené značkou začiarknutia.

Na spustenie obchodného procesu je potrebné vytvoriť obchod v sekcii „CRM a marketing“ vyplnením požadovaných polí, po čom sa karta obchodu uloží a otvoria sa 2 hypertextové odkazy: „Fáza“ a „Mapa trasy ".

V oficiálnej dokumentácii pre platformu 1C:Enterprise 8.2 v časti „13.7. Rozdelenie a zlúčenie » Správanie obchodného procesu v bodoch rozdelenia a zlúčenia je opísané nasledovne:

„Na rozdelenie obchodného procesu do niekoľkých paralelných (súčasne a nezávisle) spustiteľných vetiev sa používa bod rozdelenia. Deliaci bod má jeden vstup a neobmedzený počet výstupov.

Bod zlúčenia sa používa na synchronizáciu predtým rozdelených vetiev. Obchodný proces sa nevykoná po bode zlúčenia, kým sa neprejdú všetky v ňom zahrnuté vetvy.

Ukážem to na príklade jednoduchej mapy trasy (obr. 1)

V bode rozdelenia sa vytvoria úlohy v každej z vetiev (obr. 2), potom sa každá vetva vykoná paralelne a úloha v bode Akcia4 vytvorí sa po dokončení všetkých úloh každej pobočky (obr. 3)

Správa sa systém vždy takto? Poďme zistiť. Najprv si dajme pozor na postupnosť vytvárania úloh po bode rozdelenia (obr. 4)

Podľa čísla úlohy môžete vidieť, že úloha bola vytvorená ako prvá v danom bode Akcia3. Teraz, v module obchodného procesu pre tento bod, opíšeme nasledujúci obslužný program pri vytváraní úloh:

Postup Action3Pri vytváraní úloh(WaypointBusinessProcess, MoldableTasks, Odmietnutie )

Pre každý TaskObject From MoldableTasks Cyklus

TaskObject . Na vykonanie úlohy();

EndCycle;

EndProcedure

Takýto handler spôsobí okamžité vykonanie vytvorenej úlohy. Začneme nový obchodný proces s mapou trasy zobrazenou na obrázku 1. A čo uvidíme? Po dokončení úlohy Akcia3úloha bola vytvorená Akcia4(Obrázok 5), napriek tomu, že ostatné vetvy procesu ešte neboli ukončené! Pre tých, ktorí sa snažia reprodukovať túto situáciu, vás varujem: namiesto písania obsluhy pre bod Akcia3 môže byť potrebné napísať obslužnú rutinu automatického dokončenia úlohy pre bod Akcia1 alebo Akcia2. Akčný bod, ktorého automatické vykonanie „rozbije“ schému procesu, je presne bod, v ktorom sa po bode rozdelenia vytvorí prvá úloha. Čo určuje postupnosť vytvárania úloh, si rozoberieme nižšie.

Takéto správanie jednoduchej schémy trasy nemožno na základe popisu uvedeného na začiatku článku nijako predpokladať. Možno je to nejaký druh chyby zobrazenia schémy? Nie, toto sa v skutočnosti deje. Obchodný proces nielenže prebieha za bodom zlúčenia bez čakania na dokončenie úloh na paralelných vetvách, ale po dokončení paralelných vetiev tiež znovu vytvára úlohy v bodoch trasy nasledujúcich po bode zlúčenia. Pozeráme sa na zoznam úloh pre náš proces a vidíme po 2 úlohy pre body Action4 a Action5 (obr. 8)

Čo to hovorí? V skutočnosti to znamená, že keď sa úloha automaticky vykoná Akcia3 získame správanie sa obchodného procesu zodpovedajúce schéme znázornenej na obrázku 9, to znamená, že bod zlúčenia sa preskočí pri vykonávaní jednej vetvy. Ale to tiež nie je vždy pravda. Ak v bode Akcia4 nevykonáme prvú z vytvorených úloh, kým sa druhá úloha neobjaví ako výsledok vykonania paralelných vetiev k bodu zlúčenia, potom ďalšia úloha v bode Akcia5 vytvorí sa až pri spustení obe úlohy v bode Akcia4, to znamená, že obchodný proces takpovediac opravuje skoršiu chybu ignorovania bodu zlúčenia. Ďalej sa podľa schémy trasy vytvorí iba jedna úloha. Pre tých, ktorých zaujíma toto správanie obchodného procesu, navrhujem, aby si to overili sami.

Uvažujme o ďalšom príklade. Predpokladajme pointu Akcia3 nie je akčný bod, ale vnorený procesný bod. Pre jednoduchosť použijeme nasledujúcu schému vnoreného obchodného procesu (obr. 10)

Ak na podujatí Stav 1Skontrolujte podmienky nerobte nič, takýto proces sa končí ihneď po spustení, bez vytvorenia jedinej úlohy. V praxi to môže nastať aj pri zložitejších procesoch, ak potreba plnenia úloh procesu vzniká až pri splnení určitých podmienok. Nahradme bod Akcia3 bodom vnoreného obchodného procesu a získajme diagram znázornený na obrázku 11.

Kontrolujeme prácu obchodného procesu s vnoreným procesom a uisťujeme sa, že správanie je podobné. Obrázok 12 je schéma obchodného procesu po spustení.

Vyskytuje sa toto správanie vždy v takýchto obvodoch? Poďme na to. Všimnite si, že úlohy v bode rozdelenia sa vytvárajú v poradí, v akom boli pridané riadky v bode rozdelenia. Vidno to, ak si zobrazíte názvy spojovacích vedení (obr. 13).

Skúsme prehodiť Line2 a Line4. A nakoniec pri spustení nového procesu vidíme očakávaný výsledok (obr. 14)

Upozorňujeme, že riadky nevyhnutne treba vymeniť. Ak jednoducho premenujete čiary vychádzajúce z deliaceho bodu, výsledok zostane rovnaký. Ďalším spôsobom, ako vyriešiť tento problém, je odstrániť prepojenie Line2, pridať nové prepojenie v bode rozdelenia a pripojiť ho k vnorenému procesnému bodu.

Dospeli sme k záveru:

Pri automatickom vykonávaní úlohy spojenej s prvý v poradí pridávania delené bodové čiary, ak po tejto úlohe bezprostredne nasleduje bod sútoku , tento bod zlúčenia sa ignoruje a vytvorí sa ďalšia úloha podľa schémy trasy. Ak nevenujete pozornosť postupnosti odkazov, môžete získať odlišné správanie obchodného procesu pri vytváraní navonok rovnakých schém.

Táto závislosť by sa mala brať do úvahy aj pri úprave existujúcich schém. Predpokladajme, že sme sa rozhodli, že namiesto jednej úlohy v bode Action1 na obrázku 14, ktorá nám začala pracovať podľa potreby, by mal existovať vnorený proces, ktorý sa za určitých podmienok môže automaticky vykonať podľa podmienky podobnej obrázku 10. Potom , keď sa náš proces spustí, uvidíme známy obrázok s ignorovaním bodu zlúčenia (obr. 15)

Na záver by som rád poznamenal, že špecifikované správanie obchodných procesov bolo zaznamenané na platforme 8.1 a naďalej sa objavuje v najnovších vydaniach 8.2. Pri príprave článku sa testovalo na platforme release 8.2.15.310.

Business Process Engine (BPM) sa objavil ako súčasť 1C:Enterprise začiatkom roku 2005 a možno tvrdiť, že ide o veľmi sľubnú a užitočnú inováciu platformy. Jeho podstatou je automatizácia reťazcov súvisiacich operácií zameraných na dosiahnutie spoločného cieľa, zvyčajne v kontexte organizačnej štruktúry, ktorá definuje funkčné roly a vzťahy. Automatizácia obchodných procesov zlepšuje kvalitu organizácie práce a efektivitu riadenia.

· Zlepšenie kvality. Podnikové procesy formulujú a implementujú pravidlá vykonávania jednotlivých operácií a ich vzájomných vzťahov, ktoré môžu výrazne znížiť alebo dokonca úplne odstrániť chyby spôsobené ľudským faktorom z podnikového procesu. Jednoduchý zoznam úloh umožňuje zamestnancom sústrediť sa na ich bezprostredné povinnosti.
· Zvyšovanie efektívnosti. Pomocou mechanizmu podnikových procesov je možné formalizovať organizačné činnosti a priradiť funkcie riadenia spoločnej práce zamestnancov aplikačnému riešeniu, čo vedie k efektívnejšiemu využívaniu pracovného času.
· Poskytovanie nových príležitostí. Údaje o vykonávaní úloh a priebehu obchodných procesov môžu slúžiť ako základ pre optimalizáciu organizačnej štruktúry podniku, identifikáciu úzkych miest a skrytých zdrojov. Metodika procesného riadenia je teda plne implementovaná.

Využitie mechanizmov podnikových procesov v aplikovaných riešeniach vo všeobecnosti umožní podnikom, vrátane malých, prejsť od tradičného funkčného modelu riadenia k modernej schéme orientovanej na procesy, kvalitatívne zlepšiť svoje činnosti prostredníctvom reengineeringu a automatizácie podnikových procesov.

Základné informácie o mechanizme obchodných procesov v 1C

Obchodné procesy v 1C:Enterprise sú potrebné na spojenie jednotlivých operácií (vystavenie faktúry, prijatie hotovostných platieb, výdaj tovaru zo skladu atď.) do reťazcov vzájomne súvisiacich akcií, ktoré vedú k dosiahnutiu konkrétneho cieľa (napr. predaj tovaru v hotovosti). Účasť zamestnancov na životnom cykle podnikového procesu sa dosahuje smerovaním na základe rolí.

Mechanizmus obchodných procesov v 1C poskytuje niekoľko konfiguračných objektov naraz: obchodné procesy, úlohy, register informácií a parameter relácie. Typy úloh, ktoré sa týkajú podrobností a rozmerov informačného registra, sa spravidla priraďujú odkazmi na príslušné adresáre, preto sa k štyrom typom uvedeným vyššie pridávajú adresáre.

Hlavnými objektmi motora obchodných procesov sú obchodné procesy a úlohy. Využívajú sa navzájom a ešte tri pomocné objekty – parameter relácie, register informácií a adresáre. Pomocné predmety sa navzájom nevyužívajú, ani hlavné predmety.

Úloha je navrhnutá tak, aby zohľadňovala úlohy a opisuje, ako sú rozdelené medzi vykonávateľov, berúc do úvahy organizačnú štruktúru podniku. Adresovanie úloh zamestnancom je určené detailmi, ktoré môžu poskytnúť viacrozmerné smerovanie založené na rolách, napríklad podľa rolí, pracovných skupín, divízií, priestorov, pobočiek atď. V tomto prípade môžu byť úlohy vytvárané nielen obchodnými procesmi, ale aj inými objektmi infobázy a priamo užívateľmi. Okrem toho vo všeobecnom prípade môže byť vykonávateľom úlohy nielen zamestnanec, ale aj akýkoľvek externý systém, napríklad iný účtovný systém.

Pojem úloha v skutočnosti definuje iba rozhranie pre interakciu obchodného procesu s úlohou, ktorej vykonávanie vo všeobecnosti nemusí súvisieť s vykonávaním operácií v samotnom systéme. Napríklad obchodný proces v priebehu jeho vykonávania môže vyžadovať koordináciu nejakého problému s vedúcim spoločnosti. Takto formulovaná úloha bude napríklad adresovaná tajomníkovi, ktorý ju vyrieši akýmikoľvek prostriedkami, ktoré má k dispozícii: e-mailom, telefonicky a pod.. Úloha bude považovaná za splnenú, keď systém dostane informáciu o získanie potrebného súhlasu.

Objekt "Business process" popisuje logiku vykonávania operácií na dosiahnutie konkrétneho cieľa a riadi životný cyklus vytvorených obchodných procesov (ich inštancií) od momentu spustenia až po moment ukončenia. Logika obchodného procesu (vzťah a postupnosť obchádzania trasových bodov, podmienené skoky atď.) je jasne popísaná vo forme mapy trasy, ktorá umožňuje vizuálne opísať trasu obchodného procesu vo forme spojeného grafu. a uľahčuje popis algoritmov podmieneného skoku a reakcie obchodného procesu na rôzne udalosti.

Operácie vykonávané v priebehu obchodného procesu sú na mape trasy reprezentované akčnými bodmi, ktoré obsahujú informácie o tom, kto by mal čo robiť v tejto fáze. Vykonávateľ môže byť určený osobne (Ivanov) alebo s prihliadnutím na smerovanie rolí („Skladník“, „Vedúci obchodného oddelenia“). Keď sa obchodný proces presunie do akčného bodu, automaticky generuje úlohy nastavením poskytnutých podrobností o adresovaní v nich. Keď účinkujúci označí úlohu ako dokončenú, obchodný proces sa automaticky presunie na ďalší trasový bod v súlade s mapou.

V mieste akcie je možné zadávať aj skupinové a kolektívne úlohy. V prvom prípade musia akciu vykonať všetci členovia skupiny – napríklad keď všetci manažéri potrebujú predložiť mesačnú správu. V druhom prípade by mal akciu vykonať iba jeden z členov skupiny (napríklad schváliť dokument od jedného z vyšších manažérov). V akčnom bode môžete popísať kontrolu nevyhnutných podmienok na splnenie úlohy, interaktívny dialóg s používateľom pri ďalšom pohybe po trase a napríklad určiť, ktoré dokumenty sa majú otvárať pri aktivácii úloh spojených s týmto bodom. cesty obchodného procesu.

Mechanizmus obchodných procesov v 1C umožňuje niekoľko typov smerovania.

Pevné. Podnikový proces má mapu, ktorá neobsahuje podmienené a paralelné prechody s pevne definovanými cieľmi pre každý bod trasy. Odmietnutie takýchto obchodných procesov nie je povolené.
Zadarmo. Cieľové body na mape trasy obchodného procesu nie sú nastavené a sú určené programovo alebo interaktívne počas životného cyklu obchodného procesu.
Podmienené. Mapa trasy umožňuje kontrolu podmienok a sledovanie príslušných odbočiek. Prechody môžu byť buď binárne (podmienka) alebo viacnásobné (výber možnosti)
Paralelné. Mapa trasy počíta s rozdelením obchodného procesu na paralelné vetvy s možnosťou následného zlučovania (čakania). Podpora obchodného procesu pozdĺž každej z paralelných vetiev prebieha nezávisle, keď sú dokončené príslušné úlohy.

Všetky tieto typy smerovania sa spravidla nachádzajú v skutočných mapách obchodných procesov.

Všeobecná schéma na vytvorenie obchodného procesu v 1C

1. Vytvorte register adries

a. Vytváranie formulárov

2. Vytvorte úlohu

a. Vyplňte záložku Adresovanie
b. Údaje vyplníme údajmi prenášanými medzi úlohami a samotným obchodným procesom
c. Vytváranie formulárov

3. Vytvorte obchodný proces

a. Vyplňte úlohu, detaily, vytvorte formuláre
b. Kreslenie mapy trasy

Funkcie adresovania

Adresovanie sa zvyčajne vzťahuje na objekt, ktorému je priradená konkrétna úloha. Adresovanie môže byť buď rigidné, kedy je adresovaný objekt pridelený pri jeho vytváraní, alebo ľubovoľné, v tomto prípade nie je úlohe priradený konkrétny adresovací objekt, ale napríklad jeho rola, pozícia alebo iná hodnota, ktorá nepriamo naznačuje rozsah adresných objektov, pre ktoré je vytvorená úloha.

Informačný register sa používa na popis pravidiel adresovania. Pri prideľovaní adresovania sa systém riadi meraniami tohto registra, zdroje a detaily samotný systém na adresovanie nevyužíva, hoci v registri môžu byť prítomné. Jedným z rozmerov registra musí byť rozmer, ktorý ukladá konkrétnych umelcov, ďalšie rozmery budú použité na ľubovoľné oslovovanie. Periodicita adresovania nie je momentálne podporovaná na systémovej úrovni. To znamená, že informačný register, ktorý uchováva pravidlá adresovania, by nemal byť pravidelný.

Uveďme jednoduchý príklad: ako objekty oslovovania budeme chápať zamestnancov podniku pracujúcich s programom. Ak pri vytváraní úlohy vopred vieme, pre ktorého zamestnanca je vytvorená, tak je tento zamestnanec uvedený v jej vlastnostiach. Takéto priradenie adresovacieho objektu sa nazýva tvrdé. Ak pri vytváraní úlohy z nejakého dôvodu nie je možné špecifikovať konkrétneho zamestnanca, ale je stále známe, že túto úlohu má vykonať niekto z „Obchodného oddelenia“, potom je toto oddelenie označené ako objekt adresovania. Ktorí zamestnanci nakoniec dostanú túto úlohu, bude závisieť od toho, kto pracuje v ktorom oddelení.

Príklad adresovania: ak je konkrétny adresný objekt (zamestnanec, používateľ systému) určený ako vykonávateľ úlohy pri jej vytváraní, potom bude v každom prípade priradený. Ak nie je určený konkrétny vykonávateľ, prichádza na rad mechanizmus náhodného adresovania. Systém sa riadi korešpondenciou meraní registra. Ak sú v registri adresovania dve dimenzie (jedna pre výkonného umelca a druhá pre nejaký atribút adresovania - napríklad oddelenie), potom sa úloha pridelí všetkým účinkujúcim, pre ktorých sú v registri záznamy s dodatočným adresovaním. atribút.

Niekedy je dôležité vedieť zadávať úlohy interpretom, ktorí spolupracujú s konkrétnymi dodávateľmi a ich kontaktnými osobami. Príklad takejto adresy:

So stanovenými pravidlami adresovania bude Ivanov poverený ako vykonávateľ úloh pre „Mira“ buď s uvedenou kontaktnou osobou „riaditeľ“, alebo ak kontaktná osoba nebude uvedená. Pre prácu s kontaktnou osobou „Skladník“ bude ako vykonávateľ určený „Petrov“.

Keďže úlohy sú vytvárané za účelom ich priradenia konkrétnym vykonávateľom pracujúcim so systémom, je potrebné včas upozorniť užívateľa na výskyt novej úlohy. Na to musí systém „poznať“ prihláseného používateľa. Odkaz na aktuálneho užívateľa musí byť uložený v parametri relácie, ktorého hodnota musí byť inicializovaná pri štarte systému. Navyše, keďže v registri adries môže byť viacero dimenzií, je dôležité, aby systém uviedol, v ktorej z nich je potrebné hľadať užívateľa – vykonávateľa.

Možnosti využitia Business Process Engine.

Mechanizmus obchodných procesov je neoddeliteľnou súčasťou technologickej platformy, čo znamená, že jeho schopnosti môžu byť dostupné pre všetky aplikačné riešenia vytvorené na báze 1C:Enterprise 8. Vo všeobecnosti je mechanizmus podnikových procesov zameraný na zvýšenie efektívnosti vývoja a údržby aplikovaných riešení. Skúsenosti s jeho aplikáciou však ukazujú, že zavádzanie obchodných procesov nad hotové aplikácie spôsobuje určité ťažkosti: často sa musíte znova pozrieť na rozhodnutia o dizajne a niečo prerobiť. To, samozrejme, nie je prekvapujúce - rovnako automatizácia podniku si spravidla vyžaduje revíziu všeobecnej schémy jeho fungovania. Pre efektívnu aplikáciu mechanizmu podnikových procesov je žiaduce, aby model riadenia procesov bol na začiatku zabudovaný do aplikačného riešenia.

Samotný návrh podnikových procesov si vyžaduje nielen znalosť základov konfigurácie 1C:Enterprise, ale aj dobré pochopenie predmetnej oblasti a špecifických potrieb zákazníka. Mechanizmus obchodného procesu v skutočnosti stimuluje zapojenie špecialistov kvalitatívne inej úrovne do navrhovania a konfigurácie špecifických aplikačných systémov - obchodných analytikov, konzultantov, ako aj manažérov zákazníkov. Pozitívny efekt mechanizmu biznis procesov na klienta sa navyše prejavuje aj vtedy, keď sa priamo nepodieľa na návrhu biznis procesov, ale aplikuje len niekým vyvinuté schémy. Schopnosť formálne popísať akcie systému a prezentovať ich štruktúru vo vizuálnej podobe umožňuje zákazníkovi lepšie pochopiť logiku riešenia vrátane sledovania správnosti zadanej úlohy vývojárovi.

Hovoríme teda o ďalšom kľúčovom smere vo vývoji aplikačných riešení 1C:Enterprise – zvyšovaní úrovne ich ovládateľnosti. Použitie mechanizmu podnikových procesov umožňuje zhromažďovať kvalitatívne odlišné informácie o fungovaní systému riadenia podniku, na základe ktorých môžu manažéri vykonávať objektívnu analýzu efektívnosti fungovania organizácie ako celku a jej jednotlivých zamestnancov. Tento mechanizmus vám umožňuje presunúť zameranie z účtovných úloh na riadenie podniku ako celku.

Vývojári a používatelia sa môžu dozvedieť viac o mechanizme obchodných procesov implementovanom v 1C:Enterprise 8 pomocou demo konfigurácie distribuovanej na disku Information Technology Support (ITS). Existuje niekoľko jednoduchých obchodných procesov („Predaj tovaru“, „Objednávka“ a „Dohoda“ atď.), ktoré ukazujú rôzne možnosti praktického využitia tohto mechanizmu.

Poznámka pre programátora.

Objednávka vykonávania spracovateľov obchodných procesov

Tvar: pred vykonaním
Formulár: pred písaním (najskôr na klientovi, potom na serveri)
Modul úlohy: pred vykonaním
Obchodný proces: pred vykonaním
Modul úloh: Za chodu
Modul úloh: pred nahrávaním
Modul úloh: Pri zápise
Obchodný proces: Za chodu
Forma: po zaznamenaní (najskôr na serveri, potom na klientovi)

Interaktívne procedúry sa nespúšťajú v riadenom režime.