Forretningsregler er avgjørende for å sikre at organisasjoner opererer i samsvar med lover, retningslinjer og interne prosedyrer. Dessverre blir slike regler ofte formulert på en måte som skaper forvirring, misforståelser og inkonsistente tolkninger.

I denne artikkelen skal vi se på hvordan RuleSpeak®, en metode for å uttrykke forretningsregler på naturlig språk, hjelper oss med å skrive regler som er klare, presise og utvetydige.

Hva er RuleSpeak®?

RuleSpeak® er en samling retningslinjer for å uttrykke forretningsregler på en strukturert og entydig måte. Retningslinjene er utviklet for å:

✅ Forbedre kommunikasjon mellom forretningsfolk, analytikere og IT-utviklere
✅ Sikre at regler er praktiserbare, uten å være for tekniske
✅ Bygge bro mellom forretningslogikk og IT-systemer
✅ Unngå vanlige feil, som tvetydighet eller unødvendig kompleksitet

5 grunnprinsipper for gode forretningsregler

1️⃣ Forretningsregler skal være deklarative, ikke prosessuelle

Dårlig regel (prosedyre-fokusert):
❌ Hvis en kunde legger inn en ordre, sjekk om kunden eier en konto. Hvis ikke, avvis ordren.

God regel (deklarativ):
✅ En kunde kan bare legge inn en ordre gitt at kunden eier en konto.

👉 Unngå regler som beskriver steg-for-steg-prosesser. Fokuser heller på hva som er tillatt eller ikke.

2️⃣ Bruk «skal» og «bare» for å gjøre reglene entydige

Dårlig regel:
❌ En leietaker tillates ikke å delta i sameiets styre.

God regel:
✅ En leietaker skal ikke delta i sameiets styre.

👉 Alle forretningsregler må inneholde enten «skal» (obligatorisk krav) eller «bare» (begrenset mulighet).

3️⃣ Unngå upresise uttrykk og overflødige ord

Dårlig regel:
❌ En leveranse skal alltid ha en status.

God regel:
✅ En leveranse skal ha en status.

👉 Ord som «alltid», «uten unntak» eller «på noe som helst tidspunkt» er ofte overflødige. Fjern dem med mindre de tilfører spesifikk betydning.

4️⃣ 🄰 Bruk presise subjekter og unngå flertall

4️⃣ 🄱 “Kan” uten “bare” er ikke bra

Dårlig regel:
❌ Kunder kan kjøpe plantevernmidler hvis leverandøren har dem på lager.

God regel:
✅ En kunde kan bare kjøpe et plantevernmiddel gitt at plantevernmiddelet finnes på leverandørens lager.

👉 Bruk entallsform og unngå generelle uttrykk som kan føre til tvetydighet. Forretningsregler gjelder for enkeltforekomster. Visse typer tvetydighet kan lett unngås ved å plassere subjektet i setningen i entallsform.

👉 Ordet “bare” innskrenker handlingsrommet, og uttrykket blir dermed en forretningsregel.

5️⃣ Aktører som subjekt er ofte ikke bra

Dårlig regel:
❌ En kunde kan gjøre et uttak bare hvis kontoen er aktiv.

God regel:
✅ Et uttak fra en konto kan bare gjennomføres gitt at konten er aktiv.

👉 En forretningsregel som indikerer en aktør som subjekt bør granskes nøye. Gjelder virkelig forretningsregelen bare for denne aktøren? Ofte er svaret nei. I så fall bør aktøren erstattes med et subjekt som ikke er en typisk aktør (f.eks. uttak, som ovenfor).

⁉️ Spør: Bare kunden?

Oppsummering

Ved å bruke RuleSpeak kan vi skrive forretningsregler som er presise, klare og enkle å forstå. Husk disse 5 prinsippene:

🔹 Unngå prosessuelle regler – fokuser på hva som gjelder
🔹 Bruk «skal» og «bare» for entydighet
🔹 Fjern overflødige ord
🔹 Bruk entallsform og presise subjekter og unngå “kan” uten “bare”
🔹 Aktører som subjekt er ofte ikke bra

