| The big software vendors claim they can sell you an | | | | (EAI) tool. In many cases, the reason the additional |
| "out of the box" data warehouse including reports | | | | system is used is because it has more functionality |
| that installs onto your Enterprise Resource Planning | | | | (and therefore stores more detailed and varied |
| (ERP) software. Are these things really that easy? Is | | | | information) than the ERP module. As a result, the |
| it actually cheaper to build it yourself? How do you | | | | EAI tool cannot move all of the information into the |
| determine if a given product is a good fit for your | | | | ERP, only summaries and selected data. This means |
| situation? | | | | that for the functional area that is treated by that |
| Here's the secret- If you answer yes to all of the | | | | module at least some of the detail users are |
| following its probably a good idea to buy: | | | | interested in does not exist in the ERP. And if it's not |
| - You've configured your ERP software exactly as | | | | in the ERP, it won't be picked up by the pre-built |
| the vendor who wrote the data warehouse or data | | | | solution. |
| mart expected you to. | | | | Diverse and specific report requirements |
| - You use ALL the modules of the ERP- and do not | | | | Its amazing how the layout (column order, |
| have any "best of breed" applications for any areas. | | | | summarization, which key performance indicators |
| - You are interested in the key performance | | | | where) of a report can be very very important to |
| indicators that they have included and they calculate | | | | report consumers. Its also amazing how much work |
| them the same way your company does | | | | can be required to modify the hundreds of reports |
| - Your end users like the layout, formating and color | | | | and cubes that came with the pre-built system. |
| choices in the reports included and have promised not | | | | Report writers everywhere are nodding their heads. |
| to ask for changes. | | | | Enough said. |
| In fact if all this is true, then you will probably save | | | | Data Quality Issues |
| HUGE amounts of money by using a pre-built | | | | Even if you've used all the tables and fields in the |
| package. | | | | ERP exactly as needed, and the reports look just |
| But. Lots of things tend to get in the way of that | | | | fine to your users, if they have not already been |
| dream. | | | | given access to all this information you will probably |
| ERP Customization | | | | find that there is lots of data quality work to be |
| Anyone who has been involved in a large ERP | | | | done. This cost is there for both the build and the |
| project knows that there is always at least a bit of | | | | buy options- just be aware of it, because it means |
| customization. If the ERP is a good fit to your | | | | the buy option is going to be more than just the |
| industry, and the project is focused on avoiding | | | | sticker price. |
| customization and using all those "flex fields" and | | | | One ray of hope- very specific industry solutions |
| "category codes" as they were intended, then the | | | | Hold on, the vendors say, but we have industry |
| pre-built data warehouse that is available for that ERP | | | | specific data warehouses and data marts- these are |
| might be a very cost effective route. | | | | built just for your industry so they know your |
| But here's the rub; in many ERP projects rather than | | | | business. We have one for banking data marts, |
| change the existing processes (which by the way is | | | | another one for pharmaceutical data marts, you can |
| often the justification for installing an ERP- process | | | | get a sales data warehouse specifically for retail, and |
| improvement), the business users find reasons to | | | | so on. |
| "keep things as they are"- and as a result, the ERP | | | | Without a doubt the more focused the pre-built data |
| bends to the existing process rather than the other | | | | warehouse or data mart is the more likely it is that |
| way round. | | | | its going to save you time and money. |
| This means that new tables are created to hold | | | | Conclusion? Often when something sounds too good |
| information that normally would be in a different | | | | to be true... |
| format in one of the standard ERP tables. This means | | | | The bottom line is, although you can tell I'm not head |
| that that code in field "X" that normally would mean | | | | over heals for prebuilt datawarehousing, I think the |
| something is overloaded to mean three or four | | | | field has evolved. But then again, so have the prices. |
| things. This means that field "Y" that isn't needed by | | | | The key is to be realistic regarding how much |
| your company ends up being used for something | | | | modification will be required now, and going forward, |
| completely different. | | | | and how many of those hundreds of cubes and |
| Well, when the pre-built data mart plugs into your | | | | reports that are included are actually going to be |
| ERP, it doesn't know anything about those tables | | | | applicable to your business. |
| you've added, and its assuming that the data is in the | | | | It is possible that a package exists that will provide |
| standard tables. Its already configured its ETLs, and | | | | the best value. Just be very very careful when you |
| star schemas to use those two fields that you've | | | | are comparing the costs- because its never quite as |
| high-jacked, and so all those reports and cubes don't | | | | sweet a deal as it first seems. |
| make any sense without modifications. | | | | Smaller, very focused pre-built data marts, particularly |
| To be fair, many of the pre-built data warehouse | | | | targeted to applications or modules that are used |
| frameworks have evolved to have lots of flexibility | | | | fully by an enterprise are probably much lower risk |
| and configurability in them- you can modify and map | | | | and more likely to provide real value than a massive |
| the ETL jobs provided to fit your data. You can turn | | | | "out of the box, install it in weeks not years" data |
| off KPIs so that they don't load in false data. | | | | warehouse. |
| But the trick is the more you have to modify, map | | | | My personal experience with pre-built products was |
| and configure, the more effort you spend. The more | | | | that in the end, when the dust settled, we had |
| you shut off, the less you have. In the end you can | | | | touched almost every ETL job, and the reports that |
| find that you are always trying to fit your specific | | | | were the most used and useful were ones we had |
| requirements into the general, vanilla requirements | | | | built from scratch, largely using data loaded out of |
| that came out of the box. Often, this configuration is | | | | custom ERP tables. |
| more effort and demands more compromises than | | | | If you have customization in your ERP, you have to |
| just building what you need. | | | | think hard about this. The reason the custom tables |
| Non ERP transactional systems | | | | were put in there was because they hold information |
| In some ERP implementations, certain modules of the | | | | that was important enough to justify the |
| ERP are not used and instead a third party software | | | | development. This probably means that the |
| provides the functionality. Often, key information is | | | | information in them is going to be important to the |
| then moved in and out of the ERP as required for | | | | business intelligence you are building. |
| transactions via an enterprise application integration | | | | |