Integrované nástroje

Business Process Tools

Jedny z klíčových nástrojů v tomto informačním systému jsou Business Process Tools, sestávající z řady jednotlivých komponent.

 
Obr.: Business Process Tools

 
Business Process Modeler (BPM)

Business Process Modeler slouží k namodelování skutečných podnikových procesů, které jsou pak přímo převedeny do IS. Tento nástroj umožňuje i zpětnou vazbu IS na Process Modelling, jež zajišťuje identifikaci slabých míst Vašich procesů a příslušných odpovědností.                            

 Vždy aktuální QA-dokumentace

V Business Process Modeleru máte možnost Vaše procesy nejen namodelovat, ale také zdokumentovat přes integrovanou správu dokumentů a rozhraní OLE. Navíc, protože zobrazené procesy plně odpovídají skutečným postupům ve Vaší společnosti, máte k dispozici aktuální QA-dokumentaci.

Terminologie a symbolika

V Business Process Modeleru jsou jednotlivé procesy rozděleny do různých úrovní. Tím se neztrácí přehled a informace o procesech.

Nejvyšší úroveň odpovídá velmi abstraktnímu pohledu na společnost. Jednotlivé skupiny procesů mohou obsahovat skupiny dalších procesů nebo přecházejí do procesů jiných.

 

Obr.: Struktura v Business Process Modeleru

Dílčí procesy se skládají z minimálně jedné, popřípadě libovolně mnoha aktivit. Aktivity představují činnosti v rámci procesu, které musí být na určitém pracovním místě provedeny.

Jednotlivé aktivity se dají opět rozdělit do jedné až n akcí. Akce tvoří vlastní rozhraní s informatikou. Aktivity jsou podle průběhu činností navzájem pospojovány. Za určitých předpokladů mohou být uvnitř jednoho průběhu zapojeny různé cesty.

Jednotlivé akce představují vlastní chod systému. Akce jsou nejmenší možné elementy procesu.

Aktivity ukazují jednotlivé činnosti, které se na pracovním místě provádějí. Pravoúhlý symbol představuje nějakou činnost. Jedinou vyjímkou je rozhodování, které je představováno diamantem. Kruh symbolizuje spojení s jiným dílčím procesem. Tento dílčí proces může být zcela definován v jiném procesu.

Akce se dělí na následující druhy:

  • Makroakce
    žádná interakce s uživatelem, používá se napříkladpro určení default hodnoty
  • Akce pro tvorbu masek
    uživatel vyplňuje masku podle určitých pravidel
  • Akce pro tvorbu dokladu
    uživatel musí vyplnit doklad
  • Rozhodovací akce
    průběh se rozděluje v závislosti na určitých hodnotách
  • Vstupní konektor
    spojení z jiné akce, také vně procesu
  • Výstupní konektor
    spojení k jiné akci, také vně procesu
  • Akce pro potvrzení
    elektronický podpis
  • Externí akce
    připnutí externího souboru (např. *.doc)
  • Akce variace
    např. zahraniční pobočka pracuje dle jiné větve v procesu (odlišná legislativa)

Executer a Manager úkolů


Executer interpretuje všechna pravidla a makra vytvořená modelerem. Je také odpovědný za logickou správnost, zpracování jednotlivých aktivit ve správném pořadí atd. Celý systém úkolů je spravován Executerem.

Obr.: Executer a Manager úkolů

Executer, který je aktivován z Workplace hledá požadovaný proces. Aktivity se v rámci procesu provádějí podle pořadí stanoveném v Modeleru. Jakmile je ukončena jedna aktivita, podmínky k tomu byly rovněž definovány Modelerem, je vyvolána další. Postup trvá tak dlouho, dokud není proveden celý proces. Ve většině případů hlásí při ukončení procesu Manager úkolů nový úkol, který se zanese do seznamu úkolů odpovídající osoby nebo skupiny osob.

Příklad pro objasnění funkce Executeru:

Ve společnosti «Velo AG» jsou došlé dodavatelské faktury nejprve zaevidovány a orazítkovány účetním oddělením, poté dále předány pověřené osobě k podpisu a nakonec zaúčtovány. V tomto případě se jedná o tři různé dílčí procesy.

Pomocí zástupce na pracovní ploše MIRACLE V se zaktivuje proces «Zaevidovat fakturu». První aktivita spustí masku zaevidování a provede potřebné inicializace. Další aktivita vlastní zaevidování je interaktivní s uživatelem. Ukončí-li uživatel aktivitu zaevidování se všemi potřebnými údaji, považuje se aktivita za úspěšně uzavřenou. Neboť toto byla poslední definovaná aktivita, považuje se také proces «Zaevidovat fakturu» za uzavřený. Správce úkolů nyní vygeneruje úkol pro osobu pověřenou podepisovat.

Tato osoba pak může pomocí seznamu úkolů aktivovat proces «Udělit podpis». Bude-li také tento proces úspěšně ukončen, vznikne skupině osob účetního oddělení nový úkol a to zaúčtování. Je-li proces přerušen, jsou všechny aktivity v rámci procesu navráceny.

Analyzer

Analyzer zobrazuje postupy v systému a analyzuje je podle metod operačního výzkumu. Kromě jiného je zde možnost zjistit, jak dlouho se kumulují úkoly na jednotlivých místech. Tak mohou být upravena kritická místa a průběhy, které jsou nevhodné.

Simulator

V rámci Business Process Modeleru mohou být provedeny simulace procesů. Tím se dají pomocí analyzeru modelovat a následně simulovat modely různých společností, dokud nebude dosaženo optimálního průběhu.

Object Oriented Model Studio (OOMS)

Obr.: Obsah OOMS

