forretningsregler kommer først

for nylig talte kolleger og jeg med hovedprogramudvikleren i en stor klientorganisation om fremskridt med en større ombygningsindsats der. Vores bekymring var, om projektteammedlemmerne kunne overholde en frist omkring ni måneder ud for at levere en storstilet prototype. Vi havde lige brugt flere intensive måneder på at udvikle en omfattende forretningsmodel, og de havde stadig flere måneders systemdesign tilbage at gennemføre.

denne chefudvikler er meget skarp—ikke en til at forpligte sig til noget svar let. I længst tid sagde han intet, tabt i tankerne. Til sidst sagde han, “hvis vi allerede var begyndt at kode, ville jeg sige, at vi slet ikke havde nogen chance. Men da vi ikke er begyndt at kode endnu, vil jeg sige, at chancerne er ret gode.”

jeg var nødt til at køre det flere gange i mit sind, før jeg fik hans mening. “Hvis vi allerede var begyndt at kode, ville jeg sige, at vi slet ikke havde nogen chance.”

jeg vidste, at han troede, at selve applikationskodningen ville være ret hård. Det ville indebære at bruge en regler motor, et verdensomspændende distributionsnet, grafiske brugergrænseflader og nogle betydelige mellemvare.

han sagde, at hvis de skulle løse alle forretningsproblemer under kodning, ville de aldrig trække det ud i tide—eller sandsynligvis nogensinde. Men da projektteamet tacklede de hårde forretningsproblemer på forhånd (herunder angivelse af forretningsreglerne), troede han, at de havde en ret god chance for at udfylde koden inden måldatoen.

i vid udstrækning handler forretningsregelmetoden simpelthen om at stille de rigtige spørgsmål fra de rigtige mennesker. Der er kun en måde at ærligt overholde en deadline på—og det er først at løse forretningsproblemet.

forretningsdrevet IT

i de tidlige dage med at opbygge forretningssystemer kunne forretningssiden i det væsentlige læne sig tilbage og bare lade dem ske. Fordelene ved automatisering var så overbevisende, at du næsten ikke kunne gøre noget forkert. Nu, til alle praktiske formål, fungerer forretning og IT uadskilleligt. Når man gennemfører projekter, ville det logiske skridt være at sammensætte sømløse forretnings-/IT-projektteam og få dem til at følge en forretningsorienteret tilgang til udvikling af krav. Alligevel er mange virksomheder ikke tæt på at gøre det i dag.

alt for ofte producerer forretningssiden stadig uklare, Dårligt fokuserede “krav”, og IT-siden fortsætter med at gøre “krav” kun et hak eller to over programmeringen. Hvordan kan denne kløft mellem forretningsfolk og IT-fagfolk i udviklingen af krav elimineres?

svaret er relativt ligetil. Virksomheden har brug for en organiseret tilgang, der gør det muligt for forretningsfolk at drive udviklingen af krav. Denne tilgang skal give en køreplan, der viser, hvordan man stiller de rigtige slags spørgsmål om de rigtige ting på de rigtige tidspunkter. Det, der er brug for, er en forretningsdrevet tilgang.

i traditionelle udviklingsmetoder går meget normalt tabt i oversættelsen af forhåndskrav til det faktiske kørende system. Men at skrive et sæt klare forretningsregler forbedrer kommunikationen mellem forretningssiden og IT og giver en bro mellem forretningsanalyse og systemdesign. Forretningsregelmetoden hjælper med at lukke kravgabet mellem forretningssiden og IT-siden.

så hvad er en forretningsregel? Fra forretningsmæssigt synspunkt er det et direktiv, der har til formål at påvirke eller styre adfærd. Forretningsregler er bogstaveligt talt den kodede viden om din forretningspraksis. Fra et IT-synspunkt er en forretningsregel et atomart stykke genanvendelig forretningslogik.

på en måde ved alle, hvad forretningsregler er—de er det, der styrer din virksomhed i at drive sin daglige drift. Uden forretningsregler skal du altid træffe beslutninger i farten og vælge mellem alternativer fra sag til sag. At gøre tingene på den måde ville være meget langsomt.

regler er kendt for os alle i det virkelige liv. Vi spiller spil efter regler, vi lever under et retssystem baseret på et sæt regler, og vi sætter regler for vores børn. Alligevel er ideen om regler i forretningssystemer ironisk nok fremmed for de fleste IT-fagfolk. Sig “regler”, og mange IT-fagfolk tænker vagt på ekspertsystemer eller kunstig intelligens. Der er lidt anerkendelse af, hvordan centrale regler faktisk er til de grundlæggende, daglige drift af virksomheden.

ikke tilfældigt er mange forretningsarbejdere og ledere blevet så godt indoktrinerede i proceduremæssige synspunkter for at udvikle krav, at tænkning med hensyn til regler kan virke fremmed eller abstrakt. Stort set alle metoder er skyldige i denne henseende, hvad enten det drejer sig om re-engineering af forretningsprocesser, systemudvikling eller programmeldesign.