Ved å følge disse prinsippene sikrer vi at forretningsreglene blir forstått riktig, både av mennesker og systemer!

Ønsker du å lære mer? Sjekk ut RuleSpeak-veiledningene for flere detaljer om hvordan du kan uttrykke forretningsregler på en optimal måte.

RuleSpeak® har blitt utviklet av Ronald G. Ross siden 1996. Siden den gang har RuleSpeak blitt brukt i hundrevis av prosjekter av blant annet oss i Decisive og Business Rule Solutions, LLC (BRS). RuleSpeak har vært tilgjengelig på BRS nettsiden siden slutten av 1990-tallet.

Hva synes du om denne tilnærmingen? Har du eksempler på uklare forretningsregler fra din bedrift? Del gjerne dine erfaringer i kommentarfeltet under innlegget vårt på LinkedIn! 🚀

Det er vår i luften, været blir varmere og snøen er endelig i ferd med å forsvinne! I dag bestemte jeg meg for å ikke ta t-banen hele veien til jobb, slik jeg må innrømme at jeg har gjort i hele vinter, men i stedet gå av noen stasjoner tidligere og gå resten av veien. En av fordelene med å jobbe i byen er at man kan gå på asfaltert vei og dermed komme seg tørrskodd på jobb, selv om vårløsninga er i gang. På akkurat den veien jeg går forutsetter det at jeg må gå en omvei rundt en gressplen. I likhet med de fleste andre gjorde jeg ikke det, og det er godt synlig…

Dette fikk meg til å reflektere litt over et begrep jeg kom over for noen år siden. På engelsk heter det «desire path». Det finnes ikke et veletablert begrep på norsk, men la oss kalle det for en «krøttersti». En krøttersti er en sti som oppstår der folk eller dyr ønsker å gå, og ikke der hvor by- eller landskapsplanleggere ønsker at man skal gå. En krøttersti kan for eksempel være en snarvei gjennom et hull i gjerdet, et hjørne som kuttes i et veikryss, eller sånn som på veien til jobb, en gjørmete sti som deler en ellers fin plen i to.

Krøtterstier er lett synlige i terrenget og oppleves ofte som skjemmende. Oppstår det en krøttersti settes det gjerne opp et skilt som sier «Ikke trå på plenen», eller kanskje det dukker opp et gjerde (som de fleste likevel klatrer over). Krøtterstier blir ofte gjenstand for en kamp mellom folk flest og frustrerte anleggsgartnere.

Som en analogi er krøtterstien svært treffende i mitt fag, som er programvareutvikling. Vi som er arkitekter og utviklere er planleggerne som har idéer og meninger om hvordan brukerne skal agere. Menyer, datafelter og informasjon blir plassert og organisert slik våre idealistiske planer og ønsker dikterer. Alt skal se flott og ordnet ut, og hvis brukerne bare gjør slik som vi ønsker, så blir alt helt tipptopp.

Men brukere er som folk flest, og vil gå der de selv ønsker. I møtet mellom programvare og bruker finner vi fort ut hvor krøtterstiene i programmene våre går. Vi, som tross alt er eksperter på slike ting, responderer helst med å forsøke å tvinge gjennom at programvaren skal brukes slik vi har bestemt. Vi må sette opp gjerder og skilt for å hindre uønsket adferd. Vi kaller det gjerne «patching» eller «bugfixing».

Når jeg i morges traverserte den nå litt blaute krøtterstien på vei til jobb, tenkte jeg at det hadde jammen vært fint om noen kunne asfaltert dette stykket over plenen, slik at jeg slapp å bli gjørmete på skoene. Jeg tenker at vi som utviklere kan lære to viktige ting av dette:

1. Et godt forarbeid, der man kartlegger brukernes behov og ønsker, reduserer behovet deres for å tråkke opp egne stier i programvaren.
2. Et godt etterarbeid identifiser krøtterstiene som unektelig oppstår, slik at de kan endres, tilpasses og asfalteres etter brukernes ønsker og behov.

