ERPs en el huracán

Insensiblemente, cada día, cada semana, cada año, estamos viendo conformarse cambios en el alcance de la tecnología informática, las comunicaciones y el manejo del conocimiento que marchan hacia un modelo que parece integrar todo con todo. Están quedando desactualizados todos los conceptos que por cuarenta años han regido cada disciplina vinculada al manejo de la información, y probablemente la mejor actitud ante esto sea mantenerse abiertos y atentos a las tendencias. Si la tecnología móvil incorporó en menos de una decena de años varios miles de millones de usuarios, el ya casi con nosotros Internet de las cosas promete romper todas las barreras y escenarios en que comunicación, tecnología y conocimiento aparecen asociados. Esta totalmente masiva apertura ha dejado en un terreno irrelevante la discusión por sistemas operativos, lenguajes, técnicas, recursos, y áreas de enfoque. Hoy nuestra pregunta sería: ¿qué podemos hacer, hasta donde podemos llegar?
 En el marco de estas fuertes transformaciones del manejo de la información, los llamados ERP también están siendo alcanzados: Tras haber alcanzado ayer nomás un estatus de emperadores reinantes en el mundo empresario, los actuales cambios los están recortando a jirones, ante nuevas necesidades y nuevas velocidades de respuesta. Los actuales ERPs sin duda son capaces de atender el ciclo central de grandes áreas de negocio, quizá especialmente en el mundo de las manufacturas y en el contable, pero su capacidad de flexibilizarse ante nuevas exigencias es muy baja.
Sirva esto de introducción al excelente artículo de Alex Woodie sobre este punto: Six Signs Of The Long, Slow Decline Of  ERP. Woodie habla de "declinación de los ERPs", no sólo desde el punto de vista de la empresa usuaria, sino también desde el propio interés del fabricante del software. Así, menciona seis signos de esta declinación:

• El costo de las licencias, por resistencia de los usuarios, y por la creciente competencia de otras alternativas, especialmente desde la nube
• La propia migración hacia la nube
• Los interminables costos de sucesivos proyectos.
• Las escasas novedades incorporadas (se puede decir que cada área ocupada por un tipo de ERP deviene un commodity).
• El movimiento del enfoque hacia nichos más lucrativos (léase Big Data).
• ...y la deconstrucción de las suites, especialmente debido a la aparición de nuevas soluciones enfocadas en áreas específicas.

 Woodie mide el impacto de la declinación del uso de ERPs en el área de su interés, los equipos de rango medio, particularmente el IBM i (AS/400 en un pasado remoto), suponiendo que una disminución de la importancia de este software traerá una caída paralela de los equipos en que este software se ejecuta. Me permito dudar de esta correlación: el universo del manejo de la información no se ha simplificado, sino todo lo contrario, y difícilmente una empresa delegará todo su patrimonio a ninguna nube, salvo que sea propia.
Hay que pensar todo de nuevo...

Una arquitectura de dos velocidades (McKinsey)

Un par de artículos publicados por McKinsey este mes de diciembre, (1 y 2, firmados por Oliver Bossert, Jürgen Laartz, y Tor Jakob Ramsøy), plantean una estrategia realista de adaptación en una empresa anterior al universo digital. Los autores proponen una estrategia de dos velocidades para sumar una capa digital a una empresa de corte tradicional. Si lo releemos un poco, podríamos concluír que el escenario descripto es común y mayoritario: las empresas nativas digitales son una minoría, aunque se hayan convertido en hegemónicas en muy pocos años. Excelente artículo para pensar estrategias.
El postulado de los autores es este:

Unlike enterprises that are born digital, traditional companies don’t have the luxury of starting with a clean slate; they must build an architecture designed for the digital enterprise on a legacy foundation. What’s more, while most companies would have been comfortable in the past going through a three- to five-year transformation and not implementing new features in the meantime, today’s highly competitive markets no longer allow players to alter architecture and business models sequentially. It is therefore important to realize that the transformation toward digital is a continuous process of delivering new functionality.

Para los autores, esta migración al mundo digital requiere hacerse fuertes en cuatro aspectos: Innovación en el desarrollo de productos y servicios, habilidad para atender múltiples canales, capacidad de análisis de datos y tendencias (big data), automatización y digitalización de procesos de negocios:

First, because the digital business model allows the creation—and shorter time to market—of digital products and services, companies need to become skilled at digital-product innovation that meets changing customer expectations. One such new offering for consumers is car-insurance policies enabled by geolocation-tracking technology, where the price of the policy depends on how much and how aggressively a person actually drives.
Second, companies need to provide a seamless multichannel (digital and physical) experience so consumers can move effortlessly from one channel to another. For example, many shoppers use smartphones to reserve a product online and pick it up in a store.
Third, companies should use big data and advanced analytics to better understand customer behavior. For example, gaining insight into customers’ buying habits—with their consent, of course—can lead to an improved customer experience and increased sales through more effective cross-selling.
Fourth, companies need to improve their capabilities in automating operations and digitizing business processes. This is important because it enables quicker response times to customers while cutting operating waste and costs.

El problema básico al que hay que encarar es el relacionado con la contradicción entre una empresa estable, con procesos de negocios manejados de manera conservadora, frente a la necesidad de ser flexible, ágil, rápido y variable en la atención de los nuevos procesos. Esto requiere otra manera de organizar las actividades de IT:

While a few players have overcome some of these hurdles, it is a big challenge for many IT executives to implement all four levers so customers can, for instance, purchase individually tailored products across multiple channels. One important reason is that the legacy IT architecture and organization, for example, which runs the supply-chain and operations systems responsible for executing online product orders, lacks the speed and flexibility needed in the digital marketplace.
Indeed, the ability to offer new products on a timely basis has become an important compe­t­itive factor; this might require weekly software releases for an e-commerce platform. That kind of speed can only be achieved with an inherently error-prone software-development approach of testing, failing, learning, adapting, and iterating rapidly. It’s hard to imagine that experimental approach applied to legacy sys­tems. Nor would it be appropriate, because the demand for perfection is far higher in key back-end legacy systems. Quality, measured by the number of IT system errors, and resilience, measured by the availability and stability of IT infrastructure services, comes at slow speed but is critical for risk- and regulatory-compliance management and for core transactional activities such as finance and online sales. In contrast, lower IT-system quality and resilience can be acceptable in customer-facing areas, for instance, when users participate in the testing of new software. For these reasons, many companies need an IT architecture that can operate at different speeds.

Los autores valúan como imprescindibles los dos tipos de procesos (tradicionales, difícilmente transformables, y digitales, con grandes requerimientos de agilidad, flexibilidad y rapidez de respuesta). En este marco, elaboran una serie de recomendaciones para mantener e interactuar entre ambos tipos de procesos y necesidades:

Manage a hybrid target architecture with very different platforms. Digital target architectures are heterogeneous, with trans­actional platforms managed for scalability and resilience coexisting alongside other systems optimized for customer experience. The transformation can be sustained only if a high-level target architecture and standards in critical areas such as cybersecurity are clearly described from the beginning. Without them, the transformation can be slowed down by the complexity of legacy and new hardware and application provisioning.
Plan for ongoing software delivery with blends of methodologies. There isn’t time to develop software by using a waterfall model and then separating the transformation into several long phases, as in traditional multi-year IT transformations. Nor is the solution to migrate all delivery to agile methodologies. The answer is to do both but blend the benefits of agile (iterative development, continuous delivery) into the waterfall model. Now, the software solution for each business challenge has to be constantly developed, tested, and implemented in an integrated fashion. This requires clear segregation of platforms into domains managed for fast iterative delivery (for example, for customer-experience applications) or for transactional integrity (for back-end transactional systems).
Develop the low-speed architecture, too. It’s important to establish a clear distinction between the two IT models from the beginning and not only focus on the fast-speed part but also develop the transactional back-end architecture. Those systems of record require rigorous development and testing methodologies and must be managed for resilience and scalability, with no compromises.
Build a new organization and governance model in parallel with the new technology. In the digital enterprise, business and IT work together in a new and integrated way, where boundaries between the two start to blur. This partnership has to be established during the transformation^.
Change mind-sets. By transforming the architecture, technology can become a key fac­tor for a company’s competitiveness. Such a development requires increased management attention and usually a place on the board agenda. While IT efficiency clearly remains important, spending levels may well rise as companies transform IT from largely being a necessary expense to being a true business enabler. As such, expenses are managed as investments rather than just costs; this will often require a substantial mind-set shift for the organization.
Run waves of change in three parallel streams. In a two-speed transformation, it makes sense to have an implementation plan that runs in three parallel streams. The digital-transformation stream builds new functionality for the business, supported by the results of a short-term optimization stream that develops solutions that might not always be compliant with the target architecture (for example, using noncom­pliant interfaces). To ease the development of short-term measures and create a sustainable IT infrastructure, an architecture-transformation stream is the third necessary component.

Las técnicas descriptas pueden verse no sólo como aplicables a una estrategia de cambio hacia una economía digital, sino a cualquier escenario de una empresa grande, con una tradición establecida de procesos de negocios y soluciones tecnológicas establecidas pero anticuadas; la idea central que destaco de la visión de Bossert y otros es la de articular dos velocidades en el desarrollo de nuevos procesos y arquitecturas, dando a cada parte su importancia relativa, y manteniendo procedimientos diferenciados según de qué área se trate.
Recomiendo releer varias veces estos artículos, extrapolando cuando parezca necesario.

ERPs: Aviso a navegantes

Este es un asunto importante, que entra en el terreno de la ética: la credibilidad que puede esperarse del consejo de una empresa que vende un producto de software (en rigor, esto vale para todo vendedor). Es  interesante ver que las observaciones que siguen a continuación vienen de una consultora de primera línea: el comentario está originado en la presentación de Dennis Gaughan en la Conferencia de Gartner Australia, esta semana pasada. No tenemos el contenido directo de su presentación, pero sí su resumen tomado por dos publicaciones de tecnología, al menos: Business Insider, e IT News de Australia.
Esta es la nota en Business Insider:

The four big software vendors -- Microsoft, Oracle, IBM, and SAP -- have hidden motives that customers need to understand, otherwise they might be pushed into buying products and services that don't fit their needs.
That's the takeaway from a recent Gartner talk in Australia, reported by IT News.
At a symposium this week, Gartner analyst Dennis Gaughan explained what the four big vendors are really trying to do, based on Gartner's experience with its clients.

• Microsoft mainly wants to protect Windows and Office. Microsoft is a platform company, and its main goal is to protect its highly lucrative Windows and Office monopolies, while establishing other platforms that will be hard for customers to break away from later. New functionality is "drip fed" to users of those core platforms, but new products exist to protect the core. He advised extreme caution before moving to Office 365, and said not to slip into an "all-Microsoft" mentality.

• Oracle products don't really work well together. Oracle's sales force is extremely aggressive about pushing a suite of products, but has much fewer integration points than SAP. In fact, integration is usually left entirely up to the customer. Oracle is also very reluctant to talk about product roadmaps for fear that future products will cannibalize existing ones. The company makes more than 90% of its profits through maintenance fees, and will do whatever it takes to keep those fees flowing in. Gaughan also expressed some surprise that so many customers keep working with Oracle despite reporting that Oracle is "the most difficult vendor to deal with."

• IBM wants to take over your IT strategy. IBM bills itself as a thought leader, but its real business is selling consulting services. To thrive, IBM account managers try to take control of a company's IT strategy so they can keep pushing new products. Gaughan recommends taking a collaborative or partner approach.

• SAP confuses customers with pricing. A lot of SAP customers ask Gartner for help figuring out SAP's pricing and licensing, as SAP has unusual terms for billing data going into and out of systems. Gaughan also said that a big technology transition that was driving SAP revenue for the last few years -- moving existing customers from the old R/3 system to the newer Business Suite -- is almost done, which means SAP will have to be more aggressive with maintenance fees. He recommended locking in maintenance prices now.

Overall, Gaughan said that most of the innovation being done in these companies is in their research arms. Their real goal is protecting the status quo for as long as possible.

 Frecuentemente, las empresas son conducidas a compras que, especialmente en el campo de ERPs o grandes infraestructuras de hardware, pueden llevarlas a gastos interminables e inabordables, y luego, a un fracaso difícil de levantar. Frente a la idea de la visión del software como un commodity, algo que se puede tercerizar, estoy convencido que una compañia mediana o grande debe defender y capacitar sus recursos humanos tecnológicos, y debe defender un punto de vista y una estrategia propia, confrontada, si, aceptando la consulta de terceros, pero con capacidad de maniobra e independencia de criterio. No todas las estrategias son adecuadas para cada caso.
De aquí se derivan dos o tres líneas de discusión, que trataremos de seguir: el valor de un ERP "empaquetado", la encrucijada de la implementación de un ERP, la ética esperable de una consultoría. Será en el futuro, si es posible.

ERPs e innovación (a propósito de gerenciamiento)

Adam Hartung, comentarista de tecnología de Forbes, compara la dirección de Hewlett Packard con la de Apple, señalando el gerenciamiento "de corte industrial" de HP como gran causa de su progresivo deterioro. Pero hablando de gerenciamiento e innovación, Hartung da una agresiva e interesante visión del software ERP.  Qué dice Hartung:

Now CEO Apotheker’s plan for HP’s growth is selling ERP software from a third-tier competitor. ERP (enterprise resource planning) applications like SAP and Oracle are viewed today as the remarkably expensive, hard to install, hard to maintain, hard to modify, monolithic, bureaucracy creating, innovation killing systems they were designed to be.  ERP applications were created to force companies, functions and employees to replicate previous decisions, in the hopes of increasing control (especially financial control) and cutting operating cost.  Not to learn, or do anything new.  They were designed to create rigidity, and are completely unable to enhance flexibility, market responsiveness and growth.  ERP was the emerging high-tech “solution” in 1992!
It is clear Mr. Apotheker is returning to his previous personal success, as CEO of SAP.  He isn’t looking to the future and how he can meet new, unmet needs.  He’s investing in what he knows, from his past.  His focus on “business solutions” is his way of pushing HP to be more like SAP – only 2 decades too late, against enormously well funded competitors, in a low-growth marketplace looking for new solutions.  Too bad for HPs investors, employees and suppliers.

El dilema de un ERP

A comienzos de abril, Ajay Gupta escribe para Informit, recomendaciones para aquellas empresas que adquieren un nuevo ERP (Enterprise Resource Planning). Su punto de vista es que el nuevo software (y toda la reingeniería que trae aparejada) no debería ser modificado mas allá de lo que su propia configuración y ajuste a las características del contratante requieran, por lo menos durante los primeros seis meses, o preferiblemente durante un año fiscal completo:

It is my recommendation that organizations delay any and all customization for a minimum of six months, and preferably a full fiscal year

Sus razones son entendibles desde el punto de vista del ERP en sí, pero son difíciles de aceptar desde el punto de vista de quien lo hubiera comprado para mejorar su gestión. Más aún, aunque aceptara renunciar a ajustarlo a sus necesidades, de todas formas es probable que la dinámica de su negocio le obligara a adecuarlo imperativamente.
La argumentación de Gupta abarca tres áreas:

• El valor de la reingeniería de procesos que propone el ERP de que se trate

Enterprise resource planning systems can bring value to an organization in terms of its automation, defined internal workflow capabilities and through increased decision support transparency and operational efficiency. However, to achieve these goals, organizations almost universally must commit to reassess and re-engineer their existing business processes. A pre-implementation stage is the ideal time to document current operations in an effort to find and cut out unnecessary steps, streamline operations and reduce operating costs, as well as track how operations will translate into the new environment. The exercise of examining business practices helps and is often considered critical to a successful migration to the new system. However, this preliminary planning doesn't always happen, at least not as effectively as would be hoped. Another way an organization can ensure business processes are modified is to essentially force itself to operate with the new ERP right “out-of-the-box” and with no customizations, however slight, to the code, work flows, and system operations permitted in the first fiscal cycle. Such a delay or postponement of customization efforts will be seen as a polite way to deny such requests. Honestly, there may be some truth to this as postponing a request can be easier than openly saying no. However, organizations that truly embrace the notion that the ERP implementation is an effort to change business practices that perhaps don't work as well as they did in the past, even though they have been done that way since forever, generally can find greater success in the overall project.

• El costo de la modificación

Given the current fiscal situation throughout our economy, avoiding measures that increase operating costs in both the short and long term is often essential. At the least, such measures should be undertaken only when there is certainty about the fiscal budgets for the duration of the implementation project, and when there is certainty on the cost implications of the customization. The true cost of customizing an ERP is rarely accurately considered and includes at a minimum all of the following:

• Cost of custom code development by ERP vendor or 3rd party This is often the only factor considered. However, what is considered is only the invoice amount presented on a custom code development proposal. Cost overruns, mid-stream changes to scope, or modifications that account for insufficient requirements are not considered, even though many acknowledge such a likelihood. 

• Additional end user training and consulting costs towards adoption of customized code Customizations, whether altering the core source code or creating a new workflow, are often funded through the original implementation budget and often at the expense of training and consulting dollars. Introducing customized and unique code into an ERP system complicates the overall system use and management effort and usually requires additional training and consulting assistance. Its an interesting act of irony that training and consulting funds are often raided to fund the customizations in the first place, when the customization itself usually requires additional training and consulting support beyond what was originally allocated. Further, since the ERP is customized, the ERP vendor's trainers and consulting professionals may themselves need time to learn how it now operates before they can effectively provide the training and consulting services. Depending on the contract language for implementation support and consulting services, firms may have to pay for the time vendor representatives spend to learn the customization.

• Increased cost of post-implementation ERP maintenance Changes made to an ERP often alter the work process when implementing a vendor's regular patch updates. For example, many ERP systems present a social security number on screens that also provide other, less sensitive demographic information. Given the concerns surrounding identity theft, many consider enacting measures to remove the SSN for such screens so the screen itself can still be assigned to users as necessary for the execution of their duties without giving those users access to the SSN. It sounds worthwhile, and perhaps a change that removes one field from one screen will not be so expensive. However, such a change will have to be tested each time a patch to the ERP system is made to ensure the new patches do not overlay, reverse or otherwise alter the coding changes made in the customization. This added staff burden must be taken into consideration when evaluating this approach to making changes. In light of this, the cost of customization should include the cost of custom code development, additional training and consulting expense, and additional manpower required to maintain the system in the long run. Further, customization necessarily involves time, which may push back go-live dates. If doing so involves financial penalties for missing delivery dates, such financial penalties should also be considered.

• El real conocimiento de los nuevos procesos

Prior to actual “real world experience” in using an ERP to accomplish the numerous tasks that must be performed at all stages of the business cycle, staff may simply not be in the position to identify and articulate all of the areas where customization may present value. Until the organization has seen how the ERP supports all of its administrative and business functions and certain functions only come up once or at certain stages in a fiscal year cycle it may not be in position to know where enhancements will be most helpful to the organization. Further, customizations have the potential to alter the ERP system in ways that affect its functionality in other areas. As ERP systems are integrated systems, changes in one area can have unexpected and unintended consequences in other areas. Often, these changes may not become apparent until later in the business cycle. Only after a complete business cycle would the organization know how to articulate the design constraints that will affect the specific changes desired without compromising functionality in other areas. (...) While functional user and technical staff are still trying to fully understand the operation of the ERP, they may not be in a position to fully articulate the design requirements for any customization, nor accurately predict the consequences of customizations they do implement(...) During the migration to the ERP, the first task is really to understand the ERP and its unique intricacies. Customizing it at this early stage has the effect of giving both end users and technical staff a “moving target,” making such projects more challenging from both the operational and system administration perspective.

Esta es una lista de certeras observaciones. Sin embargo, las conclusiones podrían no ser las que su autor propondría...
Es entendible que empresas sin una cultura corporativa sólida puedan encontrar una ventaja importante en apoyarse en un ERP: éste indudablemente incorporaría técnicas y estrategias de  organización, de planificación y gerenciamiento que valorizarían sus actividades, sus procesos, y sus recursos humanos. Pero si la empresa tiene una cultura y su intención es mejorarla, no parece simple que estas recomendaciones sean aceptables. Un ERP se acerca a un commodity...Una empresa que cuida su posición en primera fila ¿puede confiar sus procesos a un estándar, y no defender su diferencial? Si basa su actividad en la mejora contínua, o reingeniería de sus procesos: ¿se conformará con no intentar refinarlos y reescribirlos? Un ERP tiende a ser un complejo estático, o de baja capacidad de evolución: cuando un ERP ataca un proceso, debe contemplar el impacto de un cambio en el conjunto de sus clientes, y más aún si se trata de un ERP internacional, donde deben contemplarse las exigencias legales y culturales de al menos la mayoría de sus clientes. ¿Cuánto tiempo pasará hasta el momento en que las necesidades de evolución de una empresa en movimiento exijan adelantarse a su ERP en abordar un área determinada de actividades? Y si se escribe nuevo software en áreas no abordadas por el ERP, ¿no comienza la rueda del impacto de lo que Gupta recomienda no hacer...?

Ralph Johnson sobre el software complejo

Una breve reflexión de Ralph Johnson sobre el colapso del software complejo:

Clay Shirky had a blog about the collapse of complex business models.  He referred to a book by Joseph Tainter called "The Collapse of Complex Societies" that I put on my must-read list.  The book describes why societies collapse, and implies that it is necessary.  Clay says the same thing about the collapse of complex business models; there is no way for the old companies to adopt the new business model, so they will eventually collapse along with their old business model.  Naturally, I thought about software.  Is there any way to save complex software when it needs to change and can't?   We can refactor it, throw parts away, reuse parts of it.  But is that any different from what collapsing societies do?

Lo relacionaremos en otro momento con el ciclo de vida de los ERPs...

Finalmente, Oracle toma Sun

Seguramente la compra de Sun tendrá impacto profundo en el negocio informático, y lo veremos progresivamente. Dos comentarios hoy destacan el carácter de oferta vertical que ahora podría presentar Oracle. Ashlee Vance, en The New York Times ("Cash in Hand, Technology Giants Go Shopping"), y Tom Steinert-Threlkeld, en ZDNet ("A complete industry in a box"). Vance dice:

Most consumers do not want to get a PC by purchasing microprocessors, hard drives and operating system software from different suppliers and assembling them all into a working computer. They prefer to buy a complete, customized machine from one supplier.

Corporate customers increasingly want the same thing: a one-stop shop for hardware, software and services. And the largest technology companies are deploying their huge cash hoards to make acquisitions to bolster their ability to be that single provider.

That trend drove Oracle, a leader in business software, to announce Monday that it was spending $7.4 billion to buy an ailing Sun Microsystems and get into the computer hardware business. Oracle beat out rival I.B.M., which considered buying Sun to enhance its own software offerings but ended serious acquisition talks about two weeks ago.

“Oracle will be the only company that can engineer an integrated system — applications to disk — where all the pieces fit and work together so customers do not have to do it themselves,” Oracle’s chief executive, Lawrence J. Ellison, said Monday.

Vance no piensa en lo que le pase a MySql, ni el cambio de manos de Java, sino en la consolidación de agentes con control completo del negocio. Quizá sea su punto de vista el más acertado en todo lo que comienza a debatirse tras la compra. ¿Habrá cometido IBM un error histórico?

La crisis llega al software

Ben Worthen, en The Wall Street Journal, comenta el día 14 una circular interna de SAP que recomienda congelar toda clase de gastos. La noticia es algo irregular, mencionando un correo interno al que tiene acceso, pero de ninguna manera desmentida por SAP, ni por la decena de respuestas que recibe la nota, de parte de miembros o asociados de la empresa. SAP ha sido medianamente castigada en bolsa, nunca tanto como cualquier banco, y más o menos recuperada en lo inmediato. Sin embargo, sea con problemas o sin ellos, refleja lo que realmente veremos sin duda: enfriamiento de la actividad.
La nota:

SAP announced last week that its revenue for the quarter would fall short of its guidance due to a sudden drop in orders at the end of September. That sent the company into cost-cutting mode, as outlined in an email co-CEOs Henning Kagermann and Leo Apotheker sent to staff last week. A copy of the email was obtained by the Business Technology Blog.

The party line in the tech industry is that businesses will keep spending on tech because it makes them more efficient. This, in turn will help them survive the downturn. We’re not sure whether to file this under irony or hypocrisy, but SAP is – you guessed it – halting new spending on information technology. “We will review all planned investments in IT equipment, hardware, software, facilities, and company cars, as well as internal IT projects,” the co-CEOs wrote in the email. “Do not order any new equipment at this time.”

The email captures the uncertainty at SAP – uncertainty that is no doubt shared by other companies in the industry. “No one at this point can say how markets and customers will react in the coming months,” the email says. “In this turbulent economic environment, we will be giving added attention to sustaining our margin and earnings health.”

Aside from halting its tech spending, here’s how SAP plans to do that, as taken verbatim from the email:

* Headcount and Hiring Freeze: “There is a complete headcount and hiring freeze, and all existing job vacancies will be canceled. This includes any temporary workers, interns, and students. There will be no replacements for employees leaving SAP. No internal transfers may take place. Only those written offers sent to a candidate and/or internal transfers agreed to on or before October 7, 2008, will go forward.”

* Third-Party Expenses: “Since we are not hiring, all engagement with external recruiters must cease immediately. We will discontinue engagement with management consultants and evaluate the impact this has on ongoing projects. Until further notice, all external training is to be canceled. Internal meetings must be held within SAP buildings, and you cannot rent external conference facilities for this purpose.”

* Travel: “Cease ALL internal non-customer-facing travel in October…Any non-customer-facing travel already booked should be canceled immediately, even if this incurs penalties.” SAP sales people will also have to fly coach from now on unless they use miles to upgrade.

La nota de Worthen es comentada por Vinnie Mirchandani, que desde hace algún tiempo le viene dedicando espacio a SAP, particularmente por su política de costos de mantenimiento a sus clientes. Que muy probablemente también sufrirá cambios.

Las últimas adquisiciones de empresas de software

Comentado ya por medio mundo, sólo dos palabras: Sun compra MySql, y Oracle compra BEA. Continúa la tendencia a la concentración de operadores en cada área, aunque en este caso se trata de modelos de negocio distintos: abierto o propietario.
La noticia de SUN/MySql:

"The combination of MySQL and Sun represents an enormous opportunity for users and organizations of all sizes seeking innovation, growth and choice," said Marten Mickos, CEO, MySQL. "Sun's culture and business model complements MySQL's own by sharing the same ideals that we have had since our foundation -- software freedom, online innovation and community and partner participation. We are tremendously excited to work with Sun and the millions of members of the MySQL open source ecosystem to continue to deliver the best database for powering the modern Web economy."

La noticia de Oracle/BEA:

On January 16, 2008, Oracle announced that it has entered into an agreement to acquire BEA Systems, Inc., a leading provider of enterprise application infrastructure solutions. The proposed transaction is subject to closing conditions, including regulatory, shareholder and other approvals. Until the deal closes, each company will continue to operate independently, and it is business as usual.
The addition of BEA is expected to accelerate innovation by bringing together two companies with a common vision of a modern service-oriented architecture (SOA) infrastructure and will further increase the value that Oracle delivers to its customers and partners.

Leído en El Economista, Pensamientos ágiles, Wall Street Journal, James Gosling, entre muchos otros.

Cognos será azul

EbizQ informa que IBM se propone comprar Cognos, una de las últimas grandes empresas dedicadas a Business Intelligence, por un precio aproximado de 4.900 millones de dólares. Luego de Hyperion y Business Objects, casi todos los competidores del negocio pasan a ser parte de grandes operadores corporativos: Oracle, SAP, IBM. La noticia en EbizQ:

Today IBM announced its intention to acquire Cognos in an all-cash transaction at a price of approximately $5 billion USD or $58 USD per share, with a net transaction value of $4.9 billion USD. The acquisition is subject to Cognos shareholder approval, regulatory approvals and other customary closing conditions, and is expected to close in the first quarter of 2008.
Steve Mills introduced the analyst briefing by talking about the state of the market, with companies becoming more sophisticated about leveraging information, and using analytics for both looking back, and looking forward, becoming more pre-emptive in their decision making. He also spoke about how real-time business analytics was becoming an important part of business process management.
Just about every analyst on the call would have to agree with those statements. Last June, in the ebizQ BI in Action virtual conference this was discussed extensively both in the panel session and in a series of pre-conference podcasts. Indeed, one of the analysts questions was that we’ve been expecting this for a while, why now (answer – a $5 billion purchase takes time).
Cognos fits very well into the IBM stack. For a change it pretty much adds new functionality without adding a lot of redundancy. Furthermore, about 5 years ago Cognos re-architected their solution as a service based offering. It runs on top of IBM (and other) infrastructure software, providing real-time business intelligence and business performance management. The business performance management capabilities are key It enables companies to align, monitor and measure business operations with business strategies. This is truly good stuff – very important to business managers.

Como refiere el artículo de Beth Gold-Bernstein, la visión de IBM es muy optimista:

"Customers are demanding complete solutions, not piece parts, to enable real-time decision making," said Steve Mills, senior vice president and group executive, IBM Software Group. "IBM has been providing Business Intelligence solutions for decades. Our broad set of capabilities – from data warehousing to information integration and analytics – together with Cognos, position us well for the changing Business Intelligence and Performance Management industry. We chose Cognos because of its industry-leading technology that is based on open standards, which complements IBM's Service Oriented Architecture strategy."
(...) “This is an exciting combination for our customers, partners, and employees. It provides us with the ability to expand our vision as the leading BI and Performance Management provider,” said Rob Ashe, president and chief executive officer, Cognos. “IBM is a perfect complement to our strategy, with minimal overlap in products, a broad range of technology synergies, and the resources, reach, and world-class services to accelerate this vision. Furthermore, this combination allows Cognos customers to leverage a broader set of solutions from IBM to advance their information management driven initiatives.”

Me olvido de alguna? Sólo queda Informatica Corporation, entre las grandes. El negocio de ERP e inteligencia de negocios cada vez más concentrado.

Oracle va por BEA

Logistics Management informa hoy sobre una oferta de Oracle por Bea. En una nota firmada por Jeff Berman, editor senior de la publicación, se reproduce la información de The Wall Street Journal, que indica que Oracle hace una "oferta oportunista" de más de 6.600 millones de dólares en momentos en que Carl Icahn, uno de sus accionistas importantes, presiona para la venta.
The Wall Street Journal presiente que existen posibilidades de que la operación se concrete:

Oracle Corp. made an unsolicited $6.66 billion offer for business-management software maker BEA Systems Inc., which has been under pressure from investor Carl Icahn to consider a sale of the company.
Several hours later, BEA issued a response saying the offer "significantly" undervalues the company, but stopped short of rejecting it outright.
Oracle's all-cash bid values BEA at $17 a share, a 25% premium to its closing price Thursday of $13.62. Shares quickly jumped above the offer price in trading Friday, amid speculation that the offer could trigger a bidding war for the San Jose company.
Mr. Icahn, for his part, said he is "certainly happy" about Oracle's bid. Mr. Icahn in recent weeks became the biggest shareholder in BEA, with a 13.22% stake as of Wednesday.
"It definitely should be taken over," Mr. Icahn said in an interview Friday, adding that BEA "would be a great fit with Oracle." He said, though, that he "would like to see it command a better price" and named SAP AG, International Business Machines Corp. and Hewlett-Packard Co. as other possible acquirers.
(...) Oracle's Mr. Ellison has been eyeing BEA for years, but Alfred Chuang, BEA's founder and CEO, has been firmly opposed to the idea of being acquired, arguing that his company could stay independent through internal research and development. The pressure from BEA shareholders to sell the company is evidence of a sea change in the technology industry that has now opened the door for an Oracle acquisition.
(...) BEA's stock has declined steadily over the past year. Before Mr. Icahn purchased his stake, the stock price was down 24% from its 52-week high last October, a drop that wiped out about $1.5 billion in shareholder wealth. Two months ago, the stock was trading at $11.25.
BEA shares haven't been above $17 since February 2002. The stock's high over the past five years was $16.77 in November.
BEA has been beating back speculation of a sale for some time. In September, Kevin Faulkner, BEA's head of investor relations, said the company had no intention of following Mr. Icahn's advice, saying BEA would get "buried inside a larger sales force."

La posible compra refuerza considerablemente la concentración de competidores en el mercado de ERP´s, a días de concretarse la compra de Business Objects por SAP. En palabras del Wall Street Journal: Four years ago, when Oracle made its PeopleSoft bid and divulged an interest in buying BEA, the move was seen as an audacious and risky one; big software acquisitions were still rare and prone to failure. But the industry has matured since then. That has made it increasingly difficult for smaller, independent players like BEA to compete against giants like Oracle and IBM.

SAP compra Business Objects

EbizQ publica la noticia de la compra de Business Objects por SAP, en una operación de 6.800 millones de dólares (4.800 millones de euros). Como allí se indica, una respuesta también a la compra de Hyperion por Oracle, concretada a un costo algo menor. Evolucionan ambas hacia la oferta de un software que abarque todo el manejo corporativo, extendiendo las funciones típicas de un ERP a la extracción de valor sobre la información operativa con software de análisis de negocios, ahora con herramientas de primera categoría. Así como el software ERP ha llegado a un grado de concentración de oferta notable, así quizá también abra una capa de negocios en todas aquellas empresas para quienes una solución "de alcance mundial" les resulte demasiado grande.
La noticia:

SAP AG (NYSE: SAP) and Business Objects S.A. (Nasdaq:BOBJ) (Euronext Paris ISIN code: FR0004026250 – BOB) today announced that the companies have reached an agreement that will "bring together two of the information technology industry’s leaders, resulting in an unmatched offering for Business Users, enabling timely and accurate decision-making." (...)
Under the terms and conditions of the tender offer agreement, SAP will make a cash offer of € 42.00 per ordinary share and for American Depositary Shares (ADS) at the US$ equivalent based on the EUR/US$ exchange rate as of the settlement of the tender offers. The transaction volume taking into account the transaction costs will be slightly above €4.8 billion. The Business Objects board of directors has approved the tender offer agreement between the two companies and anticipates recommending the offer to its shareholders subject to fulfillment of certain regulatory requirements.
Together, SAP and Business Objects intend to offer high-value solutions for process- and business-oriented professionals. The solutions will be designed to enable companies to strengthen decision processes, increase customer value and create sustainable competitive advantage through real-time, multi-dimensional business intelligence. SAP and Business Objects believe that customers will gain significant business benefits through the combination of new, innovative offerings of enterprise-wide business intelligence solutions along with embedded analytics in transactional applications. Additionally, the joint partner ecosystems will be fueled by the industry’s most powerful business process platform providing customers with the best enterprise information management platform available for SAP and non-SAP environments.

Una evaluación de Joe McKendrick:

According to a report in ComputerWorld, acquiring Business Objects will allow SAP to move into the BI market in a big way. SAP CEO Henning Kagermann said that the acquisition will enable SAP to offer integrated software, versus solutions arising from a partnership between the two companies. The deal is expected to close in the first quarter of 2008.
Enterprise systems and business intelligence tools have been moving closer in alignment in recent years. The thrust of the BI industry into corporate performance management draws directly from a enterprise/ERP foundation, so the synergy has been ripe.
In addition, over the years, one of the biggest complaints about ERP software has been its less-than-stellar reporting features. Adding a robust BI capability to the mix may help change that perception. Of course, many leading BI vendors have made a living off filling the reporting gap in ERP systems. It remains to be seen if having Business Objects built into these systems will pose a competitive threat to the bread and butter of BI industry competitors. Plus, since many organizations manage multiple ERP systems, the challenge of consolidating reporting into single views still remains a challenge.

La referencia a la debilidad de facilidades de impresión en los ERP´s, le da un lugar importante a Crystal Reports, el software de creación de reportes de BO.
La noticia en el sitio de Business Objects y en SAP.

Eric Kimberling: buen material sobre implementación de ERP´s

Eric, miembro de Panorama Consulting Group LLC, colabora frecuentemente con IT Toolbox, un sitio excelente para conocer, aprender e investigar sobre el desarrollo e implementación de aplicaciones de empresa (lo que abarcan usualmente las siglas ERP, Enterprise Resource Planning, y EAI, Enterprise Application Integration).
En el último tiempo, son destacables sus artículos "The hidden costs of ERP", y "Why Are ERP Projects Always Over Budget?", centrados en el manejo de la implementación de estas aplicaciones verdaderamente complejas.
Sobre costos ocultos:

1) Internal company resources to make decisions on ERP requirements, help with system design, and perform testing. Aside from a full-time core team, most ERP projects require the involvement of 3-5 part-time subject matter experts for each full-time core team member.

2) Internal or external resources to manage data conversion, interface development, and report generation. Getting the system implemented is a huge milestone, but not if you haven't converted data or built the right interfaces and reports.

3) Employees to support communications, training material development, and training deployment activities. Many assume that the implementation consultants will handle this, but company employees also need to provide much of their time in helping develop materials and deploy training.

4) Time that senior management is involved in decision-making and conflict resolution. In a perfect world, employees across all office locations and geographies would be able to make decisions that everyone agrees with and that is best for the business overall. Unfortunately, in reality, senior management is often required to make decisions on behalf of the business, prioritize business needs, and provide strategic direction to ensure the project is aligned with overall business goals. There are costs associated with this time, and it should be quantified accordingly.

5) Design of business processes, particularly if the project involves a large, multi-national company with fragmented operations. ERP presents an opportunity to standardize and globalize operations across multiple locations, so arriving at a common operating model takes time and resources. It should not be assumed that the software itself will provide all the answers; business users need to decide how they are going to best leverage ERP to run their operations in the future.

6) "Backfilling" project team members with contract or other employees to manage day-to-day activities for the project team members who are no longer able to commit to their usual day-to-day jobs. It shouldn't be assumed that the business will continue to run as normal without replacing people that are devoting their time to the project.

7) Travel and expenses for team members, particularly if dealing with a global project. Project budgets should assume at least 15% of total consulting costs for travel, then double this amount to account for internal project team travel.

Sobre el incumplimiento de plazos y presupuesto:

1) Ensure executives outside of IT are involved in the vendor evaluation and planning process. Having more executives involved will help the management team identify all the hidden costs and benefits of implementing ERP.

2) Take your time during the ERP evaluation and project planning phase of the process. Too many companies rush into ERP as if the world is going to end without it, and they don't take the time to clearly lay out their business requirements, thoroughly evaluate the various vendors, and plan for a successful project. Any company that is serious about making their ERP project successful should spend at least 3-6 months on the selection and planning process, and possibly even more for companies that take longer to make decisions or are over $200 million in revenue.

3) Develop an actionable, realistic business case. A business case should be used for more than just convincing top management to approve the project. It should also be used to identify and manage operational business benefits and key performance indicators during and after the implementation.

4) Develop a realistic project plan and implementation timeframe. It may seem obvious that you won't know your true costs until you develop an implementation plan, but too many companies try developing an estimate before a plan has been identified. This is a huge recipe for a significant cost overrun.

5) Be open to the fact that it might not be time for ERP. Many may find this concept blasphemous, but even companies with the most manual processes and outdated technologies may not be suited for ERP. Perhaps a better and more cost-effective solution will help, such as business process improvements, best of breed software, etc.

Pero también son valiosos los comentarios de los lectores:
Sobre los costos ocultos, Yangoh dice:

The hidden costs have a lot to do with something like "putting the cart before the horse" syndrome. The industry norm is to engage ERP systems integrators and implementation consultants to help speed up the goal of "going life" without having any cultural revolution. The work culture may have to be changed drastically in order to adopt the new ERP systems.
It is definitely important to have SCM management education and training priot to ERP implementation, so that the business processes may have to be re-designed, improved and fine-tuned.
Due to the costs of consulting on a per man-day basis, in a lot of cases, it is not uncommon to try to reduce the number of man days to "going life". In many instances the life span of the ERP systems implemented with the compressed and expedited project timeframe can become very short, simply because more often than not the key users may revert to their old ways of doing things if the system does not suit them.
If only enterprises have the proper SCM education and training prior to purchasing a major ERP systems, then the costs of business transformation may be reduced drastically. It can also be true that sometimes it may not be necessary to change the systems at all, if only proper business process systems synchronisation (www.mpicsdb.blogspot.com) has been sorted out.
The other problem is the obsession with brand name ERP rather than going for the best in class or best of breed application solutions. In any case, operations management is still perceived as an art, so many enterprises can try new business practices but with the entrenched deep-rooted time-tested culture and processes.
The people factor is the least priority with some implementers forcing their way through the configuration of the ERP systems without getting the buy-ins and the approval of the key users.
If we use ERP as the enabler, then getting the business processes sorted out and synchronised should be the top priority besides looking at the opportunity for simplification and standardisation.

Sobre el exceso en presupuesto, Doug Hadden

I wonder whether the ERP industry suffers from the "blame the victim syndrome". Don't get me wrong, this advice is realistic. But, the solution to the ERP implementation problem seems to be generic - how to run large complex projects. Project Management 101. Isn't there something that the ERP vendors themselves can do to reduce the risk of going over budget?
Every time an ERP vendor reacts to a failed or late implementation, they point out that the customer's schedule was unrealistic - there weren't enough trained staff members - business processes presented by the client weren't accurate - there wasn't a long enough testing period (and so on). All of these are absolutely correct - in context to the ERP vendor's business model. When will these vendors smarten up and find ways to reduce the risk? Or, are they making too much money to change and upset the value chain? Possibly they are too focused on features or integrating acquisitions rather than worrying about usability, time to results, sustainability etc. Perhaps making ERP more complex increases switching costs. Don’t you wonder what would happen if ERP companies spent as much on simplification as they do on marketing?
On the other hand, to what extent are the victims responsible for predatory behavior? There’s more than enough evidence that ERP implementations are fraught with danger to know that vendors leverage hyperbole during the sales process. How can any responsible organization enter into an ERP contract without knowing these well-publicized risks?

Dos palabras más sobre SAP, Oracle, y SOA

Henning Kagermann, en la nota de Wharton mencionada antes, habla de su Enterprise Services Architecture, como su elección para el uso de servicios web. Tony Baer, de onStrategies, menciona, reforzando las palabras de Kagelmann, las soluciones de SAP y Oracle, y cómo las soluciones middleware , como BEA, se aproximan a la misma visión, para soportar aplicaciones "compuestas":

With the emergence of SOAs, it’s become thinkable to tie bits and pieces from the same system, or disparate systems, together into so-called composite applications. You can use third party tools, like business process management systems to tie things together, or you can buy prepackaged composite apps, like SAP’s xApps.

And if you take SOA seriously, you start thinking about breaking down those packaged software monoliths into federated services that could loosely couple with whatever else is out there. In other words, SOA gives best of breed a new lease on life.

Oracle’s Fusion architecture is being designed to decouple enterprise apps into services. SAP’s Enterprise Services Architecture (ESA) forms the blueprint on how its apps will be exposed. However, exposing apps as services that can readily integrate with third party offerings does not mean that SAP, Oracle, et al are ready to cede account control. Just the opposite – they intend to play the hub in larger playing field.

SAP: cómo va un elefante a la guerra

Knowledge Wharton publica el cuatro de octubre un valioso reportaje a Henning Kagermann, CEO de SAP. La conversación es un excelente resúmen del estado de situación de la competencia entre los grandes actores de las aplicaciones ERP, y de la posición de su empresa en ésta. Las complejas aplicaciones construídas por SAP, Oracle, ahora Microsoft, y otras empresas menores, son una cantera para aprender ingeniería...No es muy probable encontrar otras más abarcativas, extensas, y requeridas de resolver entre persistencia y variabilidad.
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.

(...) 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].

Sobre la utilización de servicios Web:

[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.

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 el estado actual, y las derivaciones en el tiempo medio futuro, de la competencia entre las compañías que desarrollan ERPs:

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.

Sobre la complejidad de manejo de SAP:

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.

Agregando a esto, la apertura a terceros proveedores:

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...