Desde estas líneas hemos dedicado amplio espacio y varias notas a los sistemas del tipo ERP, de Programación de los Recursos Empresariales o más simplemente de Gestión Empresaria.
No hace falta aclarar el que decididamente promovemos la aplicación e implementación de tal tipo de herramientas informáticas. El compartir la información haciendo que toda transacción y/o cambio de circunstancia se refleje en todos los rincones del quehacer de la organización, asegura la coherencia intrínseca de la información. Lo cual, cuando la información es correcta, es sin duda una significativa ventaja.
Pero esta misma fortaleza de los sistemas ERP que es su coherencia, puede ser también su mayor debilidad. Efectivamente:
- Cuando algo no funciona, NADA funciona. (Si bien algunos paquetes de estructura modular permiten seguir operando algunos módulos aunque otros estén caídos).
- Es difícil descubrir un dato erróneo, ya que la información fallada sigue siendo intrínsecamente coherente. Un típico fallo de este tipo, que suele descubrirse tardíamente en la línea de producción es un error de unidades: Se compran 3000 gramos de xxx cuando lo requerido eran 2800 kilos y es muy probable que confiando en el sistema nadie se dé cuenta.
Por otra parte, tal como ocurre en el mundo profesional, hay sistemas especialistas y generalistas. El ERP es claramente un generalista. Pero si necesito optimizar la gestión de un aspecto en particular de mi negocio, es posible que necesite de un (software) especialista, uno que resuelva una sola cuestión, y lo haga excepcionalmente bien. Y no EN VEZ DE mi ERP central – ya que dejaríamos de lado las ventajas de la coherencia intrínseca de la información, sino JUNTO CON el ERP, y en lo posible compartiendo información con aquel.
Los grandes capítulos en los que estos sistemas satélite ofrecen indudables ventajas son:
- Los sistemas de gestión específica de recursos, tales como:
- Sistemas de almacenamiento autoorganizado, depósitos caóticos
- Sistemas de gestión de matrices y herramentales
- Sistemas de gestión de proyectos complejos
- Sistemas de secuenciación de carga de máquinas
- Etc.
- Los sistemas de simulación de situaciones para la toma de decisiones, como por ejemplo:
- Sistemas de análisis de costos, prorrateo por centros de costos, contribución marginal a la cobertura.
- Analisis y simulación de proyectos de inversión complejos con su correspondiente flujo proyectado de fondos.
- Los sistemas específicos de gestión de la información y en particular de la ‘gestión del conocimiento’. Los sistemas de gestión de la calidad tipo ISO 9000 son un caso paradigmático, pero no el único.
Debe señalarse que varios de los ERP modernos estuvieron y están avanzando sobre los tres capítulos, con éxito variado.
El proveedor informático que se rehusa a implementar o desarrollar nuestro requerimiento es el que probablemente adopte la posición más segura, técnicamente hablando. Efectivamente, cualquier intervención en un sistema complejo, donde todo está relacionado con todo, es probable que debilite la estructura y produzca algún fallo … en otra parte. Sin embargo esta especie está en vías de extinción, probablemente porque son cada vez más los clientes que pretenden una solución ‘taylormade’, a su medida.
El proveedor que acepta el desafío, habitualmente cotiza una cifra abultada, y demora meses o años no tanto en el desarrollo requerido en sí mismo como en depurar todos los errores indirectos que se produjeron como consecuencia de la intervención.
El verdadero problema con este proveedor que tiene ‘el si más facil’ es que no solo acepta nuestros requerimientos y desafíos, sino también los de todos sus restantes clientes y usuarios. Con lo que puede suceder – y de hecho ocurre – que con una actualización rutinaria de versión, que inocentemente incluye una mejora solicitada por algún usuario a quien nosotros ni siquiera conocemos ni sabemos de su existencia, algún proceso esencial para nosotros deja de funcionar. Habitualmente 30 minutos antes del vencimiento, pero esto ya es el corolario número 27 de la Ley de Murphy: “Todo contratiempo ocurre en el preciso instante en que maximiza el daño” .
Así planteado pareciera que las únicas alternativas que quedan son:
- Convivir con el enlatado y complementarlo con planillas de cálculo.
- Bancarnos el ‘Puede fallar’.
Los que siguen estas notas saben de las reservas que expresamos frente a las planillas de cálculo:
- Que son esencialmente monousuarias y no permiten compartir la información. Lo cual no sería grave si no fuera tan fácil generar una copia, la que a partir del momento de la ‘clonacion’ adquiere vida y desarrollo propio. Con lo que al poco tiempo dos planillas que nacieron juntas presentan información radicalmente distinta.
- Que la información de base es estática; no se actualiza automáticamente con ningún tipo de novedades.
- Que su misma flexibilidad las hace esencialmente inseguras.
Van entonces unos ‘tips’ que ayuden a trabajar con su ERP central y al mismo tiempo incorporar desarrollos específicos que refuercen las ventajas competitivas de su negocio:
- Maneje toda la rutina con su ERP central. Cuanto más rígido, mejor, siempre que cubra integramente toda la normativa legal y fiscal vigente. Si su ERP no permite facturación electrónica on line o no le calcula automáticamente las retenciones de ganancias, tírelo a la basura (al ERP, no al programador)
- Asegurese de que el ERP permite exportar datos en planillas libremente configurables. No importa cuál sea el formato, si es de hoja de cálculo, de textos fijos o delimitados, etc; lo importante es que sin recurrir al especialista pueda exportar información del ERP. Si hay una opción de ‘schedulear’ esta facilidad, tipo ‘todos los días a las 19:00 hs generame la planilla xxx’, mejor. Y con una ‘alarma estridente’ que me avise si la operación falló.
- Desarrolle o haga desarrollar su aplicación específica, tomando los datos de los archivos de transferencia del punto ‘2)’, respetando los siguientes principios:
a) Su aplicación cubre algún aspecto específico de su negocio, que significa una real ventaja competitiva.
b) Tome la info del ERP central unicamente a través de los archivos de transferencia del ERP. Por más que el programador prometa que los puede tomar directamente de la base de datos central … eso funciona mientras el ERP no cambia su formato interno; y le aseguro que eso ocurre y con frecuencia.
c) Navegue siempre aguas abajo. Esto significa que nunca, pero NUNCA,NUNCA, introduzca información en el ERP. Salvo a través de los importadores que muchos paquetes ya incluyen como standard.
d) La aplicación específica debe desarrollarse como multiusuario y de procesamiento concurrente. Para que aún dentro de ella pueda compartirse la información y los usuarios dejen de aferrarse a las planillas de cálculo.
En resumen, es recomendable complementar el sistema de gestión central con utilidades específicas, en vez de adecuar el sistema central con el riesgo de debilitamiento y fallo que ello significa.
Por último, los desarrollos específicos son tarea de especialistas en lo conceptual de la aplicación a desarrollar. Si se lo encargamos al proveedor del ERP, difícilmente se resistirá a meterlo dentro del sistema central. Y nuevamente estaremos comprando tendencia al fallo.