Dansk forskningsprojekt genopfinder ERP ? nu uden database

DIKU er med i et forskningsprojekt, der forsøger at finde den optimale tredjegenerations ERP-software. Blandt andet er databasen skrottet til fordel for en event-log.

Hvad ville du gøre, hvis du fik mulighed for at skrive din ERP-software om ? sådan helt fra grunden?

Det spørgsmål kan Microsoft, SAP og Oracle nu tygge lidt på, for til nytår kommer en dansk forskergruppe med deres forslag til, hvordan tredje generation af ERP-systemer kunne være bygget.

Forskergruppen består af forskere fra CBS og fra Datalogisk Institut på Københavns Universitet, DIKU. Ph.d.-studerende på DIKU, Morten Ib Nielsen, afleverer i slutningen af oktober sin afhandling, der indgår som en del af det store projekt, der går under navnet 3gERP. Projektet er støttet af Højteknologifonden, og har CBS, DIKU og Microsoft som partnere.

Customisering og konfigurering gør ERP dyrt
»Projektet udspringer af en undren over, hvorfor ERP skal være så besværligt og dyrt for små og mellemstore virksomheder. Det, der bidrager til en høj TCO (total cost of ownership, de totale levetidsomkostninger, red.) er, når de store standardsystemer skal customiseres og konfigureres og vedligeholdes. Vi beskæftiger os både med eksisterende ERP-systemer såsom Microsoft Dynamics NAV, men søger også at give et 'revolutionært' bud på, hvordan ERP kan forenkles ved at tage deres grundlæggende softwarearkitektur op til revision,« siger Morten Ib Nielsen.

Grundstenen i den revolutionære tilgang er, at den traditionelle tankegang, hvor ERP-softwaren ligger oven på en database, smides over bord.

Event-log i stedet for database
»I stedet for en relationel database opererer vi med en event-log,der fungerer som en form for in-memory-database. Forestil dig en lang kassestrimmel, hvor alle input bare tilføjes nederst,« forklarer Morten Ib Nielsen.

Tilgangen med en event-log har tre forudsætninger, som projektet forsøger at imødekomme.

For det første er der et særligt rapport-sprog, så brugere kan bede om svar på naive spørgsmål af typen ?læs alle data og lav beregningen?.

»Fidusen er så, at rapport-sproget automatisk transformerer rapport-funktionen til inkrementielle beregninger, der kan vedligeholdes i real time i takt med, at nye events bliver tilføjet event-loggen,« siger Morten Ib Nielsen.

Det er ph.d.-studerende Patrick Bahr, ligeledes fra DIKU, der har ansvaret for denne del af projektet.

Kontrakt-sprog placerer aben, når det går galt

Den anden hovedkomponent er en kontrakt-engine. ERP skal naturligvis kunne holde styr på forretningsprocesser, altså hvem der gør hvad hvornår. Når en event tilføjes, kigger motoren på, om den hører til en eksisterende kontrakt.

Denne del varetages af DIKU's Tom Hvidtved. »Det, der adskiller kontraktsproget fra gængse workflow-løsninger er, at det er muligt at afgøre, hvis skyld det er, hvis kontrakten bliver brudt,« siger Tom Hvitved.

Endelig er der et regelsystem, der fortæller ERP-systemet, hvordan virkeligheden ser ud. Dette er udgangspunktet for Morten Ib Nielsens bidrag til 3gERP-projektet:

Domænespecifikt sprog styrer reglerne
»En udfyldt salgsordre skal indeholde både pris og moms, og de er afhængige af hinanden. Jeg laver et domænespecifikt sprog, så jurister og revisorer i princippet kan indskrive reglerne direkte i systemet. Målet er at undgå, at en lovændring betyder, at al kode skal skrives om. I dag er det svært at se, hvordan reglerne arbejder inde i systemet, men på denne måde gør vi reglerne til et manipulerbart dataobjekt,« forklarer Morten Ib Nielsen.

Med tiden forestiller han sig endda, at mellemledet med jurister og revisorer helt kan forsvinde, hvis man fik landets lovgivere med på ideen om, at administrative ændringer af operationel karakter blev skrevet direkte i det domænespecifikke sprog i stedet for at udkomme som prosa.