Hva er Business Apps? En forretningsapplikasjon, også kjent som en business app, er et generelt begrep for programvare eller en samling av programmer som støtter forretningsdriften i organisasjoner. 

Bedrifter bruker vanligvis forretningsapper slik at deres ansatte kan utføre spesifikke oppgaver mer effektivt og nøyaktig. For eksempel kan en detaljhandel som ønsker å forbedre lagerstyringen for å redusere kostnader og unngå utsolgte varer ta i bruk en forretningsapplikasjon. Denne applikasjonen integreres videre med lagerstyringssystemene og gir et brukervennlig grensesnitt for at ikke-teknisk personell kan ta i bruk løsningen og utføre arbeidsoppgavene sine.

Teknisk sett gir en plattform et grunnlag for at applikasjoner kan bygges og kjøres. De fleste plattformer i dagens marked kommer med forhåndsbygde applikasjoner, og mange applikasjoner utgir seg også for å være plattformer. I tillegg bruker leverandører gjerne generelle termer som system, programvare, løsninger og teknologi for å kunne markedsføre sine produkter mer effektivt. I praksis er skillet mindre klart.  

Mens ferdig programvare har en viss brukervennlighet for sluttbrukeren, har de ofte begrenset fleksibilitet. Ofte er fleksibilitet mindre viktig, fordi de fleste programvarer allerede kommer med all mulig funksjonalitet. Men når det gjelder programvare for å automatisere og administrere forretningkritiske beslutninger som er operasjonelle, er fleksibilitet enormt viktig. For eksempel når det gjelder underwriting og krav i forsikring eller svindel i finansielle tjenester. Jo mindre fleksibel programvaren er, desto mer ressurser vil du bruke på å utvikle legacy IT-løsninger som kan være kostbare å vedlikeholde. For å ivareta fleksibilitet bør man tenke på hvor enkelt det vil være for både utviklere og teknisk personell å få produktet til å gjøre akkurat det du vil at det skal gjøre.  

Dette er hvor forretningsapplikasjoner som modul i plattformen SMARTS kommer til nytte. SMARTS forretningsapper er tilpassede, brukervennlige brukergrensesnitt som gjør det mulig for ikke-tekniske brukere å enkelt utføre beslutningsstyringsoppgaver. Brukere kan gjøre dette uten å bli opplært på SMARTS™ plattformen eller vite hvordan man koder. I stedet for å eksponere alle regler og alle SMARTS funksjonaliteter for alle brukere, kan forretningsapplikasjoner eksponere bare det som er nødvendig for å fullføre spesifikke oppgaver/beslutninger, for den spesifikke brukeren. Forretningsapplikasjoner kan opprettes av forretningsanalytikere og programvareutviklere direkte i SMARTS-grensesnittet ved å bruke de samme «low-code/no-code»-verktøyene for å definere regler. 

Avslutningsvis mener vi i Decisive at forretningsapplikasjoner vil spille en avgjørende rolle i å støtte forretningsdriften til organisasjoner og være en bro mellom IT og business i årene som kommer.  

Introduksjon

Som et siste blogginnlegg før jul tenkte vi å skrive litt om digitalisering, og hvordan endringer i forskjellige dimensjoner henger sammen og påvirker hverandre. Begge forfatterne av dette blogginnlegget er utdannet forvaltningsinformatikere, hvor tverrfaglighet ligger i kjernen av faget. Forvaltningsinformatikk er en tverrfaglig utdanning som kombinerer juridiske, informatiske og samfunnsfaglige innfallsvinkler. Denne kompetansen er nyttig for å forstå hvordan IKT, organisasjoner og mennesker spiller sammen og påvirker hverandre, hvordan teknologi påvirker samfunnet, og hvilke juridiske konsekvenser utnyttelse av teknolog kan gi.  

