Publisert i bloggen, mandag 9. desember 2013:

CRM-systemet «Kontor»

CRM står for Customer relationship management. På godt norsk kunderelasjonshåndtering.

Mangel på rutiner

Jeg drev sammen med flere partnere nettavisen Liernett fra 2003 og frem til 2012, da vi la ned driften. Fra 2005 ble jeg daglig leder av Liernett, og hadde derfor ansvaret for Liernetts økonomi. I motsetning til konkurrerende lokalaviser som hadde annonseinntekter, abonnementsinntekter, rubrikkmarkedsinntekter og ikke minst statlig subsidiering, hadde Liernett bare ett ben å stå på: Annonseinntekter.

I Liernetts spede begynnelse ble det «solgt» noen få annonser, men ingen av oss drev Liernett for å sitte med fakturaer og regnskap. Vi skulle gi ut nettavis, ikke sitte med administrative oppgaver. Så alt gikk derfor i null. Altså ikke bare kostnadene, men også inntektene, grunnet fravær av fakturering.

Nå tenker du at det kanskje bare var sløvhet, for det er jo bare å kladde ned beløp, kontonummer og forfallsdato, pluss noen formalia, og så sende faktura av gårde i posten. Og ja, du har nok kanskje rett. Hadde vi bare hatt en bankkonto...

Etablering av rutiner

Høsten 2005 formaliserte vi en del saker, noe som ga oss mer dedikerte roller innenfor organisasjonen. En var redaktør, en var daglig leder og en var annonseselger. Nå var også tiden inne for å opprette en bankkonto!

Men siden rollene som daglig leder og annonseselger var fordelt på to personer ble det fort vanskelig å holde oversikten over hva som var solgt av annonser, til hvilken pris, for hvilken tidsperiode, og ikke minst til hvem.

Det oppstod et behov for et CRM-system.

Jeg utviklet derfor et enkelt system og kalte det for «Kontor». Liernett hadde aldri noe fast kontorlokale, så det meste av kommunikasjon foregikk på våre interne systemer hvor vi blant annet hadde kontinuerlig oppdaterte nyhetsagenter som tipset oss om saker, et internt forum for redaksjonen, oppdatert besøksstatistikk og interne forfallskalendere (hvem dekker hva når). Navnet «Kontor» passet derfor godt til dette tilleggsystemet som skulle håndtere økonomien.

CRM-systemet skulle håndtere følgende oppgaver:

Databasemodellen

Databasen var veldig enkel med svært få tabeller.

Konseptuelt

Helt sentralt står salg. Et salg er knyttet til minimum og maksimum én bedrift (kunde). Salget kan også knyttes til minimum null og maksimum én faktura (ingen tilknytning før faktura opprettes). Hver aktivitet er knyttet til minimum og maksimum én bedrift.

datamodell-konseptuell.png

Endelig datamodell

Datamodellen nedenfor viser de forskjellige tabellene og deres relasjoner med primærnøkler (understreket), fremmednøkler (*asterisk) og forhold (en til mange, mange til mange osv.):

datamodell.png

Jeg har kun tatt med det som er relevant her, og har utelatt blant annet en del metadata for å forenkle presentasjon. Eksempler på slike metadata er opprettet tidspunkt, sist endret tidspunkt, opprettet av bruker og sist endret av bruker. Jeg har også utelatt en «ekstern» tabell med brukere, da denne egentlig tilhører Liernett på et overordnet nivå og ikke er relevant i denne sammenhengen.

Jeg har også utelatt tabeller som har kommet til senere, slik som varelagerkontroll, da dette ikke var en del av det opprinnelige konseptet.

Kritikk

Ser du hvilke to ting som skurrer litt i denne datamodellen?

  1. Poststed burde vært skilt ut i en egen tabell. Poststed i en egen tabell er jo et velkjent skoleeksempel innen datamodellering. Grunnen til at jeg ikke har gjort det i dette tilfellet var mest fordi det lille arbeidet med å taste inn poststed var noe jeg kunne leve med, samtidig som en hyperlokal nettavis som Liernett stort sett hadde kunder som opererte innenfor en liten håndfull lokale postnummer, som ville være lett å vedlikeholde manuelt. Men likevel, å ikke gjøre det skaper unødvendig redundans.
  2. I tabellen FAKTURA ser jeg nå at jeg faktisk har bedrift_id som en fremmednøkkel, til tross for at FAKTURA egentlig kun skal være knyttet direkte til SALG, og ikke BEDRIFT. Å gjøre det slik forenklet riktignok programmeringen for nettstedet, men det er kanskje ikke god praksis?

