Print

Send to colleague

E-mail us

No risk, no reward

Meditations on enterprise risk management.

by Rob Armstrong

Have you heard the phrase "everything old is new again"? That's my objective with this short column: to provide you with a fresh perspective on how to interpret some famous quotations as they relate to enterprise risk management (ERM):

"Great change dominates the world, and unless we move with change we will become its victims."— Robert Kennedy, Warsaw, Poland, July 1, 1964

You work at a utility company managing the power grid. When an outage occurs, what information from across the company do you need to know in order to quickly resolve the matter? What level of detail, and what level of timeliness of that detail, do you need to know? What reports could you have identified three months ago so that they would be developed and in the production run by now?

Just as companies have risk management processes in place for credit, investments, fraud and many OLTP (online transactional processing) systems, they need to incorporate the ideas behind risk management into the data warehouse arena. One of the biggest areas of exposure and risk in the data warehouse space is that of constant change in the requirements. It does no good to implement a solution that cannot move with the change we all know is coming.

So in the context of your business intelligence and information systems, the questions must be asked: How ready are you for the ever-changing nature of the business need? Is the data being captured at the right level of detail? Is it captured at the right frequency? Do all the users who need that data know it exists? Do you have a proper steering committee and governance structure? In short, are you moving with the changes or are you waiting for them to move you?

"Control over change would seem to consist in moving not with it but ahead of it."— Marshall McLuhan, Understanding Media: The Extensions of Man, 1964

As important as those answers to the questions above are, there is a better question: What are the clues that can tell you where the next change is going to come from? Just as you must stay ahead of the current to steer your boat, you must also watch the way ahead to avoid the rocks and waves. IT cannot wait for the users to define every aspect of the environment before undergoing development. However, that does not mean that IT cannot anticipate the next wave of needs. So what are they? The major ones are the changes that occur in the loading processes and frequency, the user community and query characteristics, and the depth and breadth of the data in the warehouse. The good news is that the IT groups have quite a bit of information in which to understand and anticipate the most likely direction of change.

Changing usage
One of the most obvious ways IT can lead is with an understanding that the user questions will change and evolve, even if the data demographics stay the same. Assume that you are a retailer and currently capture store, item and day inventory movement. The users may get reports on sales and outages. The obvious next question would be "Is this a chain-wide event or localized?" This is quickly followed by, "Do I have inventory in a neighborhood store that can be transferred?" Without additional data, these new questions could not be answered.

So what would be standing in the way of making this movement? The most common obstacle is either the front-end tool or the data model within the data warehouse. The flexibility required of the model implies there is no "functional alignment" to the model. The data is stored without regard to its usage, but it is modeled with regard to its relationship to other data. If the data was modeled to answer the initial questions explicitly, the users have a high pain threshold to get to the next level of analysis.

In a similar vein, the front-end tools must also be flexible enough to allow the users to ask the next question. Take a look at your model and your tools: How ready are they to allow the users to ask the next level of analysis directly? IT must get itself out of the process of users getting to data. The more quickly the users can get to the necessary data in a crisis, the more you can minimize enterprise risk or potential exposure. Examine the reasons IT has to intervene in the analytical process and work to remove the obstacles that prevent direct user access.

Changing data
After users start expanding their usage of the current data, they will quickly discover the need for more detail or more cross-functional data to be populated into the data warehouse. This is good, as it gives a roadmap to the IT community as to where the next change request will arise. Rather than waiting for the users to ask for more detail (transaction level, call detail, claim lines, etc.), IT can work with the business owners (not users) and the steering committee to determine which layer of detailed data helps drive the company metrics best. Also, IT can challenge the owners to see what metrics are going to be put in place to drive the users to the new data.

For example, at one retailer, the buyer's metrics went from category level to item level, and the level of data detail had to be changed. While the metrics and business operations themselves did not change greatly, the change in the level of the metric encouraged users to use the more granular data as it was made available. Here again, the IT group was ahead of the need; as the business needed to examine its item-level inventory exposures, the data was ready. The bottom line is that the rate of change was accelerated.

