From efficiency to effectiveness

Jonathan Becher of SAP Business Objects discusses the role of applications in linking strategy and execution to bring effectiveness to businesses.

Interview conducted by Vinod Baya and Kurt J. Bilafer

Jonathan Becher is senior vice president of marketing for SAP Business Objects. He is responsible for championing a wide range of solutions that help organizations optimize business performance, including business intelligence (BI), enterprise performance management (EPM), and governance, risk, and compliance (GRC). Becher joined SAP from its acquisition of Pilot Software, now SAP Strategy Management, where he was president and chief executive officer.

In this interview, Becher shares his views and insights on the future of enterprise applications, business intelligence, and how to bridge the gap between strategy and execution.

PwC: What is new and different in the world of enterprise applications? Where are they headed?

JB: We believe there are two fundamentally different kinds of applications: execution applications and management applications. One of the big stories that you may have seen from SAP last year is the closing of the gap between strategy and execution. In the early 1990s, people started talking about the difference between efficiency and effectiveness. I think our industry lost sight of that conversation, because much of the last 15 years of enterprise software has been all about efficiency. That’s why lots of software categories have the word automation after them—i.e., sales force automation, supply chain automation. It was taking an existing process and trying to figure out how to do it faster, quicker, with less waste, all that kind of stuff. And it’s absolutely great to do more with less, to reduce your supply chain. At SAP, we’re the process-centric company—hire to retire, order to cash, if you’re a retailer, sheep to shirt. We’ve spent a lot of time helping enterprises figure out how to be efficient with their processes. However, in most organizations, management processes still are not automated and are not well supported by enterprise applications. Those processes are managed by phone calls, by consultants, or maybe by desktop tools such as Outlook. At SAP we’re bringing these two worlds together: efficiency
and effectiveness.

PwC: How does the shift in focus to effectiveness relate to the need for agility or the need to deal with accelerating changes in the business environment?

JB: Because of the shifts in the rate of change, people are recognizing that hardening their processes and making them more efficient isn’t enough. In some cases, they’ve optimized the wrong processes, and now they’re going back to something that business schools talked about in the late 1980s and businesses started talking about in the early 1990s but forgot about—that is, maybe I’m doing the wrong processes in the first place and I need to think about being more effective. People say efficient and effective, not realizing that they’re fundamentally different words. Effective asks the question “which one of these things should I do?” And especially in this economic downturn, you can’t fund everything. Efficiency is now the priority, and the key question a business needs to ask is, “Is this the right one to do and am I doing it in the right way?”

Very simply, it is the difference between doing work in the right way and doing the right work. Our customers are saying, “You’ve helped me optimize the heck out of my back office, but I don’t know whether there’s a match between what I say I’m going to do and what I end up doing.” We think that’s the next big frontier for enterprise applications.

PwC: Does addressing this frontier require new kinds of apps? What is the role for the execution apps?

JB: You can’t have one without the other. If you have strategy with no execution, that’s a waste of time. But, on the other hand, if you have execution with no strategy, how do you know you get somewhere? Dashboards became popular as a metaphor. People thought dashboards were a management philosophy. They aren’t. If you think about your car, your dashboard tells you if you’re operating your car well, how fast you’re going, how much gas you have left, and so forth. It doesn’t tell you if you’re going to the right destination, if a traffic jam is going to show up, if you need to detour. It tells you that your car is efficient, but not if you’re headed in the right direction. So, in the last few years people added navigation. They [the car manufacturers] put them in your dashboard, but the information the navigation purveys is not necessarily metrics. We think the same thing should happen in business.

PwC: What could be an example that relates to enterprise applications?

JB: I’ll use a very simple example: expense reports. Sometimes people complain about their expense reporting software. Whenever people complain to me about it, I encourage them to talk to their accounts payable department. And then they go talk to them and they tell me, “They love SAP expense reporting.” I say, “This is the difference between execution apps and management apps.”

From the point of view of accounts payable, they get hundreds of expense reports a day. They want to make sure you don’t fly business class when you were supposed to fly coach, you don’t buy a dinner that’s too expensive, and so on. They want conformity. They want efficiency. They want exceptions kicked out, and that’s it. As a business traveler, you don’t even want an expense report, right? You have expenses that don’t occur in the same week. You book the hotel a month ahead of time, the flight three weeks ahead of time, and you remember the cab fare after you submit the expense report. You have this very disconnected, chaotic process.