I og med at vi er over gjennomsnittet opptatt av hvordan digitalisering påvirker samfunnet har vi sett frem til og satt pris på den nye digitaliseringsstrategien, «Fremtidens digitale Norge», som virkelig setter digitalisering på dagsordenen. I digitaliseringsstrategien står det blant annet om hvordan forskjellige drivkrefter i samfunnet påvirker hvordan samfunnet digitaliseres. Videre beskriver den hvordan drivkreftene og trender beveger seg raskt og at alle land bør arbeide med innsikt om fremtiden. Derfor tenkte vi at det kan være nyttig å diskutere en enkel metode for å analysere noen endringer og hvordan disse påvirker digitalisering.

Tre dimensjoner i endring

Begrepet digitalisering kan brukes om konvertering av analoge til digitale data, men også om innføring av digital teknologi som effektiviserer prosesser og endrer hverdagslivet. Kunstig intelligens er et eksempel på en teknologi som mange offentlige virksomheter nå inkorporerer i sine arbeidsprosesser, og som har potensialet til å effektivisere enkelte av disse prosessene betydelig. Samtidig er det viktig å huske på at teknologisk endring, slik som innføring av ny teknologi, ikke skjer i et vakuum – og at denne endringen vil føre til endringer i andre dimensjoner. Nedenfor har vi illustrert dette i en forvaltningsinformatisk figur, som viser hvordan teknologisk endring påvirker (eller fører til) både rettslig- og organisatorisk endring.     

Teknologisk endring 

Skjer det endring i teknologien, ved eksempelvis innføring av kunstig intelligens, vil dette også føre til rettslig og organisatorisk endring. Den nye teknologien påvirker samfunnet på flere måter, for eksempel ved at den kan utgjøre en risiko for individets rettigheter og friheter og at lovgiver dermed ser behov for å regulere den nye teknologien og lager en lov med mål om å gjøre nettopp dette. Dette har skjedd i forhold til kunstig intelligens med KI-forordningen, som skal sikre at KI-systemer som brukes innenfor EU er trygge, og at de respekterer våre grunnleggende rettigheter og verdier.  

Videre vil ny teknologi som KI kunne ha stor innvirkning på organiseringen av samfunnet. Vi ser allerede nå en bekymring fra enkelte yrkesgrupper når det kommer til om jobber vil gå tapt til forsøk på å automatisere stillinger. Per i dag er dette særlig relevant for kreative oppgaver som involverer å lage bilder eller skrive tekster. En endring som dette vil igjen kunne kreve vern for visse yrkesgrupper i lov, eller evt. subsidier for å beskytte ønsket kompetanse.  

Rettslig endring

En rettslig endring kommer sjeldent ut av det blå. Innføring av nye lover, eller endring i eksisterende lov og forskrift vil ofte skje som et resultat av endring i teknologi eller organisering. Selv om rettslig endring ofte trigges av teknologisk eller organisatorisk endring, vil innføring av nye lover også ha effekt på både teknologi og organisering når loven trer i kraft. Bruker vi den ovenfornevnte KI-forordningen som eksempel kommer denne som følge av bekymringer for konsekvensene KI vil kunne ha for våre europeiske grunnleggende rettigheter og verdier, og er med det lagt opp slik at den regulerer hvilke produkter som er akseptable på markedet og hva som skal til for at det enkelte produkt er akseptabelt. Forordningen vil ha potensiale til å styre produktutviklingen og kvalitetssikringen av KI-produkter, da vi antar virksomheter fremdeles ønsker å kunne selge sine produkter på det europeiske markedet.  

På grunn av kravene som stilles til systemene som treffes av KI-forordningen vil mange virksomheter se behov for å skaffe kompetanse om KI-forordningen og hvordan å sørge for etterlevelse. Dette kan fort føre til at nye roller blir opprettet for å sikre etterlevelse. På nasjonalt plan stiller KI-forordningen også krav til at medlemslandene skal ha et KI-tilsyn, akkrediteringsorganer for sertifiseringsorganer og at det skal opprettes minst en sandkasse for KI i hvert land. Alt dette er eksempler på hvordan en rettslig endring vil føre til organisatoriske endringer. Et annet eksempel er krav om personvernombud for enkelte virksomheter etter GDPR, som førte til at mange virksomheter måtte opprette en ny rolle og ny organisering for enkelte oppgaver.      

