Top 10 BI Vendor Survey – Really?

There is currently a link to a Top 10 Business Intelligence Vendors report that is viral on the EPM groups on LinkedIn.  It is has been prepared by a company called CompareBusinessProducts.com.  If you check LinkedIn, you’ll find a link easily.

I have a few problems with this report.

Over half of the paper is graphing revenues and market share for 10 BI companies.

Comparing revenues and market share of vendors does not necessarily bear any resemblance to how good the products are.

For example, most people agree other phones are better in functionality than the iPhone but the iPhone is still the benchmark in smart phones.

Just because a big vendor has the capability to discount heavily or secures business off the back of large ERP implementations, where often the BI licence is given away for free. Point is, don't confuse the Top 10 with product functionality and performance.

The notes at the end are interesting but my advice would for a more detailed review would be to get hold of the Gartner reports which you can easily find on the net.

Finally, what use is a report that compares 2008, 2009 and 2010?  Don’t they know it’s 2013 now J

From ‘data’ to ‘insight’

I’m very excited and proud to be working with The Chartered Association of Management Accountants (CIMA) on a research paper entitled “From Data to Insight” due for release later in 2013.

I’ll be posting quite a bit about this subject as the research progresses but in our initial discussions yesterday, something popped into my mind about the difference between data and insight.

The first London Underground Map was developed by Harry Beck in 1931.  This is one of the finest examples of how data can be filtered and organised into information.  Beck realised that the physical locations of the stations were irrelevant to the passenger and to this end, Beck devised a map of straight lines running vertically, horizontally or at 45 degree angles. Although some lines have changed colour over the years, the original map has lasted over 80 years.

Harry’s legacy is there for all to see underneath London.  I’ll bet he would’ve been a great EPM consultant!

 

How to involve IT during an EPM project

How to involve IT during an EPM project

Is an EPM project a finance project or an IT project? In my experience I have found situations where:

1. Finance wanted to own the project
2. IT wanted to own the project
3. Both want to own the project
4. Neither want to own the project

It really depends on the size of the organisation, history and capability of all parties.

In general though, the business case is driven and sponsored by finance as they'll be the guys who are gaining the benefit from the implementation. However, in the same way that accounting training does not give us the skills to be good managers, it also does not give us the right tools to implement an EPM project and so we are going to need to engage with IT significantly during the project.

This engagement is going to be tricky. For a start, the language is completely different. We are talking beans and the Techies are talking SQL. These two groups of people are not generally drinking buddies. The only common interest is that they are disliked by pretty much every other group in the organisation :)

During the project, IT could help with:

1. Procuring licences.
2. Project Management
3. Pricing Application Environments
4. Data Transformation
5. Extract, Transform and Loading
6. System security
7. Automation on tasks
8. Backups and restores
9. System maintenance
10. Performance tuning
11. System testing
12. Patch upgrades

So it is inevitable that the finance guys are going to need a significant amount if help from IT. It's obviously important to engage early, during the business case for sure. Many decisions that are going to be made early are going to need IT input and like other human beings, it they're involved from the start then they are going to take ownership earlier.

Get a good IT project manager on board, not one that just shuffles paper and polishes his framed PRINCE2 certificate. This guy is your interpreter, your translator from beans to bytes. As a finance guy you don't want to talk to Colin the SQL programmer. There'll be far too many uncomfortable pauses as you realise you have absolutely nothing in common. Use your PM!

Your PM is also there to make sure you are adhering to the correct project management processes. Sometimes you will feel he's being a jobs worth but suck it up and run with it. He'll only blame you when it all screws up and it was because you went straight to build without signing off design...

You'll probably have a consulting partner helping you out on the project. They'll be really slick, have been through countless implementations and you'll look to them for a lot of support and leadership. It's true to say that in this relationship, their knowledge makes then the dominant party and it’s sometimes very easy for them to lead you more than you may realise. Not everybody is as honest and trustworthy as me!

