Las empresas adquieren software para resolver un problema del negocio u obtener una ventaja competitiva. Casi siempre toman en cuenta un paquete de soluciones para no favorecer las soluciones locales y poder aprovechar la experiencia de los demás. Un paquete de soluciones presupone que el proveedor de software se mantendrá al día con las últimas mejoras tecnológicas para hardware y sistemas operativos, y que se asegurará de que el paquete refleje y soporte las tendencias de la industria. Sin embargo, las empresas no gozan de estas ventajas por ósmosis, telepatía o gracia divina, sino que se presentan en forma de versiones del software, service packs o retoques para los sistemas. La empresa que decida no implementar estos productos puede aislarse del software o encontrarse sin soporte alguno. Este artículo evalúa el razonamiento que implica la decisión de actualizar, no actualizar o evitar las nuevas versiones del software.

Antes de iniciar el tema de las actualizaciones, hay que definir algunos términos. Como demuestra la pirámide jerárquica de las actualizaciones, por lo general una versión nueva ofrece funciones nuevas (como componentes habilitados para red, soporte de identificación por radio frecuencia [RFID] o arquitectura orientada a los servicios [SOA]), proporciona nuevos elementos y captura de datos (por ejemplo, registro de medicamentos o consciencia del bioterrorismo). Generalmente, una versión nueva implicará pruebas piloto y evaluaciones, capacitación para los usuarios y conversión de datos, mientras que un service pack pretende corregir los errores inherentes al software del proveedor. Estos service packs no introducen elementos de datos nuevos como tales, y no implican pruebas exhaustivas. Seamos honestos, el proveedor debe dedicarse a corregir los problemas existentes, no a crear unos nuevos. Un retoque es una solución o una actualización más localizada, que, al igual que los service packs, debe ser transparente para la comunidad de usuarios. La jerarquía de las actualizaciones puede representarse con una pirámide, ya que las versiones nuevas pueden incluir service packs y retoques pasados, mientras que los service packs pueden incluir retoques. Nuestra discusión se centrará en las versiones nuevas y los service packs, en los que incluiremos los retoques.

Establecer expectativas de antemano

El usuario, que actúa como director de proyecto y representante de las facciones de tecnología de la información (TI), no está preparado para las versiones nuevas. Los proyectos de implementación de soluciones de planificación de los recursos de la empresa (ERP) pueden durar entre nueve y doce meses, aunque probablemente usted sepa de algunos que han durado años. Durante el proyecto, muchos usuarios trabajan doble, porque no sólo asisten a los cursos de capacitación, introducen datos, crean tablas y realizan pruebas piloto del software nuevo, sino que deben cumplir con las responsabilidades normales de un trabajo de ocho horas diarias. Pero hacen todo esto porque se les ha dicho que el software ERP puede darle a la empresa una ventaja competitiva -traer clientes nuevos, aumentar el tamaño de los pedidos, reducir las ineficacias de fabricación, acelerar las entregas, etc. Todos hemos pasado por esto.

El problema es que, mientras las empresas están en medio de un proyecto de ERP de nueve meses, los desarrolladores de software están creando las versiones nuevas. Así, cuando los empleados creen que ya pueden regresar a sus actividades laborales normales, se les pide que se preparen para la versión nueva. Muchas veces se hace creer a los usuarios que la implementación es un evento que sólo se da una vez, y no hay nada más falso. Un proyecto de ERP no termina nunca.

Hay que ayudar a la comunidad de usuarios a entender este hecho. Si bien la noticia no los hará dar saltos de alegría, al menos no se sentirán engañados. Si los ejecutivos de la empresa les recuerdan esto a sus usuarios, estos terminarán por aceptarlo, aunque sea a regañadientes. Algunas organizaciones hasta crean subconjuntos del equipo de implementación que permanecen en el sitio para entregar las versiones nuevas. Sólo hay que asegurarse de que se justifican adecuadamente estos costos de personal.

El razonamiento de las actualizaciones

La salida más obvia del dilema de las actualizaciones es que si ya pagó por la versión nueva, ¿por qué no usarla? Haga las cuentas. Siendo conservadores, podemos afirmar que un software ERP que cuesta unos $250,000 dólares (USD) implica un precio de mantenimiento de entre $50,000 y $60,000 dólares (USD). Si usted no hace las actualizaciones, estará tirando su dinero a la basura. Ahora exploremos algunas de las razones menos obvias.

Service packs

Tomar la decisión de aplicar los service packs debe ser relativamente fácil si se ha seleccionado un proveedor que tiene un programa eficaz de aseguramiento de la calidad. Los service packs modifican el código para resolver los problemas del software. Así, implican un mínimo de pruebas y es posible que no se requiera capacitación alguna. El único defecto que pude tener este proceso es que se hayan realizado demasiadas mejoras o modificaciones al paquete.