Organisatorisk endring 

Ved innføring av ny teknologi eller ved en rettslig endring, vil det også skje en organisatorisk endring. Dette kan både være at det opprettes nye roller slik vi har nevnt ovenfor, men det kan også være at interne prosesser må omorganiseres eller endres. Oppgaver som tidligere ble utført manuelt kan effektiviseres eller automatiseres, noe som kan føre til at enkelte roller blir overflødige. Rettslige endringer som ikrafttredelse av KI-forordningen fører også til en lovpålagt plikt til opplæring av ansatte.  

Bruk av hjemmekontor er et eksempel på en organisatorisk endring som har ført til tekniske endringer, ved at videokonferanseteknologi har blitt standard for alle virksomheter og kvaliteten på dette har blitt langt bedre enn før pandemien. Videre førte dette til behov for regelverksendringer som gjør at offentlige virksomheter må avtale med ansatte om bruk av hjemmekontor.  

Avslutning  

Digitalisering er et evig spill av påvirkning mellom disse dimensjonene (Og flere! Her har vi for eksempel ikke trukket inn økonomiske endringer). Det er viktig å analysere enhver kommende endring i en enkelt dimensjon, og avklare hvordan dette vil påvirke de andre dimensjonene for å kunne planlegge den videre digitaliseringen på en god måte.  

Vi mener at verken teknisk- rettslig eller organisatorisk endring kan skje i et vakuum: Ha et helhetlig perspektiv – se alt i sammenheng! 

Introduction

In this and the next blog post, I’ll be writing about principles, methods, and tools for generating text. I’ll be focusing on writing a letter to someone to provide information about something. This could be a decision made by a government agency, a letter to bank customers with information about new interest rates, or other matters. This is actually quite general and is about how you can generate a text. Whether it’s in A4 format sent as a PDF or on paper, text in an email, text message, or something else doesn’t matter. For simplicity’s sake, I’ll use the example of sending a decision letter in PDF format to inform someone of a decision. 

What I’m describing in this blog post isn’t something I came up with on my own. It largely consists of specific features developed within the “Fremtidens innkreving” program at the Norwegian Tax Administration, but it also includes general principles and methods. I’m writing about this to share something I think is smart that others might find useful. 

Overall, what I’m describing will likely be most relevant to large organizations, but some aspects may be relevant even for small organizations. 

Principles for written communication 

Here, I describe some principles that underlie the methods and tools I will discuss later. Most of this stems from how the Norwegian Tax Administration wants to communicate in its letters and present itself to the public. I believe these are relatively general principles, which some will agree with and others may disagree with. Different organizations may have different needs and preferences, so you must assess which of these are relevant to you and your organization. 

• The content must be accurate. It must be approved by subject matter experts, department heads, lawyers, or others.
  
• The content must be written in plain language so that all recipients can understand the message. It must be reviewed by someone with expertise in plain language.
  
• We must maintain consistent external communication to present a unified image:

  Some content should be consistent across different subject areas. For example, if you have a section at the end of the letter that says, “Do you have any questions? Contact us this way: …,” it should be the same in all letters where you want to include such text.

  The content should follow a consistent format across all departments. For example, decision letters from one part of the organization should resemble decision letters from another part of the organization. This could include, for example, the order of the sections “Relevant rules in this letter,” “Do you have any questions?” and “Signature.”

  Letters with essentially the same content should be identical. If one case worker is handling a case and approves an application, and another case worker approves a different application, both approval letters should be identical (with the exception of details specific to each case). 

• Some content must be presented in multiple language variants, such as Bokmål, Nynorsk, and English, because the audience requests it. In such cases, the texts must be reviewed or written by someone who is proficient in those language variants. 

• Letters that can be generated automatically should be generated automatically. This saves time in case processing, ensures consistent letters, and allows us to send out letters more quickly when something happens. For example, if we have an automated case processing system, it’s helpful if you can send the decision letter immediately instead of having to ask a human case worker to review the case and write a letter conveying the outcome. 

These principles may be waived when there are good reasons to do so. 

