FlashPoint Newsletter

View online: tdwi.org/flashpoint


		February 3, 2011	ANNOUNCEMENTS Submissions for the next Business Intelligence Journal are due February 25. Submission guidelines CONTENTS Moving Faster by Slowing Down Want Progress? Use a Dedicated BI Team The Rationale for Spreadmarts Mistake: Overlooking Requirements for Implementation and Support See what's current in TDWI Education, Research, Webinars, and Marketplace
	Moving Faster by Slowing Down Mark Peco InQvis
Topic: Business Intelligence Solutions Background The pace of business activity continues to accelerate. Responding to changes in customer demands requires that companies deliver higher-quality products at lower prices, using innovative and sustainable solutions more quickly than competitors. Successful businesses are always in danger of losing market share to competitors who provide new and more compelling products and services. Companies must constantly seek out and adapt to new market opportunities. Characteristics of successful companies include agility, innovative culture, organizational intelligence, and the ability to adapt to changing conditions. The time between strategy formulation and execution is rapidly shrinking. Organizations require growing capabilities to learn, respond, adapt, innovate, plan, and execute. A company’s ability to identify the “right work” and “do it well” before the competition does is becoming a core competency necessary for success. Opportunities and Challenges Business intelligence (BI) solutions help organizations respond to pressures created by the accelerating pace of business. Implementing intelligent responses to changing market conditions and new opportunities provides a management foundation for success. It is ironic, then, that the actual BI implementation processes typically involve difficulties and challenges. Why do these difficulties exist? If companies are eager to create the capabilities enabled by BI, why do they struggle with the implementation efforts? Repeated failures to understand the differences between the types of BI implementation projects--and the assumption that they can all be implemented using a single approach--are to blame. Responding to the changing demands of the business, “speed” is the driving force used to define project teams and scope. The move toward rapid development approaches is designed to embrace speed and flexibility across all BI implementation projects. However, many project teams believe that all BI projects must be implemented just as rapidly as the organization responds to changing drivers. If this simplistic view is present, then integration difficulties and rework may emerge in the future. The overall implementation progress may actually slow down due to a lack of architecture and standards. The Double Loop Model Successful BI solutions enable organizations to improve their performance by helping them execute the “right work well” given the context of their business strategy and overall objectives. This simple phrase, “do the right work well,” defines how a double looping model can be applied to the implementation of BI solutions. BI solutions require that many types of components and processes work together to deliver insights and information to the organization. Two major types of activities are necessary to carry this out. The first type defines the “right work.” The “right work” defines what BI assets, such as databases, integration processes, reports, and analytical models should be implemented and how they should fit together and interoperate. This type of activity, called the “thinking” category, includes planning, integration, architecture, and consensus building. It requires time, thinking and collaboration to produce desired results. The second type of activity defines “doing the work well.” This refers to the design, building, and implementation of the defined BI assets and is called the “execution” category. Most BI assets are implemented using some form of incremental approach. A double loop model recognizes that not all activities can be carried out at the same speed or in a sequential manner. The “thinking” category of activities is carried out along a slower-moving outer loop that is managed at a program level. It specifies what BI assets need to be built and how they will integrate with each other. To achieve a reasonable perspective on integration issues, time must be spent building consensus and understanding how to achieve an integrated data perspective. The “execution” category can then be implemented along a faster-moving inner loop that is managed at a project level. Activities at this level design and build the BI assets and ensure they fit together based on the architecture and integration plans defined along the “thinking” loop. Summary Allocating project activities to the appropriate loop helps separate slower tasks that require thinking, planning, and consensus building from tasks that can be implemented more rapidly. BI program teams working on the “thinking loop” can focus on defining the “right work.” BI project teams working on the “execution loop” can focus on “doing the work well” by implementing the assets in a more rapid style. Taking time and slowing down to plan and build some infrastructure will help accelerate the overall BI implementation process over time. Slowing down to think can help your initiatives pick up speed. Mark Peco, CBIP, is a consultant and educator with degrees in engineering from the University of Waterloo. He is a partner with InQvis, a strategy consulting firm based in Toronto, and is also a faculty member of TDWI. Want Progress? Use a Dedicated BI Team Bill Collins DecisionPath Consulting Topic: Business Intelligence Teams Many of our clients approach us with the same issue: their business intelligence (BI) initiative is not making the progress they expect. The decision makers and users, who are the audience for BI, complain that even straightforward requests for simple modifications or new reports take too long to satisfy. Although each client company has its own unique set of challenges, we often make the same recommendation: use a dedicated BI team. Your initial response to this recommendation might be that you already have a group of people who work on BI. However, that’s not the same as having a dedicated BI team. The most important elements of a dedicated BI team are that it be: Exclusive Specialized Self-sufficient Exclusive. Exclusive means that the BI team members work solely on a discrete BI program during their assignment to the team. Exclusivity enables focus, which drives progress. When trying to be exclusive, avoid: Having production support or maintenance responsibilities for existing BI (or other) systems; these other responsibilities invariably take precedence over new development of the BI program Being shared across multiple development projects, some of which are outside this discrete BI program Having to attend recurring meetings not related to this program, being assigned to departmental or enterprisewide committees; generally having other responsibilities Specialized. The design, development, maintenance, and support of BI systems require skills, methods, and tools specific to BI. For example, a data modeler who is highly skilled at creating normalized data models for transactional processing applications might not have the skills to create dimensional data models for BI applications. A business analyst adept at specifying use cases for transactional systems might be unskilled at creating the requirements artifacts (e.g., business questions, fact/qualifier matrix) for BI applications. In addition to being composed of people with specialized BI skills, the project team should use a BI-specific development methodology because developing successful BI/DW capabilities is fundamentally different from developing transaction system capabilities. Although the computing environment for BI is typically composed of general-purpose components (servers, storage arrays, and so on), it has unique requirements that drive its optimal configuration. For example, the test and development environments for transactional system application development are often much smaller than the production environment, because development and testing can be accomplished using a limited set of test data. However, the test environment for a BI application typically must be as large as the production environment because the performance of loading batch data and returning data from potentially large queries is core to the system. The computing environment for BI must be specialized for its purpose. Self-sufficient. Self-sufficiency means that the BI team contains all the roles and skill sets to complete all elements of the project work itself and does not have to depend on work to be done by external (to the project team) people for whom that work might not be a top priority. For example, rather than waiting a week for an external DBA to add a column to a database table in the development environment, a project team member can add the column. One aspect of self-sufficiency is the breadth of BI roles represented on the project team, which might include: Project manager Business analyst System/data architect Data modeler DBA ETL designer/developer Front-end designer/developer Other specialized roles Any work required by the project team that is not reasonable or feasible to do itself should be governed by a service-level agreement (SLA) with the centralized IT group or other enterprisewide support groups. For example, the project team probably doesn’t need to purchase or install its own hardware, but it should have an SLA with purchasing and IT for how long procurement and installation of new hardware will take. If your BI program supports critical business objectives and/or its timely completion is important, the path to success lies in having a dedicated BI team focused on that program. Bill Collins is director of business solutions for DecisionPath Consulting, which specializes in business intelligence, analytics, data warehousing, and performance management solutions. Contact Bill at 301.990.1661. Highlight of key findings from TDWI's wide variety of research The Rationale for Spreadmarts Low Cost. Another top reason for spreadmarts is their low cost. Excel comes bundled with most corporate desktops. Besides its reporting and analysis capabilities, Excel can import data from a variety of files and query remote databases. Users can then insert logic into Excel in the form of macros to automate various calculations and formatting tasks. You don’t have to be an IT professional trained in database management and SQL to create a sophisticated report in Excel. While Excel is the most popular tool for building spreadmarts, business analysts also use Microsoft Access, PowerPoint, and SAS statistical tools. (See Figure 6.) (Click to enlarge) Source: Strategies for Managing Spreadmarts: Migrating to a Managed BI Environment (TDWI Best Practices Report, Q1 2008). Click here to access the report. FlashPoint Rx prescribes a "Mistake to Avoid" for business intelligence and data warehousing professionals. Mistake: Overlooking Requirements for Implementation and Support By Mary Beth Kush Suppose you determine that, in order to meet the business requirements or service-level agreements (SLAs), you must replace existing tools with new products. You should consider and plan for the cost of training current staff, hiring new staff, and/or using consultants to develop and provide ongoing support for the new products. Consider the example of an organization that needed to support its rapidly growing business and thus had an increasing need for accurate and timely data. The business model it had been using centered on data gathering and data output. The company needed to change its ETL tool and database platform and to add robust data matching tools and an e-commerce engine to its architecture. It planned for the cost of training current employees, hired two new people experienced with its new products, and used consultants to conduct the vendor selections and lead the e-commerce, database, and ETL design efforts to ensure that the foundation was laid correctly. Although the up-front investment was large, the company knew the long-term success of its business and its ability to compete depended on its decisions about a new platform. If you determine that changing products will be too costly but aren’t sure whether the current toolset will meet the requirements, confirm that the current tools are being used to their fullest capacity. For more information on using the existing toolset, see Mistake Five. Source: Ten Mistakes to Avoid When Creating a Business Intelligence Road Map (Q2 2008). Click here to access the publication.