Cuando se trata de mejoras, en primer lugar hay que determinar si el service pack las afecta de alguna forma. En segundo lugar, hay que adaptarlas de forma retroactiva al service pack. Ya no se puede pensar que las pruebas deben ser mínimas, porque deben servir para asegurarse de que las mejoras funcionan como debe ser y que no invalidan la solución del service pack. Como regla general: para cada service pack hay que presupuestar el 20 por ciento del costo original de las mejoras o las actualizaciones. Así, para una mejora que se había instalado inicialmente por $50,000 dólares (USD) (y suponiendo que se lanzan cuatro service packs durante el año -una cantidad razonable de lanzamientos para algunos vendedores), estamos hablando de un costo de $40,000 dólares (USD). Esta cifra no toma en cuenta el tiempo que pasan los empleados realizando pruebas. Si bien los presidentes generales de las empresas disfrutan atender las necesidades de sus usuarios y domar la bestia del software, muchos no logran prever las repercusiones que puede tener a futuro.

Versiones nuevas

La decisión de implementar la nueva versión de un paquete es mucho más complicada, porque conlleva costos más altos y un periodo más largo. En gran parte es necesario tratar las versiones nuevas como implementaciones nuevas, para incluir la conversión de datos, las pruebas piloto, las pruebas integradas y la aceptación de los usuarios. Si no hay cambios importantes en la funcionalidad, no es necesario pasar por las etapas estado actual, estado futuro y análisis de las diferencias. Los usuarios que ya han recorrido la curva de aprendizaje necesitan menos capacitación en comparación con la implementación inicial.

Dicho esto, en el extremo superior de la escala, la implementación de una versión nueva debe presupuestarse como el 50 por ciento del proyecto original. Sin embargo, si se han hecho mejoras importantes al software de base, es posible que la estimación aumente al 70 por ciento o más, ya que todas las mejoras deben adaptarse de forma retroactiva a la versión nueva y deben probarse.

Sin embargo, las versiones nuevas no son como los modelos nuevos de los automóviles, que uno quiere ser el primero en tener. Salvo en los casos en que hay una necesidad apremiante de funcionalidad o el proveedor se compromete a proporcionar una mejora importante de acuerdo al contrato de venta, la mayoría de las empresas permanecen una versión atrás. Nadie quiere tener lo último en tecnología ni convertirse en un sujeto de pruebas para las funcionalidades nuevas. En general, las empresas que quieran implementar la versión actual deben esperar a que salga el primer service pack del software. Aún cuando la versión nueva ya está disponible, los proveedores siguen realizando pruebas. Si bien este plan de acción no demuestra mucha confianza en los desarrolladores de software, tiene base en el estado del desarrollo de software y en la prisa que normalmente tienen los proveedores para comercializar sus productos.

Mantenimiento continuo

Ninguna discusión sobre actualización a una versión nueva estaría completa si no se menciona el mantenimiento continuo y las tarifas relacionadas con él. Considere que, por razones válidas, su empresa decide no implementar las versiones nuevas. Debe preguntarse “¿Para qué quedarse en el mantenimiento?” Es necesario que las empresas se hagan esta pregunta cada vez que toman la decisión de no implementar una versión nueva, aún después de que han salido varios service packs. Para las empresas grandes que tienen suficientes recursos de TI, acceso al código fuente y conocimiento sobre el uso de herramientas de desarrollo, la respuesta lógica sería no realizar el mantenimiento. Pero piense que aún con estas ventajas, temas como los lenguajes propietarios de cuarta generación y las tecnologías de bases de datos pueden obstaculizar el objetivo de la autosuficiencia.

Por lo general, las pequeñas y medianas empresas (PYME) no tienen estas ventajas. Además, con frecuencia los proveedores de conjuntos de soluciones les dicen que no necesitan personal de TI (“Nosotros seremos su personal de TI”). Esto puede ser cierto si suponemos que las PYME siguen las instrucciones del proveedor, pero esta lealtad implica un pago anual por mantenimiento y soporte. Es por eso que es más difícil para las PYME tomar la decisión de dejar el mantenimiento. Si ignoramos el hecho de que no es probable tener una funcionalidad nueva, nos topamos con la preocupación mayor de la gestión del ambiente tecnológico. Si bien muchas PYME ven la licencia de mantenimiento como una póliza de seguro, sería más realista verla como una garantía. Una póliza de seguro le da dinero por su dolor y su sufrimiento, mientras que una garantía le da también las piezas y mano de obra de los expertos. Sin una garantía, debe negociar constantemente el tiempo y el material con el proveedor de software o encontrar un proveedor externo. Dependiendo de la popularidad de su conjunto de software, la última opción puede ser extremadamente difícil.

Razones para saltarse las versiones