A related situation occurs when the level of data detail is good but the breadth of data is not complete. For example, an insurance company added weather patterns and forecasts to insurance information to better respond to customers as a natural disaster hits a particular region. The company anticipated a potential disaster, understood its clients' coverage and possible needs and was able to minimize risk while increasing customer satisfaction.

Both of these situations can be anticipated by the IT community working closely with the business groups to understand the current processes, the decisions that come from those processes and the other functional areas affected by those decisions. This identifies potential areas of new data that can be "prototyped" with a small team of business users. This will help keep the development and evolution of the data warehouse ahead of the change curve rather than being reactive to an immediate crisis.

Changing timeliness
The last predictable change that will be explored here is the timeliness of data. This encompasses several aspects of data characteristics. The first is the frequency at which the data is available or collected. You may need data at the lowest level of time (i.e., by minute or transaction), but that does not mean it must be loaded at that frequency. The second aspect is the criticality in terms of recoverability and query responsiveness. Again, a large majority of these definitions and requirements are the onus of the user community but some clues can be gleaned so IT can stay ahead of the change curve.

Let's look at the first part of this area. Business owners and IT can certainly work together to look at the level of current analysis and data timeliness to see if providing data more frequently (i.e. loading more often) could help increase the actionable decisions. This happens in two ways: Either the same decisions are made closer to the events happening (and therefore are more relevant), or the same decisions are made more often. For example, if an airline only sees flight status once a day when making its gate assignment plans then it won't run very effectively. By monitoring the flight status throughout the day, the operations staff can finetune plane and gate assignments.

There are some exceptions that may also be required of the data loading process. Some may require that the data be collected more frequently, and this may become an operational systems issue. Other parts may require some data model changes. Typically, this is a relatively small effort, as you are not adding new subject areas, but rather adding data that is already understood and defined at a more frequent rate. You may also need to change the load process itself, as you may be using load utilities such as FastLoad or MultiLoad when the TPump utility would be more effective. All of these points need to be weighed against the value that could be received by the increased analytical capability.

The other aspect of timeliness is in the responsiveness of the queries, or criticality in case of disaster. Query response time will be the most likely to need attention, so it is best to focus on that need first. As the user community evolves in its understanding and depth of analysis, queries that used to come at the end of the analysis (when it was okay for them to run "long") will start to become the earlier steps (when response time will need to be "shorter"). If you look at the progression of retailers it was simple daily reporting that highlighted inventory issues. Now those same retailers are starting with the first question: "Where is my inventory in jeopardy or off-plan?" That question used to spur action, but it is now the question that shows where more analysis is necessary.

Given this natural progression, or promotion, of analytics, the IT community can start investigating which queries are long-running and the end point of analysis. Finding those situations and working with the users to understand "and then what happens" (metrics are reported, other groups get notified of the issue, redistribution plans are sent to the operational systems, etc.). This will give strong clues as to which avenues of analysis will become the "critical paths" and therefore demand "better" response time.

"There can be change without progress but not progress without change."—Anonymous

These sections have illustrated some of the ways IT can stay ahead of the change curve and continually provide the business community with a flexible, robust information architecture. Of course, just creating new data and new processes without a plan is not justifiable—or even smart. In order to drive progress with the change, it is critical that the efforts be directed by the data warehouse steering committee. It is incumbent on that body to understand the major business objectives the company needs to achieve. From there, the IT groups can decide if the solution is to be more frequent, more detailed, more cross-functional, more secure and private, or some other attribute. They can then start to drive the user community in that direction by providing the ability for the user communities to ask questions, take actions and measure results towards minimizing risk and achieving greater success. T

Rob Armstrong is a director with Teradata. Since 1987, Rob has consulted with or led teams to deliver some of the most successful data warehouse systems in existence. Rob typically works with hundreds of companies a year to identify opportunities and understand the challenges and processes involved. He also leads workshops on how to develop and enact best practices that change the way business is operated and to maximize success. With a unique and no-nonsense style, Rob is able to engage audiences and works to bring technologists, business users, and executives together for a common goal—driving value and improved business performance from their data warehouse investments.

© Teradata Magazine-March 2006

back to top