Use your PM to sniff out the BS and be your sounding board. He'll be less passionate about the detail than you which is a good thing as he'll not get caries away.

In summary, the answer is to get a good PM on board early. The difficulty is now finding one...............

Contact The Dark Lord of EPM

Although it's pretty easy to find me on the internet, thought it would be a good idea to publish my contact details.

Very glad to hear from anybody out there who finds the blog interesting of wants some help and guidance in the filed of Enterprise Performance Management (EPM).

Best email to reach me by is andycarfax@gmail.com

LinkedIn Profile

To consolidate or not to consolidate.........that is the question!

To consolidate or not to consolidate.........that is the question!

Over the years, I have heard the following phrase so many times....."We're not big enough to consolidate, we just need a reporting cube to add everything up"

Many companies I've worked with have got away with pulling their trial balance into an agile reporting cube and usually there's somebody in the team feeling very smug because they saved money by not implementing a big consolidation system.

Beware, for every one of these companies, I can name two that also wasted money on a reporting cube and ended up with a consolidation system too.

Many years ago, I started a new job as the Head of Controlling just as the company were about to finish a project implement TM1 as the consolidation system.  My new boss was the project sponsor and I was keen to impress so I immersed myself head first.  I had never heard of TM1 and soon got on the training course to get up to speed.

Day 1 I asked the trainers how we would lock up the month end numbers and was told............"That's not really possible but we'll take a copy and then archive it away."

Hmmmmm, strange consolidation system.

As the course progressed I started asking about the consolidation logic, journal vouchers, inter company reconciliation fewtures and was told there was none.

Stranger and stranger........

A quick look on the Internet and I could see that TM1 was very strong as a reporting cube but I could find no reference to it being used as a consolation system.

At work, I could find nobody who thought the product was going to work.  The only reason I could find for the implementation was that my boss had used it in a previous company.  Unfortunately he was not a 'detail' person so what he didn't realise was that in the previous company, TM1 had been used as a reporting system for a much simpler set of GL data and the financial consolidation had actually been performed in another system oooops.

Six months later, my boss no longer worked for the company and we had written off £250k straight to the bottom line..............oooops.  BTW, this company is still using Hyperion Enterprise, which TM1 was supposed to replace...................10 years afterwards!

So what are the key drivers to implement a consolidation system, rather than a reporting system, here's my check list.

1. Control

Modern consolidation systems distinguish themselves from reporting cubes in having standard functionality that actually restrict flexibility but do add control.

2. Workflow

Back in the bad old days, when consolidations were completed on spreadsheets, the 'system' would often be given names like the "John Spreadsheet".  And then there was the sad day when John run over by a rogue taxi and suddenly nobody knew how to do the consolidation.....oops.  Good consolidations build in simple process control using the concept of task lists that lead the user through the process.  If designed effectively, a trained chimp can now do the consolidation, leaving the rest of the finance team to visit poor John in hospital.

3. Validation

Once the business unit have submitted their numbers into the reporting system, the next stage is usually for group finance to check the numbers.  Aside from the fact that the time allocated for checking is usually combined with the time for producing the group results and therefore tight, the group finance team spend 90% of their time checking for numerical accuracy rather than the key review which should be "Do the numbers that have been reported to me correspond to the underlying performance of the business?"  Standard practice in a consolidation system is to develop validations that must be cleared by the business units in order to submit their numbers to group.  In doing this we shift the burden back to those who are reporting that 2 + 2 = 5 and allow time for group to really understand the numbers

4. Complex Currency Requirements

Of course it is possible to write calculations within any reporting system to calculate currency.  At the end of the day it's one number divided or multiplied by an exchange rate.  You'd be surprised as how often this is messed up but more importantly with a financial consolidation we have closing rates, average rates and need to ability sometimes to perform adhoc exchange calculations.  All of this comes standard out of the box for most consolidation systems and doesn't require a master degree in scripting to understand.

5. Complex company structure with internal trading