Es probable que algunas empresas aplacen la implementación de una versión nueva de un paquete ERP si no se les proporciona una funcionalidad nueva. Esta situación puede prolongarse varias versiones. Por ejemplo, es posible que una empresa siga operando la versión 1.0 aún cuando la versión 4.0 esté disponible. Una práctica común y contractual entre los proveedores de software es soportar tanto la versión actual como la anterior. Para la empresa de nuestro ejemplo, la versión 1.0 ya no recibe soporte. Además, para complicar las cosas, es probable que nuestra empresa hipotética siga pagando mantenimiento, pero no lo está aprovechando.

Saltarse versiones puede ser un arma de dos filos. Las empresas creen que al hacerlo están ahorrando tiempo y dinero, y que no pasarán por las complicaciones de un proyecto de implementación. Pero puede no ser el caso. Como afirmamos antes, las versiones nuevas incluyen funciones y elementos de datos nuevos. Una empresa tendría que llevar a cabo las rutinas de conversión para ir de la versión 1.0 a la 2.0, de la versión 2.0 a la 3.0, y así sucesivamente. Hay que establecer, probar y operar los trabajos, y no hay ahorro de tiempo. También hay que realizar pruebas piloto y evaluar y verificar la funcionalidad nueva. Cuando se introdujo el concepto de peso variable (asignación de precio a mercancía como, por ejemplo, carne y aves, por peso real y no por tamaño del contenedor) por primera vez en la industria, muchos proveedores implementaron esta funcionalidad por etapas para poder acelerar su penetración en el mercado. La primera etapa (probablemente la versión 2.0 de nuestro ejemplo) era introducir el peso variable como un elemento de datos nuevo. La segunda (versión 3.0) era incorporar el peso variable en las rutinas de contabilidad de costos para el material de producción. La etapa final (versión 4.0) era incorporar los enlaces de la cadena de suministro. En nuestro ejemplo de la industria alimenticia, sería muy prudente verificar la precisión del peso variable en cada versión, ya que esta funcionalidad debería encargarse de la fuerte dependencia y las decisiones relacionadas con los pronósticos. Una vez más, no hay ahorro de tiempo. Podríamos usar argumentos similares para las mejoras y los cambios tecnológicos.

Sin duda es posible eliminar o reducir de forma significativa algunas etapas, como la capacitación. Pero una empresa estaría concentrando una cantidad importante de fuerza laboral durante mucho tiempo, en tratar varias versiones de forma simultánea. Puede ser que existan factores irreprimibles, como el desarrollo de productos nuevos o los programas avanzados de mercadotecnia, que cruzan los límites de un paquete ERP y que pueden requerir un retraso en la implementación de una versión nueva. Sin embargo, si se renuncia a estos factores, los intercambios que se obtienen al saltarse las versiones nuevas no garantizan este enfoque.

Descubrimientos y recomendaciones

Cuando una empresa se compromete a comprar e implementar soluciones para toda la empresa, el proyecto se alarga más allá de la fecha de inicio de sus operaciones en vivo. Aún cuando la implementación inicial toma nueve meses, la empresa necesita comprometerse con el personal, y los planes del proyecto pueden durar varios años.

Suponiendo que no hay mejoras o son mínimas, hay que tratar los service packs a medida que van apareciendo en el mercado. Para instalarlos, las empresas no necesitan muchas pruebas y capacitación para los usuarios. Estos service packs están hechos para resolver problemas, no crearlos. Si no es así, las empresas deben pensar seriamente en el motivo de las tarifas anuales de mantenimiento y hablar de ello con sus proveedores de software. Si las mejoras son significativas, tal vez quieran cuestionar el paquete de software que seleccionaron. Además, el grado de dificultad y la cantidad de tiempo necesario para la implementar service packs en una situación como ésta se acercarán más a los de las versiones nuevas.

La naturaleza y el alcance de la implementación de una versión nueva hacen que su proyecto, su programa y su uso de los recursos sean más complejos que los del service pack. Debido a la ausencia de condiciones competitivas y convincentes del negocio, los presupuestos para las versiones nuevas no deben durar más de un año. Si las versiones nuevas tardan más de un año, el grupo de usuarios debe reunirse con el proveedor de software para rectificar esta situación. Las empresas no deben vivir en un estado constante de implementación, aún cuando hayan formado un equipo del proyecto con este propósito. Si la funcionalidad nueva se empaca adecuadamente, las versiones nuevas pueden programarse en intervalos de dieciocho meses, con la participación del grupo de usuarios.

Como se mencionó, saltarse las versiones y combinarlas puede no producir las ventajas esperadas ni un ahorro de tiempo significativo. Además, para que un proyecto se adapte a varias versiones, deberá tener un grado mayor de dificultad, como se ilustra en la tabla siguiente.

