obchodní pravidla jsou na prvním místě

Nedávno jsme s kolegy mluvili s hlavním vývojářem softwaru ve Velké klientské organizaci o pokroku v rozsáhlém re-inženýrském úsilí. Naším zájmem bylo, zda by členové projektového týmu mohli dodržet lhůtu asi devět měsíců pro dodání velkého prototypu. Právě jsme strávili několik intenzivních měsíců vývojem komplexního obchodního modelu a ještě jim zbývalo několik měsíců návrhu systému.

tento hlavní vývojář je velmi ostrý-nikdo, kdo by se zavázal k jakékoli odpovědi lehce. Nejdéle nic neřekl, ztratil v myšlenkách. Konečně, při pohledu na podrobné obchodní diagramy omítnuté na stěnách všude kolem, řekl: “kdybychom už začali kódovat.”, řekl bych, že jsme neměli vůbec šanci. Ale protože jsme ještě nezačali kódovat, řekl bych, že šance jsou docela dobré.”

musel jsem to několikrát spustit v mé mysli, než jsem zachytil jeho význam. “Kdybychom už začali kódovat, řekl bych, že jsme neměli vůbec šanci.”

věděl jsem, že si myslí, že samotné kódování aplikace bude docela těžké. To by zahrnovalo použití pravidla motoru, celosvětová distribuční síť, grafické uživatelské rozhraní a některé významné middleware.

říkal, že kdyby museli vyřešit všechny obchodní problémy při kódování, nikdy by to nestáhli včas – nebo pravděpodobně vůbec. Protože však projektový tým řešil těžké obchodní problémy předem (včetně upřesnění obchodních pravidel), myslel si, že mají docela dobrou šanci dokončit kód do cílového data.

ve velké míře je přístup k pravidlům podnikání jednoduše o kladení správných otázek správným lidem. Existuje pouze jeden způsob, jak čestně dodržet termín—a to je nejprve vyřešit obchodní problém.

Business-Driven IT

v prvních dnech budování obchodních systémů by obchodní strana mohla v podstatě sedět a nechat je stát. Výhody automatizace byly tak přesvědčivé, že jste nemohli udělat prakticky nic špatného. Nyní, pro všechny praktické účely, podnikání a IT fungují neoddělitelně. Při provádění projektů by pak logickým krokem bylo sestavit bezproblémové obchodní / it projektové týmy a nechat je sledovat obchodně orientovaný přístup k rozvoji požadavků. Přesto se k tomu dnes mnoho společností ani zdaleka nepřibližuje.

až příliš často, obchodní strana stále produkuje fuzzy, špatně zaměřené “požadavky”, a IT strana pokračuje dělat “požadavky” jen zářez nebo dva nad programování. Jak lze tuto mezeru mezi obchodními profesionály a IT profesionály při vývoji požadavků odstranit?

odpověď je poměrně přímočará. Podnik potřebuje organizovaný přístup, který umožňuje obchodním profesionálům řídit vývoj požadavků. Tento přístup musí poskytnout cestovní mapu, která ukazuje, jak klást správné druhy otázek o správných věcech ve správný čas. Co je potřeba, je přístup založený na podnikání.

v tradičních vývojových přístupech se obvykle mnoho ztratí v překladu počátečních požadavků na skutečný běžící systém. Ale psaní souboru jasných obchodních pravidel zlepšuje komunikaci mezi obchodní stranou a IT a poskytuje most mezi obchodní analýzou a návrhem systému. Přístup k pravidlům podnikání pomáhá uzavřít mezeru v požadavcích mezi obchodní stranou a IT stranou.

co je tedy obchodní pravidlo? Z obchodního hlediska je to směrnice, která má ovlivňovat nebo řídit chování. Obchodní pravidla jsou doslova zakódované znalosti vašich obchodních praktik. Z hlediska IT je obchodní pravidlo atomovou součástí opakovaně použitelné obchodní logiky.

svým způsobem každý ví, jaká jsou obchodní pravidla—jsou to, co řídí vaše podnikání při běžném provozu. Bez obchodních pravidel byste se vždy museli rozhodovat za běhu a vybírat mezi alternativami případ od případu. Dělat věci tímto způsobem by bylo velmi pomalé.

pravidla jsou v reálném životě známa všem. Hrajeme hry podle pravidel, žijeme v právním systému založeném na souboru pravidel a stanovujeme pravidla pro naše děti. Přesto je myšlenka pravidel v obchodních systémech ironicky cizí většině IT profesionálů. Řekněte “pravidla” a mnoho IT profesionálů si nejasně myslí o expertních systémech nebo umělé inteligenci. Je málo známo, jak jsou ve skutečnosti Ústřední pravidla pro základní, každodenní provoz podniku.

ne náhodou se mnoho pracovníků a manažerů na straně podnikání stalo tak dobře indoktrinovanými v procesních názorech na vývoj požadavků, že myšlení z hlediska pravidel se může zdát cizí nebo abstraktní. V tomto ohledu je vinna prakticky každá metodika, ať už jde o re-inženýrství obchodních procesů, vývoj systému nebo návrh softwaru.

