x

    10 Anaplan-bästa praxis för att optimera din modell

    • LinkedIn
    • Twitter
    • Copy
    • |
    • Shares 8
    • Reads 2265
    Author
    • Tushar SonalTushar SonalInsiktsutforskaren
      Om data är olja, så är analys förbränningsmotorn i denna era.
    Published: 22-September-2021
    Anaplan partners
    • Anaplan
    • Datateknik
    Icon Sammanfatta detta blogginlägg med:
    Bästa praxis för Anaplan-modellbyggare fokuserar på logisk struktur, optimerade formler, minimala dimensioner och effektiv moduldesign för maximal prestanda.

    Varför är det avgörande att optimera Anaplan-modeller för prestanda, implementering och avkastning på investeringen?

    Som Anaplan-modellbyggare är det få saker som når upp till spänningen som när du bygger din Anaplan-modell för planering. Du känner redan längtan efter att driftsätta den. Men vänta! Nu är det dags att optimera! Optimera! Optimera!

    Det kan inte nog betonas – att optimera dina modeller är ett mycket viktigt steg som modellbyggare i Anaplan för att förbättra prestandan för din Anaplan-modell, spara på licenskostnader, få till stånd en större användning av lösningen och därmed driva förbättrad avkastning på dina Anaplan-investeringar.

    Följande är några bästa praxis som vi har sammanställt, baserat på vår erfarenhet av Anaplan-implementeringar, för hur du optimerar din Anaplan-modell för bästa prestanda och kostnadsbesparingar.

    Hur DISCO-metoden hjälper Anaplan-modellbyggare att optimera modeller?

    Den första bästa praxisen för Anaplan som vi ska prata om är DISCO, som följer 'L' eller LOGICAL i Anaplans bredare PLANS-ramverk.

    anaplan disco

    PLANS är ramverket eller principerna kring vilka alla Anaplan-modeller bör byggas. DISCO utvecklas från principen att Anaplans modellprestanda optimeras om beräkningarna utförs över samma dimensionalitet. Även om det inte alltid är möjligt, bör modellen utformas på ett sådant sätt att beräkningarna är så samordnade som möjligt.

    Detta är kärnan i DISCO. Som modellbyggare på Anaplan behöver du skapa grupper av moduler som har ett enda syfte och en gemensam struktur, vilket säkerställer en LOGISK uppdelning av informationen inom Anaplan-modellen. Tvärtom, genom att kombinera alla olika typer av strukturer i samma modul, kommer du att göra modellen svårbegriplig, samt skapa dubbelarbete och ineffektivitet i beräkningarna.

    anaplan disco fullständig form

    DISCO står för Data, Input, System, Calculation & Output

    Använda modelltidsskala kontra modultidsintervall

    En av de viktigaste sakerna att tänka på som Anaplan-modellbyggare i din modelldesign är korrekt användning av tidsdimensioner. I modellinställningarna måste du definiera modellkalendern som kommer att ligga till grund för din planering. Det händer dock ofta att några av dina moduler behöver använda tid som ligger utanför din modellkalender. I sådana fall, definiera alltid tidsintervallen inom dessa moduler istället för att utöka modellens tidsskala. Varje år som läggs till i modellkalendern ökar modellens storlek avsevärt och lämnar de celler tomma där dessa tidsinställningar inte används. En annan sak att notera med tidsintervall är att du måste uppdatera dem varje årsskifte, eftersom de inte uppdateras dynamiskt.

    Bästa praxis för formler i Anaplan

    Använd inte formler i en kedjekoppling (mer om kedjekoppling kommer att behandlas i nästa punkt). En standardprincip bakom användningen av formler i Anaplan är att de inte ska upprepas - (formler ska köras en gång och refereras flera gånger), och de ska inte vara långa. Komplexa IF THE ELSE-formler bör brytas upp, och kom ihåg att SÄTT DET VANLIGASTE VILLKORET FÖRST! En annan standardpraxis är att inte använda SUMMA och LETARUT i samma radpost, eftersom det vanligtvis skapar prestandaproblem. Minimera användningen av SELECT-funktionen, särskilt med TIME eftersom en ändring kommer att krävas varje år. Skapa istället en dimensionslös modul för att lagra TIME och andra SELECT-värden och använd LETARUT för att referera till dem. Slutligen, om dina radposter använder villkorsstyrd formatering, stäng då av SUMMA.

    Kedjekoppla inte

    Kedjekoppling hänvisar till scheman där flera moduler är länkade till varandra i ett seriellt schema. Även om detta fungerar om din modell är enkel och okomplicerad (osannolikt!), kommer schemat att stöta på ineffektivitet när de olika modulerna ofta refererar till varandra för värden, beräkningar och indata. Ett kedjekopplingsschema skapar ett långt beroende, och formler måste beräknas i sekvens - vilket förbrukar onödiga GPU:er och saktar ner din modell. Som Anaplan-modellbyggare bör du istället designa med denna princip i åtanke - lagra eller beräkna en gång och referera många gånger. Se till att radposterna nedströms refererar till en enda modul som har den nödvändiga informationen. Detta kommer att förbättra din modells effektivitet avsevärt.

    Dotterbolagsvyer

    Underliggande vyer är användbara i vissa situationer, till exempel för att visa den alternativa hierarkin för en dimension, men de bör användas sparsamt. Att använda för många underliggande vyer i en modul motverkar PLANS-standarderna och gör det förvirrande för slutanvändaren. Att flytta gruppen av relaterade radposter till en separat modul gör den logisk, granskningsbar, hållbar och det eliminerar dubbelarbete.

    Använda listegenskaper kontra radartiklar

    Med Anaplan kan du definiera egenskaper för listor, vilka fungerar ungefär som en radpost i en modul. Det är dock bättre att använda en radpost eftersom radposter gör det enklare att skriva formler och kontrollera sammanfattningen. Listegenskaper ökar också listans storlek vid inläsning. Om din lista har egenskaper som inte används regelbundet i modellen är det bäst att skapa en systemmodul med dessa egenskaper som radposter i Anaplan.

    Delmängder

    Delmängder ökar mångsidigheten i dina listor, men att lägga till dem i stora listor kan skapa prestandaproblem. Det är Anaplans bästa praxis att skapa en separat lista i sådana fall eftersom de kommer att lägga till aggregeringarna och öka storleken på hela modellen. En annan viktig sak att tänka på för en Anaplan-modellbyggare är att dina delmängder bör använda korrekta namngivningskonventioner, annars blir det mycket förvirrande att hitta och identifiera dem.

    Undvik att använda onödiga dimensioner i din modul

    Inkludera endast de dimensioner i din modul där logiken eller data i modulen kräver det. Extra dimensioner kommer att öka storleken på din modul, kräva onödiga beräkningar och skapa ytterligare kontextväljare i modellens UX – vilket hindrar slutanvändare från att komma till önskad vy.

    Ta bort sammanfattning från radposter där den inte behövs

    Anaplan erbjuder en rad alternativ för sammanfattning - SUMMA, MEDEL, MIN, MAX, INGÅENDE/UTGÅENDE SALDO, etc. Dessa tillämpas automatiskt på dina radposter när du skapar dem och kan vara mycket användbara för planeringsändamål. Det är dock en god praxis för Anaplan att stänga av sammanfattningsinställningarna från ritningsvyn för de radposter där SAMMANFATTNING inte behövs. Detta kommer att bidra till att minska modellens storlek och ta bort onödiga beräkningar som behöver göras med sammanfattningen.

    Ta bort onödiga åtgärder och radera datakällor utan en associerad åtgärd

    Granska och identifiera vilka åtgärder som inte används, och ta bort dem. Identifiera också om det finns några datakällor utan tillhörande åtgärder – om det finns, är de onödiga och bör tas bort från din modell.

    Så, fortsätt och kontrollera om din Anaplan-modell följer dessa 10 bästa praxis för Anaplan. Genom att optimera din Anaplan-modellbyggnation för prestanda och kostnader kommer du långt i att vinna över nöjda användare och andra intressenter.

    Hur bästa praxis säkerställer skalbara och högpresterande Anaplan-modeller

    Polestar Analytics är vi ledande Anaplan-partners som betjänar flera Fortune 500-kunder med deras behov av företagsplanering. Vårt team består av mycket erfarna branschveteraner, ett team av Anaplan-modellbyggare, arkitekter och motiverade individer med en förmåga att leverera förstklassiga strategier och tjänster över hela världen.

    Om författaren

    Anaplan partners
    Tushar Sonal

    Insiktsutforskaren

    Om data är olja, så är analys förbränningsmotorn i denna era.

    Generellt talar om

    • Anaplan
    • Datateknik

    Relaterad blogg