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