You guessed it, the magic word...........INTER-COMPANY.  For anybody that's ever managed the inter-company process you'll know just how torturous this can be.  Whilst you can build rules to run the eliminations pretty easily, consolidation systems have developed over the years to include bespoke reporting for inter-company matching out of the box.  Don't waste money developing something that is out of the box in all of the recognized solutions.

6. Compliance

Not to be too product specific but HFM is the only product in the Hyperion Suit that Oracle will certify as being SOX compliance.  The reason for this is that you can pretty much lock down all user inputs to those that are properly tracked and audited using journals.  The data loads can be automated eliminating the risk of rogue users fiddling the numbers through the back door.  Although SOX dominance is only relevant in the UK with US parents, the point is that if you need the extra controls that come with your industry or company size, then use the systems that have been developed with you in mind.

7. Best in class

One of my previous companies invested in a massive SAP project.  The ONLY driver in this was that their major competition did the same and they didn't want to be seen as inferior, whilst their competitor publicized that they had invested in 'best in class' ERP.   A silly reason this but no FD ever got sacked for investing in 'Best in class'

8. You're not so different

How many times have I sat in an early requirements session to be told "We do things a little differently around here" and then by the end of the session you feed back to the customer that actually, they are doing things exactly the same as the last 5 customers you dealt with.  In all of the separate areas of finance, consolidation is less different because it is governed by accounting standards.  So with this in mind, why build something bespoke.

Hope this helps some of you make the right decision.  If you're still unsure why not drop me a line

Gimme an EPM roadmap.............PLEASE!!!!

So I was in at a client the other week, a client that had pretty much every Hyperion product in the book.

My role was to review their proposal for creating an allocation model using HPCM (Hyperion Profitability and Cost Management).

I had read the internal documentation they had produced and I was really impressed, these guys knew what they were doing. They had obviously understood HPCM and I couldn't find fault with their plans.......great, I love a smart client.

So we chatted around the subject and then I asked the question "where do you do your reporting from?" And was told the following......

• If its group stat reporting it's from HFM
• If its group management reporting still from HFM
• If its management reporting from IT then the only solution we have with projects is an old Hyperion Enterprise system
• If its budget, it's Essbase
• If its budget in IT then they have a Hyperion Planning application

WTF?!?  These guys knew what they were doing, how could it have gone so wrong.

Each application in its own right has been implemented perfectly in its own right but where was the common reporting tool, where was the 'single version of the truth'? Where had it gone wrong?

Now I know this company had been assisted by various different consultancies over the years. Practically every one of our competitions had been in there at some time and some still were. I guess this was part of the problem.

As I was in London, I went for a beer with some friends, one of which was from one of our competitions that had previously worked with the client.  We started talking..............."The problem with that client...." He said "is that they have nobody looking at the big picture..................they've spent a fortune on their applications individually but there's nobody looking at the whole system landscape"

From the few hours I'd spent with the client, I couldn't agree more.

This company had probably spent about £2m over the previous 2 years and in doing so they’d probably created about £500k worth of problems.

So what should they have done…………….

………..Another one of my clients came to us recently and told me of their plans to radically change the landscape of their financial systems starting with £500k on a new planning solution.

I said “No”.

What we actually did was spend 20 days to develop a roadmap for their EPM development.  The output of this was to:

• Establish the Vision and Goals for the developments
• Analyse the GAP to the current state and best practice
• Align available technologies to best satisfy vision and goals
• Establish and confirm the Business Case
• Develop a tactical implementation plan covering:
• Implementation phases
• Financials
• Human Resource
• Training Strategy
• Testing Strategy
• Change Management & Communication Strategy
• Key Success Factors and Quality Criteria

This was done by conducting a series of interview with:

• Key Business Sponsors
• Key Business Users
• Other Relevant Influential areas of influence e.g. IT Infrastructure, training HR etc….

Obviously part of the roadmap was the reporting strategy.  It took 20 days to complete and the client now has a concrete plan for the development over the next 3 years.

