Stop! Before you invest even 10 minutes of your precious time reading this blog, please make sure it's really business intelligence (BI) governance, and not data governance best practices, that you are looking for. BI governance is a key component of data governance, but they're not the same. Data governance deals with the entire spectrum (creation, transformation, ownership, etc.) of people, processes, policies, and technologies that manage and govern an enterprise's use of its data assets (such as data governance stewardship applications, master data management, metadata management, and data quality). On the other hand, BI governance only deals with who uses the data, when, and how.
It’s no longer just your marketing team that uses social media for business purposes. Employees across the entire organization use social media for personal and professional reasons, leveraging social to drive real business for your company. The opportunities to enhance your brand, deepen customer relationships, and glean new customer insights are all too valuable to ignore -- but the risks are real too.
Moreover, the legal and regulatory landscape is evolving rapidly, complicating the ways in which you can manage social media and the myriad reputational, security, and privacy risks (among others) that expose your organization. To take advantage of these opportunities and still protect your company, you need new tools and technology to do this effectively.
January 28th was the anniversary of the Space Shuttle Challenger disaster. The Rogers Commission detailed the official account of the disaster, laying bare all of the failures that lead to the loss of a shuttle and its crew. Officially known as The Report of the Presidential Commission on the Space Shuttle Challenger Accident - The Tragedy of Mission 51, the report is five volumes long and covers every possible angle starting with how NASA chose its vendor, to the psychological traps that plagued the decision making that lead to that fateful morning. There are many lessons to be learned in those five volumes and now, I am going to share the ones that made a great impact on my approach to risk management. The first is the lesson of overconfidence.
In the late 1970’s, NASA was assessing the likelihood and risk associated with the catastrophic loss of their new, reusable, orbiter. NASA commissioned a study where research showed that based on NASA’s prior launches there was the chance for a catastrophic failure approximately once every 24 launches. NASA, who was planning on using several shuttles with payloads to help pay for the program, decided that the number was too conservative. They then asked the United States Air Force (USAF) to re-perform the study. The USAF concluded that the likelihood was once every 52 launches.
In the end, NASA believed that because of the lessons they learned since the moon missions and the advances in technology, the true likelihood of an event was 1 in 100,000 launches. Think about that; it would be over 4100 years before there would be a catastrophic event. In the end, Challenger flew 10 missions before it’s catastrophic event and Colombia flew 28 missions before its catastrophic event, during reentry, after the loss of heat tiles during take off. During the life of a program that lasted 30 years, they lost two of five shuttles.
I’m proud to announce that this week Forrester launched our Governance, Risk, and Compliance Playbook, a collection of in-depth reports covering the critical information you need to implement a successful GRC program… one that focuses on supporting business success, not getting in its way.
I had an interesting follow-up conversation last week with Dmitry Chikhachev of Runa Capital. I asked what he was seeing in smart cities and civic innovation among Russian startups in these areas. Dmitry’s response supported my own observations that governments need to focus on the basics.
What kinds of innovation are you seeing in the public sector in Russia?
Many processes in the public sector are still supported by paperwork. One example is visa applications. To obtain a visa you need an application, on paper. You need copies of supporting documents. In Singapore, paperwork has been eliminated. You upload everything. And, you get a barcode via email to be shown with your passport when entering the country. To do this requires process change within government, which in turn, requires data handling, integration, electronic signature, and personal data protection — a combination of relatively high-tech solutions.
Within Russia, this kind of change — the shift to paperless government — is happening at the regional government level in Russia. Tatarstan is the most advanced from this point of view. (But on a promising side note, the Minister of Informatics from Tatarstan just got promoted to the federal level.) Government interaction with Tatarstan is already paperless.
Who is providing the solutions to support a paperless government?
I recently finalized a report* on software asset (SA) based IT services, this time looking at vendors’ best practices in terms of governance, organization, skills, tools, and processes. Needless to say, the move to software asset-based services will have a huge impact on the traditional operating models of IT services firms.
Obviously, IT services firms need to learn from their large software partners to understand and implement specific software asset management processes such as product sales incentive schemes, product management, product engineering, and release management.
This will induce a formidable cultural change within the IT services vendor’s organization, somewhat similar to the change Western IT service providers had to undergo 10 years ago when they finally embraced offshore delivery models.
I see a few critical steps that IT services firms need to take in order to facilitate this shift towards software asset-based business models:
Build a client-relevant SA strategy. Building an SA base offering is not (only) about doing an inventory of the existing intellectual property (IP) that you have on employee hard drives and team servers. More importantly, it’s about making sense of this IP and building strategic offerings that are relevant to your clients by centering them aounrd your clients’ most critical business challenges.
I get the following question very often. What are the best practices for creating an enterprise reporting policy as to when to use what reporting tool/application? Alas, as with everything else in business intelligence, the answer is not that easy. The old days of developers versus power users versus casual users are gone. The world is way more complex these days. In order to create such a policy, you need to consider the following dimensions:
Historical (what happened)
Operational (what is happening now)
Analytical (why did it happen)
Predictive (what might happen)
Prescriptive (what should I do about it)
Exploratory (what's out there that I don't know about)
Looking at static report output only
Lightly interacting with canned reports (sorting, filtering)
Fully interacting with canned reports (pivoting, drilling)
Assembling existing report, visualizations, and metrics into customized dashboards
Full report authoring capabilities
External (customers, partners)
Report latency, as in need the report:
In a few days
In a few weeks
Strategic (a few complex decisions/reports per month)
Tactical (many less-complex decisions/reports per month)
Operational (many complex/simple decisions/reports per day)
There is growing evidence of a harmonic convergence of Infrastructure and Operations (I&O) with Security and it is hardly an accident. We often view them as separate worlds, but it’s obvious that they have more in common than they have differences. I live in the I&O team here at Forrester, but I get pulled into many discussions that would be classified as “security” topics. Examples include compliance analysis of configuration data and process discipline to prevent mistakes. Similarly, our Security analysts get pulled into process discussions and other topics that encroach into Operations territory. This is as it should be.
Some examples of where common DNA between I&O and Security can benefit you and your organization are:
Gain economic benefit by cross-pollinating skills, tools, and organizational entities
Improve service quality AND security with the same actions and strategies
Learn where the two SHOULD remain separate
Combine operational NOC and security SOC monitoring into a unified command center
Develop a plan and the economic and political justifications for intelligent combinations
We met with 30 Sourcing & Vendor Management Professionals during an action session at Forrester’s Sourcing & Vendor Management Forum in Chicago to discuss how to improve governance for large implementation projects. Clients were looking for help across the sourcing life cycle – from determining who manages the RFP process, to determining scope with internal stakeholders, to driving governance after the contract is signed.
What tactics are Sourcing & Vendor Management Professionals using to tackle these challenges?
1. Renegotiate rates with current players. Forrester’s recent survey found that 68% of organizations are renegotiating with their existing suppliers. One attendee said, “This has always been a priority, now we are bringing more efficiency and innovation to the process.”
2. Drive innovation from vendors. Everyone wants innovation from their suppliers but few receive it. Attendees shared tips for how they overcome major hurdles to achieving this in their supplier relationships:
a. Define what you mean by innovation. Many struggle to get innovation from their providers because they haven’t defined what that means — are you looking for idea-sharing or process improvements? Determine which type of innovation you need and communicate that to your vendor.
b. Identify metrics. “It’s not just how you measure innovation; it’s how you measure successful innovation.” Clients shared a variety of metrics such as:
i. Requiring the vendor to submit continuous improvement ideas they agree are impactful to your organization
There has been a lot of negative press and commentary regarding the recent Queensland Health Implementation of Continuity Project (SAP HR and Payroll), which recently experienced a very public failure as many employees were not paid due to multiple points of failure in the project. The recent Auditor-General's Report on the process is damning, spreading the blame across multiple agencies and the systems integration partner, IBM. I make no claims to be familiar with the intricate details of the process, but I have read the report and feel I have a clear understanding of the (many!) points of failure.
While this project did seem to be a monumental failure, I would suggest that we consider two important facts: