Data, inloggning och åtkomst

Systemets minne

Vilken uppgift gäller egentligen?

En användbar app hjälper människor att arbeta med samma verklighet.

Vi följer ett påhittat städföretag med fem anställda. Chefen Samira har flyttat ett städjobb från tisdag till onsdag efter önskemål från kunden. Hon ändrar i sin kalender. En medarbetare läser fortfarande tisdag i ett gammalt mejl. Båda tycker att de har koll. Kunden är snart av en annan åsikt.

Samira vill bygga ett verktyg där jobbets aktuella datum finns på ett bestämt ställe. Personalen ska öppna sitt schema och få samma besked som hon. Där börjar frågan om data: uppgifterna som systemet använder. Det kan vara ett datum, en adress, en notering eller vem som fått uppdraget.

Samira behöver bestämma vilken plats som gäller när uppgifter skiljer sig åt. I hennes tänkta arbetssätt ska det nya verktyget vara källan till dagens schema. Om mejl och kalendrar också används behöver de få sina uppgifter därifrån eller uppdateras enligt en tydlig rutin.

AI kan hjälpa henne ordna informationen. Men Samira måste först beskriva hur företaget arbetar och vem som får besluta om en ändring. Databasen kan komma ihåg onsdag. Den kan inte själv veta att Samira menade torsdag.

Databasen i vardagsspråk

Kunder och jobb hör ihop

Börja med vilka saker företaget behöver hålla reda på.

En databas är ett sätt att ordna och spara uppgifter så att ett program kan hitta och ändra dem. En vanlig sorts databas använder tabeller med rader och kolumner. En rad kan vara ett jobb, med datum, kund och status i olika kolumner. [1]

Tabeller kan också kopplas ihop. Ett jobb kan höra till en viss kund, och samma kund kan ha flera jobb. [1] I Samiras system vill vi dessutom koppla varje jobb till den personal som ska utföra det. Då kan samma grunduppgifter användas i flera vyer.

När Samira flyttar jobbet till onsdag vill hon att onsdag visas både i hennes planering och i medarbetarens schema. Hon kan beskriva det direkt för AI: Datumet ska komma från samma sparade jobb, även när det visas på olika sidor.

Du behöver inte rita en teknisk databasmodell för att ta det samtalet. Börja med företagets egna ord: kunder, beställningar, rum, maskiner eller bokningar. Förklara sedan hur de hör ihop.

Uppgifter och filer

Var hamnar bilden och avtalet?

En bild av en skada och en notering om skadan fyller olika funktioner.

En medarbetare upptäcker en trasig golvlist hos en kund och tar ett foto. Samira vill samla både bilden och en kort notering på rätt städjobb. Då blir skillnaden mellan sparade uppgifter och fillagring tydlig. Fillagring används för exempelvis bilder och dokument. [2]

Appen behöver hålla reda på kopplingen mellan noteringen och filen. När Samira öppnar jobbet ska hon kunna se rätt foto. Personalen ska kunna förstå vad som hänt utan att leta i en gruppchatt där bilden redan hunnit försvinna mellan två lunchfrågor.

Samma tanke fungerar för avtal, ritningar och arbetsbeskrivningar. Fråga vilket sammanhang filen hör till och vilka som behöver den. Själva filen behöver också rätt åtkomstregler; att skydda sidan där länken visas räcker inte i sig. [3]

Det är ett tydligt uppdrag till den som bygger: När någon öppnar ett jobb ska relevanta filer finnas där, med samma genomtänkta gränser för åtkomst.

Två olika frågor

Vem är du, och vad får du göra?

Att vara inloggad betyder inte att man ska få tillgång till allt.

Inloggning hjälper systemet att kontrollera vem användaren är. Behörighet avgör vad den personen får komma åt. Det är två olika uppgifter, även när samma tjänst hjälper till med båda. [4] Samiras app behöver därför både känna igen personalen och tillämpa företagets regler för åtkomst.