to je nešťastné ze dvou důvodů:

1. Přemýšlení o jakékoli organizované činnosti z hlediska pravidel je ve skutečnosti velmi přirozené. Představte si například, že se snažíte vysvětlit hru jako šachy, dáma, baseball nebo fotbal, aniž byste vysvětlili pravidla.

2. Pracovníci a manažeři na obchodní straně mají znalosti potřebné k vytvoření dobrých pravidel.

vzorová pravidla

podívejte se na vzorová pravidla, která následují, a všimněte si, jak lze každý aspekt provozní kontroly v obchodním systému řešit pravidly:

* omezení: zákazník nesmí na svůj kreditní účet účtovat více než tři spěšné příkazy.

* heuristika: Zákazník s preferovaným statusem by měl mít své objednávky okamžitě vyplněny.

* výpočty: roční objem objednávky zákazníka musí být vypočítán jako celkový prodej uzavřený během fiskálního roku společnosti.

* závěr: zákazník musí být považován za preferovaného, pokud zákazník zadá více než pět objednávek nad $ 1,000.

* načasování: zákazník musí být archivován, pokud zákazník neučiní žádné objednávky po dobu 36 po sobě jdoucích měsíců.

* spouštěče: “odeslat předběžné oznámení” musí být provedeno pro objednávku, když je objednávka odeslána.

pravidla staví přímo na pojmech a faktech. Pojmy-jako zákazník, zásilka a faktura-by měly mít v podnikání přesnou a jednoznačnou definici. Například zákazník může být definován jako: “organizace nebo jednotlivá osoba, která zadala alespoň jednu placenou objednávku během předchozích dvou let.”

fakta jsou dána jednoduchými deklarativními větami, které spojují pojmy se slovesem nebo slovesnou frází, jako například ” zákazník zadává objednávku.”

“faktový model” je soubor faktických prohlášení, které popisují výsledky obchodní operace. Faktový model by měl sloužit jako počáteční plán pro datový model, ale jeho primárním účelem je zachytit znalosti o podnikání ve strukturované podobě, destilované z pracovníků na straně podniku a manažerů, kteří jej vlastní.

pravidla v podstatě přidávají smysl slov musí nebo nesmí k podmínkám a faktům, jako v: “objednávky na úvěr nad $ 1,000 nesmí být přijaty bez kontroly kreditu.”

pravidla by měla být vyjádřena v jasné, jednoznačné, dobře strukturované obchodní angličtině, počínaje explicitním předmětem. Pravidla by neměla mít žádné chmýří a žádná chybějící fakta. Pravidla mohou být kvalifikována, jako v ” zásilka musí být pojištěna, pokud je hodnota zásilky vyšší než 500 USD.”A pravidla mohou zahrnovat kritéria načasování, jako v” student musí být zapsán do nejméně dvou kurzů do konce registrace.”

nezávislost pravidel

podnikání je velmi podobné lidskému tělu. Struktura znalostí (termín a skutečnost) je jako kostra; procesy jsou silné svaly; a pravidla jsou nervový systém, který ovládá další dva. Všechny tři jsou nezbytné a vzájemně propojené. Obchodní pravidla by však měla být oddělena od ostatních dvou. Základním principem tohoto přístupu je, že pravidla jsou nezávislá na procesech a postupech. Okrajovou výhodou této “nezávislosti vlády” je obrovské zjednodušení procesů.

výsledkem je “tenký proces”, dlouhodobý cíl mnoha IT profesionálů. Vyjmutím pravidel z procesů můžete vytvářet procesy, které jsou relativně jednoduché a lze je podle potřeby změnit.

v národní fotbalové lize, pokud hra nefunguje pro tým, bude během několika her pryč ze své příručky. Hry jsou v podstatě throwaways. Podobně, podniky musí vnímat své vlastní postupy jako throwaways – dostatečně levné, aby se odhodily a snadno nahradily, když postupy již nefungují dobře.

postupy odhození jsou nutností pro to, aby byl podnik přizpůsobivý a konkurenceschopný. Tento zdánlivě jednoduchý nápad-umožněný přístupem k obchodním pravidlům-může způsobit revoluci ve způsobu práce a navrhování systémů.

Přetištěno se svolením principů přístupu k pravidlům podnikání Ronaldem G. Rossem (Addison-Wesley, 2003). Ross je spoluzakladatelem a ředitelem společnosti Business Rule Solutions LLC a výkonným editorem webu BRCommunity.com.

Knihovna Fact Model
tento diagram ukazuje grafický fakt model pro knihovnu. Formulace pravidla je založena přímo na faktovém modelu , který je schématem základních obchodních konceptů-znalostní struktury. Model faktů může a měl by poskytnout plán prvního řezu, jak budou data nakonec uspořádána v databázi. PRAVIDLO: Knihovní průkaz lze použít k prohlídce knihy, pouze pokud je kniha ve vlastnictví knihovny, pro kterou je karta oprávněna.