One possible objection to the principles above is that they lead to the centralization of letters and text within the organization. This could result in it taking longer to create new letters or modify existing ones. It is true that this can happen, but it is not true that it has to happen. It must also be weighed against how important these principles are to the organization, so you may end up with varying degrees of centralization. We will now look at methods and tools that can be used in different ways depending on how much weight you place on the various needs and preferences mentioned above. 

Phrase Bank 

One way to meet many of the needs and preferences listed above is to have a place where all letter text is stored. I use the term “phrase library,” where a phrase is a piece of text. It can be a sentence or an entire paragraph, but is never shorter than a single sentence. A phrase will have a specific formatting and may include headings, bulleted lists, etc. 

I assume that a letter written in Bokmål, Nynorsk, or English can be structured in the same way and translated paragraph by paragraph or even sentence by sentence. You have to consider the text as a whole, but I think it’s fair to say that a particular sentence or paragraph in Bokmål can be equivalent to a sentence or paragraph in English. There may be exceptions, and they can be handled, but this is the general rule. 

We can create a simple phrase store like this:

Her har vi formatert teksten mellom <h2> og </h2> som overskrift nivå 2. Vi kunne også hatt fet, kursiv, ulike skriftstørrelser osv. Der det er rød skrift på entall/flertall som f.eks. du/dere kan styres av f.eks. om du skriver brev til en person eller en organisasjon. Feltene <forsinkelsesrentesats> og <rentebeløp> skal fylles ut med konkrete tall i hvert enkelt brev. Vi kaller slike felt «flettefelt», for å vise at her skal det flettes inn noe i setningene. 

If you have such a list of texts, you can ask everyone who needs to write new texts to use them whenever possible. New letters can be written by selecting some existing texts and creating new ones. You’ll get more consistent texts and communication, and you can save time on drafting your own texts and getting them legally approved. You won’t have to translate the same text between Bokmål, Nynorsk, and English multiple times, because everyone can use the same translation. 

Such a list can become confusing, so we can add some identifiers. The table below includes the columns “Level 1,” “Level 2,” and “Level 3”: 

These identifiers can be used to filter and sort the list, and they can be used to create a letter template with various phrases. I’ll come back to this in more detail in my next blog post.   

We may also want to include legal references in our letters. For example, whenever we write about late payment interest, we may want to refer to a specific section of a specific law. It is helpful if everyone does not have to figure out for themselves which section to cite, e.g., whether it is “the Late Payment Interest Act, Sections 14 and 15” or “the Late Payment Interest Act, Chapter 3.” It’s also helpful if everyone who needs to refer to this does so in the same way—meaning they use only one of the following: “our right to calculate late payment interest, see the Late Payment Interest Act §§ 14 and 15,” or “for information on why we calculate late payment interest, see §§ 14 and 15 of the Late Payment Interest Act.” If you set this up once and for all, you’ll have a consistent format, and all new users of the same text won’t have to worry about how it should look. One way to do this is to link specific legal references to specific phrases. I’m now removing Nynorsk and English so the table doesn’t get too wide. 

This way, all letters containing the phrase “joint/late payment interest/text” will include the same legal reference. Such legal references can be listed in a separate section of the letter under a heading such as “Relevant provisions for this letter.” 

To create a new letter, follow these steps: 

1. Find out what must be included in the letter to meet legal requirements. 
2. Think about what else you want to bring  
3. Think about the general structure of the letter, but don't get too bogged down in the details. 
4. Browse the phrase library to find suitable texts, especially under “Common.” 
5. If necessary, write any new text you need that isn't already in the phrase library. 
6. New text should be added to the phrase database. All content from every letter should be included there. 

All of this can, in fact, be used to create letter templates that you distribute to case workers for manual letter writing, but a key benefit comes when it’s used to generate letters automatically. We’ll take a closer look at this in the next post on the professional blog. You can read Part 2 here.

