Por: César Díaz

|

23 Dic, 2015

Como muchas de las tecnologías de información, el contar con un Sistema de Planificación de Recursos Empresariales (ERP por sus siglas en inglés) robusto y actualizado para controlar el negocio, hace tiempo que dejó de ser una ventaja competitiva para volverse simplemente “el boleto de admisión”.

Ahora bien, la decisión de invertir en una nueva solución ERP nunca es fácil, y una vez tomada supone también algunos obstáculos que pueden surgir durante su implantación.

Pero, ¿cómo evitar caer en los obstáculos más comunes a la hora de implementar un nuevo ERP?

Para responder a eso he enlistado ocho riesgos o “dragones” que se presentan comúnmente en una implementación ERP (vistos también a la hora de implantar otras soluciones tecnológicas como CRM, BI, BPM, por mencionar algunos) con base en mi propia experiencia y la de varios colegas que amablemente revisaron esta lista:

Expectativas imprecisas respecto a lo que es una solución ERP

Un prerrequisito para que exista entendimiento entre dos o más partes, es el que todas ellas manejen un lenguaje común, de otro modo el entendimiento mutuo resulta muy difícil, si no es que imposible. Se da el “yo creí que tú pensaste que él había entendido“.

Imaginen el inicio de un proyecto de implementación ERP en la etapa de levantamiento de información. Concretamente cuando un consultor levantando requerimientos llega preguntando a un usuario cosas como ¿qué necesita que haga el nuevo sistema? En ese momento, puede que la mente del usuario comience a “volar”; y si ese usuario no entiende (o nadie se ha tomado la molestia de explicarle) cuál es la lógica detrás de un sistema configurable (y prácticamente la totalidad de los ERPs actuales lo son) que carga y parametriza todo lo que puedas, resuelve con configuración lo demás, y solo por excepción pide un desarrollo a la medida; lo que normalmente ocurre es que se termina con una lista de requerimientos tipo “carta a Santa Claus”, y con un usuario con la expectativa de que toda ella se le cumplirá. Multipliquen esto por varios usuarios, varios procesos y varios módulos de un sistema y se podrán imaginar el efecto dominó de este “dragón” hacia el final de un proyecto.

Una solución ERP no es, y no debe ser vista como un traje a la medida, sino como una prenda de fábrica a la que solo se le puede ajustar un poco aquí y allá. De otro modo gastará una fortuna en servicios de sastrería y quién sabe si al final su traje le quedará o terminará luciendo como usted se lo imaginaba al momento de comprarlo.

REMEDIO: Contar con una estrategia concreta para hacer que las personas dentro de la organización que van a implantar el nuevo ERP entiendan el concepto de “sistema configurable”, e idealmente incluso desde antes de que se concrete la compra del nuevo sistema ERP. Eso ayuda mucho a la hora de establecer y delimitar las expectativas.

Solo por el hecho de que sea “técnicamente posible” instalar un jacuzzi en medio de una sala de reuniones, no significa que sea una buena idea hacerlo. Sé que este ejemplo suena absurdo y extremo, pero a veces algunos de los requerimientos de clientes en implementaciones lo son también; así que recuerde aún cuando un requerimiento sea “técnicamente posible” (la verdad es que en términos de sistemas, con suficiente tiempo y dinero casi todo es posible), no por eso significa que es una buena idea solicitarlo.

Lo “ideal” versus lo que funciona

Al estar evaluando opciones de soluciones ERP, los ejecutivos de las empresas suelen decir a los potenciales implementadores cosas como: “Es que nuestra empresa es diferente.” “Nosotros no hacemos las cosas como todos los demás.”

Hay que tener cuidado en dónde enfocamos nuestros esfuerzos de innovación, porque puede que cometamos el error de hacerlo donde menos se están necesitando. Es cierto que la capacidad de innovar es vital para cualquier negocio, pero en lo correspondiente a cosas como la forma de llevar controles administrativos, elaborar estados financieros, programar compras o gestionar la nómina, la verdad es que la mayor parte ya está inventada. Todo eso lo tiene dominado a la perfección cualquier ERP que sea digno de llamarse así. Innove en cuánto a sus productos, a sus servicios, a su oferta de valor como organización; es ahí donde puede diferenciarse ante sus clientes, no en “formas creativas y personalizadas” de cómo llevar sus procesos de back office.