You can’t make the same application appeal to the accounts payable person and to the traveler. At SAP, that’s why we have a separate division to deal with that distinction. Obviously, the two applications need to communicate and share data, but designed around a different use case.

PwC: Our research is leading us to conclude that from an agility perspective, the application environment should be organized into three distinct layers [see Figure 1]: a layer of execution apps, a layer of what we are calling business management applications, and a flexible information mediation layer that brings together the other two layers. Does that fit your view of the future?

JB: I basically agree with you. Where I differ is that it’s not that you have to be more flexible in the information services layer. It’s the fact that the execution apps and the business management apps aren’t in sync. The changes in one have to be reflected in the other appropriately, because if they aren’t, then what you say you want to do and what you end up doing don’t match. And that’s where the challenges really come. Then when you learn about what works and what doesn’t work, that knowledge needs to feed back to the business management apps in some way, so you make better decisions the next time.

I worry that right now that loop never closes, and so the top level affects only a subset of people and doesn’t change the fundamental processes. The way we close the books—that’s statutory reporting through core ERP [enterprise resource planning]—may be different from the way we do management reporting. But we still use just the ERP. Unless we make the next step and synchronize, we’re not really changing the business process.

PwC: What form will the synchronization you are talking about take? Is it a tight coupling? Is it a loose coupling?

JB: Think of it as a producer/consumer model. One layer could publish changes that it thought were appropriate to be consumed by another, and each layer has its own governance rules that decide whether it’s going to accept them. When it chooses not to accept them, despite the fact they were published, then it communicates the rejection, the reason, and so forth, and the business management app learns incrementally what it does well. It’s not a tight coupling. If we couple too tightly, then the danger is that we anchor this [operational app] to that [business management app], and it no longer has the flexibility necessary.

PwC: Where is the world of BI [business intelligence] headed? Do you think BI really belongs in the information mediation layer?

JB: Part of it depends on what the definition of BI is in your world. BI seems to be migrating into three parts. There’s what I call the information management part: collecting, cleaning up, and storing the data. Not just the warehouses, but where they came from, ETL [extract, transform, and load], the business process, and so on. There’s the very simple tool base of BI as well, the information discovery, if you will. And there’s the delivery of information to phones and other devices. That’s the high-growth part of BI during the last couple of years. The part that’s really underserved, amusingly enough, is the original idea of BI. Remember when the category was called decision support? Who builds a decision support tool anymore? Most people don’t. They build an information presentation tool now.

“How do you make a decision? You don’t just read a report and make a decision, right? You talk to friends, you go to the Web, you do some research, you think about your history. BI helped you make that decision, but you didn’t make your decision using just BI. That’s the next BI, one that lets you talk to friends, do research, and provides the broader context necessary to make the decision.”

Analytical apps are important, but technology that is not just reporting needs to come into BI. Let me give you an example. How do you make a decision? You don’t just read a report and make a decision, right? You talk to friends, you go to the Web, you do some research, you think about your history. BI helped you make that decision, but you didn’t make your decision using just BI. That’s the next BI, one that lets you talk to friends, do research, and provides the broader context necessary to make the decision.

PwC: So the reporting applications have to support collaboration to support decision making, right?

JB: Today, application user interfaces are typically designed for one particular person at one particular point in time. I sit and look at a screen to learn something or make a decision. But if you think about the reality, at least the way I work, it’s rarely one person doing anything. Most organizations are consensus driven, requiring different points of view from different people focused on their respective area, so these apps must be designed for multiple people who have slightly different points of view but come together to make decisions. In the software industry, we don’t really know very well how to design apps that way. It’s not a wiki, because a wiki is something you write, and then I come along later and I change it, and then he doesn’t like what I said, and he changes it. That’s not collaborative. The last one in wins, right? True collaboration is where we each see each other’s point of view and then jointly agree on the right answer.

PwC: How good is the industry at this stage in bringing together structured and unstructured information? And how good do you think it needs to get?

JB: It’s pretty well known that unstructured data is in its infancy when it comes to business intelligence. Some interesting things are happening. We have a product—it’s now called Text Analysis—that does sentiment analysis from unstructured text. We’ve pointed it at job boards, for example, and used it to figure out which verticals are growing, what kind of jobs are in the highest demand. My point is that Text Analysis is finding interesting semantic meaning that can be overlaid on the structured data. The problem with using BI and structured data is that structured data is a bunch of numbers, and unless you’re the expert who understands the numbers, you don’t really know what the meaning is. If we can overlay unstructured data on the structured data, that’s where the big win is.

“If we can overlay unstructured data on the structured data, that’s where the big win is.”

