Sakssystemet etter 18 måneder: hendelsesrapportering og nyhetsbrev

For halvannet år siden bygde vi et sakshåndteringssystem (første del av historien). Dette innlegget handler om hva som er lagt til etter at det ble tatt i bruk i produksjon.

Funksjonene kom fra brukerne

Opprinnelig hadde systemet kunder, prosjekter og saker. En sak ble opprettet, kommentert og lukket. Etter noen måneder begynte brukerne å be om mer.

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 med i den opprinnelige planen. De ble lagt til fordi brukerne meldte at de manglet.

Hendelsesrapportering

Den største utvidelsen kom da en kunde trengte å rapportere produksjonsavvik: fysiske hendelser i verkstedet i tillegg til IT-saker. Det gjaldt verktøybrudd, kvalitetsavvik, maskinproblemer og HMS-relaterte observasjoner.

Vi bygde hendelsesrapporteringen som en utvidelse av det eksisterende saksystemet, med samme grensesnitt, egne kategorier og alvorlighetsnivåer, og en statistikkside som viser trender over tid.

Det tok to uker. Et ferdig HMS-system ville etter vårt anslag tatt to måneder å implementere og tilpasse, og hatt 80 funksjoner vi ikke trenger og manglet de 3 vi trenger.

Nyhetsbrev til kundene

Systemet har allerede kunder, prosjekter og aktivitet, så vi la til et månedlig nyhetsbrev: hva ble gjort, hva er planlagt, og hva kunden bør vite.

Nyhetsbrevet genereres fra data som allerede ligger i systemet. Ingenting registreres to ganger, og ingen statusrapporter skrives for hånd. Det tar noen minutter å redigere og sende.

Hvorfor vi ikke bruker Jira, Trello eller Asana

Det spørsmålet får vi ofte. Den første grunnen er integrasjon. Systemet er bygget i Laravel og kjører på vår egen server. Det henter data fra bankintegrasjonen, CNC-programvarens feilrapporter og kundens interne systemer, uten API-grenser, ratebegrensninger eller tredjepartsavhengigheter.

Den andre grunnen er tilpasning. Da en operatør ba om å velge verktøy fra en liste i stedet for å skrive fritekst, tok det 30 minutter å kode. I et hyllevaresystem er det en funksjonsforespørsel som kanskje blir implementert om 6 måneder.

For en bedrift med standardbehov er Jira et godt valg. En produksjonsbedrift med egne prosesser, maskiner og rapporteringskrav får ofte et egenutviklet system billigere på sikt, og det er raskere å endre.

Hva vi lærte

Et system er ikke ferdig når det lanseres. Brukerne finner hull, melder dem inn, og systemet endres. Det krever at utvikleren er nær nok brukerne til å forstå hva de trenger, som ikke alltid er det de ber om. Det krever også en arkitektur som tåler utvidelser uten å bli ustabil.

Etter 18 måneder i drift har systemet håndtert tusenvis av saker. Hendelsesstatistikken har ført til endrede prosedyrer, og ledelsen bruker færre timer på manuell rapportering hver måned.

Trenger du et system tilpasset egne prosesser, ta kontakt.