På denne bloggen har det allerede blitt skrevet en del innlegg som handler om Decision Intelligence Platform (DIP), eller beslutningsstyringssystem på norsk. Jeg ønsker å skrive litt om min opplevelse med SMARTS fra en person som har bakgrunn som forretningsarkitekt, der hovedfokuset oftest er på krav, forretningsprosesser og livlige diskusjoner mellom personer i grenselandet mellom IT og fag. 

Alf-Kenneth har allerede skrevet en god introduksjon til hva SMARTS er, og fordeler ved å bruke verktøyet. Øystein har skrevet et 2-delt innlegg om hvordan A-B testing i SMARTS kan utføres, der det er synliggjort hvordan du enkelt kan vurdere konsekvenser av endringer i reglene.  

Uten den tekniske bakgrunnen kan det oppleves som å vandre inn i ukjent terreng med mange fallgruver når man selv skal begynne å «kode» regler. Mitt hovedpoeng er at det er det liten grunn til, fordi dette er så enkelt at man kan lære seg de mest elementære (og viktigste) bruksområdene på kort tid – uten særlig teknisk kompetanse. Jeg har nå brukt en knapp uke på å sette meg inn i SMARTS, og selv om jeg ikke kan påberope meg ekspertise på systemet kan jeg allerede nok til å sette opp et enkelt regelsett med fakta, vilkår og utfall. Og vel så viktig kanskje – jeg kan lese og forstå hva som foregår i etablerte regelsett uten å måtte ty til utviklere for hjelp. Om du  har satt opp et Excel-ark med noen enkle formler er du kapabel til å ta i bruk SMARTS, som er et såkalt «Low-code/No-Code» verktøy. 

Uten at jeg kan eller skal skrive en komplett guide her, vil jeg vise hvor enkelt det er å sette opp et enkelt regelsett med noen fakta og en enkel beslutningstabell. Med min bakgrunn fra pensjonsfaget er jeg moralsk forpliktet til å ta et eksempel derfra. Vilkårene for innvilgelse av «påslagspensjon» (fra offentlig sektor) er gjort betraktelig enklere sammenlignet med den gamle «brutto-ordningen», og handler i hovedtrekk om tre enkle vilkår: 

• Medlemmet må være fylt 62 år  
• Medlemmet må ha søkt i tide (med andre ord kan en ikke søke tilbake i tid)
• Medlemmet må ha minimum 1 dag opptjening etter 31.12.2019  

(Så håper jeg at mine kollegaer med pensjonskompetanse kan tilgi meg for å ha gjort noen forenklinger for eksempelets skyld) 

Rekkefølgen for hvordan man ønsker å gjøre dette er fleksibel, men vi ser med en gang at vi her trenger å få etablert tre enkle faktum. Vi begynner med å sette opp faktum i SMARTS, som tre true/false (boolske) variabler.  

I SMARTS har du i prinsippet mulighet til å strukturere felter og seksjoner som du ønsker, men for å gjøre et tydelig skille mellom hva som er input (som er avhengig av- og prisgitt eksterne data og deres modeller) og fakta anbefaler vi at regler kjører på det vi enkelt kaller «fakta». Hva som er fakta i denne sammenhengen er det lovverket som bestemmer – ikke hva man har som input i en gitt kontekst. Rent praktisk er det å legge til seksjoner og felter svært enkelt – så lenge man tar stilling til datatypen (som i dette tilfellet altså er boolske).  

I SMARTS kan vi med enkle grep benytte oss av disse faktaene og sette opp regelen som en beslutningstabell:  

Tabellen viser de tre vilkårene (sendt innen fristen, fylt 62 år og har opptjening etter 31.12.2019) som kolonneoverskrifter. Hver rad i tabellen kan ses på som en regel – der utfallet av hver regel leses i den siste kolonnen (VilkårForPåslagOppfylt).

Noe forenklet forklart er dette så enkelt som å trykke add new decision table, og legge til rader og kolonner (add row og add column). Den mest kompliserte biten er å knytte kolonnene med de (etablerte) fakta til tabellen – og det tok ca. 2 minutter. Ellers er det å fylle inn enten «true» eller «false» slik at en får en fullstendig tabell med alle potensielle varianter.   