No es fácil manejar las aplicaciones empresariales y las versiones nuevas correspondientes. La simple implementación de estas últimas representa un porción grande y compleja de las responsabilidades del departamento de TI. Muchos departamentos de TI no cuentan con el personal adecuado para esta tarea, y se olvidan de crear el presupuesto y la gestión necesaria para ella. Esto hace que las empresas piensen seriamente en subcontratar la gestión de las versiones nuevas de ERP, para poder reorientar sus esfuerzos en iniciativas que generen más ingresos.

Ahora que los proveedores están empezando a organizar sus series de software en componentes, se está revalorizando el atractivo paradigma de las actualizaciones gratuitas. Los proveedores de software se están alejando de las series todo incluido y están empezando a cobrar tarifas nuevas por las licencias de los componentes nuevos (o la funcionalidad SOA) a medida que se desarrollan. La forma en que estos componentes se integrarán con las series de software existentes les está dando más dolores de cabeza a los directores de informática. Muchas empresas no pueden permitirse las actualizaciones a la versión más reciente y por componentes de las soluciones, y si pudieran, tendrían que pagar las tarifas por las licencias nuevas por la dificultad que las caracteriza. Esta transición puede obligar a muchas empresas a dejar el mantenimiento simplemente porque no quieren pagar por algo que nunca utilizan. Pero esa es otra historia.

Lo importante es que hay que pensar en la gestión de las versiones nuevas y la implementación del software en toda la empresa al revisar la justificación de los costos de la compra del software. Si bien esta consideración no tiene que cambiar su decisión de adquirir una solución ERP, seguramente alterará los cálculos del tiempo necesario para obtener el retorno de su inversión y recuperarse.

La tabla siguiente le ayuda a medir el esfuerzo necesario para cada tipo de actualización, y le proporciona un resumen general de este artículo. Refleja el tiempo necesario para adaptar las mejoras de forma retroactiva, que es directamente proporcional a la dificultad y el alcance de las mismas. Es necesario revisar las notas de las versiones para terminar las etapas de análisis del estado actual, el estado futuro y las diferencias, y poder tomar una decisión en caso de que se requiera un análisis más profundo.

A cada tarea de implementación se ha asignado un grado de actividad -bajo, moderado o alto-, para aplicar el esfuerzo de la forma siguiente:

• Un grado de actividad bajo requiere un esfuerzo de una semana de trabajo o menos.
• Un grado de actividad moderado requiere un esfuerzo de un mes de trabajo o menos.
• Un grado de actividad alto requiere un esfuerzo de un mes de trabajo o más.

De acuerdo a estas asignaciones, es posible terminar en un mes o menos el proyecto de actualización de un service pack en un ambiente donde hay pocas mejoras o ninguna. Por otro lado, un proyecto de implementación de una versión nueva en una solución de conjunto que ha tenido muchas mejoras, puede durar hasta cuatro meses. Pero recuerde que hay que agregar el esfuerzo necesario para la adaptación retroactiva de las mejoras, y esto puede representar más del doble del programa de actividades del proyecto. Utilice estas estimaciones como una guía para evaluar su proyecto de forma razonable.

Finalmente, habrá quienes piensen que es más fácil hablar de los conceptos explorados en este artículo que llevarlos a la práctica, y tienen toda la razón. Sin embargo, si se definen de antemano las expectativas de la comunidad de usuarios, se deja en claro que la implementación de un paquete en toda la empresa no es un proyecto que se lleva a cabo una sola vez y se establecen claramente las desventajas de no implementar o saltarse las versiones futuras, se estará más cerca del objetivo deseado.

Acerca de los autores

Joseph J. Strub cuenta con una vasta experiencia como gerente de proyecto senior y consultor para planeación y realización de proyectos ERP para sistemas de fabricación y distribución en empresas medianas y grandes de las industrias de procesos de menudeo, alimentos y bebidas, química y de bienes de consumo. Ha desarrollado programas de mercadotecnia y comunicación para empresas de TI y ha realizado consultoría para oportunidades de subcontratación en el exterior para empresas multinacionales. Además, fue consultor y auditor de sistemas de información para PricewaterhouseCoopers y director de desarrollo de aplicaciones y soporte para varias empresas Fortune 100. actualmente es consultor independiente. Se le puede contactar en JoeStrub@WriteTechnologyPlus.com.

Predrag Jakovljevic es uno de los principales analistas de Technology Evaluation Centers (TEC) para el mercado de las aplicaciones empresariales. Cuenta con cerca de veinte años de experiencia en la industria de fabricación, incluyendo varios años como súper usuario de TI, ERP y aplicaciones relacionadas, así como consultor, implementador y analista del mercado. Tiene el título de ingeniero mecánico de la Universidad de Belgrado (Serbia [la antigua Yugoslavia]) y cuenta con las certificaciones en gestión de la producción e inventario (CPIM) y gestión integrada de los recursos (CIRM) de APICS.