Considerazioni sulla progettazione di dimensioni

Progettazione di dimensioni per la creazione della struttura dell'applicazione

Aggiungere conti, entità e altre dimensioni a supporto del processo aziendale.

Le dimensioni consentono di categorizzare i valori dati. In Planning sono disponibili le seguenti dimensioni: Conto, Entità, Scenario, Versione, Periodo e Anni. Se si utilizza la pianificazione in più valute, l'applicazione dispone inoltre della dimensione Valuta.

È possibile utilizzare una dimensione custom per definire valori personalizzati, ad esempio Prodotto, Cliente o Mercato. È possibile disporre di un massimo di 32 dimensioni totali. La procedura consigliata prevede tuttavia di includerne meno di 12. È possibile aggiungere dimensioni mediante un file di caricamento o generale in Oracle Smart View for Office.

Video

Utilizzo del processo per l'identificazione delle dimensioni

Utilizzare questo processo per identificare la dimensione da includere nell'applicazione.

1. Identificare i processi di pianificazione specifici in base alle esigenze.

   Ad esempio, pianificazione marketing, pianificazione vendite, pianificazione costi comuni, pianificazione capitale, pianificazione flusso di cassa e pianificazione forza lavoro.

2. Identificare le dimensioni per ogni processo di pianificazione.

   Ad esempio, Prodotto, Mercato, Canale, Segmento prodotto o Segmento cliente.

3. Definire come le dimensioni sono correlate tra loro.

   Ad esempio, Prodotto ha una relazione molti-a-molti con Mercato. Segmento prodotto e Prodotto hanno una relazione uno-a-molti. Risorse manodopera e Risorse materiale non hanno alcuna relazione.

4. Separare le dimensioni in gruppi per la pianificazione e il reporting.

   Ad esempio, Prodotto, Mercato e Canale sono dimensioni di pianificazione, mentre Segmento prodotto e Segmento cliente sono dimensioni di reporting.

5. Mappare i processi di pianificazione sui moduli di Planning.

   Ad esempio, configurare la pianificazione marketing con Projects o Financials e configurare la pianificazione costi comuni e la pianificazione flusso di cassa con Financials e cubi customizzati.

Considerazione dei casi d'uso comuni per le dimensioni

Esaminare questi casi d'uso comuni per le dimensioni e comprendere le linee guida per gestirli.

• Dimensioni standard (obbligatorie)

  La maggior parte dei casi d'uso di pianificazione finanziaria di alto livello e comuni può essere gestita con dimensioni standard, che possono anche essere rinominate.

• Dimensioni customizzate o facoltative

  Estendere la dimensionalità con dimensioni customizzate o facoltative che possono essere aggiunte (abilitate) o rinominate in base alle proprie esigenze.

• Più gerarchie in una dimensione

  Combinare due o più dimensioni non correlate in un'unica dimensione per evitare l'irrilevanza interdimensionale.

• Gerarchie alternative per la pianificazione o il reporting

  Utilizzare gerarchie alternative quando gli stessi membri possono essere raggruppati sotto padri diversi al fine del reporting o dell'allocazione top-down.

• Dimensioni attributo per il reporting

  Le dimensioni attributo sono utili per soddisfare i requisiti di reporting se sono correlate a una dimensione e la relazione tra le due dimensioni non cambia nel tempo.

• Smartlist e dimensioni ASO per il reporting

  L'utilizzo di smartlist e dimensioni ASO per il reporting è utile quando la relazione tra la dimensione di reporting e le altre dimensioni cambia con il tempo.

• Smartlist e dimensioni BSO a più cubi per la pianificazione

  Questa strategia è utile quando la dimensione di pianificazione non è una dimensione principale per un processo di pianificazione che deve essere suddiviso in sottoprocessi.

Questo foglio di lavoro campione mostra un esempio di come pianificare le dimensioni, incluse l'identificazione delle dimensioni e la generazione dell'elenco dei relativi casi d'uso.

Esame delle strategie di progettazione di esempio

Esaminare questi esempi per comprendere ulteriori strategie di progettazione per le dimensioni.

Utilizzo di dimensioni attributo per il reporting

L'utilizzo di dimensioni attributo per il reporting può essere utile per soddisfare i requisiti di reporting. L'attributo è correlato a una dimensione e la relazione tra le due dimensioni non cambia con il tempo.

Esempio:

• Definire un attributo denominato Program per la dimensione Progetto.
• È quindi possibile creare una gerarchia di membri per la dimensione Program. I membri del livello più alto nella dimensione Program verranno aggregati automaticamente.
• Associare ogni membro Progetto a un membro di livello foglia nella dimensione Program in una regola Groovy Aggiungi progetto.
• Ciò consente di filtrare i progetti in base al programma.
• I form di reporting possono mostrare le spese e i ricavi a livello di programma.

Utilizzo di smartlist e dimensioni ASO per il reporting

Questa strategia è utile quando la relazione tra la dimensione di reporting e le altre dimensioni cambia con il tempo.

Esempio:

• Aggiungere una dimensione Skillset in ASO e mappare la smartlist Skillset sulla dimensione Skillset.
• Creare una mappa dati per spostare dati da BSO al cubo ASO.
• La mappa dati può essere eseguita come processo batch oppure è possibile implementare Smart Push in form o regole Groovy.
• È possibile utilizzare form di reporting per il cubo ASO per mostrare il requisito relativo alla manodopera per Skillset tra i vari progetti.

Utilizzo di smartlist e della progettazione BSO a più cubi

Questa strategia è utile quando la dimensione di pianificazione non è una dimensione principale per un processo di pianificazione che deve essere suddiviso in sottoprocessi.

Esempio:

• Dipendente e Mansione sono dimensioni in Workforce e smartlist in Pianificazione progetto.
• Pianificazione progetto utilizza elementi riga per pianificare le spese relative alla manodopera a livello di Mansione e Dipendente.

Più gerarchie in una dimensione

È possibile utilizzare più gerarchie in una dimensione. Combinare due o più dimensioni non correlate in un'unica dimensione per evitare l'irrilevanza interdimensionale.

Esempio:

• Mansioni, attrezzatura e materiale non sono correlati in Projects, pertanto vengono combinati in una singola dimensione Classe risorsa.
• I centri profitti e i centri di costo non sono correlati in Financials, pertanto possono essere combinati in una singola dimensione Entità.

Gerarchie alternative per la pianificazione e il reporting

Utilizzare gerarchie alternative quando gli stessi membri possono essere raggruppati sotto padri diversi ai fini del reporting o dell'allocazione top-down.

Esempio: creare rollup alternativi nella dimensione Prodotto per la pianificazione e il reporting in base alle categorie Marchio e Prodotto.

Apprendimento delle dieci principali procedure consigliate per le dimensioni

Attenersi a queste importanti procedure consigliate per la progettazione delle dimensioni.

1. L'ordine delle dimensioni deve seguire un formato clessidra modificato.

   Con questo formato, la dimensione più densa è la prima, seguita dalle dimensioni meno dense. A seguire le dimensioni sparse, con le dimensioni sparse di aggregazione prima delle dimensioni parse non di aggregazione. All'interno delle dimensioni sparse, le dimensioni sparse più dense devono venire prima delle dimensioni sparse meno dense.

   Con la modalità BSO ibrida, l'ordine è lo stesso, tranne per il fatto che le dimensioni sparse non dinamiche devono precedere le dimensioni sparse dinamiche.

   Ulteriori informazioni sulle dimensioni dense e sparse vengono fornite in questa esercitazione: Gestione delle dimensioni in Cloud EPM.

2. Una dimensione blocco elevata ha un impatto significativo sulle performance.

   La dimensione blocco è determinata dal numero di dimensioni dense e dai membri in tali dimensioni. La dimensione blocco ottimale è compresa tra 8 KB e 500 KB. Ridurre il numero di dimensioni dense a un massimo di 3. Il livello 1 e i livelli superiori devono essere impostati su Solo etichetta o Calcolo dinamico per le dimensioni dense.

3. I conti di tipo Testo, Smartlist, Data e Percentuale memorizzata devono essere impostati su Mai per la proprietà di consolidamento.

   Aggregando tali valori, a meno che i conti non vengano esclusi esplicitamente in uno script di aggregazione, verranno creati dati inutili.

4. Tutti i membri di generazione 2 devono essere impostati su Ignora.

   Non è possibile includere questi membri radice nei propri form perché non è possibile definire la sicurezza per tali membri. Non ha pertanto senso aggregare alla radice i membri di generazione 2. Ciò farà anche aumentare il numero di blocchi nell'applicazione.

5. Le dimensioni di tipo long o flat causeranno un problema relativo alle performance dell'aggregazione.

   Se sono presenti più di 200 membri sotto un membro padre, aggiungere padri intermedi.

