Licensoptimering - Mönster
Lär dig mer om välstrukturerad resurs- och kostnadsoptimering → Licensiering och konsumtion
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Organisation | ✅ Licenstyper matchas till faktiska användarkrav och användningsmönster (inte jobbtitlar) |
| Plattform | Organisation | ✅ Användare som endast får åtkomst till egna objekt får plattformslicenser istället för fullständiga Salesforce-licenser |
| Plattform | Organisation | ✅ Externa användare (kunder, partners, diskussionsgruppmedlemmar) använder Experience Cloud-licenser istället för interna licenser |
| Plattform | Organisation | ✅ Användare som endast kräver autentisering utan dataåtkomst får Identity-licenser |
| Plattform | Organisation | ✅ Kvartalsvisa licensgranskningar identifierar användare som endast får åtkomst till egna objekt som plattformslicenskandidater |
| Plattform | Organisation | ✅ Automatiska kvartalsrapporter identifierar användare med noll inloggningar på 90 dagar, användare som endast får åtkomst till egna objekt och externa användare med interna licenser för systematisk rätt storlek |
| Plattform | Organisation | ✅ Licenstilldelningar granskas och justeras baserat på rolländringar istället för att förbli oförändrade i flera år |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Organisation | ⚠️ Fullständiga Salesforce-licenser tilldelas alla anställda baserat på jobbtitel istället för faktiska systemanvändningsmönster |
| Plattform | Organisation | ⚠️ Användare som endast öppnar egna objekt får fullständiga Sales Cloud- eller Service Cloud-licenser istället för Platform-licenser |
| Plattform | Organisation | ⚠️ Externa användare konsumerar intern licenskapacitet istället för Experience Cloud-licenser |
| Plattform | Organisation | ⚠️ Licenstilldelningar som angetts under den inledande distribueringen förblir oförändrade i tre år trots rolländringar |
| Plattform | Organisation | ⚠️ Licensgranskningar utförs aldrig; 40 % av licenserna är oanvända eller underutnyttjade |
| Plattform | Organisation | ⚠️ Användare som loggar in färre än en gång i månaden identifieras inte som kandidater för licensåtervinning |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Säkerhet | ✅ Shield-komponenter (plattformskryptering, händelseövervakning, fältgranskningslogg) utvärderas individuellt baserat på om de uppfyller specifika efterlevnadsbehov |
| Data 360 | Arkitektur | ✅ Data 360-investering motiveras av krav på korssystemidentitetslösning, åtkomst till kunddata i realtid eller segmentaktivering |
| AI | Företag | ✅ AI-investering kräver visad ROI inom definierade mätperioder istället för att anta ospecificerat värde |
| Plattform | Industry Clouds | ✅ Industry Clouds (Finanstjänster, Hälsovård, Tillverkning, Net Zero) utvärderas mot egna utvecklingskostnader och tid-till-marknadskrav |
| Plattform | Industry Clouds | ✅ Industry Cloud-utvärdering upptäcker 40-60% snabbare implementering för standardflöden men tar hänsyn till anpassningar som minskar tidsbesparingar |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Säkerhet | ⚠️ Alla Shield-komponenter köps utan att utvärdera om specifika komponenter uppfyller faktiska efterlevnads- eller säkerhetsbehov |
| Data 360 | Arkitektur | ⚠️ Data 360 köps utan att utvärdera om enklare integreringsmetoder uppfyller kraven |
| AI | Företag | ⚠️ AI-investeringar saknar mätbara mått för affärsvärde eller ROI-demonstration |
| AI | Företag | ⚠️ AI-investeringar förutsätter att värdet levereras utan att definiera specifika mätperioder eller framgångskriterier |
| Plattform | Industry Clouds | ️ Industry Clouds köps utan att jämföras med egna utvecklingskostnader eller validera time-to-market-acceleration |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Provisionering | ✅ Nytt användarprovisioneringsflöde tilldelar automatiskt plattformslicenser för användare som endast har åtkomst till egna appar |
| Plattform | Provisionering | ✅ Nya användare provisionering arbetsflöde köar externa användare för Experience Cloud-licenstilldelning baserat på e-postdomän |
| Plattform | Provisionering | ✅ Tilldelningspolicyer definierar tydliga kriterier för licenstyper baserat på användarroll och plattformsanvändningskrav |
| Plattform | Provisionering | ✅ Godkännandeflöden kräver verksamhetsmotivering för premiumlicenstyper |
| Plattform | Provisionering | ✅ Lämplig licenstilldelning tillämpas vid provisionering istället för att korrigera felaktiga tilldelningar retroaktivt |
| Plattform | Organisation | ✅ Återkallandeprocesser identifierar automatiskt inaktiva användare (60-90 dagar) och återkräver oanvända licenser för återtilldelning |
| Plattform | Organisation | ✅ Inloggningsbaserade rapporter identifierar användare inaktiva i 60-90 dagar baserat på organisationspolicyer |
| Plattform | Organisation | ✅ Kvartalsvis återvinning förhindrar licensavfall från att samlas när anställda byter roller eller lämnar organisationen |
| Plattform | Nyckeltal | ✅ Instrumentpaneler för användningsövervakning följer inloggningsfrekvens, funktionsanvändningsmönster och licenstyplämplighet |
| Plattform | Företag | ✅ Användningsdata delas med företagsledare för att möjliggöra datadrivna licensinvesteringsbeslut under förnyelseplanering |
| Rapporter och instrumentpaneler → Instrumentpanel för licensanvändning Inställningar → Användare → Aktiva användare | ✅ Mönster: Instrumentpaneler för licensanvändning visar aktiva jämfört med inaktiva licenser, distribution av inloggningsfrekvens, funktionsanvändning efter licenstyp och distribution av licenstyp ✅ Användningsinstrumentpaneler avslöjar inaktiva användare, överlicensierade användare och licenstypfel som kräver granskning |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Provisionering | ⚠️ Licenstilldelningspolicyer finns inte; varje begäran hanteras ad hoc |
| Plattform | Provisionering | ⚠️ Godkännandeflöden kräver inte verksamhetsmotivering för premiumlicenstyper |
| Plattform | Organisation | ⚠️ Inaktiv användaridentifiering är manuell och sällan snarare än automatiserad |
| Plattform | Organisation | ⚠️ Återkallande av licenser sker endast under årlig förnyelse istället för kvartalsvis |
| Plattform | Organisation | ⚠️ Licensavfall ackumuleras i åratal när anställda byter roll eller slutar utan licensåtervinning |
| Plattform | Nyckeltal | ⚠️ Instrumentpaneler för användningsövervakning finns inte; användningsmönster är okända |
| Plattform | Företag | ⚠️ Affärsledare saknar insyn i licensanvändningsdata under förnyelseplanering |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Kontrakt | ✅ Användarantal åtaganden stöds av verksamhetsplaner snarare än optimistiska prognoser |
| Plattform | Kontrakt | ✅ Ramp scheman matchar investering till faktiska användare onboarding tidslinje istället för att betala för outnyttjad kapacitet i förväg |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Kontrakt | ⚠️ Överengagemang för användarantal skapar omedelbart slöseri genom att oanvända licenser konsumerar budget utan att leverera värde |
| Plattform | Kontrakt | ️ Fleråriga avtal tecknas utan att flexibilitetsbehoven utvärderas om tillväxtprognoserna visar sig vara felaktiga |
| Plattform | Kontrakt | ⚠️ Sann timing matchar inte verksamhetsplaneringscykler; justeringar släpar efter faktiska ändringar av antalet anställda |
| Plattform | Kontrakt | ⚠️ Organisationen har 200 oanvända licenser i 18 månader eftersom anställningsplanen försenas efter att de har åtagit sig att uppnå volymrabatt |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Arkitektur | ✅ Integreringsarkitektur planerar API-användning och utvärderar om Enterprise eller Unlimited Edition ger bättre TCO |
| Plattform | Arkitektur | ✅ Edition kostnadsjämförelsemodeller per användare premie mot inkluderade kapaciteter (API-gränser, lagring, sandboxallokeringar, Premier Support) |
| Plattform | Arkitektur | ✅ Edition beslutsmodeller beräknad användning mot båda prissättningsmodellerna med dokumenterade antaganden som möjliggör framtida omvärdering |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Arkitektur | ⚠️ Val av version blir som standard högsta eller lägsta nivå baserat på budgetbegränsningar utan att analysera arkitektoniska krav |
| Plattform | Arkitektur | ️ Enterprise Edition har valts för att minimera kostnaden per användare utan att beräkna integreringskrav och API-överskottskostnader |
| Plattform | Arkitektur | ⚠️ Integreringskraven överskrider gränserna efter distribuering, vilket resulterar i dubbel kostnad genom API-överskott plus arkitektonisk omarbetning |
| Plattform | Arkitektur | ⚠️ Versionsbeslut fattas utan att modellera faktisk användning mot både prissättningsmodeller eller dokumentera antaganden |
| Plattform | Organisation | ⚠️ Valet av version baseras endast på den årliga prenumerationskostnaden per användare utan begränsningar för modellering |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Arkitektur | ✅ Enskilda organisationsoptimeringsmetoder (delningsregler, behörighetsuppsättningar, posttyper) utvärderas innan du börjar använda arkitektur för flera organisationer |
| Plattform | Arkitektur | ✅ Multi-org TCO-modell visar 2-3x multiplikation av driftskostnader inklusive administration, releasehantering, övervakning, incidentsvar och efterlevnad |
| Plattform | Arkitektur | ✅ Flerorganisationsarkitektur används endast när lagstadgade krav (GDPR-datalagring, ekonomisk separation) kompenserar ökade kostnader |
| Plattform | Arkitektur | ✅ Motivering för flera organisationer dokumenterar äkta isoleringskrav som enskilda organisationer med behörighetsgränser inte kan uppfylla |
| Plattform | Kontrakt | ✅ Multi-org-licens kostar modell separata licenspooler per organisation förlorar volymprissättning och kräver dubbletter av administrativa licenser |
| Plattform | Arkitektur | ✅ Flera organisationers driftskostnader modellerar parallellt underhåll över flera implementeringar vilket multiplicerar utveckling och operativ ansträngning |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Arkitektur | ⚠️ Flerorganisationsarkitektur antas eftersom affärsenheter “vill ha oberoende” utan modellering 2-3x kostnadsmultiplikation |
| Plattform | Arkitektur | ⚠️ Användning av flera organisationer sker utan att utvärdera om en enskild organisation med delningsregler skulle uppfylla faktiska krav till en bråkdel av kostnaden |
| Plattform | Arkitektur | ⚠️ TCO-modellen för flera organisationer inkluderar inte multiplikation av driftskostnader (2-3x för administratör, releasehantering, övervakning, efterlevnad) |
| Plattform | Arkitektur | ⚠️ Arkitektur för flera organisationer saknar dokumenterad affärsmotivering som visar att värdet överskrider permanent och ökar kostnaderna |
| Plattform | Kontrakt | ⚠️ Kostnadsanalys för flera organisationer tar inte hänsyn till separata licenspooler som förlorar fördelar med volymprissättning |
| Plattform | Arkitektur | ️ Operativ börda för flera organisationer modelleras inte; parallellt underhåll mellan organisationer upptäcks efter distribuering |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Integrering | ✅ Multi-org TCO inkluderar MuleSoft-licensiering ($ 20K-$ 200K + årligen), integreringsutveckling, löpande underhåll och API-kapacitetsplanering |
| Plattform | Integrering | ✅ Korsorganisationsintegreringskostnader modelleras uttryckligen som visar MuleSoft-investeringar, utvecklingsinsatser och ihållande driftskostnader |
| Plattform | Arkitektur | ✅ API-konsumtion multiplikation modelleras: korsorganisationstransaktioner som konsumerar 5-10 API-anrop över flera organisationer samtidigt |
| Plattform | Integrering | ✅ Data enhetlighet overhead för att upprätthålla synkroniserade referensdata mellan organisationer inkluderar utvecklingsinsatser, övervakning och konfliktlösning |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Integrering | ⚠️ Flerorganisationsarkitektur är godkänd baserat på jämförelse av licenskostnader utan att modellera årliga integreringskostnader på 240 000 dollar |
| Plattform | Integrering | ️ Integreringskostnader mellan organisationer modelleras inte uttryckligen; en enskild organisation skulle helt eliminera dessa kostnader |
| Plattform | Arkitektur | ⚠️ Multiplikation av API-konsumtion från korsorganisationsanrop beaktas inte i kapacitetsplanering |
| Plattform | Integrering | ⚠️ Datakonsekvensoverhead för synkroniserade referensdata inkluderas inte i TCO-modellen för flera organisationer |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Inställningar → Sandboxar → Miljöstrategi DevOps → Allokeringsplan för sandbox | ✅ Mönster: Team använder Developer Pro-sandboxar för funktionsutveckling med låtsasdata, Delvis kopia med riktade konton för integreringstest ✅ Reserverar Full Copy exklusivt för förproduktion UAT och prestandavalidering där fullständig datavolym är arkitektoniskt nödvändig |
| Inställningar → Sandboxar → Balanserad strategi Ekonomi → Miljöbudget | ✅ Mönster: Utvecklarteam med 15 personer implementerar balanserad strategi med 15 Developer Pro-sandboxar (750 dollar i månaden), 3 Delvis kopia för parallella arbetsströmmar (900 dollar i månaden), 1 Fullständig kopia för UAT (3 000 dollar i månaden) ✅ Totalt $ 4 650 månatlig matchning faktiska utvecklingsmönster snarare än överprovisionering för teoretisk maximal parallellism |
| Inställningar → Sandboxmallar → Dataval Inställningar → Delvis kopieringskonfiguration | ✅ Mönster: Sandboxmallen Partial Copy inkluderar de senaste 12 månadernas säljprojekt och kundcase men utesluter arkiverade data ✅ Ger representativa testdata inom 5 GB kapacitet istället för att kräva Full Copy, vilket möjliggör billigare sandboxtyp genom strategiskt dataval |
| Process → Sandboxlivscykel Inställningar → Tillfällig miljöspårning | ✅ Mönster: Tillfällig sandboxhantering följer miljöer som skapats för specifika projekt med dokumenterade borttagningsdatum ✅ Implementera utgångspolicyer som kräver förnyelsemotivering för att upprätthålla tillfälliga miljöer utöver ursprunglig omfattning som förhindrar permanent statusdrift |
| Konfiguration → Uppdateringsschema för sandbox Kalender → Uppdateringsoptimering | ✅ Mönster: Optimering av uppdateringskadens anpassar sandboxuppdatering till faktiska krav på färskhet istället för arbiträra scheman ✅ Kvartalsvis fullständig kopia uppdatering räcker när månatlig uppdatering är onödig för att testa mönster, vilket frigör kapacitet för ytterligare sandboxar |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Överprovisionering → Bortkastade investeringar | ⚠️ Antimönster: Organisationen köper fem Full Copy-sandboxar för att ge varje utvecklingsteam dedikerade miljöer ⚠️ Multiplicerar kostnaderna 5-10x när Partial Copy skulle uppfylla de flesta testkraven; Fullständig kopia bör reserveras för scenarion som kräver fullständig produktionstrohet |
| Ingen strategi → Premiumstandard | ⚠️ Antimönster: Team med 15 personer köper premiumstrategier med 30 Developer Pro och 5 Full Copy-sandboxar (18 000 dollar i månaden) eftersom “fler miljöer är alltid bättre” ⚠️ Ingen analys som visar utvecklingshastighet begränsad av miljötillgänglighet; balanserad strategi skulle leverera samma hastighet på 4 650 dollar i månaden |
| Ofiltrerade mallar → Tvångsuppgraderingar | ⚠️ Antimönster: Mallen Partial Copy inkluderar alla objekt utan filtrering och förbrukar 5 GB kapacitet med historiska data som inte är relevanta för tester ⚠️ Tvingar köp av fullständig kopia när strategiskt dataval skulle aktivera användning av delvis kopia till 5-10x lägre kostnad per sandbox |
| Sandboxspridning → Permanent tillfällig | ⚠️ Antimönster: Tillfällig spridning av sandboxar när projektsandboxar övergår till permanent status utan motivering ⚠️ Inga utgångsdatum eller förnyelsekrav som tillåter tillfälliga miljöer att ackumulera konsumerande budget i all oändlighet |