Veamos el caso de dos empresas hipotéticas: Empresa A y Empresa B. Cada una usa un paquete de software empresarial idéntico que tiene la misma funcionalidad central. Ambas empresas tienen el mismo número de usuarios, pero el costo total de propiedad de la empresa B es casi el doble del de la empresa A.
¿Cómo es posible? Es muy simple. La empresa A decidió implementar su software tal y como lo recibió; sin modificaciones. Definamos nuestros términos; modificación y personalización son dos cosas diferentes. Una serie moderna y flexible de aplicaciones empresariales debe poder personalizarse fácilmente para adaptarla a la mayoría de las necesidades del negocio y crear una experiencia a la medida del usuario, sin alterar el código subyacente o la lógica del negocio. Las modificaciones implican alterar el código y la lógica del negocio que opera detrás de la aplicación.
Pero un momento; ¿no es cierto que la empresa B obtiene funcionalidad adicional o mayores ventajas con las modificaciones? Desafortunadamente, en la mayoría de los casos, no.
Mayores costos, menores ganancias
A todas aquellas personas que planeen un proyecto de software empresarial, les advierto que hay que tener cuidado con las modificaciones. Me he dado cuenta de que la mayoría de las empresas que operan el software como un producto de inventario, está más satisfecha con su inversión. Tienen menos problemas y piensan que la inversión que realizaron en software empresarial se paga sola -y empieza a producir recompensas financieras mensurables con mucha mayor rapidez que las empresas que operan software modificado.
En casi todas partes, la decisión de comprar e implementar un paquete de software empresarial depende de las necesidades legítimas y específicas del negocio. Las empresas deben coordinar mejor sus proyectos y sus procesos entre los departamentos, o simplificar la generación de reportes y los análisis financieros. Es posible que inviertan en un paquete de software para fomentar una mayor colaboración entre los clientes y los proveedores, o para facilitar las eficacias que hacen que la empresa sea más competitiva.
Los proveedores de software empresarial aprecian estos factores y han desarrollado software y servicios de soporte que pretenden ayudar a las empresas a alcanzar sus objetivos. Pero una vez que se ha seleccionado un software por razones del negocio, la misma situación se repite una y otra vez. En su esfuerzo por ser inclusivos y respetuosos y de facilitar el proceso de cambio, los líderes de la empresa buscan obtener información sobre el proceso de implementación de los empleados que conforman la estructura corporativa. Estos empleados sugieren modificaciones que pueden contribuir poco a lograr los objetivos del negocio, y que aumentan el costo del software sin mejorar realmente la funcionalidad o el desempeño.
Si bien aquéllos que están al frente del negocio se merecen todo nuestro respeto, cuando se alcanza cierto nivel en la mayoría de las estructuras corporativas, los empleados sólo tienen el conocimiento o la comprensión de sus propios roles en la empresa, es decir, no entienden el negocio como un todo. Es posible que no tengan conocimiento de las razones que tiene la empresa para cambiar las herramientas con las que trabajan diariamente. Los empleados insisten en realizar muchas modificaciones que son necesarias para que ellos mantengan su nivel de productividad actual, y que están diseñadas para mantener el status quo, pero que no ayudarían a que la empresa alcance sus objetivos. De hecho, estas modificaciones pueden ser contraproducentes.
Gran parte de las modificaciones solicitadas terminan siendo innecesarias, y lo único que hacen es duplicar las funciones inherentes a la serie empresarial nueva. En algunas implementaciones, he visto que las empresas piden más de sesenta modificaciones, para después abandonar la mayoría de ellas poco tiempo después de iniciar las operaciones en vivo, para favorecer las funciones que ya residen en el software. Sin embargo, cuando se logra convencer a las empresas para que usen el software tal cual durante noventa días, sucede algo fascinante. Una por una, las modificaciones solicitadas empiezan a desaparecer de la lista. Esto se debe a que los paradigmas de los empleados pasan del sistema antiguo al nuevo, y se dan cuenta de que el software nuevo puede hacer lo que hacía el antiguo -a veces hace más. El ambiente del software nuevo ya no es una amenaza, sino que se vuelve una parte familiar y normal de la vida de los empleados.
No hay que olvidar que cuando una empresa adquiere un sistema de software empresarial nuevo, los empleados creen que tienen que recorrer más pasos para lograr los resultados que obtenían con un simple clic en el sistema legado. Pero no se dan cuenta de cuánto tiempo, trabajo y gasto se ahorra en otra parte de la empresa -generalmente en contabilidad- debido a esos pasos adicionales que deben enfrentar repentinamente. Es posible que los empleados no se den cuenta de que la alteración que solicitan costará miles de dólares, y que mantenerla costará todavía más.
En algunos casos, los líderes y los empleados del departamento deben legitimar las preocupaciones relacionadas con la adopción de un software nuevo. Probablemente su rendimiento se mida de forma tal que se vería afectado ya sea por la curva de aprendizaje o por las prácticas alteradas que son inherentes a un paquete nuevo de software empresarial. El personal de tecnología de la información (TI), en particular, puede sentirse preocupado por la adopción de un paquete de software sin modificaciones. Después de todo, un departamento de TI que ha dedicado una cantidad importante de recursos a modificar y mantener las modificaciones que se hacen al sistema legado, puede considerar que un paquete de software de inventario es una amenaza a la seguridad de su trabajo. La sensibilidad a este tipo de preocupaciones ayudará a facilitar la transición de un sistema legado y a fomentar la aceptación del nuevo ambiente del software.
Modificaciones delicadas
Soluciones comunes para evitar las modificaciones Las modificaciones mencionadas se solicitan no para lograr los objetivos del negocio, sino en un intento por hacer que el ambiente del software nuevo sea más familiar y predecible para el usuario. Un producto de consumo como Microsoft Excel puede ser una referencia familiar para muchos empleados, pero cuando abre Excel, está abriendo una hoja de cálculo en blanco. Esto no sucede con un paquete de software empresarial, que está poblado con parámetros y garantías que evitan que los usuarios introduzcan los datos incorrectos, violen las reglas de contabilidad y operen de forma que entre en conflicto con las prácticas del negocio que se han establecido. Naturalmente, un usuario de software querrá contar con toda la libertad que le da Excel, sin tener que asumir las consecuencias que se desprenden de esa libertad ilimitada.
Algunas aplicaciones empresariales permiten exportar datos a Excel, manipularlos y volverlos a cargar a la aplicación. De hecho, una serie empresarial sólida permitirá este tipo de interoperabilidad -no sólo con Excel, sino con otro software patentado y tradicional. Pero hay que tener cuidado, ya que no todos los sistemas de software empresarial que se encuentran en el mercado ofrecen estas garantías al obligar la exportación de datos a un paquete de software. Tenga cuidado de que el atajo que supuestamente le ahorrará $100 en esfuerzo no le cueste en realidad $20,000 en tiempo de consultoría para reparar los datos alterados.
¿Cuándo se debe modificar el software empresarial?
La oposición a las modificaciones del software empresarial tiene mucha fuerza. Su oferta de software estándar es producto de millones de dólares de investigación y desarrollo y de una gran cantidad de pruebas que pretenden garantizar un funcionamiento confiable y constante. La lógica del negocio y la funcionalidad tienen base en las mejores prácticas que han desarrollado las industrias exitosas a lo largo de muchos años, y que son enseñadas por organizaciones de profesionales como la Asociación para la gestión de operaciones (APICS).
Cuando el software empresarial se usa como fue desarrollado, le ayuda a mejorar sus procesos del negocio, permitiéndole diseñar su negocio en lugar de dejarlo que evolucione solo. Algunas veces, un negocio puede haber desarrollado prácticas que son únicas y que en realidad le ayudan a competir en el mercado. En esas situaciones, cuando existe una verdadera razón para modificar el software y desviarse de las mejores prácticas establecidas, puede ser posible justificar el costo que implica este gasto adicional.
Pero hay que tener mucho cuidado con las modificaciones al software que no dependen de las necesidades mensurables y legítimas del negocio. Tratar de justificar una modificación así puede crear enormes problemas y la necesidad de rechazar otras solicitudes de modificación.
Acerca del autor
Jeff Kugler es un consultor de soluciones de la oficina de Milwaukee de IFS North America. Antes de iniciar su carrera en la industria del software, trabajó en fabricación y operaciones. Ha dirigido implementaciones como cliente y como consultor, y es un defensor activo de la fabricación esbelta tanto dentro como fuera de IFS. Tiene el título de ciencias informáticas de Lakeland College, en Sheboygan, Wisconsin.