Licensoptimering - mønstre
Læs mere om veludviklet ressourceoptimering → Licensering og forbrug
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Platform | Organisation | ✅ Licenstyper matches med faktiske brugerkrav og anvendelsesmønstre (ikke jobtitler) |
| Platform | Organisation | ✅ Brugere, der kun har adgang til tilpassede objekter, modtager platformslicenser i stedet for fulde Salesforce-licenser |
| Platform | Organisation | ✅ Eksterne brugere (kunder, partnere, fællesskabsmedlemmer) bruger Experience Cloud-licenser i stedet for interne licenser |
| Platform | Organisation | ✅ Brugere, der kun kræver godkendelse uden dataadgang, modtager Identity-licenser |
| Platform | Organisation | ✅ Kvartalsmæssige licensrevisioner identificerer brugere, der kun har adgang til tilpassede objekter som platformslicenskandidater |
| Platform | Organisation | ✅ Automatiserede kvartalsvise rapporter identificerer brugere med nul-logins på 90 dage, brugere, der kun har adgang til tilpassede objekter, og eksterne brugere på interne licenser til systematisk højre størrelse |
| Platform | Organisation | ✅ Licenstildelinger gennemgås og justeres baseret på rolleændringer i stedet for at forblive uændrede i årevis |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Organisation | ⚡️ Fuld Salesforce-licenser tildeles til alle medarbejdere baseret på jobtitel snarere end faktiske systemanvendelsesmønstre |
| Platform | Organisation | ⚡️ Brugere, der kun har adgang til tilpassede objekter, modtager fulde Sales Cloud- eller Service Cloud-licenser i stedet for platformslicenser |
| Platform | Organisation | ⚡️ Eksterne brugere forbruger intern licenskapacitet i stedet for Experience Cloud-licenser |
| Platform | Organisation | ⚡️ Licenstildelinger, der er angivet under den indledende implementering, forbliver uændrede i tre år, på trods af rolleændringer |
| Platform | Organisation | Licensrevisioner udføres aldrig. 40 % af licenserne er ubrugte eller underanvendte |
| Platform | Organisation | ⚡️ Brugere, der logger på færre end månedligt, identificeres ikke som kandidater til licensgenoprettelse |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Platform | Sikkerhed | ✅ Shield-komponenter (platformskryptering, begivenhedsovervågning, feltrevisionsspor) evalueres individuelt baseret på, om de håndterer specifikke overensstemmelsesbehov |
| Data 360 | Arkitektur | ✅ Data 360-investering er berettiget af krav til løsning af krydssystemidentitet, adgang til kundedata i realtid eller segmentaktivering |
| AI | Forretning | ✅ AI-investering kræver demonstreret investeringsafkast inden for definerede målperioder i stedet for at antage en uspecifik værdi |
| Platform | Industry Clouds | ✅ Industry Clouds (Finansielle tjenester, Sundhed, Produktion, Net Zero) evalueres op mod tilpassede udviklingsomkostninger og tid-til-marked-krav |
| Platform | Industry Clouds | ✅ Industry Cloud-evaluering genkender 40-60 % hurtigere implementering for standardarbejdsflows, men tager højde for tilpasning, hvilket reducerer tidsbesparelser |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Sikkerhed | ⚡️ Alle Shield-komponenter købes uden at evaluere, om specifikke komponenter håndterer faktiske overensstemmelses- eller sikkerhedsbehov |
| Data 360 | Arkitektur | Data 360 købes uden at evaluere, om enklere integrationsmetoder opfylder kravene |
| AI | Forretning | ⚡️ AI-investering mangler målbare forretningsværdimetrikker eller ROI-demonstration |
| AI | Forretning | ⚡️ AI-investeringer antager, at værdien vil blive leveret uden at definere specifikke målperioder eller succeskriterier |
| Platform | Industry Clouds | ⚡️ Industry Clouds købes uden at sammenligne med tilpassede udviklingsomkostninger eller validere tids-til-markeds-forøgelse |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Platform | Provisionering | ✅ Nyt brugerprovisioneringsarbejdsflow tildeler automatisk platformslicenser til brugere, der kun har adgang til tilpassede apps |
| Platform | Provisionering | ✅ Ny brugerprovisioneringsarbejdsflowkøer eksterne brugere for Experience Cloud-licenstildeling baseret på maildomæne |
| Platform | Provisionering | ✅ Tildelingspolitikker definerer tydelige kriterier for licenstyper baseret på brugerrolle og krav til platformsanvendelse |
| Platform | Provisionering | ✅ Godkendelsesarbejdsflows kræver forretningsjustering for premiumlicenstyper |
| Platform | Provisionering | ✅ Korrekt licenstildeling håndhæves på provisioneringstidspunktet i stedet for at rette forkerte tildelinger retroaktivt |
| Platform | Organisation | ✅ Genanvendelsesprocesser identificerer automatisk inaktive brugere (60-90 dage) og tilbagekalder ubenyttede licenser til gentildeling |
| Platform | Organisation | ✅ Loginbaserede rapporter identificerer inaktive brugere i 60-90 dage baseret på organisationspolitikker |
| Platform | Organisation | ✅ Kvartalsvis tilbagebetaling forhindrer, at licensaffald akkumuleres, når medarbejdere skifter roller eller forlader organisationen |
| Platform | KPI’er | ✅ Dashboards til overvågning af anvendelse sporer loginfrekvens, funktionsanvendelsesmønstre og relevans for licenstype |
| Platform | Forretning | ✅ Anvendelsesdata deles med forretningsledere, der aktiverer datastyrede licensinvesteringsbeslutninger under fornyelsesplanlægning |
| Rapporter og dashboards → Dashboardet Licensanvendelse Opsætning → Brugere → Aktive brugere | ✅ Mønster:**** Licensanvendelsesdashboards viser aktive kontra inaktive licenser, loginfrekvensfordeling, funktionsanvendelse efter licenstype og licenstypefordeling ✅ Anvendelsesdashboards afslører inaktive brugere, overlicenserede brugere og ikke-matches for licenstyper, der kræver gennemgang |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Provisionering | ⚡️ Licenstildelingspolitikker findes ikke. Hver anmodning håndteres ad hoc |
| Platform | Provisionering | ⚡️ Godkendelsesarbejdsflows kræver ikke forretningsjustering for premiumlicenstyper |
| Platform | Organisation | ⚡️ Inaktiv brugeridentifikation er manuel og sjælden i stedet for automatiseret |
| Platform | Organisation | ⚡️ Licenskupring sker kun under årlig fornyelse i stedet for kvartalsvis |
| Platform | Organisation | ⚡️ Licensaffald akkumuleres i årevis, når medarbejdere skifter roller eller forlader uden licensgenoprettelse |
| Platform | KPI’er | ⚡️ Dashboards til overvågning af anvendelse findes ikke. Anvendelsesmønstre er ukendte |
| Platform | Forretning | ⚡️ Forretningsledere mangler synlighed i data om licensanvendelse under fornyelsesplanlægning |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Platform | Kontrakter | ✅ Brugeroptællingsforpligtelser understøttes af forretningsplaner snarere end optimistiske prognoser |
| Platform | Kontrakter | ✅ Ramp-tidsplaner matcher investeringer med den faktiske brugerintroduktionstidslinje i stedet for at betale for ikke-anvendt kapacitet på forhånd |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Kontrakter | For meget forpligtelse over for brugerantal skaber øjeblikkeligt spild gennem ikke-anvendte licenser, der forbruger budget uden at levere værdi |
| Platform | Kontrakter | ⚡️ Flerårige aftaler signeres uden at evaluere fleksibilitetsbehov, hvis vækstprojiceringer viser sig at være ukorrekte |
| Platform | Kontrakter | ⚡️ True-up-tidsangivelse matcher ikke forretningsplanlægningscyklusser. Justeringer er forsinkede efter faktiske personantalændringer |
| Platform | Kontrakter | Organisationen har 200 ikke-anvendte licenser i 18 måneder, fordi ansættelsesplanen forsinkes efter forpligtelse til at opnå en mængderabat |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Platform | Architektur | ✅ Integrationsarkitekturplanlægning projekterer API-forbrug og evaluerer, om Enterprise eller Unlimited Edition giver bedre TCO |
| Platform | Architektur | ✅ Version omkostningssammenligningsmodeller pr. brugerpræmie op mod inkluderede funktioner (API-grænser, lager, sandbox-tildelinger, Premier Support) |
| Platform | Architektur | ✅ Prognosticeret anvendelse af beslutningsmodeller for versioner op mod begge prismodeller med dokumenterede antagelser, der aktiverer fremtidig genevaluation |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Architektur | ⚡️ Valg af version sættes som standard til højeste eller laveste niveau baseret på budgetbegrænsninger uden at analysere arkitektoniske krav |
| Platform | Architektur | ⚡️ Versionen Enterprise er valgt for at minimere omkostninger pr. bruger uden at forudsige integrationskrav og API-overforbrugsomkostninger |
| Platform | Architektur | ⚡️ Integrationskrav overskrider grænserne efter implementering, hvilket resulterer i 2x omkostninger gennem API-overforbrug plus arkitektonisk omarbejdning |
| Platform | Architektur | ⚡️ Beslutning om version træffes uden at modellere faktisk anvendelse op mod både prissætningsmodeller eller dokumenterede antagelser |
| Platform | Organisation | ⚡️ Valg af version er udelukkende baseret på pr. bruger - årlig abonnementsomkostninger uden arkitektoniske begrænsninger |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Platform | Architektur | ✅ Enkeltorganisationsoptimeringstilgange (delingsregler, tilladelsessæt, registreringstyper) evalueres, før du anvender multiregionsarkitektur |
| Platform | Architektur | ✅ Multi-org TCO-model viser 2-3 gange multiplikation af driftsomkostninger, herunder administration, versionsstyring, overvågning, hændelsessvar og compliance |
| Platform | Architektur | ✅ Flere organisationsarkitektur anvendes kun, når bestemmelseskrav (GDPR-dataplacering, økonomisk adskillelse) forskynder øgede omkostninger |
| Platform | Architektur | ✅ Flerorganisationsjustering dokumenterer ægte isoleringskrav, som enkeltorganisation med tilladelsesgrænser ikke kan opfylde |
| Platform | Kontrakter | ✅ Multi-organisations licensomkostninger model adskilte licenspuljer pr. organisation, der mister mængdeprissætning og kræver dubletadministrative licenser |
| Platform | Architektur | ✅ Parallel vedligeholdelse af model for driftsomkostninger for flere organisationer på tværs af flere implementeringer, der gange udviklingen og den driftsmæssige indsats |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Architektur | ⚡️ Flere-organisationsarkitektur er ibrugtaget, fordi forretningsenheder “ønsker uafhængighed” uden modellering af 2-3 gange multiplikation af omkostninger |
| Platform | Architektur | ⚡️ Ibrugtagning af flere organisationer sker uden at evaluere, om enkeltorganisation med delingsregler ville opfylde faktiske krav til en brøkdel af omkostningerne |
| Platform | Architektur | ⚡️ Multi-org TCO-model inkluderer ikke multiplikation af driftsomkostninger (2-3 gange for administrator, versionsstyring, overvågning, overensstemmelse) |
| Platform | Architektur | ⚡️ Flerorganisationsarkitektur mangler dokumenteret forretningsjustering, der viser værdien overskrider permanent og multiplikation af sammensatte omkostninger |
| Platform | Kontrakter | ⚡️ Analyse af omkostninger for flere organisationer tager ikke højde for, at separate licenspuljer mister fordele ved mængdeprissætning |
| Platform | Architektur | Driftsbelastning for flere organisationer er ikke modelleret. Parallel vedligeholdelse på tværs af organisationer findes efter implementering |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Platform | Integration | ✅ TCO for flere organisationer inkluderer MuleSoft-licens ($20.000-$200.000 årligt), integrationsudvikling, igangværende vedligeholdelse og API-kapacitetsplanlægning |
| Platform | Integration | ✅ Krydsorganisationsintegrationsomkostninger er eksplicit modelleret, der viser MuleSoft-investeringer, udviklingsindsats og vedvarende driftsomkostninger |
| Platform | Architektur | ✅ API-forbrugsmultiplikation er udarbejdet: krydsorganisationstransaktioner, der forbruger 5-10 API-kald på tværs af flere organisationer samtidigt |
| Platform | Integration | ✅ Dataoverensstemmelse overhead til vedligeholdelse af synkroniserede referencedata på tværs af organisationer inkluderer udviklingsindsats, overvågning og konfliktløsning |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Integration | ⚡️ Flere organisationsarkitektur godkendes baseret på licensomkostningssammenligning uden modellering af årlige integrationsomkostninger på 240.000 USD |
| Platform | Integration | ⚡️ Omkostninger til krydsorganisationsintegration er ikke eksplicit modelleret. Single-org ville eliminere disse omkostninger fuldstændigt |
| Platform | Architektur | ⚡️ Multiplikation af API-forbrug fra krydsorganisationsopkald tages ikke med i betragtning i kapacitetsplanlægning |
| Platform | Integration | Dataoverensstemmelse overhead for synkroniserede referencedata er ikke inkluderet i multi-org TCO-model |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Opsætning → Sandboxes → Miljøstrategi DevOps → Sandbox-tildelingsplan | ✅ Mønster:**** Team bruger Developer Pro-sandboxes til funktionsudvikling med mock-data, Delvis kopi med målrettede konti til integrationstest ✅ Reserverer fuld kopi udelukkende til førproduktions-UAT og validering af ydeevne, hvor fuld datamængde er arkitektonisk nødvendig |
| Opsætning → Sandboxes → Balanceret strategi Finance → Miljøbudget | ✅ Mønster:**** 15-personers udviklingsteam implementerer en afbalanceret strategi med 15 Developer Pro-sandboxes ($ 750 pr. måned), 3 Delvis kopi for parallelle arbejdsstreams ($ 900 pr. måned), 1 Fuld kopi for UAT ($ 3.000 pr. måned) ✅ Totaler $4.650 pr. måned, der matcher faktiske udviklingsmønstre i stedet for overprovisionering for teoretisk maksimal parallelisme |
| Opsætning → Sandbox-skabeloner → Datavalg Opsætning → Delvis kopi-konfiguration | ✅ Mønster:**** Delvis kopi-sandbox-skabelon inkluderer de sidste 12 måneder af salgsmuligheder og sager, men ekskluderer arkiverede data ✅ Leverer repræsentative testdata inden for 5 GB kapacitet i stedet for at kræve Fuld kopi, hvilket aktiverer en sandbox-type med lavere omkostninger gennem strategisk datavalg |
| Proces → Sandbox-livscyklus Opsætning → Midlertidig miljøsporing | ✅ Mønster:**** Midlertidig sandbox-styring sporer miljøer, der er oprettet for specifikke projekter med dokumenterede sletningsdatoer ✅ Implementer udløbspolitikker, der kræver fornyelsesjustering for at vedligeholde midlertidige miljøer ud over det indledende omfang, der forhindrer permanent statusforskydning |
| Opsætning → Sandbox-opdateringsplan Kalender → Opdater optimering | ✅ Mønster:**** Optimering af opdateringskadence justerer sandbox-opdatering med faktiske krav til dataopdatering snarere end vilkårlige tidsplaner ✅ Kvartalsvis fuld kopi-opdatering er tilstrækkelig, når månedlig opdatering er unødvendig for test af mønstre, hvilket frigør kapacitet for yderligere sandboxes |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Overprovisionering → Spildte investeringer | ⚡️ Anti-mønster: Organisation køber fem Full Copy-sandboxes for at give hvert udviklingsteam et dedikeret miljø ⚡️ Ganger omkostninger 5-10 gange, når Delvis kopi ville opfylde de fleste testkrav. Fuld kopi bør reserveres til scenarier, der kræver fuld produktionsfidelitet |
| Ingen strategi → Premium-standard | ⚡️ Anti-mønster: 15-personers team køber Premium-strategi med 30 Developer Pro- og 5 Full Copy-sandboxes ($18.000 pr. måned), fordi “flere miljøer er altid bedre” ⚡️ Ingen analyser, der viser udviklingshastighed begrænset af miljøtilgængelighed. Afbalanceret strategi vil levere den samme hastighed ved $4.650 pr. måned |
| Ufiltrerede skabeloner → Tvungne opgraderinger | ⚡️ Anti-mønster: Skabelonen Delvis kopi inkluderer alle objekter uden filtrering, hvilket forbruger 5 GB kapacitet med historiske data, der ikke er relevante for test Kræver fuld kopi-køb, når strategisk datavalg ville aktivere Delvis kopi-anvendelse til 5-10 gange lavere omkostninger pr. sandbox |
| Sandbox Sprawl → Permanent Midlertidig | ⚡️ Anti-mønster: Midlertidig sandbox-udbredelse som projekt-sandboxes skifter til permanent status uden begrundelse ⚡️ Ingen udløbspolitikker eller fornyelseskrav, der tillader midlertidige miljøer at akkumulere forbrugerbudget uendeligt |