REMEDIO: La forma de lidiar con esto es mantener apertura a ajustar los procesos de nuestra organización a la funcionalidad estándar del nuevo sistema cuando tenga sentido hacerlo, sin perder de vista que el resultado final es lo más importante. Atrévase a probar las soluciones que le ofrece de forma estándar la solución que está comprando (después de todo “son parte del paquete”), tomando en cuenta que lo más probable es que usted no sea el primer “creativo” al que se le ha ocurrido hacer las cosas del modo en que las hace, alguien más ya debe haberlo resuelto (no se ponga a inventar “el agua tibia”.)

Si resulta que de verdad es usted “el primer creativo” al que se le ha ocurrido, evalúe si de verdad es indispensable para su operación, o se trata simplemente de un intento de hacer que el sistema nuevo resuelva el requerimiento tal y como lo hace en la actualidad.

Las “configuraciones peculiares” o los desarrollos a la medida pueden ser caros, complejos de implementar y sobre todo muy complicado de migrar a versiones posteriores del sistema que se adquirió.

¿Por qué buscar que quede “perfecto” algo que de todas formas en unos años deberá migrar a la siguiente versión?

Las soluciones “de ayer” 

Este dragón guarda mucha relación con el anterior, sin embargo aunque aquel se gesta al inicio del proyecto y cerca del final ataca, este otro pretenderá hacernos quitar la vista del objetivo sin siquiera darnos cuenta.

La inercia es una de las fuerzas que hace del cambio algo tan complejo. Es más sencillo mantenerse inmóvil, en el camino actual, que pensar en si esa es la mejor forma de hacer las cosas. En especial si en el pasado requirió mucho esfuerzo y energía hacer que las cosas estuvieran tal y como están ahora. Por definición, toda solución viene con fecha de caducidad.

Quizá hasta ahora su forma de hacer las cosas era por medio de “atajos” o “puertas traseras” para expeditar sus procesos de backoffice “aquí y allá”, sin embargo los ERPs de clase mundial suelen ser rígidos en cuanto al control y la gobernancia, así como apegados a buenas prácticas por industria, por lo que pretender reproducir el cúmulo de“soluciones personalizadas” en su nueva solución ERP puede que le resulte un verdadero dolor de cabeza. Esto es particularmente cierto si el ERP vendrá a sustituir otro sistema originalmente desarrollado a la medida, pero que ahora ya le queda “pequeño”.

Además, existe una razón práctica y económica para limitar el número de desarrollos a la medida en una implantación ERP. Si abusa de ellos, acortará la vida útil de su solución. En mi experiencia he visto muchos casos en los que al verse en la necesidad de migrar a la siguiente versión del ERP, le resulta tan complicado y costoso a una organización reproducir el cúmulo de desarrollos a la medida en la nueva versión, que prácticamente termina implementándola desde cero.

REMEDIO: En lo que se refiere a la funcionalidad ERP, el resultado correcto es más importante que la forma particular de alcanzarlo. Pero ver las cosas de esa manera puede demandar ajustes a sus procesos, o el tener que cambiar algunos hábitos de años en la gente. Generalmente la solución más simple es la mejor, así que no caiga en la tentación de pretender resolver a punta de desarrollos a la medida, cosas que sería más sencillo resolver ajustando un poco la manera en que se hacen las cosas.

La regla de oro es que si algo de su funcionalidad actual es complejo de implementar y no es absolutamente indispensable (se necesita ser “brutalmente” honesto con usted mismo), déjelo para una etapa posterior y trate de acostumbrar su operación a la solución estándar. Si pasados 3 meses a los usuarios les sigue haciendo falta dicha funcionalidad, entonces pida que la desarrollen; y si se han acostumbrado al estándar de la solución, habrá ahorrado dinero al haber modificado un proceso o un hábito en la gente.