V OOMS jsou soustředěny všechny Design-Tools. Jelikož jsou k dispozici přednastavené modely společností, které již ztvárňují řadu typů obchodních a výrobních společností, provádí se zpravidla v OOMS jen porovnání vhodného modelu se skutečnými procesy ve Vaší společnosti a následné upravení tohoto modelu.

Class Master

Class Master je centrální definiční nástroj všech tříd. Pomocí Class Masteru se odvozením od základních tříd sestavují jednotlivé třídy v Repository a vzájemně se propojují.

Obr.: Class Master - nástroj pro stavbu tříd

Pořízení, změna atributů a metod třídy se provádí prostřednictvím Class Masteru, který je schopen přímo aktivovat jiné nástroje k podpoře této práce. Má-li být například změněna určitá metoda, máte umožněn přístup přímo k nástroji Makrojazyk/Debugger.

V podstatě existují dva druhy vazeb mezi třídami. U prvního druhu se odvozují třídy od sebe. Tento vztah odpovídá objektově orientované technologii a jedná se o hierarchickou vazbu. Druhý způsob vytváří prakticky libovolné spojení mezi jednotlivými třídami. Druhý způsob vazeb odpovídá vazbám sítě.

Transaction Processor

Tento nástroj je zodpovědný za knihování a uchování pravidel pohybových dat. Pohybová data se pořizují ve formě dokladů a ukládají se. Pojem doklad má v souvislosti s miracle xrp rozšířený význam. Každá transakce představuje určitý doklad. Například příjem na sklad je transakce a proto má také doklad.

Obr.: Transaction Processor - zaknihování pravidel pohybových dat

Doklady se shromažďují v žurnálech. Přitom může být jeden doklad případně zaknihován do různých žurnálů. Jaký doklad náleží ke kterému žurnálu, je předmětem definice informačního systému.

Žurnály tvoří základnu pro souhrn. Z dokladů je možno vždy znovu sestavit žurnály a souhrny nebo dodatečně vytvořit žurnály se souhrny.

Form Manager

Systém masek se skládá ze tří součástí:

  • Runtime-Tool, interpretuje a vykonává definice masek.
  • Generátor masek, na základě definic automaticky vytváří/generuje (průběhy, dotazy, datové objekty) návrhy masek pro každého uživatele. Na základě definovaných maker se tak automaticky vytvoří nejvhodnější ovládací prvky.
  • Editor masek, v němž mohou být jednotlivé masky manuálně přepracovány a rozčleněny.

Development System

  • Help Desk
    nástroj pro dálkový přístup k pracovním stanicím. Má-li uživatel problém, administrátor se připojí na dálku k jeho stanici a může upravit např. pracovní plochu uživatele nebo poradit s nastavením.
  • Import Task Designer
    nástroj pro import dat do miracle xrp. Načítat lze soubory typu *.txt nebo *.dbf

V IS miracle xrp je integrován zvláště výkonný makrojazyk pro miracle xrp, ve kterém jsou vytvořeny vlastní metody aplikací. Je to objektově orientovaný 32-bitový programovací jazyk. Kromě Multithreadingu je také podporována celá OLE 2-automatizace. Makrojazyk pro miracle xrp je v porovnání s Visual Basic rozsáhlejší. V makrojazyku je integrován obsáhlý Debugger (program Trace Master).

Obr.: Ukázka používaného makrojazyka

Report Generator

Nástroj Report Generator užívá externí aplikaci Report Smith, jež je do systému miracle xrp vestavěna. Poskytuje potřebnou funkcionalitu a navíc přináší výhodu, že bývá nasazena rovněž v jiných známých software (např. Visual Basic).

Query System

V Query systému se definují všechny druhy dotazů na databázi (datové třídy). Query systém je úzce propojen s Form Manager, převádí dotazy na optimalizovaný SQL příkaz, který je poslán proti databázi. Výsledek může být zobrazen rozdílnými formami
v miracle xrp nebo i v jiné aplikaci.

Zde uvádíme příklad dotazu (Query) na datovou třídu Condition (podmínky). V levé části je seznam všech nadefinovaných dotazů, v pravé části seznam atributů jednotlivých dotazů.

Obr.: Příklad dotazu na datovou třídu Condition

MaskDesigner (Design masek)

Slouží k vytvoření a úpravě masek. Je k dispozici široká škála nástrojů známých z vizuálního programování (např. Visual Basic).

Concentrator

Aby byly některé informace rychle k dispozici, jsou redundance ve formě souhrnů potřebné a smysluplné. Translator souhrnů vytváří Triggers nebo tabulky, se kterými Transaction Processor komunikuje a na základě zápisů vytváří souhrny.

Souhrny se zakládají na určitém žurnálu. Každá transakce (doklad) probíhá Concentrátorem. Tak je zajištěno, že každá změna pohybových dat je zohledněna také při souhrnu. V závislosti na prioritě se souhrny vytváří okamžitě nebo později.

Database Interface

Database Interface slouží jako rozhraní mezi Runtime-systémem a SQL-databází. Rozhraní je rozděleno do dvou úrovní. To umožňuje bezproblémovou podporu různých SQL-databází. Součást tvořící vyšší úroveň rozhraní převádí speciální SQL-příkazy systému miracle xrp do standardu SQL.

Communication Manager

miracle xrp podporuje standardní rozhraní MAPI a TAPI. Do budoucna se počítá s možností například zasílání E-mailů nebo rozesílání zpráv na Pager.


 

Zpět na začátek strany. Ptejte se přímo nás.

 

© 1999 Copyright: Tradia, s.r.o., Kartouzská 4/200, Praha 5, tel. 02-57317220, fax 02-57317229 E-Mail na správce webu