Det här är ett förslag för vårt exempel. Ditt företag kan behöva andra gränser. En medarbetare kanske ska kunna föreslå ett nytt datum, medan arbetsledaren bekräftar det. Att läsa, ändra och godkänna är olika saker. Beskriv dem var för sig när du ger AI uppdraget.

Tänk också på när någon byter team eller slutar. I Samiras arbetssätt ska en ändrad tilldelning påverka vilka jobb personen ser, och avslutad anställning leda till att kontots åtkomst tas bort. Sådana vardagshändelser är bra att beskriva redan i idén till verktyget.

Regler bakom gränssnittet

Dold på skärmen är inte låst

Systemet behöver kontrollera rätten att få uppgifter, även bakom den snygga sidan.

Anta att Samira ser alla jobb medan en medarbetare bara ser sina egna. Det ser rätt ut. Men om appen först skickar alla jobb till medarbetarens webbläsare och sedan gömmer de flesta på skärmen, har uppgifterna ändå redan skickats dit.

Behörighetskontrollen måste därför finnas bakom gränssnittet, där åtkomsten till uppgifterna avgörs. En dold knapp eller ett filter i webbläsaren räcker inte som skydd. Systemet måste även neka en otillåten förfrågan som kommer på ett annat sätt än genom den vanliga sidan. [3]

Du behöver kunna uttrycka det här kravet även om du inte skriver kontrollen själv. När AI presenterar lösningen kan du be den visa var regeln gäller och hur det går att kontrollera den. Svaret ska handla om att otillåten åtkomst stoppas, inte bara om hur sidan ser ut.

För Samira är poängen enkel: personalen ska kunna göra sitt jobb, och kundernas uppgifter ska följa de gränser företaget har bestämt.

Dela underlag med eftertanke

Vad behöver AI egentligen läsa?

Att något finns i företagets system betyder inte att varje AI-uppgift behöver det.

Samira vill lägga till en AI-hjälp som kan svara på personalens frågor om arbetsmetoder. En medarbetare undrar hur företagets rutin för en viss golvtyp ser ut. AI behöver då den relevanta arbetsbeskrivningen. Kundens fakturor och alla andra medarbetares scheman tillför ingenting till just det svaret.

Börja med att beskriva vilken uppgift AI ska lösa och vilket underlag den behöver. Gör sedan tillgången så begränsad som uppgiften tillåter. Det följer principen att ge den åtkomst som behövs för arbetet. [3] En AI som bara ska läsa rutiner behöver exempelvis inte kunna ändra bokningar.

Skilj också på uppgifter som används inne i företagets app och sådant som skickas till en extern AI-tjänst. Samira behöver veta vilket underlag som lämnar appen och bedöma om det är lämpligt att dela. Att hon själv får läsa ett avtal är ett annat beslut än att låta en ansluten AI-tjänst behandla det.

När hon diskuterar idén kan hon använda påhittade kunder och exempeluppgifter. För att förklara att ett schema har datum, jobb och tilldelad personal behövs ingen verklig kundlista. Den riktiga datan kan vänta tills hon vet vad lösningen ska göra med den.

Ditt nästa initiativ

Beskriv informationen före bygget

Ett kort samtal om uppgifter kan göra hela idén tydligare.

Samira har nu en tydligare bild av sitt verktyg. Det ska hålla ihop kunder, jobb och personal. Filer ska höra till rätt jobb. Olika personer ska kunna göra olika saker, och AI-hjälpen ska bara få det underlag som behövs. Hon kan be sin kodande AI hjälpa henne fånga detta innan bygget blir stort.

När översikten känns rimlig kan Samira ta ställning till detaljerna: Behöver medarbetaren hela kundhistoriken eller bara dagens arbetsbeskrivning? Vem får flytta ett jobb? Vilka uppgifter ska finnas kvar efter att jobbet är klart? Det är verksamhetsbeslut som hon nu kan leda.

Hur informationen kan återställas och vem som sköter lösningen över tid hör till nästa samtal. Läs vidare i Att äga det man bygger när du är redo för den delen.