az üzleti szabályok Az elsők

nemrégiben kollégáinkkal egy nagy ügyfélszervezet vezető szoftverfejlesztőjével beszélgettünk az ottani jelentős átalakítási erőfeszítések előrehaladásáról. Aggodalmunk az volt, hogy a projektcsapat tagjai betarthatnak-e egy kilenc hónapos határidőt egy nagyszabású prototípus szállítására. Több intenzív hónapot töltöttünk egy átfogó üzleti modell kidolgozásával,és még több hónapnyi rendszertervezés maradt hátra.

ez a vezető fejlesztő nagyon éles—nem egy, hogy kötelezzék el magukat bármilyen választ könnyedén. A leghosszabb ideig, nem mondott semmit, elveszett a gondolat. Végül, szemügyre véve a falakon vakolt részletes üzleti diagramokat, azt mondta: “Ha már elkezdtük volna a kódolást, azt mondanám, hogy egyáltalán nem volt esélyünk. De mivel még nem kezdtük el a kódolást, azt mondanám, hogy az esélyek elég jók.”

ezt többször is át kellett gondolnom, mielőtt megértettem a jelentését. “Ha már elkezdtük volna a kódolást, azt mondanám, hogy egyáltalán nem volt esélyünk.”

tudtam, hogy azt gondolta, hogy maga az alkalmazás kódolása elég kemény lesz. Ez magában foglalna egy szabálymotort, egy világméretű terjesztési hálózatot, grafikus felhasználói felületeket és néhány jelentős köztes szoftvert.

azt mondta, hogy ha kódolás közben meg kell oldaniuk az összes üzleti problémát, soha nem fogják időben—vagy valószínűleg soha. Mivel azonban a projektcsapat előzetesen foglalkozott a nehéz üzleti kérdésekkel (beleértve az üzleti szabályok meghatározását is), úgy gondolta, hogy nagyon jó esélyük van a kód kitöltésére a céldátumig.

nagy mértékben az üzleti szabály megközelítés egyszerűen a megfelelő emberek megfelelő kérdéseinek feltevéséről szól. Csak egy módja van annak, hogy őszintén betartsuk a határidőt-és ez az, hogy először Megoldjuk az üzleti problémát.

üzletközpontú IT

az üzleti rendszerek építésének kezdeti napjaiban az üzleti oldal lényegében hátradőlhetett, és csak hagyta, hogy megtörténjenek. Az automatizálás előnyei annyira meggyőzőek voltak, hogy gyakorlatilag nem lehetett rosszat tenni. Most, minden gyakorlati célból, az üzlet és az informatika elválaszthatatlanul működik. A projektek megvalósításakor logikus lépés lenne a zökkenőmentes üzleti / informatikai projektcsapatok összeállítása, és a követelmények kidolgozása során az üzletközpontú megközelítés követése. Ennek ellenére sok vállalat ma közel sem áll ehhez.

túl gyakran az üzleti oldal még mindig homályos, rosszul fókuszált “követelményeket” állít elő, az informatikai oldal pedig csak egy-két fokkal folytatja a “követelményeket” a programozás felett. Hogyan lehet kiküszöbölni ezt a szakadékot az üzleti szakemberek és az informatikai szakemberek között a követelmények kidolgozásában?

a válasz viszonylag egyszerű. A vállalkozásnak szervezett megközelítésre van szüksége, amely lehetővé teszi az üzleti szakemberek számára a követelmények kidolgozását. Ennek a megközelítésnek olyan ütemtervet kell biztosítania, amely megmutatja, hogyan lehet a megfelelő kérdéseket feltenni a megfelelő dolgokról a megfelelő időben. Üzleti alapú megközelítésre van szükség.

a hagyományos fejlesztési megközelítésekben általában sok minden elveszik az előzetes követelmények tényleges futó rendszerre történő fordításában. De az egyértelmű üzleti szabályok megírása javítja az üzleti oldal és az IT közötti kommunikációt, és hidat biztosít az üzleti elemzés és a rendszertervezés között. Az üzleti szabály megközelítés segít megszüntetni az üzleti és az informatikai oldal közötti követelményszakadékot.

tehát mi az üzleti szabály? Üzleti szempontból ez egy irányelv, amelynek célja a viselkedés befolyásolása vagy irányítása. Az üzleti szabályok szó szerint az üzleti gyakorlatok kódolt ismerete. Informatikai szempontból az üzleti szabály az újrafelhasználható üzleti logika atomi darabja.

bizonyos értelemben mindenki tudja, hogy milyen üzleti szabályok vannak—ezek irányítják vállalkozását a napi műveletek végrehajtásában. Üzleti szabályok nélkül mindig menet közben kell döntéseket hoznia, eseti alapon választva az alternatívák között. Így csinálni a dolgokat nagyon lassú lenne.

a szabályok mindannyiunk számára ismerősek a való életben. Szabályok szerint játszunk, egy szabályrendszeren alapuló jogrendszerben élünk, és szabályokat állítunk fel gyermekeink számára. Az üzleti rendszerek szabályainak gondolata azonban ironikusan idegen a legtöbb informatikai szakember számára. Mondja ki a “szabályokat”, és sok informatikai szakember homályosan gondolkodik a szakértői rendszerekről vagy a mesterséges intelligenciáról. Kevés felismerés van arról, hogy a központi szabályok valójában az alapvető, a vállalkozás napi működése.

