Forretningsregler Kommer Først

nylig snakket kolleger Og Jeg med sjefsprogramvareutvikleren på en stor klientorganisasjon om fremgang på en stor re-engineering innsats der. Vår bekymring var om prosjektgruppemedlemmene kunne møte en frist noen ni måneder ut for å levere en storskala prototype. Vi hadde nettopp brukt flere intensive måneder på å utvikle en omfattende forretningsmodell, og de hadde fortsatt flere måneder med systemdesign igjen å fullføre.

denne sjefsutvikleren er veldig skarp-ikke en å forplikte seg til noe svar lett. For lengst mens, han sa ingenting, tapt i tankene. Til slutt, eyeing de detaljerte forretningsdiagrammer pusset på veggene rundt, sa han: “Hvis vi allerede hadde startet koding, ville jeg si at vi hadde ingen sjanse i det hele tatt. Men siden vi ikke har startet koding ennå, vil jeg si at sjansene er ganske gode.”

jeg måtte løpe det flere ganger i tankene mine før jeg fikk hans mening. “Hvis vi allerede hadde startet koding, ville jeg si at vi ikke hadde noen sjanse i det hele tatt.”

jeg visste at han trodde at applikasjonskodingen selv skulle bli ganske tøff. Det ville innebære å bruke en regelmotor, et verdensomspennende distribusjonsnettverk, grafiske brukergrensesnitt og noen betydelig mellomvare.

Han sa at hvis de måtte løse alle forretningsproblemene mens de kodet, ville de aldri trekke det av i tide – eller sannsynligvis noensinne. Men siden prosjektgruppen taklet de tøffe forretningsproblemene på forhånd (inkludert å spesifisere forretningsreglene), trodde han at de hadde en ganske god sjanse til å fullføre koden innen måldatoen.

i stor grad handler forretningsregeltilnærmingen ganske enkelt om å stille de riktige spørsmålene til de riktige menneskene. Det er bare en måte å ærlig møte en frist-og det er å løse forretningsproblemet først.

Forretningsdrevet IT

i de tidlige dagene med å bygge forretningssystemer, kunne forretningssiden i hovedsak lene seg tilbake og bare la dem skje. Fordelene med å automatisere var så overbevisende at du kunne gjøre nesten ingen feil. Nå, for alle praktiske formål, opererer virksomheten og IT uadskillelig. Når du foretar prosjekter, ville det logiske trinnet være å sette sammen sømløse forretnings – / IT-prosjektteam og få dem til å følge en forretningsorientert tilnærming til å utvikle krav. Likevel er mange selskaper ikke i nærheten av å gjøre det i dag.

altfor ofte produserer forretningssiden fortsatt fuzzy, dårlig fokuserte “krav”, OG IT-siden fortsetter å gjøre “krav” bare et hakk eller to over programmering. Hvordan kan dette gapet mellom forretningsfolk og IT-fagfolk i å utvikle krav elimineres?

svaret er relativt enkelt. Virksomheten trenger en organisert tilnærming som gjør det mulig for forretningsfolk å drive utviklingen av krav. Denne tilnærmingen må gi et veikart som viser hvordan du stiller de riktige spørsmålene om de riktige tingene til rett tid. Det som trengs er en forretningsdrevet tilnærming.

i tradisjonelle utviklingsmetoder går mye vanligvis tapt i oversettelsen av forhåndskrav til det faktiske løpesystemet. Men å skrive et sett med klare forretningsregler forbedrer kommunikasjonen mellom forretningssiden OG IT, og gir en bro mellom forretningsanalyse og systemdesign. Business regel tilnærming bidrar til å lukke krav gapet mellom virksomheten siden OG IT-siden.

så hva er en forretningsregel? Fra forretningssynspunktet er det et direktiv som er ment å påvirke eller veilede atferd. Forretningsregler er bokstavelig talt kodet kunnskap om din forretningspraksis. Fra ET IT-synspunkt er en forretningsregel et atomisk stykke gjenbrukbar forretningslogikk.

på en måte vet alle hva forretningsregler er—de er det som styrer virksomheten din i å drive sin daglige drift. Uten forretningsregler må du alltid ta beslutninger i fly, velge mellom alternativer fra sak til sak. Å gjøre ting på den måten ville være veldig sakte.

Regler er kjent for oss alle i det virkelige liv. Vi spiller spill etter regler, vi lever under et rettssystem basert på et sett med regler, og vi setter regler for våre barn. Likevel er ideen om regler i forretningssystemer ironisk fremmed for DE FLESTE IT-fagfolk. Si “regler” og MANGE IT-fagfolk tenker vagt på ekspertsystemer eller kunstig intelligens. Det er liten anerkjennelse av hvor sentrale regler faktisk er for den grunnleggende, daglige driften av virksomheten.

