Innledning 

SMARTS er et beslutningsstyringssystem (Decision Intelligence Platform, DIP) utviklet av Sparkling Logic. Systemet er designet for å optimalisere og automatisere beslutningsprosesser innenfor organisasjoner ved å tillate rask implementering, testing og endring av kompleks beslutningslogikk. I denne bloggposten bruker jeg SMARTS som eksempel, men teksten vil i stor grad kunne være relevant om man vurderer andre systemer også. I den første delen av innlegget vil jeg presentere noen nøkkelegenskaper og fordeler ved bruk av SMARTS, før jeg lenger ned beskriver sentrale prinsipper for implementering av beslutninger.   

Her er noen nøkkelegenskaper og fordeler ved å bruke SMARTS: 

Sentralisert beslutningslogikk 

SMARTS hjelper organisasjoner med å sentralisere beslutningslogikken, noe som forenkler vedlikehold og oppdatering. Dette er spesielt nyttig i miljøer hvor beslutningsreglene endres ofte som respons på nye forretningskrav eller ekstern regulering fra f.eks. Stortinget eller et departement. 

Tilgjengelighet for ikke-tekniske brukere 

En av de mest fremtredende egenskapene til SMARTS er hvor tilgjengelig systemet er for ikke-teknisk personell. Plattformen tilbyr et brukervennlig grensesnitt for regelutforming, noe som lar både forretningsanalytikere, regeladministratorer, og andre ikke-tekniske roller bidra til utvikling og vedlikehold av beslutningslogikken uten dyptgående programmeringskunnskap. Ansatte med disse rollene får større eierskap til løsningen når de kan jobbe i den selv. Dette bidrar også til større trygghet i at man forvalter regelverket riktig og at automatikken fatter riktige beslutninger. 

Fleksibilitet og skalerbarhet 

SMARTS er bygget for å være fleksibelt og kan skaleres for å møte behovene til både små og store organisasjoner. Systemet kan distribueres i skyen (på plattformer som AWS, Azure, GCP, OpenShift) eller on-premise, avhengig av organisasjonens preferanser og krav til datasikkerhet. 

Avanserte analysefunksjoner 

SMARTS inneholder avanserte analysefunksjoner og simuleringsverktøy som lar brukere teste og evaluere beslutningslogikken før den settes i produksjon. Dette bidrar til å redusere risikoen og øke tilliten til beslutningene som systemet genererer. Øystein Grøndahl har tidligere skrevet om mulighetene for å vurdere konsekvenser av regelendringer, se A-B testing i SMARTS: Del 1 og A-B testing i SMARTS: Del 2.

Integrasjon med moderne teknologier 

Med støtte for HTTP APIer og tilgang til et Software Development Kit (SDK), kan SMARTS enkelt integreres med eksisterende IT-infrastruktur og applikasjoner. Dette sikrer en sømløs flyt av data og beslutninger gjennom organisasjonens økosystem.  

Sikkerhet og compliance 

Sikkerhet og compliance er kritiske aspekter for alle beslutningssystemer. SMARTS støtter sikkerhetsstandarder og autentiseringsprotokoller for å sikre dataintegritet og tilgangskontroll, samt evnen til å implementere zero trust-prinsipper gjennom bruk av kortlivede tokens. SMARTS lagrer SMARTS aldri data, heller ikke når reglene blir kjørt. 

 

Prinsipper for implementasjon av beslutninger 

Etter å ha brukt SMARTS i flere prosjekter er det noen sentrale  prinsipper det er lurt å tenke på når man implementerer beslutningstjenester. Disse prinsippene sikrer at beslutningstjenestene er robuste, vedlikeholdbare og lett integrerbare i ulike forretningsprosesser. Prinsippene kan også benyttes når man velger å implementere regler i programmeringsspråkene som en virksomhet benytter til vanlig, dette kan typisk være Java, C#, Kotlin eller Python. 

Figuren nedenfor viser et mulig eksempel på hvordan SMARTS kan integreres i en løsning:

 

Beslutninger bør være tilstandsløse 

Beslutninger bør ikke håndtere eller initiere oppdateringer av andre objekter eller ressurser. Ansvaret for slike oppdateringer bør ligge hos den prosessen som benytter resultatet av beslutningen. Dette forenkler beslutningstjenestene og sikrer at de utelukkende er dedikert til beslutningstaking. 

Beslutningstjenester bør være uavhengige av prosesser og systemer 

Ved å designe beslutningstjenester som er uavhengige av spesifikke prosesser og systemer, øker potensialet for å kunne gjenbruke tjenestene på tvers av ulike deler av organisasjonen. Dette fører til at man også støtter sentralisering av regelverket, noe som fører til likebehandling og lettere vedlikehold og oppdatering av regler. 

