Requisiti del Business Plan

L’inizio del processo di pianificazione è definito dal sistema di business Plan.

Durante la fase di analisi è stato modellato il flusso partendo dal sistema già presente e dalla seguenti assunzioni:

• L’applicazione deve essere dotata di funzionalità specifiche per la raccolta dati distribuita e deve gestire differenti permessi in base al ruolo dell’utente che si appresta ad utilizzare l’applicativo;

• alcune informazioni devono essere solo ready-only per gli utilizzatori;

• gli utenti devono avere una determinata tasklist nella compilazione delle form e i dati immessi devono soddisfare determinate logiche (ad esempio appartenere ad una lista predefinita di valori) o regole di verifica;

• determinate celle devono esser calcolate partendo dai valori che l’utente ha immesso nel sistema.

Il Business Plan dei fondi immobiliari deve contenere delle data entry che rappresen- tano dei sotto processi e che permettano l’inserimento a sistema di tutti i dati necessari. Le form necessarie alla composizione del sistema sono le seguenti:

• Assumption Immobili: in questa sezione, per ciascun fondo, a livello di singolo immobile, vengono presentati i dati anagrafici dell’immobile e richiesti i dati di Capex, Opex, Lease/vacancy.

Nella tabella in figura 4.3 è possibile visualizzare tutti i campi presenti nella data entry. I punti salienti della form sono:

– gestione fase di pianificazione: se è effettuata nel corso dell’anno allora vengono richieste le stime a finire per l’anno in corso e gli importi per gli anni futuri, mentre se è effettuata a fine anno, vengono richiesti solo i totali per gli anni futuri con la definizione (data inizio/data fine) del periodo di competenza;

– gestione degli oneri: occorre identificare dei metodi semplici per definire la durata o l’arco temporale sul quale valorizzarli. Allo stesso modo occorre iden- tificare condizioni contrattuali standard ed eventualmente pre-inizializzare la maschera con tali valori che possono poi essere modificati dagli utenti che si occupano di property management;

– gestione della vendita degli immobili: per il piano di dismissione dell’im- mobile si deve prevedere l’inserimento di parametri quali exit cap rate, prezzo al mq, sconto su OMV, data di inizio e fine vendita, le commissioni d’agenzia, altri costi legati alla vendita e in base al criterio di definizione del valore di vendita sarà eseguito il corretto algoritmo di calcolo;

– gestione frazionamenti immobili: si deve prevedere una vendita frazio- nata degli immobili ovvero che permetta l’uscita di cassa dell’immobile in percentuale sui differenti mesi in cui inputata. A tal proposito, la percentuale ricadrà anche su tutte le voci di costo annesse all’immobile;

– gestione dati: i dati sono in parte provenienti dall’applicativo esterno di Navision ed in parte provenienti da Ref. L’applicativo Navision invierà ad ogni periodo schedulato tutte le informazioni di contabilità mentre Ref sarà utilizzato per l’aggiornamento delle anagrafiche.

• Assumption Tenant: in questa sezione vengono gestiti gli step rent dei sin- goli immobili. Per ciascuna lease unit univoca, vengono riportate le seguenti informazioni:

– il codice del contratto, il tenant, la destinazione d’uso, la superficie lorda locabile, la superficie ponderata e la data di partenza del contratto;

– vengono pianificati gli step rent del contratto: attualmente vengono gestiti 3 step rent statici, mentre il nuovo applicativo deve gestirne un numero dina- mico in relazione alla richiesta. Per ciascun step rent dovrà essere possibile specificare:

∗ rent: il rent effettivo, la data di decorrenza; ∗ indexation i parametri di indicizzazione;

∗ vacancy e lavori di ristrutturazione: durata vacancy e costo al mq dei lavori di ristrutturazione;

– dovrà essere presente una sezione per formulare ipotesi di rilocazione (market rent): canone mercato al mq (erv), data di validità erv, agency su contratto, ecc;

– i dati gestiti in questa form provengono principalmente da Ref ovvero il siste- ma informativo utilizzato dal property management in cui vengono gestiti i singoli contratti e il dettaglio delle lease unit. L’anagrafica tenant sarà pre- sente in questo caso su Navision. Tra il sistema di Navision e l’applicativo creato, ci sarà un sistema Dwh utile a verificare la correttezza dei dati prima del caricamento;

