The extensive world of enterprise data is quite tricky; however, it’s very important to clearly distinguish all the solutions used when dealing with data.

As customers are very important for any company, customer data is among the greatest company’s assets. In fact, customer data integration (CDI) solutions are to deliver the fullest information about customers.

However, as CDI is a software solution, and, in fact, is a clearinghouse for data synchronization and deployment, it is inevitably compared to data warehouses. There are several reasons of this confusion:

• the aim of both solutions is to accommodate clean, meaningful information to the enterprise
• both solutions are undoubtedly beneficial for business
• both demand a solid partnership of business and IT

This confusion is risky, for these solutions differ in term of their positioning as well as in term of their usage. According to Jill Dyché one of the most acknowledged BI experts:

Data warehouses are designed and built to support business intelligence, and are meant for use by business people. Best practice data warehouses are those that have been planned around a set of business requirements that inform a series of applications—we call this the BI Portfolio—that are deployed incrementally to the business over time.

CDI, however, is purpose-built for operational data integration. The CDI hub is the ultimate home of customer master data that has been matched, reconciled, and certified, and is available to a series of business applications and systems (not end users). Unlike the data warehouse, which usually stores historical detail, summarized data, and time-variant information, the CDI hub stores or points to certified master data about a customer.

Data migration is an inevitable evil for any enterprise. As business requirements change and demand for new applications, or there is a need of removing duplications and inefficiencies, business-critical data migration can’t be avoided. Data migration initiatives, unfortunately, still have a high rate of failures due to the complexity of the process. According to CRN Australia’s article I’ve found lately, there are four common data migration rulles which could help to drive the initiative to success.

The first rule says that data migration is primarily a business issue. Technical side is important, but only as a means to fulfill the process. IT people don’t always have the power or the necessary knowledge to deliver what is required by the business. It is business who is to make the decision on:

• What is the purpose of migrating data?
• What data should be migrated?
• When should the data be migrated?

The second rule claims that business goals define the solution and approach selected for data migration. This rule supports the first one. It is important to bear in mind that the best technical solution is not always the best business solution. IT’s responsibility is to make sure the chosen migration technology is able to support possible changes in priority and direction without restarting every time. IT also should provide for the issues that may occur during the migration.

The third rule is about setting the level of acceptance of data quality level. Many data migrations have been scuppered by overestimating or not understanding the quality of the source data. While enhancing data quality is a worthy goal, it is really important not to go off on a data perfection crusade. It is a trap that drives many, many projects to inflating both the cost and the time to deliver the project. To avoid this trap, data owners and users need to determine the level of quality they require at the start of the project, in order that the technologists have an appropriate goal.

The fourth rule is about measuring data quality in order to determine the level of quality business users require. Those measures should make sense to business users and not just to technologists. It makes possible to rightly measure deliverables, perform gap analyses, and monitor and improve ongoing data quality. It also ensures that the efforts are concentrated on where business users see value and can quantify the benefits.

Open source data warehouses possess the same options as any other types of open source software: the same model of licensing, community development processes, and same degree of openness. They may be offered as free downloads, or for a nominal flat fee, as fully supported systems. Or there may be no limit to the number of licenses and implementations a company may make with the software.

Acording to BeyeNetwork article, the benefits of the open source data warehouses are following:

• Up front and maintenance costs are less than those of proprietary software. Besides, there is a possibility to customize the products companies use to improve their operations, for the original source code is open and may be downloaded.
• Skill sets that are widely available in the market are employed.  As a result, an organization with existing database or data warehouse expertise will not have to look further when a new open source data warehouse project is put into place.
• Improved standardization. Transparent and community supported open source code considers important standards to be consistently supported across all versions and implementations. Something that proprietary formats cannot and will not offer.
• Flexibility which enables enterprises to expand the solutions to an unlimited number of users, with no per-user or per-processor charges of proprietary software packages.
• Community effect. Open source solutions leverage communities of developers and innovators to advance development. New code and features are contributed back to the community, constantly increasing the range of new options available to end users.  Moreover, companies may address the community in order to fix any bugs or security flaws, which takes, normally, only days, instead of waiting weeks and months for the next security patch or service pack from a vendor.
• Incremental implementation.  There is no need to a mega project at once. Projects can start small and build upon the success of implementations. This dumps the tendency to “overpromise,” which is often a necessary evil for acquiring optimal levels of funding for data warehouse projects.