Bruk gjenkjennelige begreper 

Beslutningene bør implementeres ved hjelp av begreper og terminologier som er lett gjenkjennelige og direkte avledet fra regelspesifikasjonen og den tilhørende faktamodellen. Dette styrker forståelsen og overholdelsen av reglene gjennom hele organisasjonen. 

Det finnes flere initiativ for å beskrive beslutninger og forretningsregler på en strukturert måte. Formålet er både å standardisere måten regler beskrives på, samtidig som man også muliggjør verktøystøtte. Her er noen lenker som kan være av interesse: 

• https://www.decisionmanagementsolutions.com/wp-content/uploads/2014/11/Manifesto-White-Paper-October-7.pdf 
• https://decisionmanagementsolutions.com/wp-content/uploads/2019/10/The-Decision-Management-Manifesto-October-6-2019-Norwegian.pdf 
• https://en.wikipedia.org/wiki/Decision_Model_and_Notation  
• https://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_Rules  
• https://www.rulespeak.com/no/ 

Modellbasert input og output 

Input og output for beslutninger kan integreres med modeller som allerede er i bruk i organisasjonen. Dette bidrar til enkel integrasjon og dataflyt. 

Det er nødvendig å etablere en klar og pålitelig mappingprosess mellom de eksisterende modellene og den interne faktamodellen som beslutningstjenesten bruker. Denne mappingen bør gjøres i selve beslutningen (altså før og etter selve regelevalueringen skjer). 

Dokumentasjon og vedlikehold 

Effektiv dokumentasjon av beslutningslogikken og hvordan denne er implementert er kritisk for vedlikehold og fremtidige revisjoner. Dette inkluderer regeldokumentasjon, endringshistorikk og systemdokumentasjon. 

Testing og validering 

Systematisk testing og validering av beslutningstjenester er essensielt for å sikre at de fungerer som forventet under ulike scenarier. Dette inkluderer enhetstesting, integrasjonstesting og ende-til-ende testing. 

 

Oppsummering 

Samlet sett tilbyr SMARTS en robust, fleksibel og brukervennlig plattform for beslutningsstyring som kan tilpasses en rekke brukstilfeller, fra finansielle tjenester, detaljhandel, og mer. Og ikke minst for offentlig forvaltning hvor lovverk og forskrifter er grunnleggende i mange av systemene. SMARTS evne til å gjøre beslutninger tilgjengelig for ikke-teknisk personell, samtidig som systemet opprettholder høye standarder for sikkerhet og compliance, gjør det til en verdifull ressurs for enhver organisasjon som ser etter å optimalisere sine beslutningsprosesser.

Ved å følge prinsippene for implementering av beslutninger som jeg har beskrevet ovenfor, kan organisasjoner utvikle effektive og pålitelige beslutningsstyringssystemer som er både robuste og fleksible nok til å møte de stadig skiftende kravene i en dynamisk forretningsverden.

I mitt forrige innlegg skrev jeg om koblinger i programvare, hva de egentlig er og hvilke ulemper og fordeler de gir. I dette innlegget ser jeg videre på ulempene koblinger gir, og beskriver en modell for å vurdere hvor store disse er. Modellen er hentet fra Vlad Khononov sin presentasjon og kommende bok, Balancing Coupling in Software Design. 

I modellen klassifiseres koblinger i tre dimensjoner: styrke, avstand og endringstakt. Nedenfor beskrives disse dimensjonene, samt hvordan de kan brukes for å finne ut om ulempene med en kobling er store eller små.

Styrke

Styrken i en kobling mellom to moduler av programvare følger av hvilken av de fire beskrivelsene nedenfor som beskriver koblingen best. Modul kan her bety alt fra noe så lite som en metode i en klasse, til så store ting som hele IT-løsninger. 

Inngripende kobling (intrusive coupling) 

Dette er den sterkeste typen kobling. Her har koblingen gjort seg avhengig av interne detaljer i implementasjonen, bruker private funksjoner eller tilsvarende. Koblingen fra modul K til modul S bruker altså deler av modul S som det ikke er ment at noen andre skal bruke. Da er det stor fare for at det kan skje endringer i modul S som skaper store problemer for modul K. 

Funksjonell kobling 

Her har de to modulene fått en tett funksjonell kobling, altså at en funksjonell endring i en av modulene krever at den andre modulen også endrer sin funksjonalitet. Dette er et symptom på feil inndeling i moduler (low cohesion), og er en ganske sterk kobling. 

