Proof of Concept

Overview

The most powerful way to “turn on the lights” with your business stakeholders … a Proof of Concept

Show your organisation why it is critical to invest in IBM Cognos Business Analytics. Conducting a Proof of Concept (POC) while leveraging Cortell’s POC methodology will “turn on the lights”.

The Cortell ‘POC’ allows a business area or issue to be viewed, analysed and observed in new and exciting ways. This analysis will uncover trends, correlations or anomalies that were not previously available, captured or noticed.

Approach

An area where you can get a quick win

Our approach is to immediately create a return on your investment on the initial engagement, develop a solid relationship with your stakeholders and create a roadmap for additional applications that drive value creation within your business strategies.

The key to achieving a successful Proof of Concept (POC) is:

  • Decide on what you want to achieve. Business analytics becomes very exciting to many people once you can see the evidence of better decision making. It is imperative to agree upfront on the POC goal.
  • Start with an area of the business where you have a lot of clean data – an area where you can get a quick win.
  • Properly set expectations. Expectation management is an important step within a POC. A successful POC is subject to the business stakeholders’ perception of whether or not we succeed together. We clearly outline a standard process on how we plan to address your unique challenges.

Step 1 – Knowledge transfer to your organisation

The format of the first day is very interactive and treated like a workshop.

There is a lot of knowledge transfer where we go into more detail on how the IBM budgeting, forecasting and planning solution (Planning Analytics) works; terminology and example models and other key components to help you think about what is possible when we start deep-diving into your specific requirements.

Step 2 – Knowledge transfer to the Cortell Team

To assist us in completing the Proof of Concept scoping, we will need:

  • copies/examples of existing templates, spreadsheets and reports
  • dimensionality (such as chart of accounts and hierarchy)
  • user list and security
  • anything else that would be appropriate for reference or discussion.

We then spend considerable time gaining a greater understanding of your requirements, A good place to start is the existing process where you can explain what works well, what doesn’t, what needs to remain and what is up for discussion around potential changes.

Step 3 – The Planning Analytics “refresher session” – making sure we have all pieces of the puzzle

We will complete the following:

  • overview of what Planning Analytics is and how it can be used to meet your requirements
  • demonstration and explanation of the terminology (same page) – dimensions, rules, cubes, front-end, ETL/TI, etc.
  • explanation of types of users and typical tasks they perform
  • demonstration of similar models that are relevant and we are approved to showcase
  • set the scene for the scoping engagement and confirm roles and responsibilities.

The initial workshop will be completed at a reasonable high-level.

Step 4 – Building an agile POC – making sure each piece fits

Over the coming days, following the initial workshop, each model or component (or cube in Planning Analytics language) will be explored in more detail.

During this time, a cut-down version of the final reporting/modelling application will be built rapidly.

The Cortell team interactively work with you to validate the required capabilities and functionality using your own data. It is at this point any key users or planning managers are brought into the process, seeking their valuable thoughts and buy-in to the process.

The various areas that we need to address for a detailed model design and scoping include – but is not limited to.

Dimensionality of the Model

  • what dimensions do you need to capture the data against?
  • what do you need to analyse and report the data by?

Population of the Dimensions

  • what is going to be automated, and from what source?
  • how do we manage slowly changing dimensions or new elements added during the planning process (i.e. business units, products, etc.)?

Population of Historical Data or Seeded Information

  • do we require actuals or a baseline?
  • historical budgets for comparatives?
  • from where and how is it going to be mapped into the model?

Business Rules and Logic

  • what are the calculations within the model itself?
  • what are the exceptions?

Overall Architecture

  • how does this model fit in with the overall architecture?
  • what P&L accounts are hit as a result of the model?
  • should we use business rules, or ETL processes to move the data?

Users / Security / Workflow Process

  • we need to get an understanding of the process that will be followed along with any impact on security or workflow reporting that may (or may not) be required

Reporting and Analysis

  • what reports are required to be produced, and in what format?
  • are there any cube views that need to be created to support ad-hoc analytics?

Output

  • do the results need to be fed back into another source system? if so, what format?

Step 5 – Moving to the next phase now that the light’s turned on

For the next phase, the other items that are defined include;

  • training plan
  • documentation
  • project management methodology
  • UAT and testing process
  • server architecture and sizing / environment
  • Planning Analytics version for build and other required software.