La adicción al Excel (o a las hojas de cálculo)

MS Excel y en general las hojas de cálculo son una de las herramientas informáticas de más amplio uso en los negocios. Han ido incorporando mayores y mejores capacidades y funcionalidad las cuales no resultan excesivamente difíciles de dominar. Primordialmente por una sencilla razón empoderan al usuario, haciendo que no tenga que depender del área de sistemas para hacer cosas verdaderamente sorprendentes. En mi experiencia, he visto hojas de cálculo para casi todo, no solo en temas financieros, estadísticos o de manejo de cálculos complejos, sino hasta diagramas de flujo y “maquetas” de aplicaciones web.

Pero como muchas cosas en la vida, las hojas de cálculo también tienen un “lado oscuro”. En el contexto de las organizaciones, es posible hacer que una hoja de cálculo diga casi cualquier cosa, simplemente ajustando un poco los datos, recombinándolos, poniendo una tabla pivote por aquí o por allá y ¡listo! Nuestras gráficas para esa presentación ejecutiva lucen mucho mejor. Y todo se magnifica cuando dos o más áreas de la organización hacen lo mismo dependiendo de su punto de vista o conveniencia ¿A quién creerle? Ese es el dilema diario de no pocos altos ejecutivos en todo el mundo.

Este fenómeno por sí mismo puede convertirse en la pesadilla de cualquier tomador de decisiones aún cuando se cuente con una base de datos centralizada; pero mucho peor si se tienen 2 o 3 versiones diferentes de los datos fuente.

No pretendo “satanizar” a las hojas de cálculo, pues es innegable que son una herramienta poderosa para que las personas en áreas usuarias puedan resolver problemas en la operación de forma creativa y eficaz, sin tener que “hacer fila” en la saturada lista de espera para desarrollos de TI de cualquier organización moderna. Sin embargo muchas de esas soluciones basadas en hojas de cálculo presentan al menos uno, si no es que todos los siguientes inconvenientes. Su manipulación requiere extremo cuidado por parte del usuario; un click en la casilla equivocada, datos copiados y pegados en la columna o el renglón incorrecto, borrar por error una fórmula o simplemente un “error de dedo” pueden inutilizarlas del todo.

Peor aún si un pequeño “error de dedo” pasa desapercibido, pueden transcurrir días, semanas o incluso meses sin que se detecte, habiendo distorsionando la información generada durante ese tiempo.

Las “mejoras” al proceso pueden terminar circunscribiéndose a simplemente añadir mayor complejidad (verificaciones redundantes, celdas y hojas protegidas para evitar “errores de dedo”, formatos en colores, etc.) a una solución basada en hojas de cálculo.

Se tiene dependencia casi absoluta de quien creó y programó las macros, tablas, fórmulas, etcétera, volviéndolo una verdadera “caja negra”.

Los respaldos generalmente no se hacen de manera confiable, si es que se hacen del todo.

Un concepto de “Teoría del Caos” enuncia que la complejidad da lugar a la incertidumbre

Si se trata de un pequeño proceso que pretendemos automatizar, y si el nivel de complejidad de la hoja de cálculo es bajo, puede que sea inofensivo y hasta recomendable simplificar una operación que de otra forma tendría que hacerse manualmente, mediante una solución creada en una hoja de cálculo; pero cuando la operación comienza a depender más y más de un cúmulo de pequeños desarrollos basados en hojas de cálculo, la continuidad del negocio en caso de fallo o emergencia estará comprometida seriamente, y la dependencia de quienes crearon o saben manejar dichos desarrollos puede ser algo muy serio.