PwC: Often the semantics of information is tied to a particular use. Data models or schemas are defined for a particular report and transactions that feed the data model are captured. When the same information is to be used in a new application, new data mapping or transformation is usually necessary. For agility sake, do you think it’s important to separate the semantics of the information from its use, so that unintended uses are possible in the future?

JB: I would think about it this way. Applications in the execution layer are designed with process at the center of the universe. Services in the information mediation layer are designed with information at the center of the universe. And things in the business management layer are designed with users at the center of the universe. Designing software from a user point of view, from an information point of view, and from a process point of view are completely different.

Historically, we, as an enterprise software company, would say, “Yes, let’s tag this data as many ways as we can possibly imagine so that we have the widest use.” I submit that’s the wrong way to think about it. Let’s say a user is using an app, and describes his or her request. That application context will have some number of content tags and so forth, and the request gets pushed down to the information layer and says, “Give me the information that I need based on the request.” If it’s not available, then the true self-describing data will then go back to the application and figure out what else. The concept of predefined doesn’t exist anymore. Now, maybe you’ll want to do some caching, so you’ll pre-create some of these things, much like people did in the query days. But if you really want this to be flexible, the vast majority of the requests can’t be predefined there. So I would say you want to store data so that you do not assume any potential use in the future.

PwC: Would you say it’s sort of like IP [Internet protocol] networks in how they decouple transport from the applications that use them? The IP network does not assume anything about which applications will use them in the future, resulting in open and unconstrained innovation in applications.

JB: Exactly right. You can divide them and reassemble them on the fly, and it doesn’t matter. And if you lose a few packets, it doesn’t matter. I think that’s a great analogy. Unfortunately, it’s opposite of things like multidimensional analysis, which was developed for predesigned hierarchies and specific use cases. The problem with multidimensional analysis is you have to do all this heavyweight design ahead of time. If you got it right, it’s phenomenally good, but what happens the minute you get something new?

PwC: Before coming to SAP, you led Pilot Software, which provided a strategy management solution. What role do strategy management solutions have in bridging the gap between strategy and operations?

JB: First, let me clarify that there is a difference between strategy development and strategy management. I don’t see any time in the near future where software will do much to replace strategy development. It can help automate and document it, and all the management tools will help, but at the end of the day somebody has to do some deep thinking and say, “Do we go into Russia? Do we go into India? Do we build blue products?” And so on.

One fundamental problem I think most people overlook is that after you decide what to do, the number of people who decide what to do is miniscule compared to the number of people who have to do it. Here at SAP, we now have more than 50,000 employees. The number of people involved in creating our corporate strategy document is fewer than 100. So how do you get that knowledge that was dynamically involved in 100 people into the heads of the 50,000 so that the knowledge correctly impacts this thing down in the execution layer? That was the original problem that we tried to tackle with strategy management.

I used to joke at Pilot: “Strategy is trapped in the boardroom.” And yet the whole reason you come up with a strategy is to actually execute on it. How do you formalize that? How do you translate that strategy document into something that means something to everybody else as per their daily functions?

We believe there are three fundamental components that you have to focus on. There are objectives—it’s the what you want to do. There are initiatives—it’s the how you’re going to accomplish what you want to do. And then there are KPIs [key performance indicators] or measures or metrics—which are whether you’re making progress on those first two things. And the strategy management metaphor says if you do KPIs first, which is everyone’s temptation, you’re less likely to succeed. Because you’re immediately keeping score without telling people what game they’re participating in.

PwC: How will enterprises differentiate in the future, and what role will enterprise applications play in that differentiation?

JB: The closer you get to the users, the more differentiated you are. Let me give you a very rough analogy. On one hand, every retail store is the same. You could claim there’s no way to create differentiation, because they all have store shelves, they all have scanners, they have cash registers in the front, they all have lights ahead, they all have roughly the same shape. If you use that as an analogy for ERP, then you’d say there’s no difference between a Kmart and a Lowe’s and a Saks Fifth Avenue. But we know that’s not really true, right? They are highly similar in some ways, but they put different items on their store shelves and they interact with the users differently. Even those guys that have the same item interact with their customers in completely different ways. That’s the beauty of putting together execution systems with management systems. You get the scale, repeatability, and trustworthiness of ERP with the decision-making and strategy components of management systems. You’re differentiated and close to the users.

1From Wikipedia: In statistics, econometrics, and related fields, multidimensional analysis is a data analysis process that groups data into two basic categories: data dimensions and measurements.