Modell-kobling 

I motsetning til en funksjonell kobling, er koblingen her bare mot datamodellen. Dette er en svakere kobling enn den funksjonelle, og kun endringer i selve datamodellen i den ene modulen kan medføre krav til endring i den andre modulen. Like fullt er datamodellen en svært sentral del av en modul, og det at andre moduler gjør seg avhengig av detaljer i den, vil gjøre det mer tungvint/risikabelt å gjøre endringer i modellen. 

Kontrakts-kobling 

I en kontrakts-kobling er det laget en egen modell, ofte kalt DTO, og et eget grensesnitt for integrasjon mot andre moduler. Da har modulen større frihet til å gjøre endringer i sin interne datamodell uten at det påvirker andre moduler, og tilsvarende med interne funksjoner. Dette er den svakeste koblingen av de fire. 

Avstand 

Avstanden mellom modulene som har en kobling kan ha stor praktisk betydning for hvor store ulemper koblingen gir. Avstand her er ikke fysisk avstand, men i stedet et uttrykk for hvor mye koordinering som må til for å få gjennomført endringer på begge sider av en kobling. 

Om koblingen er mellom to moduler i samme kodebase er avstanden veldig liten. Å endre i begge disse modulene samtidig er helt naturlig, og ingen koordinering trengs utover blant de som programmerer endringen.  

Hva om koblingen er mellom to mikrotjenester? Da kan det være at endringene i disse må koordineres, kanskje må det brukes expand-contract-pattern for å gjennomføre endringen på en trygg måte. Likevel er de som må koordinere arbeidet gjerne på samme team, og koordineringen er normalt ganske enkel å gjennomføre. 

Hva så om koblingen er mellom to forskjellige løsninger i samme organisasjon? Eller enda verre, mellom to løsninger i forskjellige organisasjoner? Sistnevnte kan være svært krevende å få gjennomført, og åpenbart svært mye tyngre enn å endre i moduler som ligger i samme kodebase. 

Endringstakt 

Ulempene med koblinger utløses gjerne når det skal gjøres endringer. Hvis endringer skjer svært sjeldent, kan en kobling ha både høy styrke og lang avstand, men likevel skape lite ulemper totalt sett. På samme måte kan en kobling ha både lav styrke og kort avstand, men likevel skape store problemer hvis den har veldig høy endringstakt. 

Smerten ved en kobling 

Hvordan skal så disse tre dimensjonene, styrke, avstand og endringstakt, brukes for å finne hvor uheldig en kobling er? Sentralt i Khononovs modell er følgende ligning: 

 

Smerte = Styrke * Avstand * Endringstakt 

 

Smerte er altså ulempen som koblingen gir, eller smerten ved å forvalte systemet som har koblingen. Styrke, endringstakt og avstand angis med en verdi mellom 0 og 1. Da ser vi at hvis en av faktorene er veldig nærme null, kan smerten være lav selv om de to andre faktorene er høye.  

Denne modellen synes jeg hjelper veldig med å kunne gjøre konkrete og gode vurderinger av koblinger i programvare, og slik også bidra til å avmystifisere disse koblingene som arkitekter snakker om hele tiden.

Om du vil lære mer om modellen anbefaler jeg å se en av presentasjonene til Khononov, f.eks. denne fra DDD Europe 2023. 

Vi arkitekter snakker hele tiden om hvor viktig det er med løse koblinger i programvare. Hva betyr egentlig det? Og hva er egentlig en kobling i programvare, sånn helt konkret?

Ofte har vi en tjeneste som løsning S tilbyr, og som løsning K tar i bruk. Her er løsning S server-siden, mens løsning K er klient-siden. Løsning K sin bruk av tjenesten i løsning S har da skapt en avhengighet, eller en kobling, mellom de to løsningene.

Det følger flere ulemper med dette. Det kan være at løsning K krasjer hvis løsning S sin tjeneste går ned (en driftsmessig kobling). Eller hva om løsning S endrer på tjenesten, kanskje endres navnet på et av feltene? Vil denne endringen føre til at løsning K brått bare får feilmeldinger når den prøver å bruke tjenesten (en endringsmessig kobling)? Hvis slike problemer oppstår, har vi det som kalles harde koblinger. Et driftsavvik, eller en endring, på løsning S, slår altså veldig uheldig ut for løsning K.

Hva er så en løs kobling, som vi er så opptatt av å få til? En løs kobling gjør at endringer eller driftsavvik i løsning S ikke får store negative konsekvenser for løsning K. Hvordan går vi så frem for å få til dette?