REMEDIO: Tratándose de una implementación ERP, la recomendación es “nada con exceso, todo con medida.” Como en cualquier “adicción”, el primer paso es aceptar que se es adicto. Sé que suena exagerado usar ese término, pero los comportamientos que algunas personas pueden llegar a evidenciar hacia sus “sagradas” soluciones basadas en hojas de cálculo, rayan en la negación, el apego, la dependencia y la irracionalidad. Y es que quizá antes sufrían terriblemente haciendo las cosas manualmente o teniendo que depender del área de sistemas (y para ser honestos en muchos casos tienen razón, pero ese es otro tema), y ahora por fin está en su mano hacer mejoras a su trabajo del día a día, y les costó tanto esfuerzo y tiempo llegar a dominar el MS Excel, que es difícil dejarlo ir.

Es importante hacerle ver a la gente los problemas intrínsecos del uso y abuso de las hojas de cálculo en lo tocante a integridad de la información. Trate de evitar que la gente utilice “macros” o “tablas dinámicas” a manera de “parches” de funcionalidad en la que está basada la operación y/o la toma de decisiones. En vez de eso, invierta en que su gente (no solo las áreas de TI sino también las áreas usuarias) desarrolle un conocimiento profundo de la nueva aplicación y sus bondades en el contexto de sus procesos particulares, y asegúrese de que haya una buena transferencia de conocimiento por parte de su implementador.

Aclaro que a mí mismo me encanta el MS Excel como instrumento para potenciar la creatividad y la habilidad humana de resolver problemas.

El síndrome del punto medio

¿Alguna vez ha iniciado un régimen de ejercicios o alguna dieta? ¿Ha decidido aprender a tocar un instrumento musical? ¿Se ha inscrito en algún programa de estudios específico? Seguramente que sí. Probablemente, al inicio, su nivel de motivación y entusiasmo era alto, y cerca del final los frutos de su esfuerzo ya lucían tangibles. Pero a la mitad, quizá ya no tenía el entusiasmo del inicio, pero tampoco podía ver aún muchos resultados concretos. Quizá las dudas y el desánimo hicieron acto de presencia.

En los proyectos no es muy distinto, y es a lo que llamo “el síndrome del punto medio”. Al inicio, se tiene mucho entusiasmo y expectativa, y cerca del final aún cuando el proyecto haya sido demandante, por lo menos ya se ve la luz al final del túnel (y eso que el último 10% de todo proyecto demanda siempre recursos y esfuerzo extra). Pero es en ese “punto medio” donde buena parte de los proyectos se atascan, se comienza a renunciar a alcances, el presupuesto comienza a excederse, e incluso donde se cancelan. Es un fenómeno que tiene que ver más con la “conciencia colectiva” que con la propia ejecución de las tareas del proyecto en sí, pero cuyo impacto es innegable.

Se comienza a diluir la confianza entre los proveedores y el cliente, al grado que pueden comenzar a verse mutuamente como rivales, y pareciera que se vuelve más importante “tener la razón” que el alcanzar los objetivos del proyecto.

Entre los síntomas más comunes están cosas como:

  • El nivel de energía y tiempo que se destina a “dejar documentado” quién falló o quién decidió en tal o cual cosa para deslindar responsabilidades, crece muy por encima de lo razonable.
  • Se comienza a incumplir en acuerdos, las minutas de reuniones toman semanas en aprobarse (después de numerosas correcciones), si es que se aprueban del todo.
  • Las partes comienzan a “esgrimir” cláusulas del contrato de servicios, ya sea para reprochar al otro o para auto justificarse, más que para buscar el consenso o los acuerdos. El negativismo y la búsqueda de culpables, más que de soluciones, se vuelve el “modus operandi”.
  • En el “radio pasillo” predominan las anécdotas referentes a situaciones de conflicto entre personas; cosas como quién se peleó con quién, quién dejó a quién como un tonto en la reunión de comité, quién ya ni siquiera asiste a las reuniones, a quién van a quitar del proyecto, etc.

 REMEDIO: Es un simple (aunque no sencillo) esfuerzo de establecer y mantener la comunicación constante a todos los niveles. Ahora bien, el problema debe abordarse desde dos enfoques simultáneamente; uno preventivo y otro de mantenimiento.

