Andy on Enterprise Software

Regulatory regimes and dog food

October 7, 2005

It would seem self-evident that accountants enjoy dealing with numbers, but those who may not have worked in large corporations would be shocked by the number of meetings that occur arguing over whose version of data is correct. Just answering a simple question like “how profitable is customer x to us” is a nightmarish task in large companies, because business to business enterprises have data about customers scattered throughout a raft of different computer systems, and may not account for costs uniformly across the enterprise. This is not isolated to a few backward companies: a friend of mine who used to work for Goldman Sachs confirmed that if they wanted to know how much business they did with a major corporate client then it was a significant project to gather this information from around the corporation. This is especially a problem with global companies, whose operating subsidiaries and structure may be opaque. For example, Calvin Klein is owned by Unilever, but how many people know that? Consequently it is easy to see how a company supplying Calvin Klein may not necessarily record that information as actually being linked to Unilever. There are many, many examples like this, which would cause issues even without the problem of uniformity of cost allocation across an enterprise.

An article in Accounting and Finance mentions the notion of the “data driven CFO”, which alludes to the notion that CFOs these days really need to get to grips with this kind of issue. Not only are they under pressure to answer questions from their business colleagues about corporate performance (such as “how profitable is customer x to us”) but they also have to contend with increasing regulation such as Sarbanes Oxley and various industry specific rules such as Basel 2 in banking, or FDA rules within life sciences. People often gripe about such regulations, but there are some sound reasons for them. An amusing example of the need for the latter was a discussion my wife (who worked at Smith Kline Beecham at the time) shared with me. SKB had an anti-worming drug which they decided was not worth marketing to humans for technical reasons, but were pondering whether it could be usefully put into pet food, since dogs in particular have a lot of problems with worms. After much ferreting around, it turned out that this could not actually be done because in fact a scary percentage of people actually eat dog food, and so it would have to go through the same regulatory regime as if it was for humans (as an aside, I found this quite surreal, but when I mentioned it at lunch that day at Shell, two of the five people at the table admitted to having eaten dog food; if you think I am joking see the internet for recipes involving pet food).

The point is that the regulations are a fact of life and are increasingly specific about the auditability of reported data. Much of which may involve reconstructing past history at some point a few years back. Now if a company can’t tell how profitable a customer is without a significant effort, just how easy will it be for them to answer a question regarding profitability four years ago, since when the business has probably restructured a couple of times? I suspect that there are a lot of increasingly nervous CFOs out there, who my be sorely tested if they actually have to go back and reconstruct historical data. Yet even apart from regulatory compliance, for departments such as marketing really need to understand trends over time in order to be effective. How many of these are getting the trend data that they need from their finance groups? As pressures increase for performance improvement, more and more CFO departments are going to have to become more data driven in years to come, like it or not. Let’s hope their suporting systems can deal with such requests, or they will spend a long time barking up the wrong tree.

del.icio.us:Regulatory regimes and dog food  digg:Regulatory regimes and dog food  reddit:Regulatory regimes and dog food  Y!:Regulatory regimes and dog food

The Need for Real Business Models

One of the perennial issues that dogs IT departments is the gap between customer expectations and the IT system that is actually delivered. There are many causes of this e.g. the long gap between “functional spec” and actual delivery, but one that is rarely discussed is he language of the business model. When a systems analyst specifies a system they will typically draw up a logical data model and a process model to describe the system to be built. The standard way of doing the former is witti entity relationship modelling, which is well established but has one major drawback in my experiences: business people don’t get it. Shell made some excellent progress in the 1990s at trying to get business people to agree on a common data model for the various parts of Shell’s business, a thankless task in itself. What was interesting was that they had to drop the idea of using “standard” entity relationship modelling to do it, as the business people at Shell just could not relate to it.

At that time two very experienced consultants at Shell, Bruce Ottmann and Matthew West, did some ground-breaking research into advanced data modelling that was offered to the public domain and became ISO standard 15926. One side effect of the research was a different notation to describe the data used by a business, which turned out to be a lot more intuitive than the traditional ER models implemented in tools like Erwin. This notation, and much else besides is described in an excellent whitepaper by Bruce Ottmann (who is now with Kalido).
We use this notational form at Kalido when delivering projects to clients as diverse as Unilever, HBOS and Intelsat, and have found it very effective in communicating between IT and business people. The notation itself is public domain and not specific to Kalido, and I’d encourage you to read the whitepaper and try it out for yourself.

del.icio.us:The Need for Real Business Models  digg:The Need for Real Business Models  reddit:The Need for Real Business Models  Y!:The Need for Real Business Models