Løsning K kan designes slik at den har en intern kø for kallene som skal gjøres til løsning S. Hvis tjenesten i løsning S går ned, blir kallene liggende på køen i løsning K, så lenge tjenesten er nede. Når tjenesten kommer opp igjen, plukkes kallene opp fra køen og gjennomføres. Konsekvensene av nedetid på tjenesten er da begrenset til å skape en forsinkelse, i stedet for at løsning S krasjer. Da er den driftsmessige koblingen gjort løsere.

For å redusere den endringsmessige koblingen kan løsning S rulle ut endringer i tjenesten sin i flere trinn. En vanlig teknikk for dette kalles expand-contract-pattern. Da skjer endringen i følgende trinn:

1: Tjenesten utvides med ny verdi, men tjenesten krever enda ikke at alle klienter sender inn den nye verdien. Dette er expand-trinnet.

2: De som bruker tjenesten legger til den nye verdien i kall de gjør til tjenesten. Dette kan gjøres når det passer klientene, kanskje dager eller uker etter at del 1 er gjort.

3: Når alle klientene har gjort endringen, endres tjenesten til å kreve at verdien legges med i alle kallene. Dette er contract-trinnet.

Hvis løsning S gjør endringer med denne metoden, har løsning K god tid til å gjøre sine endringer, og unngår dermed plutselige feil, eller krevende koordinering. Da har vi gjort den endringsmessige koblingen mye løsere.

Både utviklere og arkitekter bruker mye tid og energi på å gjøre koblinger løsere. Dette har blitt enda viktigere de senere årene, siden det nå forventes at løsninger alltid er oppe, og at endringstakten skal være høy. Dette kommer ikke uten kostnad. Å designe klienter slik at de takler nedetid på tjenester øker kompleksiteten og kostnaden ved å ta i bruk tjenester. Å bruke expand-contract-pattern for å gjøre endringer tar mer tid, og er mer komplisert, enn å bare gjøre endringer rett frem.

Vi får det kanskje til å høres ut som koblinger er noe negativt som må unngås, men det stemmer jo ikke. En løsning har faktisk ingen verdi uten koblinger. Tenk om løsning K var en løsning for å beregne og utbetale penger igjen på skatten, og at løsning S var bankens løsning for å overføre penger. Løsning K hadde ikke vært mye verdt, hvis den ikke hadde noen kontakt med bankens løsning. Forretningsverdien til løsning K leveres faktisk gjennom koblingen til bankens løsning S.

Koblinger er altså en naturlig og nødvendig del av IT-løsninger for at de skal skape verdi. Samtidig må vi som utvikler løsninger også bygge disse koblingene på en måte som skaper mest mulig robuste og endringsvillige løsninger, selv om det kan være krevende å få til.

In their previous blog post, Benjamin and Mohammed wrote about how they use generative AI to solve challenges both at work and in their daily lives. They also mention that the use of artificial intelligence systems will always carry a certain risk of error and bias, and that one must be especially cautious when artificial intelligence is used to make decisions that affect people’s lives. These challenges underscore the need for responsible use and continuous ethical evaluation of AI technology. In this blog post, I thought I’d write a bit about the regulations we have ahead of us, but also a bit about the requirements we already have to deal with.

The AI Regulation:

We are eagerly awaiting the legal regulation of this technology. The European Parliament and the European Council have now reached a provisional agreement on the content of the EU Artificial Intelligence Act, and this regulation is expected to enter into force in 2026. The objective of the regulation is to increase the use of human-centric and reliable artificial intelligence and to ensure a high level of protection for health, safety, fundamental rights, democracy, the environment, and legal certainty from the harmful effects of such systems. Such a framework will ensure that all development and use of artificial intelligence within the EU/EEA safeguards our statutory rights and is in line with our values. The regulation takes a risk-based approach and imposes requirements not only on the AI system itself, but also on the provider and the user.

Although the AI Regulation will not take effect until 2026 at the earliest, that does not mean we are waiting to adopt artificial intelligence until the regulation is in place. Artificial intelligence has the potential to generate significant benefits for society by, among other things, increasing efficiency, providing us with new knowledge, and supporting decision-making processes, and Norwegian businesses are eager to start using the technology right now. Using artificial intelligence in a lawful manner can be challenging when there is little legal precedent in the field. Fortunately, three out of four of this year’s projects selected by the Norwegian Data Protection Authority for exploration in the regulatory sandbox are projects that explore the use of generative artificial intelligence. Hopefully, the results of these projects will have transferable value and set a standard for how we can use generative artificial intelligence.

Not a lawless area:

Although we currently do not have legislation that specifically regulates the development and use of artificial intelligence, this does not mean that this is a lawless area. We have several laws that set the framework for how we can develop and use artificial intelligence: If artificial intelligence is to be used to process personal data, the requirements of the General Data Protection Regulation will apply. Among other things, the GDPR requires transparency—where the data subject has the right to relevant information about the underlying logic, as well as the significance and expected consequences of such processing, in the event of automated decision-making. This requirement will be difficult to comply with if we cannot explain how the artificial intelligence system arrives at a given result.

Similarly, it will be difficult to provide justifications for individual decisions that refer to the factual circumstances on which a decision is based, in accordance with Section 25 of the Public Administration Act, if we do not understand how the model works, which factors are given weight in the decision-making process, and how these factors have led to the outcome. We also have anti-discrimination protections under the Equality and Anti-Discrimination Act, which is intended to promote equality and prevent discrimination in Norwegian society. Since artificial intelligence is often trained on large datasets, it is important to be aware of biases in the data the model is trained on. Historical biases or errors in data collection can cause the model to make decisions on the wrong basis, and thus act in a discriminatory manner. We also have rules for the protection of intellectual property rights, such as copyright. Issues related to copyright may arise both in connection with the training of artificial intelligence and in the use of the material generated by the artificial intelligence.

As noted above, we already have legislation that sets clear guidelines for how we can develop and deploy artificial intelligence, even though these do not directly address the unique challenges associated with AI systems. We look forward to following these developments closely, both in terms of the benefits that artificial intelligence can bring and the developments in the legal sphere.

Etter et godt år som nyutdannede IT-konsulenter støter vi stadig på utfordringer i både arbeidslivet og i hverdagen, som vi har brukt generativ AI til å løse eller forbedre. Bli med oss på en reise i hva vi bruker AI til. 

AI for Kodeforbedring 

Vi har utforsket hvordan generativ AI kan optimalisere kode for økt lesbarhet og effektivitet. Nedenfor viser vi et Kotlin-kodeeksempel som kan forbedres, etterfulgt av en AI-optimalisert versjon. Forbedringene inkluderer mer intuitive funksjonsnavn, bedre parameter-navngivning, og håndtering av spesialtilfeller. 

La oss starte med den opprinnelige koden:

Kodeeksempelet ovenfor er et grunnleggende eksempel som tar inn en liste med heltall og regner ut gjennomsnittet av disse. For å gjøre koden mer lettlest kan vi gjøre små endringer. Vi lot AI hjelpe oss med forbedringene: 

I denne versjonen har funksjonsnavnet blitt gjort mer forståelig, parameteren har fått et mer beskrivende navn, og det er lagt til en sjekk for å håndtere et spesialtilfelle. Dette eksempelet viser hvordan koden kan gjøres mer lesbar og lett å forstå. 

Eksempelet vi bruker her er grunnleggende, men metodikken er også anvendelig på mer komplekse kodeutfordringer. 

Fremtidens søkemotor? 

Som utviklere kan vi ofte tilbringe betydelig tid på plattformer som Stack Overflow eller lignende steder i jakten på eksempler og løsninger på våre problemstillinger. Prosessen med å søke gjennom Google for å finne relevante tråder kan være tidkrevende, og det er ikke alltid lett å finne oppdatert informasjon i eldre dokumentasjon eller tråder. Med hjelp av ChatGPT kan prosessen forenkles. Ved å tilby raske og presise svar, reduseres behovet for dyptgående søk gjennom gamle tråder. Dette kan frigjøre verdifull tid for oss og andre utviklere, så vi får mulighet til å fokusere på dagens utfordringer med mer effektivitet og nøyaktighet. 

AI i Hverdagslivet 

Overfører vi dette til hverdagen, møter vi på liknende situasjoner. Som travle konsulenter i 20-årene, med tidsklemme og et kjøleskap som av og til ser ut som et kulinarisk puslespill, har vi vendt oss til AI for hjelp. I stedet for å søke blindt etter oppskrifter, spør vi vår AI-assistent om forslag basert på det vi har tilgjengelig. 

Vi spurte AI-assistenten vår ‘Hva kan jeg lage med laks, melk, mel, egg, smør, løk og brokkoli?’ 

Svaret ble en appetittvekkende laks- og brokkoligrateng, med en trinnvis oppskrift: 

Med ingrediensene laks, melk, mel, egg, smør, løk, og brokkoli, kan du lage en deilig laks- og brokkoligrateng. Her er en enkel oppskrift: 

Laks- og Brokkoligrateng 

Ingredienser: 

