This post was originally published on this site.

Säg att du kommer på en bra funktion som du vill ha i ert CRM. Hur bör du då gå tillväga? Jag skulle göra Use Cases men det gör långt ifrån alla. Vissa försöker kanske göra ändringen själv direkt, andra pratar igenom det med några kollegor och ytterligare några förpassar idén till bakhuvudet för att omedvetet bearbeta den under några dagar.

Oavsett hur man gör så är det viktigt att man tänker ett varv extra innan man skickar iväg en beställning på funktionen eller på egen hand börjar införa något nytt i en produktionsmiljö. Att föreställa sig ändringen ur andras perspektiv. I det stadiet brukar det som kallas för Use Cases, eller användningsfall som den svenska skaparen* började med att kalla dem, vara en bra metod för att utvärdera om man har tänkt på alla scenarios som kan uppstå.

Innan man blivit van vid att jobba med Use Cases kan det kännas som en lite märklig företeelse. Men när man väl gjort det några gånger inser de flesta hur enkelt det blir att formulera krav för en ny funktion. Och samtidigt blir det väldigt enkelt att testa funktionen när den är på plats i testmiljön (för alla använder sig väl av en testmiljö för att säkerställa att ny funktionalitet lever upp till kraven, eller hur?).

Låt mig beskriva hur du kan tänka

En person har noterat att landsnamn skrivs på olika sätt eller stavas fel vilket medför att alla rapporter som segmenteras på land blir felaktiga. Den föreslagna lösningen är att byta ut fritextfältet mot ett rullgardinsfält där alla länder finns förifyllda. Innan man gör detta byte måste man definiera vart denna information finns, hur den kan fyllas på och vad som påverkas av ändringen. Så därför skapar vi ett par Use Cases för att säkerställa att vi tänkt rätt.

Use Cases exempel

Det ursprungliga kravet handlar om att rapporter ska segmenteras korrekt på land, vilket ger det första Use Caset.

  • En person ska se data uppdelat på ”rätt” länder i rapporterna
    • Rapporterna ska alltså ta hänsyn till det nya fältet <land> istället för det gamla fältet

För att rapporterna ska stämma måste nya fälten <land> kunna uppdateras med korrekt information. Alltså behöver de anställda som jobbar i CRM kunna använda fälten.

  • En anställd ska kunna se och ändra värdet på fälten <land>
    • Vi måste lägga in de nya fälten på alla formulär där de befintliga fälten finns
      • Vi måste ta reda på vart de befintliga fälten ligger
    • Vi måste ge användare rättigheter för att se och ändra i fältet

För att användare inte ska använda det gamla fältet för land så bör något göras.

  • En användare i CRM ska inte se det gamla fältet för land
    • Vi ska dölja det på alla formulär det finns
    • Sätta rättigheter att endast ett fåtal anställda har rätt att ändra värdet i fältet

Vi vill knappast gå igenom alla befintliga poster i CRM manuellt för att lägga in landet i det nya fältet. Detta måste gå att lösa på ett bättre sätt.

  • En person behöver kunna göra en massuppdatering av de nya fälten land på befintliga poster.
    • Här kan man t.ex. använda sig av ett SSIS-paket

Nu har vi definierat några Use Cases, hur går vi vidare?

Vi börjar med att se över hur vi ska lösa de uppkomna frågorna på bästa sätt. Först tittar vi på det som är direkt kopplat till rapporterna.

Alla befintliga rapporter som använder sig av land tar hänsyn till vad som står i det gamla fältet. Att göra om alla befintliga rapporter vekar väldigt tidskrävande och bör om möjligt undvikas. Med andra ord vill vi att rapporterna ska fortsätta att använda det gamla fältet för land, samtidigt som fältet hålls uppdaterat med korrekt data. En lösning kan vara att skapa ett arbetsflöde som varje gång det nya fältet uppdateras kopierar dess innehåll till det gamla fältet. Problem löst med minimal arbetsinsats!

Då det nya fältet skall finnas på flera formulär behöver vi skapa ett fält per entitet där man kan ange land i CRM. För att slippa ha flera olika listor över alla länder så låter vi alla fält peka på en och samma lista, en global alternativuppsättning. Då får vi flera fält med länder men endast en lista att underhålla. Där sparade vi en hel del tid på underhåll av systemet!

Så vart finns alla dessa fält för land som vi är intresserade av? På konto, kontakt, lead. Det innebär en global alternativuppsättning och 3 separata fält som pekar på det.

Men vänta nu… Företaget har ju ett webformulär där potentiella kunder kan ange sitt intresse för företagets produkter och dessa blir automatiskt skapade som leads i CRM. Vilken tur att vi kom på det!

Kunderna anger vilket land de verkar i på hemsidan, men där kommer vi inte ha tillgång till den nya rullgardinslistan utan bara ett textfält. Vi behöver ett arbetsflöde som automatiskt försöker sätta rätt land i det nya fältet beroende på vad som angetts i webformuläret. Men vad händer om det inte fungerar? Vi behöver ett Use Case till!

  • En användare i CRM måste kunna se alla leads där värdet för land i det gamla och nya fältet inte stämmer överens
    • Vi behöver skapa en vy som visar alla leads som uppfyller detta kriterium. På så sätt kan vi enkelt hitta och manuellt hantera dessa.

Att tänka rätt före ger fler fördelar

Som ni kan se så börjar det enkla lilla ingreppet att byta ut ett fält förvandlas till något lite mer komplicerat. Detta i sig är kanske inte så roligt, men det är väldigt mycket bättre att fånga dessa frågeställningar innan man börjar ändra på något. Genom att fånga upp alla saker som behöver hanteras kan man göra en mycket bättre skattning av hur mycket en ändring kommer kosta. I slutändan hjälper detta er att undvika att slösa på tid och pengar på ändringar som kostar mer än de smakar. Och allt detta genom att tänka efter, före.

*  https://en.wikipedia.org/wiki/Use_case#History