, ,

Fra issuetracker til hendelsesrapportering — 18 måneder med egenutviklet sakssystem

Dashboard for hendelsesrapportering

For halvannet år siden bygde vi et sakshåndteringssystem. Den historien har vi fortalt. Det som har skjedd siden er mer interessant — fordi det viser hva som skjer når et system faktisk brukes i produksjon, av ekte mennesker, hver dag.

Systemet vokste innenfra

Opprinnelig var det enkelt: kunder, prosjekter, saker. En sak ble opprettet, kommentert, og lukket. Det fungerte, men etter noen måneder begynte brukerne å presse på grensene.

Operatørene ville legge ved bilder direkte fra nettbrettet — så vi la til bildevedlegg med lightbox-visning. Arbeidslederne ville ha statistikk — så vi bygde dashboards. Ledelsen ville varsles ved alvorlige hendelser — så vi la til automatiske e-postvarsler ved høy og kritisk alvorlighetsgrad.

Ingen av disse funksjonene var i den opprinnelige planen. De kom fordi systemet ble brukt, og brukerne sa «dette mangler».

Hendelsesrapportering

Den største utvidelsen kom da en kunde trengte et system for å rapportere produksjonsavvik — ikke bare IT-saker, men fysiske hendelser i verkstedet. Verktøybrudd, kvalitetsavvik, maskinproblemer, HMS-relaterte observasjoner.

Vi bygde hendelsesrapportering som en utvidelse av det eksisterende saksystemet. Samme grensesnitt, men med tilpassede kategorier, alvorlighetsnivåer, og en egen statistikkside som viser trender over tid.

Det tok to uker å bygge. Hadde vi kjøpt et ferdig HMS-system, ville vi brukt to måneder på implementering og tilpasning — og fått et system som gjør 80 ting vi ikke trenger, og mangler de 3 tingene vi faktisk trenger.

Nyhetsbrev til kundene

En annen funksjon som vokste frem organisk: nyhetsbrev. Når du har et system med kunder, prosjekter og aktivitet, er steget kort til å sende ut en månedlig oppsummering. Hva ble gjort, hva er planlagt, og hva bør kunden vite.

Nyhetsbrevet genereres fra data som allerede finnes i systemet — ingen dobbeltregistrering, ingen manuell skriving av statusrapporter. Det tar noen minutter å redigere og sende.

Hyllevare vs. skreddersøm

Spørsmålet «hvorfor ikke bare bruke Jira/Trello/Asana?» kommer alltid. Svaret er todelt:

  1. Integrasjon. Systemet er bygget i Laravel og kjører på vår egen server. Det snakker med bankintegrasjonen, CNC-programvarens feilrapporter, og kundens interne systemer. Det er ingen API-grenser, ingen ratebegrensninger, ingen tredjepartsavhengigheter.
  2. Tilpasning. Når en operatør sier «kan jeg velge verktøy fra en liste i stedet for å skrive fritekst?», er det 30 minutter med koding. I et hyllevaresystem er det en feature request som kanskje blir implementert om 6 måneder.

Det betyr ikke at skreddersøm alltid er riktig. For en bedrift med standardbehov er Jira utmerket. Men for en produksjonsbedrift med spesifikke prosesser, spesifikke maskiner og spesifikke rapporteringskrav, er et tilpasset system ofte billigere på sikt — og mye raskere å tilpasse.

Hva vi lærte

Den viktigste lærdommen er at et system ikke er ferdig når det lanseres. Det er ferdig når det slutter å bli brukt — og da har det mislyktes. Et godt system vokser med brukerne. De finner hull, melder dem inn, og systemet tilpasses.

Det krever at utvikleren er tett nok på brukerne til å forstå hva de faktisk trenger, ikke bare hva de sier at de trenger. Og det krever en arkitektur som tåler å bli utvidet uten å bli ustabil.

Etter 18 måneder i drift har systemet håndtert tusenvis av saker, generert hendelsesstatistikk som har endret prosedyrer, og spart ledelsen for timer med manuell rapportering hver måned. Ikke verst for noe som startet som en enkel issuetracker.

Trenger du et system som gjør akkurat det du trenger — og ingenting annet? Ta kontakt for en uforpliktende prat.


Trenger du hjelp med dette?

Ta kontakt for en uforpliktende prat om hvordan jeg kan hjelpe deg.

Navn