6. Abilitando i membri dimensione per più cubi, si creeranno Xref dinamici e si avranno problemi di performance.

   Utilizzare l'attributo definito dall'utente HSP_NOLINK per evitare la creazione di Xref dinamici. Utilizzare mappe dati o Smart Push per spostare dati tra cubi.

7. Per calcoli semplici, utilizzare i normali schemi matematici invece di scrivere formule membro.

   Un esempio di calcolo semplice è Conto C = Conto A - Conto B.

8. Quando possibile, evitare membri padre con figli singoli.

   I membri padre con figli singoli danno luogo a condivisioni implicite oppure a dati su disco o blocchi duplicati se il membro padre viene impostato su Non condividere.

9. Quando possibile, aggregare le dimensioni estese in ASO invece che in BSO.

   Ciò migliora le performance, ad esempio l'aggiornamento dei cubi e la fase di manutenzione.

10. Memorizzare i dati cronologici di oltre due anni in ASO invece che in BSO.

    Se si dispone di 5 o 10 anni passati di dati cronologici, per i calcoli non sono necessari tutti i dati. Se occorre, è possibile avere un paio di anni di dati cronologici per i calcoli nel cubo BSO ed è possibile spostare gli altri dati cronologici nel cubo ASO. Per performance ottimali, come procedura consigliata mantenere leggero il cubo BSO e assicurarsi che sia incentrato sui calcoli per l'immissione dati.

Pianificazione della dimensione Entità

La dimensione Entità rappresenta la struttura organizzativa, ovvero Centri di costo, Reparti, Unità operative, Divisioni e così via.

È possibile raggruppare i centri di costo creando membri rollup, detti padri, per rappresentare le modalità di visualizzazione dell'organizzazione. Ad esempio, i rollup possono essere costituiti da unità operative, divisioni o altre strutture funzionali. È possibile creare, ad esempio, centri di costo che confluiscono in unità operative che confluiscono in divisioni.

È inoltre possibile creare più strutture di reporting. Ad esempio, potrebbe essere creata una struttura alternativa a supporto del reporting regionale. Se si utilizza la pianificazione in più valute, impostare la valuta base di ogni entità.

La dimensione Entità è una delle dimensioni principali utilizzate per il processo di definizione del budget. Utilizzata con le dimensioni Scenario e Versione, la dimensione Entità consente di definire un'unità di approvazione, un componente discreto che può essere promosso o retrocesso per approvazione o revisione dai pari livello di un utente.

I membri di tutte le dimensioni esterni all'unità di approvazione verranno promossi e retrocessi insieme all'unità di approvazione stessa. Ad esempio, tutti e dodici i mesi vengono promossi insieme quando viene promossa un'unità di approvazione. I singoli mesi non possono essere promossi in modo indipendente.

Dopo il caricamento o l'aggiornamento di ogni dimensione, la procedura consigliata prevede l'aggiornamento dell'applicazione.

Pianificazione della dimensione Conto

La dimensione Conto è l'ambito di definizione del piano dei conti. Deve includere i membri su cui si basa la pianificazione o la previsione. Non include necessariamente ogni conto nel piano.

Ad esempio, la dimensione Conto definita può includere i conti per Conto economico, Bilancio patrimoniale e Flusso di cassa oppure per indicatori KPI e rapporti. In alcuni casi i conti possono contenere conti secondari, ma non si tratta di una configurazione standard.

La dimensione Conto include Financial Intelligence. Sono supportati i tipi di conto seguenti:

• Spese: costo dell'attività svolta

• Ricavi: fonte di entrate

• Attività: risorse aziendali

• Passività ed equity: interesse residuo o obbligo nei confronti dei creditori

• Ipotesi salvata: ipotesi di pianificazione centralizzata per garantire la coerenza nell'applicazione

Le impostazioni di tipo Conto vengono utilizzate per il reporting dei valori Trimestrale e Totale anno e per l'analisi della varianza.

In Planning viene utilizzata una struttura gerarchica per creare un conto che raggruppi i totali parziali e i totali. A ogni gruppo del conto viene assegnato un operatore di consolidamento che ne determina il modo in cui confluisce nell'elemento padre.

Esempio:

Entrate nette = Totale ricavi - Totale spese

In questo esempio, l'operatore di consolidamento per Totale ricavi è Addizione e l'operatore di consolidamento per Totale spese è Meno.