El enfoque preventivo consiste en una labor intensa al inicio del proyecto para construir lazos e identidad de equipo en quiénes estarán participando en el proyecto, sin distinción de si es personal del cliente, personal del proveedor o de un tercero. Por el simple hecho de poner a trabajar juntos a “un puñado de expertos” no los vuelve automáticamente un equipo, pero por alguna razón se tiende a asumir que sí.

El enfoque de mantenimiento consiste en asegurarse de estar comunicando las veces que sea necesario no solo objetivos, sino también avances y logros aún cuando sean parciales. Esto ayudará a mantener el empuje y evitará dar lugar a la comunicación informal que casi por regla general tiende al pesimismo.

No pretendo afirmar que en un proyecto ERP todo debe ser “color de rosa” como en un cuento de hadas, los conflictos entre personas son algo inevitable en situaciones donde existe complejidad e incertidumbre como lo es cualquier proyecto. Sin embargo, el mantenerlos en niveles saludables no debe dejarse a la suerte, más bien, debe ser un esfuerzo deliberado y continuo.

Este es uno de los desafíos más grandes para todo líder de proyecto, y las palabras o los comunicados no son suficientes; hace falta que la gente vea el ejemplo.

Infraestructura no confiable

Como solía decir el célebre “maestro del suspenso” Alfred Hitchcock: “es lo que no vemos lo que en verdad nos asusta.” Imagine que es usted un usuario final a quien se le ha convocado a capacitación previa a la salida en productivo. Usted todavía no ha interactuado con el “sonado nuevo sistema ERP” y tiene tanto expectativas como dudas al respecto. Usted ha escuchado decir que en las pruebas el sistema ha funcionado muy bien, y cuando finalmente es su turno de ver las pantallas y comenzar a usar la nueva aplicación, el sistema se vuelve lento, se cae la conexión o es intermitente y usted no puede trabajar en él. Ve a los expertos que supuestamente debían impartir la capacitación, haciendo tiempo, hablando unos con otros, sentados frente a los monitores de sus computadoras tratando de arreglar la situación, para que la capacitación pueda comenzar. ¿A quién va a culpar alguien que no entiende mucho de Tecnologías de Información? ¡Exacto! Al nuevo sistema, no a la plataforma o infraestructura de TI que lo soporta.

Esto aplica también para sesiones de demostración (demos) a ejecutivos, pruebas integrales, o peor aún, salida en productivo. El efecto de esto es exponencial y el daño a la credibilidad de su nuevo ERP puede ser igualmente exponencial.

REMEDIO: La gente tiende a ser recelosa con aquello que no conoce o aquello en lo que no confía; por otro lado, hay cosas en las que uno sencillamente no puede escatimar. Por ello, desde un inicio asegúrese de que se ha contemplado para su proyecto la infraestructura que se va a necesitar, en el momento que se va a necesitar. Por medio de un dimensionamiento técnico de los recursos que demandará la nueva aplicación, hecho por profesionales expertos, puede usted mitigar este riesgo.

Organigrama y funciones no alineados con la nueva solución

Es lógico suponer que derivado de la implantación de una nueva tecnología, los procesos de la organización se verán modificados; pero por alguna razón, muy rara vez se contempla en el alcance de un proyecto, alinear la organización a los nuevos procesos. Si deja que esto ocurra espontáneamente, llevará demasiado tiempo y desgaste para su gente, quienes tendrán que lidiar con la incertidumbre, teniendo que “arreglárselas como puedan” e “inventar ellos mismos cómo hacerlo”; solo los más proactivos tratarán de poner un poco de orden desde su particular área o departamento, pero sin que eso sea el resultado de un esfuerzo integrado, ni mucho menos coordinado ni metodológico. Se comenzarán a generar por doquier políticas o prácticas que les faciliten un poco las cosas a las áreas que las han propuesto, pero que quizá le compliquen la existencia a otras. ¿Y quién, a los ojos de la gente será el culpable de semejantes padecimientos? Sí, lo ha adivinado, el nuevo sistema.