Tilsammen danner de tre elementer kernen i det, som et ERP-system skal kunne, og som 3gERP-projektet definerer med akronymet POETS, Proces-Oriented Event-driven Transaction System. POETS skal være med til at minimere de omkostninger til customisering og konfigurering, som ethvert ERP-system indebærer.

... Nu også på Android
3gERP-projektet løber ind til slutningen af 2010, men inden da holder projektet i hele august et kursus på DIKU, hvis mål er at implementere forskellige komponenter til POETS ved brug af udviklingsmetoden SCRUM, herunder web- og Android-klienter.

De første resultater forventes at foreligge i september. Men de store ERP-producenter behøver ikke frygte, at brødet bliver taget ud af munden på dem lige med det første.

»Målet for vores udvikling er en proof-of-concept prototype, som fokuserer på den nye arkitektur. Derfor er vi selvfølgelig ikke i nærheden af at have alle de features, der kendes fra moderne ERP-systemer. Men selvfølgelig ville det være interessant at se nogle af perspektiverne videreført i fremtidige produkter for hurtigt og pålideligt at kunne tilpasse systemer til de altid skiftende krav,« siger Morten Ib Nielsen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

Den omtalte eventlog indeholder alle de oplysninger, der skal til for at lave business intelligence og data mining / data warehousing. Det er blot et spørgsmål om at lave de rigtige rapportfunktioner til at udtrække data. Disse rapportfunktioner bliver så automatisk transformeret til effektiv kode, der inkrementelt opdaterer rapporten, når der kommer nye events til.

Man kan tænke på eventloggen som en liste af alle de ændringer, der er sket på en traditionel ERP database siden systemet blev sat i gang. Derfor kan man udtrække, hvad der svarer til snapshots af enhver tidligere databasetilstand samt statistik over bestemte typer events i bestemte perioder -- uden at man behøver at have forudset, at man ville lave denne forespørgsel tidligere.

Denne eventlog fylder selvfølgelig mere end en traditionel database, men den giver mere fleksibilitet og et [i]paper trail[/], som kan bruges til analyser og dokumentation (revision osv.). Udfordringen er at strukturere denne log og de funktioner, der arbejder med den, så det ikke tager en evighed, hver gang man skal lave en forespørgsel.

  • 0
  • 0
Morten Ib Nielsen

Ang. DW kan man spørge sig selv, hvad det skal bruges til. Det er jo ikke et formål i sig selv, at have et DW. Hvis BI er svaret, så er det her erstattet af omtalte reporting-engine (med tilhørende sprog). Sproget giver rig mulighed for at udtrykke BI beregninger.

  • 0
  • 0
Jeppe Cramon

Et rigtig spændende projekt. Selve princippet ligger meget tæt på CQRS (Command Query Responsibility Segregation), som jeg selv er stor tilhænger af, da det skaber nogle dejligt fleksible systemer. Har projektet en hjemmeside, hvor man kan læse mere om hvordan I har tacklet selve process delen?

  • 0
  • 0
Kim Dalsgaard

Hej Morten, jeg tror I vil kunne bygge et meget robust system op omkring CouchDb. Hver business transaktion kunne være et dokument i databasen (f.eks. kontantsalg, faktura etc.). Disse dokumenter kunne så 'emit'te posteringer ved hjælp af en map funktion (feks. salg, skyldig moms, etc.). Posteringerne kunne aggregeres ved hjælp reduce funktioner.

PS. Det var ikke min mening at være spydig (vist bare en gammel refleks).

  • 0
  • 0
Henrik Schmidt

Nu har jeg efterhånden nogle gange hørt den med, at når man laver et DSL, så kan domæne-eksperter i princippet direkte programmere, hvad de gerne vil have. Er der noget litteratur/forskning på området, der undersøger, hvordan det ser ud i praksis?

Dermed ikke være sagt, at et DSL ikke kan være en fremragende idé, men der har været så mange forsøg på, at få ikke programmører til at programmere, at jeg er gået hen og blevet en smule skeptisk :)

  • 0
  • 0
Log ind eller Opret konto for at kommentere