– ove possibile le data entry di questo step dovranno essere pre-inizializzate con i dati provenienti da ref in modo che i Fund Manager possano poi modificare tali dati ove necessario. L’applicativo che si andrà a creare, dovrà distinguere la provenienza dei dati (dati caricati dal sistema, inputati dall’utente o calcolati dalla business rule);

– nuovi tenant potranno essere inseriti a runtime dai fund manager oltre alla simulazione di nuove locazioni;

– bisognerà verificare la coerenza tra la superficie lorda e la superficie ponde- rata di ogni singola lease unit rispetto alle medesime grandezze definite per l’immobile.

• Aggrega Assumption: al termine della compilazione delle due precedenti form illustrate il nuovo applicativo sostituirà le macro precedentemente presenti con una business rule che si occuperà di calcolare ogni aspetto al massimo livello di det- taglio. Lo strumento è dotato di funzionalità native specifiche per la gestione dei periodi temporali e per l’allocazione di dati aggregati sui periodi di dettaglio; ta- li criteri allocativi possono essere effettuati in base a logiche di equal allocation (ovvero ogni periodo ha lo stesso peso), logiche di allocazione in base a curve peso definite dall’utente, logiche di allocazione in base a driven presenti a sistema (curve storiche o di precedenti BP). Sarà inoltre possibile per gli utenti bloccare ai fini allocativi determinati periodi di dettaglio (ad esempio perchè il valore puntuale è già corretto), operare a totale periodo e allocare sulle celle non bloccate i delta in base al peso delle celle stesse.

A seguito del calcolo l’utente avrà sempre la possibilità di modificare i valori proposti dal sistema con data entry di rettifica sui singoli quarter.

• Finanziamenti: questa form gestisce tutte le informazioni inerenti ai finanzia- menti. L’output rappresenta un valore che finisce direttamente nei prospetti finali;

• Partecipazioni: questa form gestisce tutte le informazioni relative alle partecipa- zioni per ogni singolo fondo. Come per i finanziamenti, anche per le partecipazioni verranno create delle form che permetteranno l’inserimento delle informazioni utili e quindi fungerà da collettore di grandezze precalcolate dai fund manager attraverso altri strumenti;

• G&A: in questa form vengono calcolate le spese generali del fondo; Il punto di partenza è un valore annuo che viene poi inflazionato e allocato sui vari quarter. Per le commissioni verranno gestite diverse tipologie di calcolo, mentre per i crediti verranno individuati degli standard tali per cui l’applicativo consentirà la raccolta delle informazioni già calcolate secondo semplici data entry.

• Proventi e Rimborsi: Lo step calcolerà i proventi ed i rimborsi con calcoli applicati a grandezze già presenti all’interno del sistema o con data entry.

• I 3 prospetti: definite le caratteristiche individuali e il risultato di gestione dei singoli immobili, determinate le linee strategiche del portafoglio immobiliare è necessario redigere, anno per anno, i seguenti prospetti di riepilogo del fondo immobiliare:

– Conto Economico: riporta i ricavi e i costi della gestione per tutta la durata del fondo; questo presenta l’output finale a livello di totale singolo fondo andando ad unire i dati provenienti da tutte le form precedentemente citate; – Stato Patrimoniale: fornisce una visione sull’evoluzione prospettica del

capitale investito;

– Cash Flow: evidenzia i flussi monetari netti generati nella gestione del fondo. Il modello dovrebbe garantire, per tutta la durata del fondo, una distribuzione sistematica di proventi ai titolari delle quote e il ricorso, ove finanziariamente op- portuno a forme di rimborsi parziali pro quota.

Nell’applicazione di business plan occorre permettere diversi momenti di approva- zione per i BP dei singoli fondi e sarà inoltre possibile mettere a disposizione degli utenti dell’applicazione i BP precedenti.

A quanto emerso dalla specifica dei requisiti per il sistema, i dettagli del modello saranno i seguenti:

– Specifica per fondo;

– Specifica per immobile fino al dettaglio della lease unit; – Specifica per tenant fino al dettaglio del singolo contratto; – Piano dei conti gestionale per i prospetti di CE, CF e SP; – Tempo con il dettaglio da anno sino a quarter;

– Scenario: actual, business plan e forecast;

– versione: per gestire gli eventuali workflow approvativi.