REMEDIO: Contemplar en el alcance el alinear la organización con base en los nuevos procesos derivados de la implantación tecnológica, aplicando una metodología probada, robusta e integral. El objetivo es claro, que todas las áreas sepan exactamente qué le toca hacer ahora a cada quién, sin “áreas grises” o dos personas siendo responsables de la misma cosa, pues un axioma de diseño organizacional dice, “cuando dos personas son responsables de la misma cosa, entonces nadie es responsable”.

La calidad de los datos a usar

Por alguna razón, las organizaciones tienden a subestimar y hasta a minimizar la necesidad de que su nuevo sistema ERP (en el cual estarán invirtiendo cantidades nada despreciables de dinero y recursos) cuente con datos limpios y correctos.

Cabe aclarar que desde el punto de vista de un sistema ERP, básicamente los datos son de dos tipos: datos maestros (catálogo de productos, catálogo de clientes, etc.) y datos transaccionales (facturas, notas de crédito, pedidos en tránsito, etc.) 

Visto de este modo, podemos ver que los datos son lo que hace funcionar a un sistema ERP como el combustible para el motor de un carro. No hace falta ser ingeniero mecánico automotriz para saber que sin combustible, el carro simplemente no se moverá, y que por otro lado, con un combustible de óptima calidad será capaz de desarrollar toda su potencia. Ahora que, con un combustible de dudosa calidad, con plomo, sedimentos y basuras, restos de otros líquidos como agua o aceites, ¿cómo cree que le irá al motor de ese carro?

REMEDIO: Tratándose de datos, no existen los atajos, y el volverle la espalda a un problema no lo hace desaparecer. El esfuerzo de asegurar la calidad de los datos bien puede representar un proyecto en paralelo a la implementación ERP; a decir verdad, en casos muy extremos, la labor de limpieza de datos puede llegar a ser tanto o más costosa que el mismo proyecto de implementación del nuevo sistema. Tome también en cuenta que el tener listos los datos no solo es necesario a la hora de salir en productivo, de hecho sería mucho mejor contar con al menos muestras de ellos desde las etapas de desarrollo o cuando menos en la etapa de pruebas integrales. Esa labor de ninguna manera es trivial, sino algo fundamental para el éxito de cualquier proyecto.

Sale del alcance de este artículo describir una estrategia de depuración o migración de datos; solo mencionaré que lo más pronto posible, incluso previo a iniciar el proyecto, debe buscar responder a estas simples preguntas:

  • ¿Cuáles de los datos de mi sistema actual es realmente indispensable que estén en el nuevo sistema? ¿Qué tan accesibles son en este momento?
  • ¿Cómo está la calidad de esos datos actuales? ¿Requieren limpieza (registros duplicados, obsoletos, incompletos)?
  • ¿Cuál es la mejor forma de cargar y/o migrar esos datos al nuevo sistema ERP?
  • ¿De quién es la responsabilidad de hacerlo?
  • ¿Cuándo se requiere que estén listos? ¿Esa fecha es factible?

 Debemos aceptar el hecho de que los datos no se van a arreglar por sí mismos simplemente por haber instalado una nueva solución ERP; y entre más pronto aceptemos eso y tomemos cartas en el asunto, mucho mejor. No vivimos en un mundo perfecto, y como dijo Napoleón Bonaparte una vez: “ningún plan sobrevive intacto el primer contacto con el oponente”, por eso es muy importante asegurarse de que tanto usted como su implementador sabrán cómo lidiar con estos ocho “dragones” si es que se presentan, pues lo más probable es que algunos (o todos) se encuentren acechando ya su siguiente proyecto.


Edición #64

Business transformation Edicion #64

Contenido

  • Ponga su negocio en movimiento, sea una empresa móvil
  • Cómo matar 8 dragones de una implementación ERP
  • Nuevos: SAP SimpleLogistics y SimpleFinance
  • Infrastructure Experts
  • En búsqueda de una transformación relevante
  • Transformando su negocio por medio del desarrollo de software
  • Key Performance Indicators
  • ¿Cómo seleccionar un buen aliado en servicios gestionados?
  • ¿Cuán segura es su pequeña o mediana empresa?
  • SmartNet Total Care
  • LENOVO XClarity
  • Geek