• 400 g laks (fersk eller frossen) 
• 300 g brokkoli, kuttet i små buketter 
• 1 stor løk, finhakket 
• 2 ss smør 
• 2 ss hvetemel 
• 400 ml melk 
• 2 egg 
• Salt og pepper etter smak 
• En klype muskatnøtt (valgfritt) 

Fremgangsmåte: 

1. Forbered Laksen og Brokkolien: Forvarm ovnen til 180°C. Hvis du bruker frossen laks, la den tine. Kok brokkolien i lettsaltet vann i ca. 3-4 minutter til den er al dente. Tøm av vannet og sett til side. 
2. Lag Hvitsausen: Smelt smør i en kjele på middels varme. Tilsett finhakket løk og stek til den er myk. Tilsett hvetemelet og rør godt. Spe gradvis med melk mens du rører, til sausen blir tykk og jevn. Kok opp, og la sausen småkoke i ca. 5 minutter. Smak til med salt, pepper og en klype muskat. 
3. Bland Inn Egg: Ta sausen av varmen. Rør inn ett egg om gangen, pass på at sausen ikke er for varm så eggene ikke koagulerer. 
4. Montering: Legg laksen i en smurt ildfast form. Fordel brokkolien rundt. Hell hvitsausen over. 
5. Stek: Stek i forvarmet ovn i ca. 20-25 minutter, eller til overflaten er gyllen og gratengen er gjennomvarm. 
6. Servering: La gratengen hvile i noen minutter før servering. Serveres varm, gjerne med et dryss av friske urter for ekstra smak. 

Nå vil jeg lage et bilde av hvordan denne retten kan se ut når den er ferdig. 

Utfordringer med AI 

Med stor makt følger også et stort ansvar. AI har mange fordeler, men det er også flere utfordringer som må tas på alvor. Overbruk av AI-systemer kan skape avhengighet av teknologi og vi kan risikere at kritisk tenkning og problemløsning blir negativt påvirket av bruken. AI-systemer behandler i tillegg store mengder data, inkludert personopplysninger. Selv om treffsikkerheten ofte er høy vil det alltid være en risiko for feil og fordommer, som man må være ekstra varsom på dersom man bruker det til avgjørelser som påvirker menneskers liv. Disse utfordringene understreker behovet for ansvarlig bruk og kontinuerlig etisk vurdering av AI-teknologi.           

Konklusjon 

Gjennom våre erfaringer med generativ AI, ser vi hvordan denne teknologien kan være en kraftfull ressurs for å løse komplekse problemstillinger og forenkle hverdagen. Samtidig minner de mulige utfordringene ved bruk av AI oss på viktigheten av en balansert og ansvarlig tilnærming til denne transformative teknologien. Ved bruk av AI er det avgjørende å ha en klar forståelse av systemets begrensninger og etiske implikasjoner for å sikre at vi drar full nytte av dens potensiale uten å gå på akkord med våre verdier og sikkerhet. 

 

Dette er innlegg 2 i en serie på 2 deler der vi skal se på hvordan vi kan bruke regelmotoren SMARTS til å vurdere konsekvensen av en eller flere endringer i forretningsreglene våre. I del 1 satte vi opp reglene for en fiktiv offentlig etat som behandler søknader om penger. I del 2 ser vi på hvordan vi kan vurdere konsekvensen av regelendringer.

Et eksempel er at en offentlig etat får spørsmål fra departementet om hvor stor innvirkning en viss regelendring politikerne vurderer vil ha på statsbudsjettet. Slike konsekvensvurderinger kan gjøres på mange måter. Her er en beskrivelse av hvordan det kan gjøres i regelmotoren SMARTS.

I dette eksemplet later vi som vi er en offentlig etat som behandler søknader om penger. La oss si at vi får et spørsmål fra departementet. Det viser seg at politikerne vurderer to regelendringer:

• Den ene er å legge til Viken fylke i listen over fylker vi godkjenner søknader fra.
• Den andre er å redusere utbetalingene fra 80 % av inntekten over 50 000 til 70 % av inntekten over 50 000.

Departementet lurer på hvordan dette vil slå ut på antall søknader som innvilges per år og totalt utbetalt beløp per år.

Vi kan legge inn de nye regelforslagene som alternative regler som vist under for beregningen:

Deretter kan vi kjøre et «experiment» der vi sammenlikner ulike konfigurasjoner av reglene. Vi kjører fire varianter av reglene og sammenlikner resultatene:

1. Dagens regler.
2. Dagens regler + ny regel for godkjente fylker.
3. Dagens regler + ny regel for beregning.
4. Begge de to nye reglene.