Utfallet fastsetter her verdien «Vilkår for påslag oppfylt» som enten true eller false. Her har du mulighet til å legge inn flere utfalls-kolonner, om du for eksempel vil legge til hjemmelshenvisning, begrunnelse eller annet for hver rad som kan slå til.   

Når jeg har fylt inn tabellen kan jeg endre visning av regelen til rule list, der jeg ser koden som er generert:  

Bildet viser de samme reglene som uttrykt i beslutningstabellen over som individuelle kodede regler. I hver regel er det en tittel (fet skrift), vilkår og utfall.

Foreløpig har vi tatt utgangspunkt i en regel der forutsetningen er at faktum er etablert. I den virkelige verden vil vi også måtte utlede disse faktaene – med andre ord transformere input til de faktaene vi trenger. Her er det flere veier til mål, men én enkel mulighet er å utlede dette med flere regler i SMARTS. I mitt eksempel har jeg skilt mellom regler som utleder fakta, og vilkårsregler (som igjen kjører på fakta). For å utlede fakta har jeg lagt inn noen enkle utledningsregler: 

Utledningsreglene fastsetter altså de fakta som vi benytter for å kjøre de «reelle» forretningsreglene våre. Dette var nok det vanskeligste å få fatt på for min del – men her er det prøving og feiling, og det å gjøre seg kjent med SMARTS sin dokumentasjon og veiledning som gjelder. Du kan også få hjelp av den innebygde AI-assistenten til SMARTS, som jeg har vist med et enkelt eksempel her:  

Det er langt flere muligheter og funksjoner i SMARTS enn det jeg har fått vist med mitt enkle eksempel her – og erfarne brukere eller kodere vil nok ikke være 100% overbevist av mitt forsøk på å implementere denne regelen. Men det er heller ikke poenget med denne bloggposten.  

Som funksjonell arkitekt er det en kjent problemstilling at forretningslogikken er lite tilgjengelig. Både fagpersoner, forretningsressurser, testere og andre har ofte lite innsikt og tilgang til den faktiske koden. Og selv om vi hadde sittet med koden foran oss er det ikke gitt at vi hadde blitt mye klokere. Fagpersoner som sitter med den faktiske forretningskompetansen jobber aktivt med faget og utarbeider oppslagsverk og wikier, men har sjelden eierskapet eller innsikten i den faktiske implementeringen – som i realiteten er måten de samme reglene praktiseres på.  

Når systembrukere oppdager feil eller mangler i eksisterende systemer er det ofte en tungrodd prosess å spore hva som faktisk foregår. Feilsøking og påfølgende kravspesifisering og retting kan være tidkrevende og frustrerende. Ofte er systemer eller tjenester såkalte «black boxes» – der få (eller ingen) i virksomheten helt vet hvordan løsningen fungerer. Men hva om saksbehandleren eller fageksperten selv kunne gå rett inn å sjekke den faktiske regelimplementeringen? Eller enda bedre – om fageksperten selv kunne rettet feilen med noen tastetrykk?  

Å spore hvilke regler som er kjørt – og eventuelt slått til er heller ikke særlig problematisk i SMARTS. I eksempelet nedenfor kan jeg se (med «grønt lys») hvilke regler som har slått til i mitt testcase: 

Én av hensiktene med DIP er altså å la fagekspertene selv få innsikt og til syvende og sist eierskap til de praktiserte reglene i systemene. Det er et oppnåelig mål, og spesielt for virksomheter der kompliserte forretningsregler er en del av hverdagen. Betyr det at det også er et mål å «kvitte seg» med utviklere eller systemarkitekter? Selvsagt ikke. For å ta i bruk en DIP kreves det integrasjoner, kvalitetssikring og testing for å nevne noe. For komplekse regler vil også det å utlede fakta være krevende – og i større grad kreve kompetanse med koding. Vi ønsker heller ikke at fageksperter skal bli fulltidskodere (med mindre de selv har veldig lyst) – men jeg har forsøkt å vise (med de rette hjelpemidlene) at gapet mellom forretning og IT kan bli litt mindre med enkle grep.