Et annet problem her, som ikke har med datamodellen å gjøre, men mer med god forretningsførsel å gjøre er at man i teorien kan endre en faktura lenge etter at den er fakturert. Endrer man kundedata på kundekortet vil de samme kundedataene endres på fakturaen også. En faktura skal altså låses og forbli nøyaktig slik den var da den ble utstedt.

Brukergrensesnitt

Systemet skulle være enkelt og tilgjengelig fra en hvilken som helst nettleser. Selger ville ha ansvar for kundebehandlingen og salgsarbeidet, mens daglig leder ville håndtere faktureringen og rapporteringen. Og begge ville ha innsyn i den andres arbeid. Alle endringer ble logget, slik at man enkelt kunne se hvem som gjorde hva og når.

Jeg lar skjermdumpene nedenfor fortelle resten (alle kundedata er anonymisert):

Kundekort:
kundekort.png

Aktiviteter som har blitt logget:
aktiviteter.png

Oversikt over alle salg:
salgsoversikt.png

Viser et enkeltsalg:
enkeltsalg.png

Oversikt over alle opprettede fakturaer:
fakturaoversikt.png

Viser enkeltfaktura:
enkeltfaktura.png

Faktura genereres som PDF-dokument for utskrift på giroblankett:
giroblankett.png

Videre bruk av systemet

Jeg måtte etter hvert utvikle en del tilleggsfunksjoner til «Kontor»:

Jeg har også tatt i bruk det samme CRM-systemet for Sylling Hardcode. «Kontor» har vist seg å være velegnet også for fakturering av arbeidstimer.

Relatert innhold

Google Analytics API: Muligheter
Publiseringssystemet Outpost
Publiserings -systemet

Bloggen

Paid and organic last click
Are og Ida på date
Kunstig intelligens
Vekst- prosjektet
Da Outlook stjal ikonet mitt
Sen eller tidlig påske?
Koordinater i SVG
Påstand: Corner er mål
Vestfold-Rogaland kalkulator
Twitter og VM på ski
My New Year's Resolutions
Et bilde sier mer enn tusen ord
Rogaland blir nye Vestfold
På størrelse med Vestfold
Datoformat i Excel og Google Analytics
what3words Hvilke tre ord?
Covfefe will make America great again
Om domenenavn og firmanavn
Fotballfrue: Jeg tar innpå deg
Sakte-TV: Se gresset gro
Sakte-TV: Se maling tørke
Første generasjon iPapp har kommet
Jukselapp fotografering
Det sorte hullet cookies disabled
Høysesong for kjipe annonser
Om analsex og popups
Rotasjon av vindsymboler
Hvor mye er Fotballfrue verdt?
Slik tar du et screenshot
Nyttige husketrekanter
Enklere utregning med kryssmultiplisering
Min egen lille adventskalender
Logge antall likes på Facebook
Hva er sitemap.xml?
Hva er robots.txt?
Responsivt design
Webscraping med PHP
Jeg sammenligner epler og pærer
Scalable Vector Graphics
Google Analytics API: Hente data
Google Analytics API: Muligheter
HTML5: Video
Big Data
Cookies: Hvordan det brukes
Cookies: Hva er det?
Excel i to vinduer
CRM-systemet «Kontor»
Gigantisk timelapse
Hva er jQuery?
Overvåke ReadyNAS DUO med PHP
Favicon - ikonet i adressefeltet
Animert heading på hardcode.no
CSS -sprites
Komprimere PNG-bilder
Redesign av hardcode.no
Klikkbar flash uten clickTAG
Relevans har stor verdi
Alle har wide- screen i 2013
Markedsandeler nettlesere 2010
Internet Explorer-vindu i feil størrelse
Hvor stor er en piksel?
Markedsføring og kundelojalitet
Flash-versjoner
Vestre Sylling og Øverskogen JFF
Sidevisninger, besøk og brukere
Widescreen kommer
Hvor brede bør sidene være?
Fortsatt lese hele saken?
Lese hele saken nå?
Første møte med AdWords
Bort med IE6
Utviklingen på nettleserfronten
Nyttige jukselapper
Nye Sylling.no
Klær med egen logo?
Værdata fra yr.no
Logodesign trender i 2008
Gmail grimaser
Google Analytics
Publiseringssystemet Outpost
Hardcode.no relanseres
Publiserings -systemet