How to Get Started with Operational Business Intelligence
Getting started is often the hardest part of any project because it involves dealing with so many unknown factors. Operational BI can be especially daunting, as it can have such an impact on non-technical people and processes. Claudia Imhoff, on the b-eye network blog, offers some thoughts on getting started with operational BI:
1. Start small - Making changes, especially changes that impact people and their business processes, can be tough. By starting small and building on subsequent successes, everyone gains confidence in the new system, paving the way for bigger changes down the road.
2. Asses the existing DW/BI infrastructure - As BI moves into an operational role, existing problems will only get worse, and they gain a wider, less forgiving, audience. Make a plan to reduce bottlenecks and solve any delivery, infrastructure and data quality issues.
As BI projects go, introducing BI software into an operational role is particularly challenging. However, the payoffs can be huge for both the organization and the IT department. The organization wins with gains in productivity and efficiency in achieving business goals, while the IT department wins increased respect as a strategic part of the organization.
7 Steps for Troubleshooting BI Software
Earlier today I published the final version of this white paper: 7 Steps for Troubleshooting BI Software. Have a look, and if you find it helpful, please say thanks by sending me a note or by leaving a comment.
Nine Steps for an Effective Change Managment Process
Once a business intelligence system goes “live” and into production, a change management process is an essential tool for keeping production servers humming, the jobs running and the business users happy. A balance must be struck between being strict enough to maintain control and accountability, but agile enough that changes can be made quickly for the business. Here are the nine steps for an effective change management process:
- Change Request
- Change Approval
- Planning - includes the evaluation of any risks and a back-out plan
- Testing - simulation in a lab or on a non-production system
- Scheduling - can the change fit into the regular maintenance window?
- Communication - all affected groups need to be notified
- Implementation - actually making the change
- Documentation
- Follow Up - closing the loop with all involved parties
As business intelligence and data warehouse applications move into more mission-critical, operational roles in the enterprise, change management is an essential consideration.
Rules for IT Consulting
While browsing around on IT Toolbox, I came across this post by Josh Berkus about database contracting. This was posted almost a year ago, but his “rules” are timeless, and they can equally apply to any type of IT consulting, be it BI, CRM, web application development, or whatever. Anyone in the business of hiring IT consultants would also find this useful, if for no other reason than to see the work from a different perspective. Here are some highlights and common threads:
- Anything deemed temporary is more permanent than you think. (rule 3)
- Everything takes more time and or costs more money. (rules 2, 6, and 7)
- Documentation is worth the trouble. (rules 8, 12, and 14)
Build vs. buy, CPM edition
Rick Sherman, of Athena IT Solutions, has published in his latest newsletter a discussion of buy versus build for Corporate Performance Management (CPM) or Business Performance Management (BPM) software. The lower total cost of ownership (TCO) for packaged software assumes that business and technical requirements are met, and this is a grand assumption with CPM for the following three reasons:
- The particular challenge with a CPM package is that the built-in metrics, metadata, business logic, etc. must be a good fit for the business. This requires delving into both the business processes and the technical details of the software implementation.
- CPM relies on BI and ETL tools to feed it data. Is the CPM package compatible with the existing BI tools? Or does the CPM package come with its own set of BI tools that must be adopted?
- If multiple CPM packages are required, is there are risk of creating CPM silos? These will be even harder to break down than data silos, especially if the packages are from different vendors.
More often than not with CPM, the buy vs. build question becomes buy vs. build vs. buy and customize, as the cost of retro-fitting business processes to fit the software is so high.
Secure Business Intelligence Development
In order to build a secure business intelligence system, business intelligence developers need to be more security conscious as they go about creating data models, cubes, and reports. eWeek has an article titled 5 Steps to Secure Development, which outlines how to make security an integral part of the enterprise software development process. These lessons are equally applicable to Business Intelligence projects.
- Definition - Start thinking about security from the beginning of the project and build it into the project plan. Most BI vendors will have a security framework for preventing unintended access to data, but how well does it match up with existing business processes? Will the BI system will leverage the existing security infrastructure? Is there any custom coding required?
- Education - According to the article, there is lack of security training across the IT industry. Be sure that the team knows how to roll out secure applications, and how to establish appropriate responses to security breaches. Shutting everything down is effective, but such drastic actions will quickly undermine the confidence of end users.
- Equipment - An emphasis on security can risk slowing down a project, but having the right software tools can mitigate this risk. Look for analyzers and automated testing tools that have security testing features.
- Test, test, test - Testing must be expanded beyond functionality, performance and data validation. Security testing means studying potential failures to see they can be exploited. How a component or the systems fails is as important as preventing it from failing in the first place.
- Monitoring - As part of the roll-out, alerts and processes must be put in place to monitor for failures and suspicious activity. For example, being alerted to huge spikes in activity and abnormal amounts of data being downloaded by a single user or in a single location.
Most business intelligence vendors take security seriously, with published guidelines for implementing security and details about how their software handles various threats. Here are two examples from Cognos and Microsoft. However, despite these convincing assurances, the responsibility for a secure system ultimately lies with the project team.
Agile Development
Agile development is usually thought to be most fitting for “code from scratch” projects. I have always admired the tenets described in the Pragamatic Pogrammer book, but until recently I had not given much thought about how these concepts are as applicable to Business Intelligence projects, or any project based on off the shelf, proprietary software. Usually, the vendor’s or the lead consultant’s methodology (like this example by Accenture) is accepted as the best practice. I came across this blog post that got me thinking a little bit further about the positive influence that agile development methods can have by promoting the following ideas:
- iteration
- communication
- evolution
- proof
- ownership
There is certainly no need to go to the agile extreme of Ruby on Rails, but injecting some agile practices into a project is well worth the effort.
The Problem with Late Software
With the delay of the highly anticipated database, Microsoft SQL Server 2008, the problem of late software releases is again receiving attention. An article over on TDWI highlights four problems a delayed software release can cause:
- Delayed implementation
- Delayed training
- Loss of project budget
- Loss of momentum
I would also add the following:
- Rushed testing, resulting in potentially unforeseen problems during the go live.
- The time and budget originally allocated for enhancements is reduced, affecting long term satisfaction with the solution.
- The snowball effect: follow on projects are delayed.
- Disappointment among business users. Their hard earned trust in the IT department is eroded.
After reading through the article, I realized that these challenges are not specific to BI projects, or even projects based on off-the-shelf software. Any project with a wide audience of end users, executive level visibility and high expectations will be severely affected by pushing out a release date. This is a risk that must be considered and mitigated from the very beginning of any IT project.
Start with business process modeling
Despite the plethora of tools, modeling languages and buzzwords, business process modeling is often misunderstood. It can be a great way to start a business intelligence project, if for no other reason than it brings together the techies from IT, the outside consultants, and the business users. Even if it ends there (not that it should), the exercise can pave the way for smoother requirements gathering, and more importantly, IT has a better understanding of the business context of the requirements.
Kalido has just announced that it will be distributing a business modeling tool for free, as an entry point into their other solutions. This might be worth considering as a fresh approach to bridging the gap between the users that need the BI solution and those who are tasked with designing it.
Does adoption equal project success?
It seems trite to state that user adoption drives success of an IT project. For example, imagine that some OLAP cubes or a series of reports are made available to a group of business users. If the majority of them make use of them, then a reasonable ROI can be calculated and the project declared a success. However, when an IT project is first proposed, does the business case assume a realistic rate of adoption? Is adoption even considered? Does the adoption rate have to be anywhere near 100% in order to make the project viable? Failing to give serious thought to these questions can lead to a negative ROI, even if the technology implementation is flawless.In his book, Common Approach, Uncommon Results, Ian Gotts of Nimbus, proposes a formula to be applied to all technology projects: Results = Initiatives x Adoption squared. Though the book itself can be light on the details, it does outline a framework for driving wide scale user adoption, and not just user acceptance. The adoption rate of technology in the enterprise may seem like a squishy metric, but ignoring it introduces additional risk to any project.