Quick reference guide on check points to be considered before going ahead with Data Hub Setup
- Commit
- Any data that goes in and out of Anaplan should use Data Hub - Get an alignment with business users, model builders & IT team that any data that goes IN and OUT of Anaplan will go through Data Hub.
- Answer
- What Data? What Granularity? - Decide on what data will be stored in Anaplan and at what granularity (Ex: In Capex planning, we can bring data at ASSET CLASS level instead of ASSET level)
- How many years of data? - Get an alignment with business users on how many years of data (Actual & Forecast/Budget) to be loaded into Anaplan (Ex: Previous year, Current Year & 2 future years)
- Which Currencies? Get an alignment with business users on whether we need data in all transaction currencies or we just need Local Currency (LC) & Group currencies (GC) like USD, EUR.
- Which Source Systems? We need to make a decision on which source systems will feed data to Anaplan. This has to be analyzed during requirement gathering phase. During design phase, we need to decide if the data flow will be automated, do we need to setup connections with the source systems or we can load the source data from flat files.
- Frequency of Data Refresh - Get an alignment with business users and IT team on how frequently we need to refresh the data from source system (Ex: Daily or Weekly or monthly refresh). Also decide if we need to go with DATA PULL or DATA PUSH mechanism.
- Clear & Overwrite (or) Append - We need to decide if we need to CLEAR & OVERWRITE (or) APPEND to the dataset.
- Finalize
- Data Strategy, Retention & Archival Strategy - Get an alignment with business users, model builders and IT team on how many years of data will be retained in the Anaplan instance. How frequently we need to Archive the data and after how many years we can purge the data. We also need to decide on how to automate the archival and purging process.
- Caution
- Flat modules to keep the size to minimum - Since the entire data needs of Anaplan will be stored in Data Hub, we need to be cautious of the model size. We can keep the data hub modules as FLAT modules and non-dimensionalised.
- Modules with subset of data - It is better to store the data in subsets so the modules are flexible for future requirements. Example: Version based Headcount (HC) numbers, i.e., we can create separate modules for ACTUAL HEADCOUNT numbers, FORECAST HEADCOUNT numbers etc..
- Primary Key for data feeds - Since the data hub modules are non-dimensionalized, we need to differentiate the data using primary key (Ex: Can be a combination of version, time & account - ACTUAL_WAGES_01012018).