I SMARTS kan vi lett sammenlikne resultatene for de ulike konfigurasjonene. I bildet nedenfor sammenlikner vi resultatene for punkt 1 og 2 over.

Vi ser at det endres fra 7 avslag til 6 avslag blant våre 16 testcaser, og det medfører at totalt utbetalt beløp øker fra 2 900 800 til 3 172 000, en økning på 271 200. Blant våre 16 tester var det en søknad fra Viken, som med gamle regler ble avslått, men som med nye regler blir innvilget.

Vi kan altså se konsekvensen av den foreslåtte regelendringen på vårt sett av testcaser. For å svare på spørsmålet fra departementet kan vi gjøre en av følgende:

1. Påstå at vårt sett av testcaser er representativt for de faktiske søknadene vi får gjennom året, og gange opp med en viss faktor for at det skal tilsvare det faktiske antallet søknader gjennom året.
2. Lage et sett av testcaser som er representativt for de faktiske søknadene vi får gjennom året.
   a) Vi kan studere ekte søknader, intervjue saksbehandlere osv. og lage et sett av tester.
   b) Vi kan ta ekte søknader fra en viss periode (f.eks. 3 måneder av fjoråret, eller hele fjoråret), anonymisere de og bruke disse som testcaser.

Det er ikke lett å lage et sett av tester som er representativt for ekte søknader gjennom året. Det er heller ikke trivielt å anonymisere faktiske søknader, men det er en mulighet.

I tillegg til å lage et sett av tester som er representative for søknader vi pleier å få, må vi vurdere om søknader vi pleier å få er representative for hva vi vil få med nye regler. F.eks. kan det hende at vi får flere søknader fra Viken når vi begynner å innvilge også for dette fylket, fordi folk i dag lar være å søke fordi de vet at søknadene vil bli avslått. Det er altså sannsynlig med en større økning i utbetalt beløp enn den vi kan se på 271 200 i bildet over. Kanskje vi kan estimere basert på antallet søknader fra et tilsvarende fylke.

Verktøy som SMARTS hjelper oss med å vurdere konsekvensene av regelendringer på våre sett av testcaser, men vi må alltid tenke selv i tillegg og vurdere om det kan skje endringer som gjør at vårt sett av testcaser ikke er representativt for de søknadene vi vil få hvis regelendringen innføres. Til sammen lar dette oss svare departementet med et estimat på hvor mange søknader som vil innvilges med nye regler, og et estimat på totalt utbetalt beløp.

 

Dette er innlegg 1 i en serie på 2 der vi skal se på hvordan vi kan bruke regelmotoren SMARTS til å vurdere konsekvensen av en eller flere endringer i forretningsreglene våre. I del 1 setter vi opp reglene for en fiktiv offentlig etat som behandler søknader om penger. I del 2 ser vi på hvordan vi kan vurdere konsekvensen av regelendringer. 

I dette eksemplet later vi som vi er en offentlig etat som behandler søknader om penger. Søknadene skal innvilges hvis 

• søker er minst 18 år gammel 
• søker har inntekt på mer enn 50 000 kr per år og under 800 000 kr per år 
• søker bor i et av fylkene Vestland, Nordland, Agder eller Trøndelag. 

Når en søknad innvilges skal vi utbetale 80 % av den inntekten som overstiger 50 000 kr per år.

I bildet ovenfor ser vi at en person som er 29 år gammel med inntekt på 600 000 og som bor i Vestland fylke får innvilget søknaden, og får utbetalt 440 000. Reglene som avgjør dette kan se ut som vist i bildet nedenfor:

Vi lager til sammen 16 testcaser med ulike inputs og setter opp søylediagram som viser antall avslag, antall innvilgelser, og totalt utbetalt beløp. Vi ser at 7 av 16 søknader avslås, 9 av 16 innvilges, og totalt utbetales det 2 900 800 kr for innvilgede søknader (og 0 kr for avslåtte søknader).

Turnus-teamet er et lite team på tre personer som jobber med utvikling, forvaltning, test, kvalitetssikring og support av et egenutviklet turnussystem – og alle jobber fra hjemmekontor spredt i landet! Under pandemien ble alle sendt på hjemmekontor, men vi ble værende når samfunnet gikk tilbake til normalen. Vi så at hjemmekontor-løsningen fungerte veldig godt for oss og det er noen nøkkelfaktorer som bidrar til at løsningen fungerer.

Her er våre viktigste erfaringer (og tips!) til å få et velfungerende team basert på hjemmekontor:

1. Arbeidsgiver tilrettelegger for hjemmekontor: Det er ingen forventning fra arbeidsgiver sin side om at teamet skal møte opp på kontoret i det daglige. I tillegg er det opp til hver enkelt om vi vil sitte hjemme å jobbe eller på kontoret.
2. Alle i teamet sitter på hjemmekontor: Når alle sitter på hver sin kant får alle samme tilhørighet til teamet, som ikke hadde vært en selvfølge om noen hadde sittet sammen på kontoret og noen hadde sittet på hjemmekontor. Det er enkelt å ta kontakt med hverandre uten å være redd for å forstyrre andre fordi de som er på jobb sitter i kontorlandskap. I tillegg gjør digitale løsninger som Teams det sømløst å ringe hverandre for en prat eller for å dele skjerm.
3. Lite og selvstendig team med tydelige verdier: Teamet vårt er ikke avhengig av andre utenfor teamet. Vi tar selvstendige avgjørelser, samtidig som vi har enkel tilgang til andre ressurser i selskapet. For oss er en viktig faktor for at teamet fungerer at vi ønsker å nå de samme målene, det er rom for selvstendig initiativ og vi heier alle på hverandre. Det er ingen skjulte agendaer og alle vil hverandre vel.
4. Arbeidsoppgaver som krever individuelt fokus: Komplekse problemstillinger krever rom for konsentrasjon, som er enklere å oppnå på hjemmekontor enn i et åpent kontorlandskap.
5. Faste møtepunkter: Hver morgen møtes vi digitalt kl. 09:00 for å gå igjennom dagens oppgaver og avklarer eventuelle problemstillinger. Vi har også et uformelt ikke-faglig møte der vi snakker om løst og fast og har «kaffemaskin-praten». I løpet av året møtes vi for sosialt og faglig samvær, i tillegg til faste sosiale sammenkomster med hele arbeidsplassen.

Med utsikt som dette er det ikke rart vi trives på hjemmekontor 😊

Forutsetninger som må være på plass for at dette skal fungere

For at vi skal ha samhørighet til hverandre og ikke føle på ensomhet, må vi ha lav terskel for å ha hyppig kontakt. Alle i teamet har dessuten vært i arbeidslivet i mange år og for oss er lang erfaring en viktig faktor for at det skal fungere. Decisive er åpne for at vi kan sitte både hjemme og på kontoret, og når vi enkelt kan velge å jobbe hjemmefra slipper vi å bruke tid og energi på å pendle til og fra kontoret. Decisive holder til på Helsfyr i Oslo, så for et team som bor i Oslo, Østfold og på Vestlandet blir dette viktig for vår trivsel!

 

Kortversjonen: Ja, business rules eller forretningsregler, er relevant for offentlig forvaltning. Business er ikke en henvisning til noe kommersielt, din business er det du gjør.

Som konsulent og jurist som jobber med automatisering av beslutninger i offentlig forvaltning, hender det (mer før enn nå) at jeg møter på synspunktet om at business rules, eller forretningsregler som det heter på norsk, bare er relevant for kommersielle virksomheter. Kanskje ikke så rart. I Norge er vi vant til å tenke på business som noe kommersielt, men ordet har også en annen betydning – både på norsk og engelsk.

Business refererer til det du gjør, og ikke til noe kommersielt som vi kanskje lett kan tro.

Hvis du graver et lite hull i din egen hage, er det din business, og ikke naboens – som kanskje lurer på hva du gjør. Dersom virksomheten din er å forvalte en pensjonskasse, utbetale integreringstilskudd, utstede førerkort, fatte vedtak om byggetillatelser eller innvilge oppholdstillatelser når vilkårene er oppfylt, er det det som er forretningen din.

At vi på norsk oversatte business rules til forretningsregler lurer jeg på om egentlig var et arbeidsuhell. På svensk kan vi snakke om att få ordning på sina affärer, og de har også affärsregler. Kanskje burde vi omdøpe forretningsregler til foretaksregler eller virksomhetsregler?

 Illustrasjon som viser en metode for å beskrive forretningsregler.

Uansett, hovedpoenget i dette innlegget er at forretningsregler er regler som regulerer det forretningen gjør – selv om forretningen ikke er en kommersiell virksomhet. At forretningsregler har grensesnitt mot både rettsregler og systemregler får jeg komme tilbake til i et annet innlegg.

Selv bruker jeg forretningsregler både til å beskrive akseptansekriterier i brukerhistorier og til å beskrive rettsregler som styrer prosesser og automatiserte beslutninger – også i offentlig forvaltning.

Hvis du er nysgjerrig på hvordan du kan bruke konseptet forretningsregler i din virksomhet til å skrive presise krav som også er enkle å implementere, kan du gjerne ta kontakt.