Per popolare la dimensione Conto è possibile caricare i dati oppure utilizzare Smart View. Per caricare i dati da un file, è necessario che il formato del file soddisfi requisiti specifici.

Dopo il caricamento o l'aggiornamento di ogni dimensione, la procedura consigliata prevede l'aggiornamento dell'applicazione.

Procedure consigliate:

• I membri di livello superiore devono essere impostati su Calcolo dinamico.

• Per le formule membro utilizzate per calcolare i rapporti e altri tipi di indicatori KPI o percentuali, scegliere l'impostazione Calcolo dinamico, A due passaggi. L'impostazione A due passaggi consente di calcolare in modo corretto le percentuali nei livelli superiori.

Pianificazione della dimensione Versione

Le versioni consentono di conservare iterazioni differenti del processo di pianificazione. Le versioni si rivelano utili anche per il controllo dell'accesso in lettura o in scrittura ai dati.

Sono disponibili i due tipi di versioni riportati di seguito.

• Target standard: i dati di input possono essere immessi nei livelli superiori.

• Bottom-up standard: i dati di input possono essere immessi solo nel livello 0.

Le funzionalità di approvazione e flusso di lavoro possono essere abilitate solo per le versioni Bottom-up.

Si consiglia l'uso delle versioni seguenti.

• Di lavoro: in cui gli utenti eseguono i propri task, compresi la revisione dei risultati effettivi e lo sviluppo del piano e della previsione.

• 1° passaggio: se si desidera gestire più iterazioni del piano, è possibile conservarne un passaggio in questa versione. Se sono necessarie più iterazioni salvate, è possibile creare altri membri. Per spostare i dati in questa versione è possibile utilizzare la funzionalità Copia dati. Copia dati copia i dati e l'input di testo.

• What-If: fornisce un segnaposto per la modifica delle ipotesi e l'analisi dei risultati da parte degli utenti.

Dopo il caricamento o l'aggiornamento di ogni dimensione nel processo di creazione, la procedura consigliata prevede l'aggiornamento dell'applicazione.

Pianificazione della dimensione Valuta

Se sono state abilitate più valute per l'applicazione, è possibile aggiungere le valute da utilizzare per le esigenze di pianificazione e reporting.

Successivamente è possibile definire i tassi di cambio per scenario e anno da utilizzare nelle conversioni. Viene creato uno script di calcolo che consente di eseguire la conversione della valuta. Per immettere i tassi di cambio, seguire il processo descritto nella sezione Definizione dei tassi di cambio della guida Amministrazione di Planning.

Procedure consigliate:

• Limitare il numero delle valute di reporting. In genere i clienti dispongono di una sola valuta di reporting.

• Immettere i tassi di cambio per ogni combinazione scenario-anno valida.

• Da questo punto in poi, la conversione della valuta può essere calcolata eseguendo la regola business Calcola valute associata per impostazione predefinita a ogni form.

• Il tipo di tasso di cambio di un conto viene modificato, ad esempio da Finale e Medio.

Eseguire lo script di calcolo per la conversione della valuta prima di:

• rivedere i dati locali aggiornati nelle valute di reporting;

• eseguire determinati calcoli che potrebbero dipendere dai dati della valuta di reporting.

Pianificazione dei tassi di cambio

Ogni applicazione dispone di una valuta predefinita specificata dall'utente durante la creazione dell'applicazione. Quando si impostano le tabelle dei tassi di cambio, si immettono i tassi di cambio di tutte le valute di origine nella valuta predefinita. Per la conversione in tutte le altre valute di reporting viene utilizzata una valuta di triangolazione.

I tassi di cambio vengono impostati per scenario e anno per i tassi Medio e Finale.

Pianificazione della dimensione Periodo

Utilizzare la dimensione Periodo per stabilire l'intervallo del calendario, ad esempio per mese, all'interno dell'anno specificato.

Procedure consigliate:

• Utilizzare variabili di sostituzione per questa dimensione per supportare il reporting e i calcoli. Le variabili di sostituzione potenziali sono: CurrMo, CurrQtr e PriorMo. Queste variabili devono essere aggiornate ogni mese.

• Per utilizzare i calcoli del periodo di tempo, ad esempio Progressivo anno (YTD) o Progressivo trimestre, selezionare l'icona Dynamic Time Series nella dimensione Periodo. Sarà quindi possibile selezionare i calcoli del periodo di tempo necessari per supportare il processo.

