Thomas Cook Belgium (TCB) is the market leader in Belgium within the organized Leisure Tourism Market with an overall market share between 40% and 50%. TCB carries three strong Tour Operating brand names: Neckermann, Thomas Cook and Pegase. These brands are distributed through an important own Travel Agency network: some 100 Neckermann branded shops and some 40 Thomas Cook Travel Shops. Moreover the Thomas Cook and Pegase brands are distributed through the open Leisure Travel Distribution Market.
The fast growth of TCB in Belgium over the recent years has lead to an increased demand in better predictability of its performance and better management of its costs. The market situation also required Thomas Cook Belgium to invest in innovating the tour operating business by new product launches and new channels of distribution. Additionally, there were several changes in middle and senior management as the organization was re-thought.
TCB was facing important hurdles when trying to retrieve relevant management information or when trying to predict future performance. One of them was a lack of processes and tools to support a financial information process including a budget and budget follow-up process, leading to accountability. TCB has a complex planning cycle with plans/budgets produced at different levels (shareholder plan, management plan and internal plan). Also regular forecasts are held during the year. Therefore Thomas Cook was looking to automate its budgeting process. The solution envisaged had to enable fully fledged bottom-up logic as well as a possibility to adapt top-down by locking certain data when examining alternative scenarios.
Analyzing the needs
The Thomas Cook Corporate Controlling department took the time to define a new "to be planning process. IBM Cognos Planning 8.4 was selected as the software solution to automate the new process. The controlling department of TCB was in the lead of the implementation project, 2 controllers acted as the key users and administrators of the new environment while all the other controllers were involved in the process for their own areas of responsibility.
The implementation of the solution, based on element61 elementary methodology and templates, was started with a detailed analysis of the new planning process. TCB is a complex organization with multiple legal entities and a lot of different brands following different business rules. First an overview of the legal structure and all the departments was made. This gave a first impression of where the most difficult parts of the organizations planning processes were situated. The two large parts of the organization are tour operating on the one hand (assembling the brochures division Tour Operators Car/City and Flight) and the distribution channels on the other hand (points of sales division Distribution). The sales channels are mostly own Thomas Cook shops (Thomas Cook Travel Shops and Neckermann Shops), however not every product is for sale in every shop, leading to additional planning complexity. As an example, Neckermann products are not sold within Thomas Cook Travel Shops. To sell as many holidays as possible, a large number of marketing campaigns are ran by the Marketing division, most of the time for a specific set of products. TCB also operates its own aircrafts (division Airline) and needs to fill these aircrafts and where needed- buy extra capacity when necessary (division Capacity and Yield). All these divisions are supported by a number of general divisions such as Finance, HR and IT. Within the ICT department, a large number of projects are executed to upgrade IT infrastructure and roll out new software and hardware.
All of the above interrelated activities had to be modeled in the driver-based planning environment. By interviewing all of the controllers and some of the key users, the details of the logic were documented and the different dimensions were identified and described. 54 dimensions were defined and 2 different models were retained, a top-down and a bottom-up model. For every dimension, up-to-date metadata was retrieved and included in the Analysis document. Some dimensions were quite big, like the cost and profit center dimension which has 1.500 elements.
Within the planning model, resulting data from one division becomes input data to another division. Revenue from a division A' becomes an expense for division B'. All of these flows must be identified and business logic had to be described where necessary. Within an IBM Cognos Planning implementation it is also crucial to carefully examine which functionality to model within Cognos Planning, as Cognos Planning is not a consolidation solution. Caution is needed to stay focused on the planning process and leave the consolidation for the consolidation environment.
Designing the new environment
Because of the large number of dimensions, the number of items within some dimensions and the complexity of the top-down and the bottom-up model, a split of the project in different applications was needed. The top-down and the bottom-up model became 2 different models with a link from the bottom-up to the top-down model.
For every dimension, a draft "d-list was made and also the "e-lists and "d-cubes were defined and created preliminary to start building the first prototype. Proto-typing is an ideal way to further refine and test the correct translation of business requirements into the application design. The limitation of approximately 20 million cells within an IBM Cognos Planning application is important to keep in mind when designing the final solution. The dimension of the General Ledger had 560 items and also some other dimensions were quite large. Using all these dimensions, even within separate cubes, in combination with 13 time periods (12 months and full year) exceeded the limit of 20 million cells. We must keep in mind that some dimensions like destinations, catalogues and GL accounts will keep changing and growing during the year because of normal business growth and change. Access Tables and Cut-down models should be used to shrink the application to the needs of the end-user without losing any functionality.
Building the solution
The source application to feed Cognos Planning with the metadata and actuals in the case of TCB was SAP. As the current reporting environment was not capable of delivering the necessary data in the correct format, an alternative solution to extract data from the operational system was created. Drivers and other data not existing within the operational SAP environment were manually entered or loaded within Cognos Planning.
Three main Planning & Budgeting models were built : top-down, bottom-up and HR budget application. The HR application is managed centrally by the HR department and the data of the model flows into the bottom-up model. The top-down model and the HR-model have only one application. The bottom-up model exits out of 14 different applications, all linked to each other. The split into different applications allowed to have logical units to work with, as a lot of drivers and dimensions were specific to one application & user group. By splitting up the application, the access tables became smaller and easier to maintain.
Creating all the dimensions and populating them manually or with data coming from SAP
Combining the dimensions into cubes and creating the applications
Building links within the applications to let data flow from one cube to another
Building inter-applications links to link data from one application to another
Creating the application hierarchy and setting up the security
Using access tables to shrink the applications and limit the user input to the necessary fields
Creating load processes for some drivers to avoid manual input
Loading actuals data
Initial testing of the environment
Creating an administrator & user manual
Training & Coaching of the TCB future IBM Cognos planning super users & administrators
Finally the solution was tested and accepted by the user community.
The new release IBM Cognos 8.4 Planning was used and during the project the first maintenance release of this version was also installed to deal with a number of remaining issues & bugs.
element61 has been responsible for the following roles & activities:
- Analyzing the requirements
- Defining and designing the new solution
- Extracting data from SAP
- Installing the software
- Building the planning applications
- Rollout, training & coaching of the customer both on the concepts & technology deployed.