You are currently browsing the tag archive for the ‘Risk Management’ tag.
At its annual Influencer’s Summit in Boston, SAP offered multiple perspectives on where the company’s strategy and products are heading. Overall, I was struck by the essential similarities to its message on its strategic direction a decade ago. The overarching objective in its roadmap now, as then, is to have information technology increasingly adapt to the needs of individual users and how they choose to execute established/repetitive or ad-hoc processes, rather than forcing them to adapt to the limitations of the technologies they are using. Back then the idea was to create a comprehensive process framework – a closely coupled approach. Today, it’s essentially the opposite, as SAP products run on an architecture that enables flexibility – a loosely coupled approach – both in how the computing infrastructure is organized and how people execute their tasks. It seems to me that this reflects the impact of having choices between cloud-based software as a service (SaaS) and on-premises systems and the need to enable access through a variety of devices (from desktops to mobile handhelds and tablets). Mobility is important both for people whose roles take them beyond the firewall (in sales, service and logistics, for example) and executives and managers who often find themselves managing by walking around. Tablets, smartphones and similar devices are attractive also because people consider them personal items and associate them with fun, whereas desktops and notebooks are corporate and work-related.
Architecture drives product design, and SAP continues to stress HANA and the ability of its in-memory system to expand the scope and capabilities of applications that run on it. That makes sense since any in-memory computing platform can transform how software is used. The challenge then becomes transforming the habits of users. For example, I’ve noted the need for more contingency planning. One reason it’s not used more is that the latency between thought and answer in complex scenario analyses on disk-based systems is often too long to be useful in promoting a collaborative dialogue around possible situations and their potential outcomes. “Too long” is a relative thing, of course, but based on my experience, the outer edge in this case may be 10 seconds to 1 minute. Once the technology foundation is in place, the hard work begins. Companies have to understand what is technologically feasible and that they need to adopt better planning techniques, notably driver-based planning. From my perspective, few technology advances have immediately led to forehead-slapping, “aha!” moments. Thus the spread of adoption of in-memory technology into business processes is never automatic, so one of SAP’s challenges is to create demand for HANA by promoting improved management techniques that are supported by in-memory computing. So the technology is different, but the business issue is much the same.
Since it offers differentiation in an increasingly commodity-like business computing product market, advanced analytics was a key theme at the summit. Analytics are an increasingly important capability for organizations, enabling companies to manage more effectively, not just efficiently. Predictive analytics, for example, should play a role in more than the 13 percent of organizations that our research shows are using them. They have become much more accessible but aren’t well understood. Predictive analytics certainly help in forecasting, but they’re also handy for spotting exceptions from expected results, especially when companies have to work with large data sets. Departures from expected results can provide the basis for management alerts and notifications, as when an order from a regular customer or an invoice payment is not received within the normal period. Both situations can indicate customer issues. A follow-up to the former might uncover that a competitor is offering promotional deals to gain market share, and the company could counter the move sooner. The latter might be the result of some issue that occurred in fulfilling the order, in which case it would be better to have the first communication with the customer be an immediate note of concern rather than a dunning notice weeks later. Analytics is an important theme in business computing, and SAP will need to focus on it in its product efforts.
Risk management is yet another area where real-time data can be an important enabler of capabilities that are not practical without the ability to crunch substantial amounts of data rapidly. Outside of financial services, few industries manage risk comprehensively, and even financial services can put more of their operations into a risk management framework. In part this situation reflects the fact that few industries have developed a framework for measuring risk objectively. Part of this is historical: Financial services have always been about numbers, and it’s straightforward to use these numbers to measure risk. Financial ratio analysis therefore can be applied to assessing many operational risks in that industry. And since it was one of the first to utilize computers to handle operations, these corporations have long experience in using software to manage risk. By contrast, only within the past few decades have other types of companies begun using IT systems to manage operations. Using data to identify and track operational risks is still nascent, so any discussion of how far it has developed strikes me as premature. Yet I believe risk management in consumer, industrial and business services should be on the radar screens of executives, especially because it addresses the agency dilemma. SAP’s risk management software portfolio could expand substantially over the next several years to address the need. (I expect the same from Oracle and IBM, along with many smaller vendors.) But here again businesses must become aware of the need before a market will grow.
SAP Business ByDesign is a topic worthy of its own blog, so I’ll post one on this topic shortly.
It struck me that this Influencer Summit demonstrated SAP’s understanding of what it needs to accomplish over the next few years to be competitive with its substantially larger rivals – IBM, Oracle and, in applications for small and midsize businesses, Microsoft. Strategy is one thing but execution – as ever – is probably more important. Here, SAP must demonstrate that it can operate at faster clock speed than it has in the past to maintain its top-tier position in business computing.
Regards,
Robert D. Kugel – SVP Research
My colleague Mark Smith and I have frequently commented on the artificiality of the emerging software category governance, risk and compliance (GRC). To be sure, once stand-alone categories of software (IT governance, audit documentation and industry-specific compliance management, to name three examples) have started what I expect to be a long convergence process. Moreover, since just about all controls and risk management efforts require a secure IT environment to be effective, there is a growing interdependence between effective IT governance and everything else connected with enterprise GRC.
The main issue I have with the GRC label is that many of those in IT departments may think it makes sense to adopt a GRC platform or standardize on a vendor for all this. From an operational perspective, GRC is far too amorphous and decentralized for that. I believe that today and for at least the next several years it makes more sense to base software purchases on the specific needs of users rather than the supposed convenience of buying a single GRC platform for a company. Odds are that such a unified platform will constrain an organization’s overall ability to manage governance, risk and compliance even if it is more efficient.
Companies face two basic technology challenges as they try to automate and manage their governance, risk management and compliance efforts. One concerns vendor selection: As in most purchases, there is a general issue of what software best balances the trade-offs between current business requirements, existing infrastructure and (perhaps) longer-term standardization objectives. The second issue, related to risk management, is data availability. Financial services companies can have sophisticated risk management systems because the definitions of risk for banks, insurance companies and the like are well established, the data needed to measure it is readily available and automation of controls is mature (although by no means perfect). In other industries, automating risk management is more complicated because the data needed to measure and control risk may not be collected already, it may be difficult for a company or business unit to define or quantify risk metrics, or both may be issues.
At this point, I believe that governance and risk management for IT departments are further along than in other parts of the business because decades of work has been done to define standards and ensure that environments are secure and controlled. I expect many IT departments (as opposed to others) will find comprehensive solutions available to automate, measure, manage and optimize their governance and risk management efforts, and therefore IT may find that focusing on a limited set of vendors is both possible and practical today. That is not so with the lines of business and general corporate management. Many compliance requirements and the software that addresses them are specific to an industry or department. Thus, at this point, I see little value – and potentially much harm – in looking for a “platform solution” to these varied needs.
As for risk management, today’s reporting, analytics and BI technologies are adequate to support these efforts. The initial challenge is less about the tools than the fundamentals of risk management. An array of questions arises as soon as we start to think about this. What are the key risks? How should they be measured? Is data available on which to base the measurement? If not, how can it be made available? How can risks be mitigated? What is the corporation’s risk tolerance? When risk events occur, who should handle them and how?
In many companies, people understand the risks that face their part of the business, but this knowledge is tacit, not explicit. Therefore one of the first steps in maturing risk management in an organization is “simply” performing a comprehensive key risk definition program. (Of course, there’s nothing simple about it.) A follow-on step is to ensure that executives and managers define and understand cross-functional risks, those where a risk event in one part of a company can have a parallel or follow-on impact elsewhere. (For example, failure to get a building permit to complete construction of a new store will affect inventory requirements until the delay is resolved.)
Once past these steps, the next is to agree on what data must be collected, how and by whom. For some companies, this may be relatively easy to complete. But I expect that most midsize or large companies will find that building out risk management metrics and gathering the data will take years.
Risk management, controls and compliance with laws and regulations all are essential to good corporate governance. A category of software that supports these functions will benefit companies by making their compliance efforts more efficient and their risk management more effective. Even so, it’s important for executives and managers, especially in IT departments, to understand that there is no single product suite for enterprise GRC yet and that for the next several years, less overarching business needs must be the focus of GRC software purchases.
Best regards,
Robert Kugel – SVP Research
Business Exchange
Google+
Klout
LinkedIn
Plaxo
Twitter
Facebook Fan Page
Facebook Group
Ventana Research Website
