You are currently browsing the monthly archive for January 2011.
I have written before about enterprise risk management, which is an essential piece of both performance management and corporate governance. Every aspect of business entails risk. Everyone who makes a business decision is – whether consciously or not – making trade-offs between risk and reward. Assessing risk is tricky in business because it means different things to different people depending on where they work and their specific role in an organization. From a broad view, risk management becomes an “enterprise” issue for three reasons. One is to ensure that risk management is harmonized across the company and consistent with the corporation’s risk tolerance. A second purpose is to manage cross-functional risks – things that happen in one part of the company can have negative impacts on other areas. The third is to address the risk elements of what’s called the agency dilemma.
Economists long ago recognized the agency dilemma when the modern corporation separated the roles of its principals (that is, the shareholders) from management. The agency issue exists where the best interests of the principals are either not congruent or in conflict with the interests of the agents (the professional managers running the corporation). Agency issues are rife in any large-scale business, at times to the point of distorting business practices in whole industries. For example, motion-picture distribution companies might be better off if they were to handle a larger number of lower-budget films, but today’s industry is driven by producers and agents whose interests are best served by making blockbusters. For the producers and “above the line” talent, these projects have large potential payoffs while the outsized risks are mainly borne by others.
Much of the focus in the economics literature has been on the shareholder/senior management version of the principal/agent problem and the various mechanisms used to align their interests, such as stock-based compensation plans (increasingly with vesting provisions to encourage a long-term view) and other incentive-based plans. Indeed, one reason “performance management” has been the focus of so much IT investment is the need to have measurement capabilities and incentive plans that align the strategic interests of the corporation with the objectives of executives, managers and employees.
Yet the explicit focus of many performance measurement and incentive compensation plans has been on goal achievement with little regard to the risks. In this respect, the risk aspect has been more implicit, leaving it up to the employees to use their judgment or relying on supervisors to police risk-taking and set the tone for risk tolerance. Fortunately, most of the time this works well enough. Unfortunately – as recent disasters have demonstrated – it doesn’t always. And it strikes me that in most of the latter cases, one of the contributing factors has been the lack of attention to the risk aspects of the agency dilemma.
Just as shareholders’ concerns are not always going to be aligned with senior management’s, middle managers’ objectives may not always be well aligned with those executives. I think this is especially true when it comes to making decisions about risk. Reputational risk, for example, is usually of greater value to the senior managers (who are more closely identified with the company) than to those running business units or functional areas. For this reason, and because they almost always are evaluated explicitly on some sort of output measure (volume, profits, cash flow and the like), lower-level managers have every reason not to err on the side of caution. Senior executives also may (intentionally or not) court disaster by stressing output without measuring risk. In such a case, a line manager may forgo required maintenance in order to meet some rush order. Ninety-nine times out of 100 this doesn’t matter. But the one time it does, catastrophe ensues.
Thus when risk is not measured explicitly, midlevel managers are put into a position where they have a strong incentive to ignore or undervalue risks (from the shareholders’ and executives’ perspectives), even if senior executives would support a decision to, say, forego the rush order or negotiate some alternative. Part of this is human nature – it’s hard to disprove a negative. Without explicitly being able to demonstrate that they made the appropriate trade-off, a middle manager may be penalized for choosing the safer option. Over time, if employees learn that making a sensible trade-off only leads to grief, they stop making sensible decisions.
Compounding the problem is the difficulty of appropriately defining and measuring risk. One of the factors that inhibit explicit enterprise risk management is that, outside of several already heavily regulated industries, there is limited experience with establishing formal systems for measuring and monitoring business risks. Banks and insurance companies, for example, have centuries of experience developing analytical frameworks for risk management and devote a great deal of management horsepower to compliance. (Despite this, disasters happen with depressing regularity, but that’s another topic.) Consequently, organizations may not collect risk metrics and may not even understand or agree on what those metrics ought to be. The lack of data, in turn, can inhibit the development of formal enterprise risk management systems and processes. Yet despite this lack of experience, I suspect that it’s possible to assemble a sufficient number of risk metrics to make this part of a performance measurement system. For example, in the maintenance example, the appropriate control is to monitor a system that schedules the work and can raise cautionary flags when it is delayed. A built-in audit function also could be added to compare actual to budgeted maintenance spending and flag this if outlays lag expectations.
Another contributing factor to the neglect of enterprise risk management is the absence of this important factor from purveyors of “balanced scorecards.” This technique emerged as a way to address the unintended negative consequences of simplistic performance measurement systems that focus on one or a few metrics. They are “balanced” because they incorporate metrics that model the kinds of trade-offs that managers want employees to make. If, for example, call centers only measure call times, customer satisfaction will suffer because agents will attempt to get them off the phone as soon as possible, regardless of whether their questions have been answered or their issues have been addressed. A balanced scorecard would include first-call-resolution percentage as a compensating metric.
Some companies have developed sophisticated systems that properly balance objectives so employees are rewarded for making the right trade-offs. Still, few include risk explicitly; I think “risk” ought to be a separate category alongside the typical array of “financial,” “internal business processes,” “customer” and “learning and growth.” Incorporating risk explicitly in performance management systems helps manage the agency dilemma. Because managers are explicitly evaluated on risk, they have incentive to apply the proper balance in day-to-day decision-making. Moreover, this approach addresses the agency dilemma since those further up in the hierarchy can be alerted when risk thresholds are exceeded.
Robert Kugel – SVP Research
Open source business intelligence (BI) software vendor Jaspersoft recently announced general availability of its flagship product Jaspersoft 4 and earlier this week announced a new reporting project that provides data connectors to a variety of large-scale data sources.
Jaspersoft claims millions of downloads of its software and has a staff of 120 employees. The company focuses on the information delivery aspects of BI and partners with another open source vendor, Talend, that I recently wrote about. Jaspersoft 4 has a robust set of traditional BI features based around a report metaphor. It includes ad-hoc reports, pixel-perfect reporting , dashboards and online analytical processing (OLAP), both in-memory OLAP and relational OLAP (ROLAP). But as with many business intelligence tools, these OLAP capabilities are read-only and haven’t yet tackled advanced analyses such as statistics and predictive analytics.
In my previous life, I partnered with Jaspersoft as well as other BI tool vendors. I observed that while the platform was robust and capable, the look and feel needed an overhaul because it looked antiquated and lacked the interactivity available in modern Web interfaces. Jaspersoft 4 addresses that issue with a new user interface that makes the product look much more modern and provides much better interactivity for the end user. The new interface is part of a re-architecting of the product that separates the presentation layer from the events layer and the structure. (The product is also architected with a data abstraction layer, but more about that later.)
The separation of the presentation layer is important to Jaspersoft’s focus on enabling embedded BI capabilities. The company also has invested in multitenancy capabilities, including per-tenant user interface themes. So, for example, if your organization has multiple divisions with different branding, each division could have its own look and feel even if they all run on the same instance of Jaspersoft.
These features are derived from Jaspersoft’s strategy to build platform as a service (PaaS) and software as a service (SaaS) offerings. As the software market evolves, more and more products will be delivered as a service, and Jaspersoft is betting that it can capture a large share of this market by architecting its products to behave well when running as a service and by supporting the data sources these service providers might choose to leverage.
For software vendors, committing to re-architecting is always a difficult decision because it takes lots of development effort without providing much visible benefit in the form of new features. So it is often driven by a fear that the company can’t be competitive with its previous approach. Jaspersoft sees the market evolving toward a model where BI becomes an embedded capability; I endorsed that notion in my posting “What Is Wrong with Business Intelligence?”
Jaspersoft 4 provides a complete Web-based BI product stack while many BI products still have developer or designer components that must run outside of the browser environment. The advantage of a completely Web-based BI stack is that it’s easier to move and cross the boundaries between end user and developer. For example, if you want to allow certain groups of users in your organization to design new reports or screens, you can do this with Jaspersoft 4 simply by turning on or off certain features for certain classes of users. If the developer tool was a completely separate product, doing that would be much more difficult.
Despite all the focus on Web-based delivery, mobile delivery platforms are not currently a core focus of this vendor. Jaspersoft 4 works on mobile devices via a browser, but it does not provide native applications and therefore cannot support gestures and features specific to a platform. Given the rising interest in mobile BI, as evidenced in our business intelligence and performance management benchmark research, Jaspersoft will need to do more to take full advantage of mobile platforms. I expect to hear more from them in the future on this subject.
Independent of Jaspersoft 4, the company created a new project to provide native access to a variety of large-scale data sources including massively parallel processing (MPP) database technologies, Hadoop and NoSQL. The news here is not the support of MPP technologies, although Jaspersoft now supports additional MPP database products. Nor is it the support of Hadoop, although it is among the early group of BI vendors to support Hadoop. No, the real news is support for a variety of other large-scale data technologies often referred to as NoSQL alternatives, including Cassandra, CouchDB, GemFire, HBase, Infinispan, MongoDB, Neo4J, Redis, Riak and VoltDB.
These projects are in relatively early states. The connectors to all the open source technologies are themselves open source and available for download at the project link above. Jaspersoft refers to them as beta versions, but that might be a little generous in terms of how far along they are: They support parameterized reports only and generally require some modification of the code to make the connectors work with a particular data source. As with many open source projects, the goal of releasing them in their current state is to engage others in helping to develop these connectors further.
It is an interesting play on the part of Jaspersoft. It gives the company an opportunity to grab market share in a segment where there is little or no competition currently. I suspect that this market is likely to grow. As more software is delivered as a service, performance and scalability become much bigger concerns than adherence to standards. A company that makes its living developing and delivering software services can afford to stray from industry standards under the covers of the services that it provides. In many cases that’s the only way to deliver the performance and scalability users require. In fact, that’s how some of today’s most popular technologies originated: Google, Facebook, Yahoo and others did not want to constrain their growth by limiting themselves to the capabilities of standard relational databases. The question for Jaspersoft is whether the technologies it is involved with continue to grow and whether they represent a large enough market to justify the investment it is making. There’s certainly enough interest in the NoSQL market to attract attention these days, as evidenced by a recent article in the New York Times. The companies behind some of these technologies have attracted venture capital investments.
As a Jaspersoft customer or potential customer, what does this mean to you? If you use one of the NoSQL technologies, you now have a potential reporting solution. If you don’t, then the question is whether the energy devoted to these NoSQL alternatives detracts from investment and attention in more traditional data sources. It’s a long list of data sources to support. The quality assurance process alone could become a big burden going forward. Jaspersoft does have the advantage of its open source model to attract support from the community for many of these connectors, but depending on the level of external support I would be concerned about negative impacts on the timeliness or quality of the new releases of the many product lines.
Charting a new direction has risks. This could be a brilliant move on the part of Jaspersoft, or it could turn out to be a costly mistake. Only time will tell.