Algunos puntos destacables:
Dice introductoriamente Wharton sobre las posibilidades de cambio del producto:
When Henning Kagermann became the sole CEO of SAP in 2003, a role he had previously shared with company co-founder Hasso Plattner, he faced a number of challenges, including an economic slowdown that hurt SAP's growth. Kagermann moved quickly to put in place a program to reshape the company's product offerings and adjust its market focus to position it for the next generation of software. But because major corporations use SAP's software to run nearly every aspect of their business, change at SAP requires a delicate balance between progress and stability.[Resaltado mío]Sobre el estado de la competencia:
Based in Walldorf, Germany, SAP is the worldwide market leader in enterprise software applications with annual revenues of $10.08 billion at the end of 2005. Microsoft and Oracle compete with SAP and are among the fiercest rivals in the industry. Oracle's recent acquisition spree -- scooping up PeopleSoft, Siebel Systems and more than a dozen smaller companies -- has increased its customer base and consolidated much of the market. Microsoft poses an additional challenge: While serving as a vital partner for SAP to link its ubiquitous Office products to SAP's enterprise backend, Microsoft is also SAP's main competitor in the mid-range market, a key segment for SAP's future growth. Managing such complex relationships is one of Kagermann's major challenges.Sobre el cambio tecnológico planeado:
In addition, he [Kagermann] must navigate SAP through industry changes that are rewriting the rules of software deployment. With a long history of developing tightly integrated client/server systems -- which use traditional desktop "client" software tightly coupled with back-end server applications -- SAP has to compete in a rapidly-evolving world of Internet-based software applications. Some competitors, such as SalesForce.com's brash CEO Marc Benioff, have even declared the death of traditional, locally installed software. Determining whether these are growing trends or passing fads are key decisions for Kagermann.Sobre la utilización de servicios Web:
(...) we want to reach out to more users within the company and beyond. To put it differently -- we have the philosophy that in the future people will work differently. They won't just sit down and have a transaction with a computer. It will be more of a "push" principle, managed by exceptions -- so that the application is pushing exceptions to your desk. For example, in the morning you would have not only email, but also an inbox of all the urgent business issues you should know about -- information which is critical for you to make decisions. This empowers people and brings decision making down to a decentralized level. People can act very quickly, but still -- I come back to this -- within the company's rules. And if you do those things you can reach more users.
In Duet, some of the Microsoft screens have an SAP panel on the right-hand side, where the user sees the productivity environment and can then go for deeper information. But there will also be users who are not using Outlook. If you go to manufacturing plants, for example, it's more about the integration between manufacturing execution systems and ours. It's more about the information coming from the NC [numerically controlled] machines, etc.
It's about collecting all of this information so that the guy who is managing the manufacturing flow is getting all the information on one screen. He can make smart decisions [based on information] coming from different systems. So, if I say "push," it doesn't mean that the user has to have an SAP user interface. If he wants a different user interface, we could push the alerts into it. And we also have to do it for mobile [hand-held devices].
[Habla Kagermann]Another piece that has impacted SAP is the concept of Web Services, which was also developed to provide more interoperability between the applications of different departments and companies. We have extended this concept to an enterprise level. We felt it was still too technical, it was still not in business language, and it didn't have the scalability and the robustness that business needs.Sobre el estado actual, y las derivaciones en el tiempo medio futuro, de la competencia entre las compañías que desarrollan ERPs:
And we have used the standards of Web Services, or the Web Services stack, to build what we call Enterprise Services, which helps companies to communicate. So, yes, it has impacted SAP, but we went beyond this because companies expect us to solve their business problems and not just to deliver the technology.
(...)You cannot convert everything into a service. It always depends on whether something is strategic for a company. Why are companies buying assets and not leasing them all the time? The same thing happens with software. There will be areas where companies still believe they have to own the software and have it on site because only then are they entirely independent. But there are areas where it's not that important and they say, "Why should I own this? I can have it as a service, and I can switch it off. [Referido aquí en dos sentidos:Servicio Web, y externalización de la aplicación]"
Sobre la complejidad de manejo de SAP:
Knowledge@Wharton: Speaking of your competitors, how do you differentiate SAP's strategy from that of your key competitors, like Oracle and Microsoft?
Kagermann: In enterprise applications we are the market leader -- and that means that we have to lead the market. And if you want to do that, you should believe in your own capabilities, and therefore we have adopted organic growth strategies. We have developed most of our products ourselves. We acquire [other companies] only if we are not fast enough to market and in areas where we have no capabilities. That's our difference from Oracle and Microsoft.
Microsoft entered the market with two acquisitions and is building competency from there. That's fine, but we don't have to do this. And Oracle has consolidated the market to buy market share and customers.
We are the market leader. If we bought customers [through acquisition] we would have to maintain the acquired products in parallel for a long time, which would split our R&D capabilities and defocus us from what is really important. We could not push clients to migrate quickly to our products, because we have a good relationship with our clients. We didn't want to be in the position where we have to maintain, develop and migrate three or four different products designed by different people. We have done a pretty good job with the organic growth strategy. We have gained a lot of market share.
(...) Knowledge@Wharton: You mentioned Microsoft briefly. You compete with them on mid-range business software, but they are also a key partner of yours. You've launched "Duet," which integrates their front-end client tools with your back-end enterprise software. How do you manage that kind of relationship?
Kagermann: That's a good question. First of all, we are driven by customer demand. If you are a strategic partner to your customer, you have to follow the demand. And the demand is for interoperability between the key vendors.
Even if you compete in some areas, you have to be professional enough to be a good partner. We are continuing to support Oracle's database with our applications, because our clients want this. The point of view that drives us is: If it's a client demand and it's important for the client's success, we have to do it.Now, internally you are right, it takes strong leadership to make the organization aware that the customer's success is more important than the little fights you might have internally. And as long as you deal fairly with your partner and the partner is fair with you -- it works. It only starts not working if one of the partners doesn't believe in win/win and fairness in business. But so far we have had fair partners.
Agregando a esto, la apertura a terceros proveedores:
Knowledge@Wharton: Historically your software has had the reputation of being a bit complex, difficult to install and, perhaps, rather inflexible...
Kagermann: Yes. Yes.
Knowledge@Wharton: Is there some justification for this?
Kagermann: You have to be fair here. On the other side you hear "highly integrated," "big productivity improvements," "entirely reliable," "highest quality." With the existing architecture, these are more or less [exclusionary]. If you have lots of functionality, you are not simple any longer. If you have lots of choices, it takes time to find the right thing. If you have a high degree of integration, you are not the most flexible. So, these benefits we brought to the market are always a trade-off.
We have seen other products which were more flexible and [yet they] died, because all of a sudden, the books were not in sync. Those types of things happen when it is too flexible.
But I'm with you; the future is getting both. And that's what we are trying to do with a new architecture. We don't want to give up on what we achieved in the past -- 100% compliance, etc., but we want to add much more flexibility. And I think we can do so.
I feel that [what we have done] was the right sequence. You should not come with highly flexible but noncompliant and unproductive software. You should first come with highly integrated, highly productive software and then make it flexible. I think this is the better sequence.
This concept of enterprise service and process components is so important. We would not bring flexibility and modularity to a level where it's not compliant. This is a big point. We will not open up the platform. Our flexibility starts on top of the platform. What is inside the platform we will not open up because that's where we can guarantee that the pieces are compliant.
Here you have a platform which should also guarantee compliance. You can innovate; you can put pieces together but only pieces that still guarantee the compliance. The components have built-in integration so that you cannot, [for example,] decouple logistics from finance.
It's more like exchanging documents. If you do it by a message flow, by a document, it's decoupled enough, but we would write this document and show it. If somebody then plugs in a different finance system, which has bugs in it, we are at least compliant so that we can say, "Our file documents the entirety of what's happening on a client level so that you can have clear books." So, this type of compliance we will keep. We would not allow people to say, "We don't need this any longer," and switch it off.
En fin, hay mas... Para leer desde distintos puntos de vista, y extraer líneas de trabajo...