|
|||||||||||||
|
Essential Guidelines for Evaluating Analytic Applications There has been a great deal of industry buzz about analytic applications over the last year, much of it from the trade press, industry analysts and vendors. Every software vendor has introduced a set of analytic applications, and they all want your business. You listened to their presentations, viewed their demos and read their brochures. Now you have to decide if you need one and, if so, which one. Analytic Application PackagesAn analytic application package is a packaged solution that enables business users to access and analyze information needed in various business processes. The business solutions provided are tied to particular industries or to functional areas within a company such as finance, sales, marketing and supply chain. The packages are used for tasks such as budgeting and forecasting, marketing campaign analysis, fraud detection and inventory control. A typical analytic application package includes a data model; extract, transform and load (ETL) processes; reports; and an integrated set of tools to create, deploy and maintain this environment. The popularity of customer resource management (CRM), enterprise resource planning (ERP) and supply chain management (SCM) packages set the stage for analytic applications. Companies spent the latter part of the 1990s implementing ERP systems to automate operational business processes. These systems were a business necessity, often driven by the need to replace homegrown applications that would fail in Y2K. A massive investment was made both in time and money to deploy these systems. Many businesses found it more cost effective to use prebuilt software packages to run back-office business processes than to write programs from scratch. Many of these projects, however, required significant customization of the packages that was not planned in budgets or project timetables. During the technology bubble, many front-office packages, such as CRM, emerged to help business manage their customers and suppliers. During that period, we were on "Internet time," and businesses felt they needed to deploy CRM and e-commerce as soon as possible. Businesses made huge investments to deploy these packages and improve their customer and supplier interactions. The proliferation of CRM and ERP packages has led to a proliferation of data. Businesses are now focusing their attention on accessing and analyzing that data. They need to gather and view data to better monitor, measure and understand their business. Armed with this knowledge, they understand how to improve their operations and increase revenue. Enter analytic applications. ERP, ETL and BI (business intelligence) software vendors have started offering packaged analytic applications over the last few years. The packages are based on predefined data models oriented to a specific industry or business process. They include ETL and BI tools, which extract data from source systems, load it into predefined data models, and then provide reports or analytic capabilities accessing the loaded data. The analytic applications vendor may have integrated other vendors' offerings into their product. The type and orientation of analytic applications vary widely from one vendor to the next. The implementation of ERP, CRM and SCM packages paved the way for software solution packages. They allowed businesses to implement complex applications without large build-from-scratch IT projects. If we've learned anything from recent history, however, it's that these packages were not simply buy-and-use projects. A great deal of customization was required to implement and deploy these packaged solutions. Many projects took much more time, money and effort than initially envisioned by the business or suggested by the software vendor. However, as these packages matured, the vendors added features and made them easier to customize. Build Versus BuyMany think they need to make a choice between building or buying an application. It's not that simple. It's really a build versus buy-customize-build decision. Which approach is quicker to market, more cost effective and more likely to provide the better business return on investment (ROI)? Start with a quantitative and qualitative assessment of the build-versus-buy alternatives. The quantitative assessment is an old- fashioned, comparative cost/benefit analysis of the alternatives. Some businesses will rush to purchase without doing their homework. If the applications they purchase have the right functionality, data, processes, tools and architecture, they will get away with their shortcuts. However, if the business is surprised – a common occurrence when a software market is as immature as analytic applications – it will be forced to do a lot of after-the- fact analysis, evaluation and planning. This is a very costly process and often results in project failure. A careful assessment will steer you in the right direction during the build-versus-buy decision process. The assessment includes:
Obtain Functional and Data RequirementsFirst, determine the business functionality your business is seeking including business processes; business rules, metrics and measures used in these processes; and business reporting and analysis capabilities. Second, based on these business requirements, determine the data model needed. The data model must be detailed enough to determine the business subjects, data fields and level of granularity. Third, based on the data model, determine the data sources required including the data fields from each source, business rules used when sourcing the data, data cleansing rules and transformations needed to cross-map data from multiple data sources. Fourth, document your existing IT architectures and standards. Finally, assess your organizational skills and knowledge. Assess your business' knowledge of the business processes that the application will provide, as well as IT's experience with the tools that come with the application. Review the Analytic Application PackageFirst, does the analytic application provide the functionality your business is seeking? This may be a simple "no" if there are no analytic application packages covering the business processes or tasks that your business requires. However, if it appears to fit, look beyond the great demo and the user interface to determine if the application performs the business functions you need. Review the detailed business processes and tasks provided including business rules, metrics and measurements. You don't need to evaluate the BI tool capabilities provided with the application yet. You can purchase BI tool functionality without purchasing the application. At this point, you're just examining the application's value-added business functionality to see if it matches your requirements. Second, does the analytic application's data model match your requirements at both the data field and granularity levels? This is where you really need to get details. A cursory examination won't be enough. Third, review the data sources supported by prebuilt ETL code. Are all you data sources covered? Of those that are supported, are the specific data fields and granularity provided? Fourth, review the architecture and tools used by prebuilt solutions. Review the BI, data model and ETL code with respect to the standards used, quality of the code and its documentation. Determine what tools will be introduced into your IT environment. Document any limited-use licenses provided with the prebuilt solutions and understand what would be needed to extend the license usage. Compare the versions of the any tools bundled in the application from other vendors with the current versions provided by those vendors. Determine the Gaps and Overlaps Determine the extent of functionality, data and source systems not covered by the application. What will you have to add to the prebuilt solution? Another important step is determining how much you will have to customize the analytic application. This is usually the biggest surprise for those who do not conduct a detailed assessment of their needs and evaluation of the application's functionality and data. Many ERP projects went over budget, were late and did not meet expectations because significant customization was needed but not initially accounted for. Customizing may be more economical than building from scratch, but you can only calculate that from the details. When you're examining the supported data sources, such as ERP systems, it is not sufficient to simply verify that the analytic application sources data from your ERP systems. You need to go one step further and determine how much you have customized your ERP system in relation to the data you are sourcing from it. If you have customized your ERP system, you will have to customize the prebuilt ETL code to accommodate those changes. In addition, you need to determine if there is overlap with a data warehouse or data mart that you have built and the analytic application you are considering purchasing. If there is overlap, there is the potential for conflicting information to be provided by these systems. Does this conflicting information cause problems in your business decision making or slow the process by requiring reconciliation processes? Do you need to retrofit your existing data warehouse or data mart with the data from the analytic application? If you do, then this must be considered part of the effort to customize your prebuilt solution. Estimate the Effort to Fill the Gaps Now you need to move from this project phase to building or buying and customizing the analytic application needed by your business. First, develop a project plan, including the tasks, time and resources to create the application from scratch. Your decisions regarding the database, ETL tool and BI tool to use in the project can be made using existing standards within your company. If you need to introduce these tools, pick one of the top three market leaders or perform a quick check with industry analyst reviews. Second, develop the project plan for purchasing and deploying the prebuilt analytic application. You have already determined the gaps in functionality, data and sourcing, as well as the customization required. In addition to the base level work to install, implement and deploy the prebuilt portion of the solution, your project plans need to include the customization work needed. Produce a Cost/Benefit Analysis When the project plans and budgets are completed for the two alternatives, they should be compared by project timetable, resources, costs, training, risks, issues and constraints, and business ROI. You will be making some quantitative and qualitative comparisons when you review the alternatives. You may find, for example, that buying results in a quicker time to deploy but costs more and requires more outside resources. Building, on the other hand, may provide a solution that is an exact fit for the business but involves more upfront business involvement to gather requirements, prioritize and obtain feedback during development. A careful analysis will ensure that your company makes the right tradeoffs. Analytic applications help improve business operations and performance. They may decrease time to deploy analytics to your business if they match the metrics and measures your business is trying to use and get their data from your data sources. At this point, the analytic applications software market is immature but growing. Many vendors across a variety of software categories are introducing prebuilt solutions. Your executives may be excited when they see the customer demos and hear the promises about rapid deployment (with almost no work involved!), but don't be fooled by the hype. Don't let yourself be set up for failure by not meeting expectations, taking more time to deliver than promised and exceeding your budget. Do your homework. The decision to build or buy should be based on a thorough cost/benefit analysis and the business ROI. Business analytics, either built or bought (and customized), offer great potential to your company. They enable you to unleash accumulated data and transform it into information to better understand, manage and grow your business.
About Athena IT SolutionsAthena IT Solutions provides data warehousing and business intelligence consulting services to help businesses increase the return on investment of their corporate data. Athena IT Solutions founder Rick Sherman has more than 17 years of business intelligence and data warehousing experience, having worked on more than 50 implementations as an independent consultant and as a director/practice leader at a Big Five firm. He founded Athena IT Solutions, a Boston-based business intelligence and data warehousing consulting firm and is a published author, industry speaker, instructor and consultant. He can be reached at rsherman@athena-solutions.com or (617) 835-0546. |
||||||||||||