Of course it can’t guarantee a completely smooth ride but I guarantee in three years’ time they won’t be reporting the same number out of 6 different systems!

The curse of the spreadsheet

When I talk to finance teams who are thinking about investing in finance systems, the most common phrase I hear is "We are far too reliant on spreadsheets".

So what's the problem with spreadsheets. Like most aging accountants, I've loved and loathed spreadsheets from the days of Classic Lotus, Wysiwyg, Supercalc through to Lotus for Windows and then modern day Excel.

When I was getting into finance, the key skill you needed was to be able to be proficient in a good spreadsheet. A nicely crafted spreadsheet was a work of art.

In the early days when we were all getting to grips with rows and columns in a window, each week somebody would find some new functionality and then show it off. the next week, we'd all be using it. We were pushing boundaries, spreadsheets were fun....................well most of the time.

The guys who were the best at spreadsheets soon got promoted, they became leaders because they were good at spreadsheets. They were masters of the keyboard shortcut, their hands moved so quickly fingers twirling so fast they were in a blur. The ones who were really good had mastered the holy grail of the modern spreadsheet, a macro!

We were constantly being called by the network guys in IT asking us to delete some files from the network because we were taking up too much space. Didn't these idiots understand that our wonderful spreadsheets were items to be treasured, cared for.....not deleted......that was spreadsheet murder!

Problem is that when the spreadsheet kings got promoted, these works of arts were passed down to the next generation of young & keen accountant. In my first job as a management accountant, my colleague and I were in charge of a monster spreadsheet called "RESPONSE.xls". I never really understood the name but this one file produced the management accounts for the whole of a blue chip company. It was big, very big and full of file links to a hundred other spreadsheets that were saved in the same folder.

The source files were maintained by other guys in the team and sometimes they would make changes to the file which would screw up the link. Setting up the file and refreshing the links would take at least a day but the worst task was the reconciliation.

My mate and I would spend days reconciling to the source spreadsheets. The reconciliation had manual numbers input that seemed to stay in there forever. We didn't understand all of these reconciling numbers. Once I can remember asking the 'creator' of the spreadsheet what one of her numbered was and she burst into tears. To this day I'm not sure why she cried but she didn't know what the reconciling number related to, so it stayed. After all, the file only balanced when we left it there.............

As management accountants we would spend 2 weeks completing the month end and then 2 weeks trying to improve the process, making the spreadsheets more automated was the flavour of the day........bring on the macros. Don't ask how we fitted budgets into the process, I do remember it was not during daylight hours.

During this time we were all studying for our accountancy qualifications too. It all seemed very bizarre because the subjects we were learning at college were tax, law, economics, consolidation logic but nothing about Excel or Lotus.  There seemed a wide divergence between theory and practicality.

Now with the power of hindsight, I can now see that what we were learning was absolutely relevant.  We were learning the concepts, the process to follow, NOT the tools.

The tool of the day was a spreadsheet but in today’s modern world the tool is often a system.  The concepts and processes are still the same……………just different.

So is there a place in the modern world for the spreadsheet?

ABSOLUTELY – YES

However the key to many successful processes is to match the right tool with the process you need to accomplish.  If you’re producing the management accounts for the whole of a blue chip company, as I was in 1995, then this is wrong.

For quick unstructured ad hoc analysis, there is no better tool than the humble spreadsheet.  Use it with joy in your heart – IT IS ALLOWED.

Modern EPM solutions such as Oracle take it a stage further using what they call Smartview.  Use again for adhoc analysis but with the benefit of being able to draw down live data from your internal systems.

Fantastic – is there anything better?

So in summary, when I see customers today and they say "We are far too reliant on spreadsheets" I have to correct them.  The spreadsheet will have it’s place in history……..we just have to use it correctly.

It reminds me of the following analogy, “Guns don’t kill people, people kill people with guns”.

Don’t shoot the spreadsheet!!!!