ikke tilfeldigvis har mange bedriftsarbeidere og ledere blitt så godt indoktrinert i prosessuelle synspunkter for å utvikle krav som tenker i form av regler kan virke utenlandsk eller abstrakt. Nesten hver metodikk er skyldig i denne forbindelse, enten for forretningsprosesser, systemutvikling eller programvaredesign.

dette er uheldig av to grunner:

1. Å tenke på organisert aktivitet når det gjelder regler er faktisk veldig naturlig. For eksempel, tenk å prøve å forklare et spill som sjakk, dam, baseball eller fotball uten å forklare reglene.

2. Bedriftsansatte og ledere har kunnskapen som trengs for å skape gode regler.

Utvalgsregler

Ta en titt på utvalgsreglene som følger, og legg merke til hvordan alle aspekter av operasjonell kontroll i et forretningssystem kan håndteres av regler:

• Restriksjoner: en kunde må ikke legge inn mer enn tre rush-ordrer belastet sin kredittkonto.

* Heuristikk: En kunde med foretrukket status bør ha sine bestillinger fylt umiddelbart.

• Beregninger: en kundes årlige ordrevolum må beregnes som totalt salg stengt i løpet av selskapets regnskapsår.

* Utløsere: “Send forhåndsvarsel” må utføres for en bestilling når bestillingen sendes.

Regler bygger direkte på vilkår og fakta. Vilkår-som kunde, forsendelse og faktura-skal ha en presis, entydig definisjon i virksomheten. For eksempel kan kunden defineres som: “en organisasjon eller enkeltperson som har plassert minst en betalt ordre i løpet av de to foregående årene.”

Fakta er gitt av enkle, deklarative setninger som forbinder vilkårene med et verb eller verbfrase, for eksempel ” Kunde plasserer ordre.”

en “faktamodell” er et sett med faktaerklæringer som beskriver resultatene av en forretningsdrift. En faktamodell bør tjene som en innledende blåkopi for en datamodell, men dens primære formål er å fange opp kunnskap om virksomheten i en strukturert form, destillert fra forretningsmessige arbeidere og ledere som besitter den.

Regler legger i hovedsak betydningen av ordene må eller må ikke til vilkårene og fakta ,som i ” Ordrer på kreditt over $1000 må ikke aksepteres uten kredittsjekk.”

Regler bør uttrykkes i klar, entydig, godt strukturert business engelsk, starter med en eksplisitt emne. Regler bør ikke ha fluff og ingen manglende fakta. Regler kan kvalifiseres, som i ” en forsendelse må være forsikret hvis forsendelsesverdien er større enn $ 500.”Og regler kan inkludere timing kriterier, som i” en student må være registrert i minst to kurs ved utgangen av registreringen.”

Regel Uavhengighet

en bedrift er veldig mye som en menneskekropp. Kunnskapsstrukturen (term og fact) er som skjelettet; prosessene er de kraftige musklene; og reglene er nervesystemet som styrer de andre to. Alle tre er viktige og sammenhengende. Men forretningsregler bør være skilt fra de to andre. Et grunnleggende prinsipp i denne tilnærmingen er at reglene er uavhengige av prosesser og prosedyrer. En frynsegode av at “regelen uavhengighet” er en stor forenkling i prosessene.

resultatet er en “tynn prosess”, et langvarig mål for MANGE IT-fagfolk. Ved å ta reglene ut av prosessene, kan du produsere prosesser som er relativt enkle og kan endres etter hvert som behovet oppstår.

I National Football League, hvis et spill ikke fungerer for et lag, vil det være borte fra sin playbook innen et par spill. Spillene er i hovedsak throwaways. På samme måte må bedrifter se sine egne prosedyrer som throwaways-billig nok til å kaste bort og erstatte lett når prosedyrene ikke lenger fungerer bra.

Kast prosedyrer er et must for virksomheten å være tilpasningsdyktig og konkurransedyktig. Denne villedende enkle ideen-muliggjort av forretningsregler-kan revolusjonere måten arbeid utføres og systemer utformes på.

Gjengitt med tillatelse Fra Principles Of The Business Rule Approach, Av Ronald G. Ross (Addison-Wesley, 2003). Ross er co-grunnlegger Og rektor Av Business Rule Solutions LLC og redaktør av Nettstedet BRCommunity.com.

Bibliotekfaktamodell
dette diagrammet viser en grafisk faktamodell for et bibliotek. Regelens ordlyd er basert direkte på faktamodellen, som er et diagram over grunnleggende forretningskonsepter-en kunnskapsstruktur. En faktamodell kan og bør gi en første-cut blåkopi for hvordan data vil bli til slutt organisert i en database. REGEL: Et lånekort kan brukes til å sjekke ut en bok bare hvis boken eies av et bibliotek som kortet er autorisert.