I often joke about how easy it is to take two or three loosely related bits of information and declare them a trend. But there’s also an opposing tendency to think that nothing fundamental ever really changes. This makes it harder to recognize significant developments when they do occur.
One of those fundamentals has always been the need to define requirements before building or selecting a system. But I’m beginning to suspect that has changed. In systems, we see methodologies like “extreme programming” that advocate incremental development with a minimum of advance documentation. In marketing, we see rapid test cycles taking advantage of low cost and quick feedback on the Internet. We also see outsourced systems making it easy to try new methods and media with little investment or implementation time. In databases we see tools like QlikTech, SkyTide, Alterian and SmartFocus that radically reduce the effort needed to load and manipulate large volumes of data. If you want to stretch a bit, you could even argue that non-relational data sources, such as XML, text and graphics files, are part of the movement towards a less structured world.
This all takes some getting used to. Loyal readers of this blog (hi Mom!) know how much I like QlikTech (reminder: my company is a reseller), precisely because it lets me do complicated things to large amounts of data with little technical skill, hardware or cost. The other products I’ve mentioned offer similar flexibility, although they aren’t quite as easy or inexpensive.
My point is, we’re used to a world where advance planning is necessary because building a significant-sized system takes a great deal of skill and effort. These new tools radically reduce that skill and effort, making possible hands-on experimentation. The value should be obvious: we can bring in more data and look at it in different ways, making discoveries that would be unavailable if doing each analysis were more expensive.
We may need to revise our standard model of a business intelligence architecture to accommodate this. Specifically, we would add ad hoc analysis systems to the existing data warehouse and data marts. The ad hoc systems would hold data we may want to use, but haven’t quite figured out how. They would be a stepping stone in the development process, letting us experiment with data and applications until we understand them well enough to harden their design and add them to the regular production systems.
(Incidentally, some data warehouse gurus have proposed an "exploration warehouse" or "exploration data mart" that is a somewhat similar concept. They seem to have in mind more carefully processed data than I do, but I wouldn't want to claim to be the first to think along these lines.)
This notion may meet some resistance from IT departments, which are naturally reluctant to support yet another tool. But the price/performance ratios of these new products are so overwhelmingly superior to conventional technologies – at least when it comes to ad hoc analysis – that IT should ultimately see the advantage. End-users, particularly the technically skilled analysts who suffer the most from the rigidity of existing systems, should be more enthusiastic from the start.
Thursday, April 19, 2007
Subscribe to:
Post Comments (Atom)
4 comments:
How does one work to establish a Customer contact policy in a bank. I run marketing for a large bnk an the silo led organization structure has led to a decentralized customer data distribution model. hat are the best practises with regard to centralizaing customer data list distribution and more critically establishing a Customer contact policy. A lot of our silo busines heads seem to believe that list fatigue does not exist. Also in a hugely growing market like India,customer privacy has only now become very important for banks like ourselves.
Hi Ajay,
I've asked Client X Client CEO Michael Hoffman to reply to this one, since he has a great deal of banking experience. His comment follows:
The simple answer is that customer contact policy needs to be set at the top of the organization, but rarely, even where touted as an executive order, do banks execute using central customer data policy.
The most successful quick adaptations to a centralized policy have added another tier of silos in the form of segment managers responsible for managing highly profitable customers, moderately profitable and low to unprofitable customers. Segmentation based on current value is less successful than segmentation based on potential value but still creates a programs and delivery that are more customer centric. Potential value segmentation is better, however much more (BI) business intelligence intensive and few companies have the patience and expertise to succeed.
A pure relationship manager approach, think of a portfolio of customers, has also been extremely successful where relationship managers are tasked with growing the profitability of an identified set of customers. This approach is most successful when the relationship managers’ compensation is based on growth within their portfolio. The portfolio approach typically requires substantial cultural changes (performance based compensation practices and systems). The portfolio approach typically extends employee tenure (merit based performance and career path benefits). The portfolio approach requires some amount of discretionary budget for the managers and the ability to track customers and households over time and across channels and product silos.
I guess the simple answer is that an IT or marketing policy that simply shuts down access to customer lists and contacts will absolutely not work. The bank needs a common customer goal (the requirement for leadership to communicate the goal is huge) and management’s ability to communicate each employees role is extremely important. Tying these objectives to performance incentives is the ideal.
Ajay asks a great question, one that's really difficult to answer. Michael Hoffman's reply is spot on.
The "solution" requires a lot more than a policy. I put "solution" in quotes, because using that word implies there's a problem. If there is a problem, it's from the customer's perspective -- not the bank's.
But it might be the bank's problem and it just doesn't see it. Specifically, across product lines, response rates to marketing efforts may be lower than they might be because customers and prospects are getting over-touched.
The place to start, Ajay, isn't with a policy -- it's with analysis that can start to prove to the bank's product-focused execs that if they don't coordinate marketing efforts across LOBs that they'll continue to depress results.
Ron, I fully agree: you have to start with analysis that proves to top management that uncoordinated LOB efforts are depressing results for the business as a whole. Otherwise you have a "tragedy of the commons" situation where the product managers push their own promotions so long as they are incrementally profitable, regardless of what it does to everyone else. Unless top managers see a way that over-promotion is costing them money, they will never have a strong enough reason to rein in the LOB efforts.
Post a Comment