Built for SpeedExecutive dashboards are a requirement for intelligent organizations that need to respond to threats and opportunities in an "agile" manner
by Nancy Zurell Continued from Page 1 In the semidistributed architecture, the upside and downside points are a reversal of the fully distributed architecture scenario. Security may not be as tight. If all the components, save for the feeder systems, are on the same box, a hacker need only access that box to compromise the entire application. Security is a big concern. The data the dashboard presents is the heart of the company. It's the trade-secret, how-are-we-doing data that nobody outside the company should see. Furthermore, if one part of the system fails — say, the Web server blows up for some reason — the entire dashboard must come down so that the failure can be repaired, or the entire system must be rerouted to the backup system. That could mean significant downtime. However, the upside of faster access time and easier maintenance that comes with implementing a semidistributed architecture offsets the security risks and makes the semidistributed option the better option of the two architecture schemes. Good security people can protect a semidistributed dashboard architecture. As long as all the dashboard components don't reside on the same box, the system can be protected very well. A typical, secured, semidistributed architecture could have the Web server and BI engine on the same machine, while the database for the dashboard resides on a separate machine. In this architecture, there are only two machines, instead of three — making for quicker troubleshooting of any problems that might arise — and there are, correspondingly, only two backup machines. Response times are also generally quicker with this type of architecture because the information requests don't have to pass through as many firewalls and gateways. For the money, security, and maintenance time, the semidistributed architecture is just the better plan. Before You BuildNow you know what the end product should look like. Because dashboards are one-screen presentations of information, and because most BI tools on the market are relatively easy to use, many organizations rush to pull performance metrics from various sources, plop them into a database, and start work on the dashboard interface. But be careful, because there are two serious pitfalls to watch out for when building a dashboard: correct definition of KPIs and scope creep. It goes without saying that a dashboard that doesn't enable executive management to monitor the most critical performance metrics of the organization isn't worth much. However, defining exactly what key performance indicators are is often a tough task. Managers all have their own ideas of what key information is. Also, many organizations don't have a really good handle on the statistics that really forecast the success or failure of their business. They just go by the tried-and-true financial metrics that they've always used. That process won't work with a dashboard. Well, it will, but the dashboard will be useless. Before you build a dashboard, take some time to gather proper requirements. Bring users together from across the organization to get input about what specific metrics predict the performance of the business. Gain consensus on which metrics are most critical to monitor on an ongoing, alert-based basis. When you have that information, put those metrics into your dashboard. But don't put too much information into the dashboard. Remember, dashboards are supposed to be time-saving tools. Sure, they're supposed to give you all the critical information you need, but all information is not critical. As with any IT project, as word gets out about the new application you're building in the finance department, there'll be hangers-on who'll want to add to the mix. Don't let it happen. If you've gone through a thorough requirements gathering process, you know what information you need. Stick with it. If you keep adding new pieces, you'll soon be dragged down by slow response times and meaningless information. Charging AheadBuilding an executive dashboard is just like undertaking any other IT project: A dashboard will only be as good as the tools and processes with which you build it. Look for the best BI toolsets available, and use a sound methodology, including the proper architecture and information requirements, to build the application. Keep focused on the task at hand, and don't let scope creep bog the project down. If you follow this route, you'll come away with a solid executive management tool that will contribute very positively to your organization's bottom line. Nancy Zurell [nzurell@kpmg.com] is a senior manager with KPMG Consulting Inc. in Atlanta. Her area of focus is data management and BI solutions. WHAT DO THE BI VENDORS OFFER?Some BI vendors do provide more than just the foundation for building an executive dashboard. For example, Business Objects SA recently released four packaged applications — Customer Intelligence, Product and Service Intelligence, Supply Chain Intelligence, and Operations Intelligence — that work in conjunction with its Application Foundation development platform. Similarly, Cognos provides six packaged analytic applications, including Inventory Analysis, Sales Analysis, Procurement Analysis, General Ledger Analysis, Accounts Receivable Analysis, and Accounts Payable Analysis. Both of these product sets include prebuilt applications, reports, and KPIs. Your needs will dictate whether you build an application using the toolkit, use the applications as is, or customize the applications as necessary. However, regardless of what their marketing literature may claim, not all BI vendors offer dashboard capabilities. There are several specific functionalities a tool must have (but is not limited to) before you can use it to build a dashboard:
RESOURCESBusiness Objects: www.businessobjects.com Cognos: www.cognos.com
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
| |||||||||||||||||||||||||||||||
