During a data migration project, the information technology department is in a unique position to either help or hinder how well all the different parts of a company work together.

The transactional systems that a company uses can be the glue that binds, or can be a key part of the walls that block inter-departmental collaboration and information sharing.

The data migration project is your best chance to break down the data silos- but it won’t be the easy path.

Not only can the ERP project create new opportunities for efficiency and process improvement, but it can also be the process through which people from across the company start to work together.

ERP projects often require teams of subject matter experts from various functional areas (finance, sales, manufacturing) to work together- depending on how serious your silos are it might be the first time many of these people have met.
Make the most of it- see if you can’t encourage some new working relationships that last beyond the project. A few key personal contacts between departments can make a huge difference.

Best case and worst case: big difference

1. Best case– processes that stumbled along without any coordination are totally reworked for the better and everyone- including your customers- see a huge positive difference that ends up hitting your bottom line. Win!
2. Worse case– no-one will accept change, everyones position is that either things stay the same, or others adapt to their vision of the future- you end up finding a way to shoehorn all the existing processes into the ERP, resulting in a messy, customized compromise that no one likes and limits progress while costing a fortune. So sad.

If you are doing a data migration project- how can you help make it be a more positive and unifying step, rather than a transfer of the existing silos intact into the new ERP at great expense?

The first step is to admit you have a problem.

The first thing to do is to identify how bad your silos are, and get all the players to look the problem in the face.
If you have silos, but people don’t identify it as an issue, there is no way you’ll get the resources you need to fix them.

Make it clear that customization is the enemy.

Sure you could customize the ERP application that you are installing to do exactly what each department does now. Add some tables, write some bolt on code.

I’m sure you can do it. Thats not the point.

Technical resources love customization because it’s more fun than configuration. Don’t fall into the trap of thinking “we’re satisfying the customers requirements.”

Customization in an ERP system is expensive, usually reduces functionality and in the long term drives significant maintenance and upgrade costs.

If you customize the new ERP system to accommodate the existing silos you are NOT satisfying requirements. You are leading the business towards a failure that they don’t really understand.

You need to find language that the functional teams and management can understand and explain the risks clearly.

If we don’t get together and consolidate our processes and our data definitions we’re going to end up with a mess in the ERP.

The system was not designed to do that- the point of an ERP is to be integrated- if our departments don’t work together, than the ERP isn’t going to make anything better- and its a waste of money.

Get top down support for the painful change that is necessary.

Sometimes things can be grassroots, originating at a level below the executive suite. If that works for your company, thats great.

But in the majority of cases the kind of short term pain that breaking down entrenched silos will cause is too intense to be initiated anywhere but at the very top.

The leadership needs to make it clear that everyone is going to share in the change, and no-one has a “get out of change free” card.

It has to be clear that it is not a competition between the various approaches that might exist, but a move to a new approach.

It’s really really hard. If it’s not hard, you’re not doing it right.

There’s nothing I can write here to make this kind of change easy, it’s not.

But by building cross functional teams, making goals clear, and managing expectations it’s possible to make progress.

So in summary what I’ve been trying to convey in this series of posts:

• Data migration projects are data quality projects.
• Data migration projects are master data management projects.
• Data migration projects are an opportunity to break down the walls between silos within the organisation.

You can make a real difference if you strive to make the data migration project advance on these three fronts.

You always have to work within the constraints you have in terms of budget, company culture, existing systems and of course, internal politics, but if you take a step by step and pragmatic approach with these goals in mind, you’ll be contributing to the solution.