nem véletlen, hogy sok üzleti oldalon dolgozó munkavállaló és vezető olyan jól beiskolázta az eljárási nézeteket a követelmények kidolgozására, hogy a szabályokban való gondolkodás idegennek vagy elvontnak tűnhet. Gyakorlatilag minden módszertan bűnös ebben a tekintetben, legyen az üzleti folyamatok újratervezése, rendszerfejlesztés vagy szoftvertervezés.

ez két okból sajnálatos:

1. Bármely szervezett tevékenységre gondolni a szabályok szempontjából valójában nagyon természetes. Képzelje el például, hogy megpróbálja megmagyarázni egy olyan játékot, mint a sakk, a dáma, a baseball vagy a futball, anélkül, hogy elmagyarázná a szabályokat.

2. Az üzleti oldalon dolgozó munkavállalók és vezetők rendelkeznek a jó szabályok létrehozásához szükséges ismeretekkel.

Mintaszabályok

vessen egy pillantást a következő mintaszabályokra, és vegye figyelembe, hogy az üzleti rendszer működési ellenőrzésének minden aspektusát hogyan lehet kezelni a szabályokkal:

• korlátozások: az ügyfél nem helyezhet el háromnál több rush megrendelést a hitelszámlájára.

• időzítés: az ügyfelet archiválni kell, ha az ügyfél 36 egymást követő hónapban nem ad le megrendelést.

a szabályok közvetlenül a feltételekre és tényekre épülnek. A kifejezéseknek—mint az ügyfél, a szállítás és a számla-pontos, egyértelmű meghatározással kell rendelkezniük az üzletben. Például az ügyfél a következőképpen definiálható: “olyan szervezet vagy magánszemély, amely az előző két évben legalább egy fizetett megrendelést adott le.”

a tényeket egyszerű, deklaratív mondatok adják meg, amelyek összekapcsolják a kifejezéseket egy igével vagy igekifejezéssel, például: “az ügyfél megrendeli.”

a “ténymodell” olyan ténymegállapítások összessége, amelyek leírják az üzleti tevékenység eredményeit. A ténymodellnek az adatmodell kezdeti terveként kell szolgálnia, de elsődleges célja az üzleti ismeretek strukturált formában történő rögzítése, amelyet az üzleti oldal dolgozói és vezetői rendelkeznek.

a szabályok lényegében hozzáadják a szavak értelmét kell vagy nem szabad a feltételekhez és tényekhez, mint például: “az 1000 dollár feletti hitelre vonatkozó megrendeléseket nem szabad hitelellenőrzés nélkül elfogadni.”

a Szabályokat világos, egyértelmű, jól strukturált üzleti angol nyelven kell kifejezni, kezdve egy kifejezett témával. A szabályok nem lehetnek bolyhosak vagy hiányzó tények. A szabályok minősíthetők ,mint például: “a szállítmányt biztosítani kell, ha a szállítmány értéke meghaladja az 500 dollárt.”A szabályok magukban foglalhatják az időzítési kritériumokat is, mint például: “a hallgatónak legalább két kurzusra kell beiratkoznia a regisztráció befejezéséig.”

szabály függetlenség

a vállalkozás nagyon hasonlít egy emberi testre. A tudás (kifejezés és tény) szerkezete olyan, mint a csontváz; a folyamatok az erős izmok; a szabályok pedig az idegrendszer, amely irányítja a másik kettőt. Mindhárom lényeges és összefügg egymással. De az üzleti szabályokat el kell különíteni a másik kettőtől. E megközelítés egyik alapelve, hogy a szabályok függetlenek a folyamatoktól és eljárásoktól. Ennek a “szabályfüggetlenségnek” a béren kívüli előnye a folyamatok hatalmas egyszerűsítése.

az eredmény egy “vékony folyamat”, amely sok informatikai szakember régóta célja. Ha kivesszük a Szabályokat a folyamatokból, akkor viszonylag egyszerű folyamatokat hozhatunk létre, amelyek szükség esetén megváltoztathatók.

a National Football League-ben, ha egy játék nem működik egy csapat számára, akkor néhány játékon belül eltűnik a játékkönyvéből. A színdarabok lényegében eldobhatók. Hasonlóképpen, a vállalkozásoknak saját eljárásaikat eldobhatónak kell tekinteniük—elég olcsónak ahhoz, hogy könnyen eldobják és kicseréljék, amikor az eljárások már nem működnek jól.

az eldobható eljárások elengedhetetlenek ahhoz, hogy a vállalkozás alkalmazkodóképes és versenyképes legyen. Ez a megtévesztően egyszerű ötlet—amelyet az üzleti szabályok megközelítése tesz lehetővé-forradalmasíthatja a munka elvégzését és a rendszerek tervezését.

Ronald G. Ross (Addison-Wesley, 2003) Újranyomta a Business Rule Approach alapelvei engedélyével. Ross a Business Rule Solutions LLC társalapítója és igazgatója, valamint a weboldal ügyvezető szerkesztője BRCommunity.com.

könyvtári Ténymodell
ez az ábra egy könyvtár grafikus ténymodelljét mutatja. A szabály megfogalmazása közvetlenül a ténymodellen alapul, amely az alapvető üzleti koncepciók diagramja – a tudásszerkezet. A ténymodell egy első vágott tervet nyújthat arra vonatkozóan, hogy az adatok végül hogyan lesznek rendezve egy adatbázisban. Szabály: Könyvtári kártya csak akkor használható könyv megtekintésére, ha a könyv olyan könyvtár tulajdonában van, amelyre a kártya engedélyezett.