The curse of being good, or why strategic information management is hard
I was with a customer all day on Tuesday. The pieces I so love about customer visits are the descriptions of the entire system landscape, descriptions of problems they have solved, and key use scenarios going forward. Ooooo….love to talk use scenarios. It’s so awesome to wheedle through how it works now vs. how a customer dreams of it working—and how technology can make it easier.
This customer (let’s call it Tuesday, Inc.) suffers—like most I talk to—from the curse of being good. We rarely deal with a customer who is starting with a blank slate and wants to implement a strategic information strategy. Oh, but we like to draw those clean, orderly pictures. EIM as a shared service across the enterprise. Unified data integration across lines of business, business processes, and user types. Single point-of-design data quality rules deployed throughout the enterprise. What they HAVE is more like a Rube Goldberg machine.
But most customers are like Tuesday, Inc. They have solved individual data management problems over the last 10+ years. As each problem gets solved, processes and expectations grow upon that single point solution like a web. Tuesday, Inc. implemented new customer create scenarios which required classifying the customer into Simple or Complex. Now dependence on those classifications has grown throughout analytics and business processes. Changing that system of customer create means that all of those “subscribing systems” need to change their expectations and mode of operation, too.
And that customer create is just one tiny section of the data management web.
As we talked with Tuesday, Inc.. throughout the day, it became clear that they need a systematic way of looking at their entire information landscape. Tuesday has a rough idea of that clear, orderly picture we would draw if they were starting from scratch. But they desperately need a system to help them figure out where to start.
Here are some of the criteria we discussed:
- Assessment/discovery: First, make sure your picture of your information landscape is accurate. Do you know how the business processes feed each other? Do you know which BI and analytics systems depend on which data stores? Do you know when/how often you are getting data from external sources?
- Nicely contained: One place to start might be where a system can be nicely contained. Not TOO many far-afield applications or processes depend on the information. In this way, a small, well-informed team can design, test, and deploy the new system.
- High value: Tuesday had a board-level initiative around Customer Information. So they were nicely attached to executive sponsorship and funding. However, even within Customer Information, there were multiple projects to choose from. Choose a project that can show hard ROI through metrics you can reasonably track. Seriously. Don’t tie yourself to a metric of increased Customer Satisfaction if you have no way to refresh that metric until long after your project is done—and no way to trace increased customer satisfaction back to better information. It’s tempting. Don’t do it. Focus on value you can *get* and value you can somehow track back to better information.
- Remove an external service: Many times, companies use external service bureaus for part of list processing—either in preparation for mailing, or in purchased-list merging. These projects are nicely contained, for one. Second, the cost is well defined, because you’re paying the service provider now. Third, somewhere you already have design specifications that you pass off to the service provider. So you have a jump start.
- Strategic impact: Do not pick an area that will undergo a lot of technical change in the next 6 months. I’m talking about major, disruptive technical change. If you’re looking to start major changes like HANA or mobility in a specific area, don’t spend your time implementing a technical solution where they will be major requirement/infrastructure changes. In some small set of cases, if you can implement fast, then you may get automatically included in the disruptive project. It’s up to you…that’s more of a political decision.
As always, make sure you understand the roadmap and direction from your major technology partners. Without that information, you may box yourself in. There are lots of ways you can get those details from SAP: TechEd and SAPPHIRE presentations, a Roadmap website, or ASUG webcasts.
This is more like micro-surgery than major surgery. However, in both, you need to understand how the entire body works. What I’m suggesting is to start with a non-invasive laser procedure instead of a heart transplant or a triple by-pass.
If your company has been good–solving information problems along the way—it may seem like you’ve made the problem of strategic information management harder for yourself. And, in some ways, you have. However, in the most difficult aspects of a project, your path is easier:
- You have people who understand information.
- You have design document s and requirements…somewhere.
- You have a pretty good understanding of where you can do better.
- You have competency in a myriad of tools.
- You have a company that expects you to be able to solve information problems—and that understands information problems *must* be solved.
Use these things to your advantage!