The following question comes from many of our clients: what are some of the advantages and risks of implementing a vendor provided analytical logical data model at the start of any Business Intelligence, Data Warehousing or other Information Management initiatives? Some quick thoughts on pros and cons:
Leverage vendor knowledge from prior experience and other customers
May fill in the gaps in enterprise domain knowledge
Best if your IT dept does not have experienced data modelers
May sometimes serve as a project, initiative, solution accelerator
May sometimes break through a stalemate between stakeholders failing to agree on metrics, definitions
May sometimes require more customization effort, than building a model from scratch
May create difference of opinion arguments and potential road blocks from your own experienced data modelers
May reduce competitive advantage of business intelligence and analytics (since competitors may be using the same model)
Goes against “agile” BI principles that call for small, quick, tangible deliverables
Goes against top down performance management design and modeling best practices, where one does not start with a logical data model but rather
Defines departmental, line of business strategies
Links goals and objectives needed to fulfill these strategies
Defines metrics needed to measure the progress against goals and objectives
Defines strategic, tactical and operational decisions that need to be made based on metrics
Slowly but surely, with lots of criticism and skepticism, the business intelligence (BI) software-as-a-service (SaaS) market is gaining ground. It's a road full of peril — at least two BI SaaS startups have failed this year — but what software market segment has not seen its share of failures? Although I do not see a stampede to replace traditional BI applications with SaaS alternatives in the near future, BI SaaS does have a few legitimate use cases even today, such as complementary BI, in coexistence with traditional BI, BI workspaces, and BI for small and some midsize businesses.
In our latest BI SaaS research report we recommend the following structured approach to see if BI SaaS is right for you and if you are ready for BI SaaS:
Map your BI requirements and IT culture to one of five BI SaaS use cases
Evaluate and consider scenarios where BI SaaS may be a right or wrong fit for you
Select the BI SaaS vendor that fits your business, technical, and operational requirements, including your tolerance for risk
First we identified 5 following BI SaaS use cases.
Coexistence case: on-premises BI complemented with SaaS BI in enterprises
SaaS-centric case in enterprises: main BI application in enterprises committed to SaaS
SaaS-centric case in midmarket: main BI application in midsized businesses
Elasticity case: BI for companies with strong variations in activity from season to season
Power user flexibility case: BI workspaces are often considered necessary by power analysts
You never know what’s coming at you next, which is why process agility is so important. Your organization must have a ready response for anything. And you must make sure that every process participant can identify, at their level, what that response might be, so they can take appropriate action.
Self-service is all the rage in the world of business intelligence (BI), but it’s no fad. In fact, it’s the only way to make BI more pervasive, delivering insights into every decision—important or mundane—that drives your business. It’s the key to empowering users with actionable insights while removing many mundane BI development and maintenance tasks from IT’s crushing workload.
In mid- 2009, I published a Forrester report describing key benefits, use cases, and approaches for implementing self-service BI, under the broad heading of “mighty mashup.” Forrester customers have responded very favorably to the discussion, asking for advice on whether, when, and how they should adopt this approach. Going forward, Forrester will deepen our discussion of self-service as a best practice to be incorporated into enterprise BI Solution Center (BISC) teachings.
Business processes can be incredibly hard to fathom. The more complex they are, the more difficult it is to find the magic blend of tasks, roles, flows, and other factors that distinguish a well-tuned process from a miserable flop. Even the people who’ve been part of the process for years may have little clue. It’s not just that they refuse to look beyond their job-specific perspectives, for fear of jeopardizing their careers. It’s often an issue of them being too close to the problem to see it clearly, even if they try very hard.
Process analytics is all about identifying what works and doesn’t work. It’s a key focus for us here at Forrester, and I’m collaborating with one of our leading business process management (BPM) analysts, Clay Richardson, on research into this important topic. The first order of business for us is to identify the full range of enabling infrastructure and tools for tracking, exploring, and analyzing a wide range of workflows. It’s clear that this must include, at the very least, business activity monitoring (BAM) tools, which roll up key process metrics into visual business intelligence (BI)-style dashboards for operational process managers. Likewise, historical process metrics should be available to the business analysts who design and optimize workflows. And each user should have access to whatever current key performance indicators are relevant to the roles they perform within one or more processes.
People often use the end of a decade to say goodbye to trends that have played themselves out, or good riddance to things that have long since passed their cultural expiration dates. I like to use the beginnings of decades for that same purpose. What, we should ask ourselves, is not likely to last beyond the close of this new ten-year cycle?
In data warehousing, the most likely casualty of the Teens will be the very notion of a data warehouse. You can tell that a concept is on its last legs when its proponents spend more time on the defense, fighting definitional trench wars, than evolving it in useful new directions. Here’s a perfect case in point:a recent article by Bill Inmon, self-described “father of the data warehouse,” where he takes pains to specify what is not a data warehouse. Apparently, many of the approaches that we normally implement in our data warehousing architectures—such as subject-specific data marts, dimensional data structures, federated architectures, and real-time data integration—don’t pass muster in Inmon’s way of looking at things. Though he didn’t mention hybrid row-columnar and in-memory databases by name, one suspects that Inmon has a similarly jaundiced view of these leading-edge data warehousing technologies.