top of page
  • Jonathan Prentice

Myth busting - Excuses not to roll out a modern EDW

Updated: Jun 24, 2023

In today’s data driven age, every growing business eventually requires a data warehouse to underpin their BI strategy. This blog breaks down a few of the excuses and myths that prevent businesses implementing a modern EDW (data warehouse) and realizing the benefits.





EDW is a “nice to have”... our business is not ready for that yet!!!

EDW should be seen as key foundational pre-requisites to businesses success and growth. A companies data warehouse is a critical foundational piece of your IT application stack. EDW should be considered just as critical as your ERP software, or your office365 subscription … sure you can get by without it for a while (using nasty work arounds), but the sooner this is established the sooner you can realize the benefits and use it to grow your business.

But we don’t have a BI team?

Dedicated BI staff are great, but existing IT staff are often capable of adopting ownership and responsibility for your data warehouse. IT staff are typically excited and grateful to get involved in this area, and willing to build up there expertise.


Using the right cloud technology greatly reduces the need for a large team to manage your data warehouse. Administration and maintenance workloads associated with traditional on-premise EDW databases are minimized, and in many cases eliminated. Setup times for modern data warehouse tools are also greatly minimized.

Modern data visualization (reporting) tools like PowerBI/Tableau, are very user friendly. This means its feasible to offload report development to business users (with some guidance from IT), leaving your limited IT resources to focus on providing data to the users. Modern “best in class” cloud tools are well supported by free online training material. So minimal effort / cost is required to upskill your users on these tools.

But the applications we want to report on are really old and out of date?

Business that have old outdated applications will get the most benefit from a modern Data Warehouse. With a modern EDW you have a unique opportunity to completely modernize your companies BI offering without having to upgrade your core ERP/CRM applications.

Older applications are likely to have low quality “built-in” data and analytics tools. But once the data is extracted, cleaned and transformed into reporting friendly format in your EDW, it makes no difference how old the source application is.


There are plenty of good data pipeline tools around to reliably and efficiently extract data from older on-premise applications. So working with older systems is not an issue.

We don’t have the money, its too expensive.

Modern data tools can be very cost effective and cheap. Best in class EDW tools don’t need to cost you the earth. Most are consumption based charges with zero upfront licensing costs. So getting started with small amounts of data is generally very cheap, and the tools will effortlessly scale as your data grows. The biggest cost will be the man power needed to establish the foundational pieces of your data warehouse and ETL processes. But with the right partner, and right strategy, this can be done in a cost effective way. With the wrong partner this can turn into snowballing, never ending, consultant fees, that lead to your project failing.

It takes years to build a usable EDW, the business can’t wait 12 months before getting value out of this type of project?

EDW implementations can take large amounts of time and resources. But there are ways to minimize this and make the core foundational “first steps” quick and painless, so that you can start delivering visible value to your business in a short time frame. Using the right technology and tools is critical to achieving this. Using the right partner to get your foundational architecture of your EDW data stack right is also critical.


First steps typically involve keeping scope small, and focusing on a particular “use case” e.g. Inventory reporting. And building out only the data pipelines and ETL to achieve that “use case”. E.g. You don’t need to ingest and model every field/table/object in your ERP system as a first step. It is best to build this up over time, as quickly or as slowly as you want. The types of data you prioritize on developing and bringing into your EDW first, should be driven by real user requirements. This also helps keep cost down during early stages of a project as volume of data will be minimal to begin with, as you focus on just your first few “use cases”.


It’s important your EDW implementation strategy factors in how to deliver visible value to the business as early as possible in the implementation process. The last thing you want is your exec team cancelling the project because you are 12 months into the EDW implementation and no visible value has been delivered. A good partner will help you achieve a quick efficient implementation of the core pieces to enable delivery of visible business value early on in the project (typically a simple report or dataset for users). The day your EDW delivers something valuable and visible to the business users is an important milestone for your EDW implementation.


Data warehouse implementation is a continuous never ending journey, where the EDW team keep adding more value, more data, more reporting, more users indefinitely. So don’t assume you have build everything you will ever need in during the initial implementation.

But my ERP/CRM vendor has a BI EDW solution I can buy?

That’s an option, but an EDW is not for 1 particular ERP/CRM application, it’s a place to consolidate data from all your applications. Your EDW solution should not have hard ties to 1 x particular ERP or CRM brand. E.g. This would create issue should you ever decide to change ERP/CRM.


This type of solution will not be based “best in class”, “multi-purpose”, “modern” data warehouse technology. So you will miss out on all the benefits of using "best in class" technology, that made them “best in class”.


There will also potentially be a number of constraints, limitations and hooks applied to these types of solution. E.g. you might have to use specific data visualization software, you might have to use there specific ETL tools and processes, they might not work well with data sources outside of the CRM/ERP they are built for.




22 views0 comments

コメント


bottom of page