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