There’s been quite a period of time since open source data warehouses evolved and gained popularity. However, an open source data warehouse is still regarded as a solution for small or mid-sized companies lacking enough budgets for solid proprietary solutions. Bigger companies may also use open source solutions as complimentary to their proprietary data warehouses.
Getting the most out of an open source data warehouse implementation is possible. There are some ways below provided by Claudia Imhoff:

• Open source data warehouses complementing already existing proprietary enterprise solutions may help quickly address the new company’s needs. Proprietary solutions being more strategic are not so fast to react to those changes.
• Normally, it’s the analysts who work with data warehouses; they are familiar with building massive queries and other technical stuff. But in some cases, there are end users who don’t have special technical knowledge, and need as much ease of use as possible.
• Open source data warehouses should be compatible with related open source environments.
• While open source data warehouses may seem cheaper than proprietary solutions at first, additional costs, such as transition and training costs, should be taken into account.

CRM has become extremely popular in the recent years. Nowadays, many companies have accepted the importance of CRM and have made the decision to implement CRM initiatives enterprise-wide. However, a great deal of CRM strategies fails. In fact, those failures may be caused by different factors. But here are the most typical reasons of CRM projects failures:

• Believing that CRM starts and ends with software. However, a CRM project means the right people executing the right processes, using the best possible tools at their disposal.

• Under committing a CRM initiative – which means failing to invest enough time and attention to to develop a comprehensive sales process reengineering vision, settling instead for a series of minor, tactical changes.

• Considering CRM to be a part-time project. A part-time approach will not generate part-time results; it will generate no results at all. For CRM projects require full-time assignment of people for the duration of the project, active executive involvement, full-time commitment of personnel, accountability for results, and a process-driven budget.

• Having big expectations and small budgets. Trying to implement a CRM initiative as cheaper as possible is a mistake a company will regret very soon. A low-cost approach is extremely prone to failure. Starting a CRM initiative one should never focus primarily on price, but only on benefits.

• Picking wrong technology partners is a mistake that occurs when a company bases vendor choice only on product features. However a company must thing about their specific sales process functionality needs.

• Assuming that automating your sales process will be similar to automating manufacturing or finance. The degree of complexity in implementing a CRM system is significantly higher than the other two examples. Budgets should be provided for necessary upgrades and for ongoing system support.

Business intelligence is considered to be the helping hand for organizations wishing to do more with less. However, David Hatch, an Aberdeen Group analyst, has outlined four potential cost factors likely to arise in a BI initiative if an organization isn’t paying attention. According to Hatch, overall cost of ownership is not about the costs of purchasing the software, there are also indirect and hidden factors which affect the real BI costs. Very often the resources the company needs to acquire to properly implement, deploy, support, and maintain a BI solution are far more greater than it was assumed in the beginning.

Here are those factors, as Hatch describes them:

1. Year-after-year budget increases: The typical best-in-class company sees a drop in year-after-year BI budgetary costs. Average and laggard companies, however, can witness increases in BI expenses that range from 2 percent to 9 percent.
2. Cost per user: Best-in-class companies lower per-user costs by 4.3 percent whereas average performers and laggards often see increases ranging from 1 percent to 7 percent.
3. Time to complete projects: Best-in-class achievers complete BI projects, on average, within 14 days. Average performers take nearly three times as long (approximately 39 days) to complete a project, and the typical laggard company takes more than 12 times as long (177 days).
4. Modifications to BI software: Altering a BI program takes less than a day for best-in-class companies; three days for average performers; and up to eight days for laggard organizations.

Then, how a company can avoid additional costs of ownership and achieve higher returns from BI initiatives? Aberdeen suggests that investments in the following areas will maximize results:

• Data integration and cleansing: “Companies are finding it difficult to bring data together from multiple, disparate sources,” Hatch says. Investing in tools for data management can be of help in this regard. Best-in-class companies are twice as likely as their counterparts are to institute data integration and cleansing capabilities.
• End-user requirements: “You really have to stop and think about why…so many companies have deployed tools that so many aren’t able to use,” Hatch says. Companies must understand that end-users — especially nontechnical, non-data-guru types — may need different approaches. Hatch advises companies to focus on end-user needs before deploying a solution.
• Training: Top performers are 37 percent more likely to invest in extensive user training on BI solutions and 40 percent are more likely to have formed formal user committees to encourage adoption. Additionally, best-in-class companies are twice as likely as laggards and average performers are to sign up for vendor-provided services.
• Operational BI: Successful users of BI use the technology on an everyday basis rather than merely getting a summarized spreadsheet version of performance and high-level trends. Hatch says that operational BI seems to be gaining traction as companies look to make comparisons over shorter time spans rather than just examine large-scale trends.