dette er uheldigt af to grunde:

1. At tænke på enhver organiseret aktivitet med hensyn til regler er faktisk meget naturlig. Forestil dig for eksempel at prøve at forklare et spil som skak, brikker, baseball eller fodbold uden at forklare reglerne.

2. Medarbejdere og ledere på virksomhedssiden har den viden, der kræves for at skabe gode regler.

Sample Rules

Tag et kig på de eksempler på regler, der følger, og læg mærke til, hvordan alle aspekter af operationel kontrol i et forretningssystem kan løses ved regler:

• begrænsninger: en kunde må ikke placere mere end tre rush ordrer opkrævet på sin kreditkonto.

* heuristik: En kunde med foretrukken status skal have sine ordrer udfyldt med det samme.

• beregninger: en kundes årlige ordremængde skal beregnes som det samlede salg lukket i løbet af virksomhedens regnskabsår.

• Indledning: en kunde skal betragtes som foretrukket, hvis kunden placerer mere end fem ordrer over $1.000.

• Timing: en kunde skal arkiveres, hvis kunden ikke afgiver ordrer i 36 på hinanden følgende måneder.

• udløsere: “Send forhåndsmeddelelse” skal udføres for en ordre, når ordren sendes.

regler bygger direkte på vilkår og fakta. Vilkår – som kunde, forsendelse og faktura—skal have en præcis, entydig definition i virksomheden. For eksempel kan kunden defineres som: “en organisation eller individuel person, der har afgivet mindst en betalt ordre i løbet af de foregående to år.”

fakta er givet ved enkle, deklarative sætninger, der forbinder udtrykkene med et verb eller verb-sætning, såsom ” kunde placerer ordre.”

en “faktamodel” er et sæt faktaerklæringer, der beskriver resultaterne af en forretningsdrift. En faktamodel skal tjene som en indledende plan for en datamodel, men dens primære formål er at fange viden om virksomheden i en struktureret form, destilleret fra de forretningsmæssige medarbejdere og ledere, der besidder den.

regler tilføjer i det væsentlige betydningen af ordene skal eller må ikke til vilkårene og fakta, som i, “ordrer på kredit over $1.000 må ikke accepteres uden en kreditcheck.”

regler skal udtrykkes i klar, utvetydig, velstruktureret forretningsengelsk, begyndende med et eksplicit emne. Regler bør ikke have nogen fluff og ingen manglende fakta. Regler kan kvalificeres, som i “en forsendelse skal være forsikret, hvis forsendelsesværdien er større end $500.”Og regler kan omfatte tidskriterier, som i “en studerende skal være tilmeldt mindst to kurser ved afslutningen af registreringen.”

regel uafhængighed

en virksomhed er meget som en menneskelig krop. Viden (term og fakta) struktur er som skeletet; processerne er de magtfulde muskler; og reglerne er nervesystemet, der styrer de to andre. Alle tre er væsentlige og indbyrdes forbundne. Men forretningsregler skal være adskilt fra de to andre. Et grundlæggende princip i denne tilgang er, at reglerne er uafhængige af processer og procedurer. En yderligere fordel ved denne “regeluafhængighed” er en enorm forenkling i processerne.

resultatet er en “tynd proces”, et mangeårigt mål for mange IT-fagfolk. Ved at tage reglerne ud af processerne kan du producere processer, der er relativt enkle og kan ændres, når behovet opstår.

i National Football League, hvis et spil ikke virker for et hold, vil det være væk fra sin playbook inden for et par spil. Stykkerne er i det væsentlige kast. Tilsvarende skal virksomheder se deres egne procedurer som kast—billige nok til at kassere og erstatte let, når procedurerne ikke længere fungerer godt.

Smideprocedurer er et must for virksomheden at være tilpasningsdygtig og konkurrencedygtig. Denne vildledende enkle ide – muliggjort af forretningsreglerne—kan revolutionere den måde, arbejdet udføres på, og systemer er designet.

genoptrykt med tilladelse fra Principles of the Business Rule Approach, af Ronald G. Ross (Addison, 2003). Ross er medstifter og rektor for Business rule Solutions LLC og chefredaktør på hjemmesiden BRCommunity.com.

Biblioteksfaktamodel
dette diagram viser en grafisk faktamodel for et bibliotek. Regelens ordlyd er baseret direkte på faktamodellen, som er et diagram over grundlæggende forretningskoncepter – en videnstruktur. En faktamodel kan og bør give en første-cut blueprint for, hvordan data til sidst vil blive organiseret i en database. REGEL: Et bibliotekskort kan kun bruges til at tjekke en bog ud, hvis bogen ejes af et bibliotek, som kortet er godkendt til.