• I periodi di tempo di riepilogo, ad esempio i totali trimestrali e il totale anno, devono essere impostati su Calcolo dinamico per ridurre il tempo di calcolo.

• Dopo il caricamento o l'aggiornamento di ogni dimensione, aggiornare l'applicazione.

Pianificazione degli anni e delle variabili di sostituzione

La dimensione Anni è incorporata in più elementi dell'applicazione, tra i quali form, calcoli, report e Smart View. Poiché l'applicazione verrà utilizzata per molti anni in futuro, per fare riferimento a questa dimensione è consigliabile utilizzare una variabile di sostituzione.

Le variabili di sostituzione fungono da segnaposto globali per informazioni che variano regolarmente. La variabile e il valore corrispondono all'anno e il valore può essere modificato in qualsiasi momento.

Il valore della variabile di sostituzione viene visualizzato nei form e nei report come segnaposto. Ciò riduce l'attività di manutenzione per l'applicazione.

La procedura consigliata prevede la creazione di variabili di sostituzione per ogni anno incluso nel processo. Ad esempio:

• CurrY, anno corrente

• NextYr, anno budget (piano)

• PriorYr, anno precedente

Progettazione di dimensioni customizzate

È possibile utilizzare una dimensione custom per definire ulteriori categorie per i dati. Ad esempio, le dimensioni custom possono includere Prodotto o Mercato.

Tenere presente che non è possibile concedere le autorizzazioni di accesso al livello dimensione, detto anche generazione uno. Ad esempio, le autorizzazioni di accesso non possono essere assegnate direttamente al membro Prodotto per tutti i discendenti. Se si abilita la sicurezza per la dimensione customizzata, si consiglia di progettare la generazione due per tutte le dimensioni customizzate alle quali verrà applicata la sicurezza tenendo presenti le assegnazioni dell'accesso di sicurezza.

Dopo il caricamento o l'aggiornamento di ogni dimensione, la procedura consigliata prevede l'aggiornamento dell'applicazione.

Procedure consigliate aggiuntive

Completare questi task dopo aver aggiunto o aggiornato le dimensioni.

• Aggiornare l'applicazione.

  È necessario aggiornare l'applicazione ogni volta che la struttura dell'applicazione viene modificata.

  Le modifiche apportate all'applicazione non vengono estese agli utenti che eseguono task di immissione dati e approvazione finché non si aggiorna l'applicazione.

  Ad esempio, quando si modificano le proprietà di un membro Entità, si aggiunge uno scenario o si modificano le autorizzazioni di accesso, le modifiche apportate saranno visibili per gli utenti solo dopo l'aggiornamento esplicito dell'applicazione.

• Caricare i dati cronologici.

  Dopo aver caricato tutte le strutture, ad esempio i conti e le entità, è possibile caricare i dati cronologici. I dati cronologici possono includere i dati dei risultati effettivi dell'anno precedente e del piano e del budget dell'anno corrente.

  Il caricamento dei dati cronologici consente agli utenti di analizzare i risultati, esaminare le tendenze ed effettuare confronti significativi.

  Ciò facilita inoltre la verifica delle strutture create nell'applicazione. Ad esempio, è possibile verificare che i dati sono associati a report creati in precedenza. Se la riconciliazione dei dati non riesce, è necessario verificare se la causa è un problema dei dati o un problema verificatosi nelle strutture.

  Creare una regola di aggregazione per visualizzare i dati consolidati nell'applicazione.

• Pianificare intersezioni valide.

  Le intersezioni valide consentono agli amministratori servizi di definire regole, dette regole di intersezione valida, che filtrano le intersezioni dimensionali per gli utenti quando questi immettono dati o selezionano prompt runtime. Ad esempio, è possibile specificare che determinati programmi siano validi solo per reparti specifici. Sfruttare le intersezioni valide per controllare l'immissione dei dati solo per le intersezioni valide.

  Durante la progettazione dei form, ricordare questi punti per intersezioni valide.

  • Se nella pagina vengono trovate dimensioni con intersezioni valide, l'utente visualizzerà solo le combinazioni valide nel selettore membri.
  • Se le dimensioni con intersezioni valide si trovano nella colonna o nella riga, il designer form può sopprimere completamente le intersezioni non valide. Quando l'opzione di soppressione non è selezionata, le intersezioni non valide diventano di sola lettura.