For many companies, the benefits of a business intelligence portal can be substantial. Smaller entities, however, don’t require all the robust features some portals offer; for these organizations, something simple with a few available data sources and reports may be sufficient.
Before embarking on the journey to create a portal, discuss the overall vision and ideas with key leaders within the company. Discuss the relative need for a BI portal, and gauge their level of commitment to creating one. See what features they want and need, and encourage departmental conversations about what reports and features others might be looking for.
Hagfeldt has some additional suggestions about planning for the creation and implementation of a BI portal:
Catalog all the content you have today.
Analyze what is and isn’t important.
Enrich the important content to provide additional value (e.g., automate uncovering exceptions and anomalies).
Organize content by user groups to ensure they only get the content that’s relevant to them.
“Make sure what you’re looking to do is in line with where you want to go as a business,” Hensley suggests. “Getting [departments like marketing and sales] in alignment with IT is very important if you want to grow your business.”
You should also discuss how you will measure the success of the portal. Will there be reports about how people are using the system? Will other sources of data disappear so people will be forced to use the portal? Discuss what usage levels are necessary to justify costs.
“Explain the why and the value of why you’re going through the project,” Liferay’s Hensley emphasizes. Including end users in the planning process and making them understand the value of the system and what it will do will help with buy-in. “They know the good and they know the bad because day in and day out, they’re using the system.”
A BI portal is only as good as the data that feeds into it. Take a look at the quality of your data. Is it structured, unstructured, or a combination? A data profile can help you identify the content, consistency, and structure of your data.
“It’s cheaper to clean up the data before implementing a portal,” Hensley notes. He uses what he calls the one to 100 rule. It might cost $1 to clean up data before going into the system, $10 to clean it up once in the system, and $100 once that data impacts a sale or leads to an unhappy customer. “A lot of organizations treat the management of data as an afterthought, which leads to problems,” he says.
For example, make sure databases record items in the same manner. If one spells out state names while another uses the two-letter postal codes, a database will treat them as two different entities (for example, it won’t realize that “FL” is the same as “Florida”). The same goes for cities (“St. Petersburg” versus “Saint Petersburg”). Data discrepancies like that could lead to incorrect sales figures or reports.
“Part of a portal is coming up with a data dictionary,” Hensley adds. “That’s where things go wrong — [when you don’t have] a governance of the data.” The dictionary should include common vocabulary and style. In the previous example, state and city would be included in a dictionary, as would definitions of common terms. Hensley explains one example of a company that did not have one definition of a “customer” — some people said a customer was a single person, another thought it was a company, yet another considered it anyone with a current subscription but not a past one, etc. Different definitions can lead to confusion and inaccurate data.
Here are some other items to consider when planning a business intelligence portal:
Will the company’s databases talk to each other and feed into the new portal?
Will existing data and applications migrate to a new system?
Does there need to be a data or equipment upgrade before creating the portal?
Who will maintain the business intelligence portal and update the data?
Do your technology and IT departments have the staffing and skills to support and maintain a system?
Who will answer help calls?
Hensley also recommends implementing a form of version control. If the system updates and something goes wrong, it’s best to have a process in place to revert back to the previous version.