Tiempo estimado de lectura: 36 minutos
Una y otra vez se lee sobre intentos fallidos de sustituir un sistema mainframe que ha crecido durante décadas por una solución "pequeña" como Navision o Business Central.. Hay muchas razones para el fracaso. Y muchas son correctas, todas son innecesarias.
Si no tiene tiempo, vaya directamente a como hacerlo correctamente
¿Por qué? Navision / Business Central es el sustituto "natural" de cualquier solución SNI/Comet/AS400.
-> Porque Navision y Business Central siguen el mismo principio de orientación a los datos que, además del AS/400 con su DB2, también hizo de Clipper & Dbase, así como de Access, un modelo de éxito "por aquel entonces".
Ah... por cierto: sí, Access también es una aplicación basada en datos. Navision o Business Central también es un sustituto natural de las viejas y evolucionadas soluciones Access o Filemaker que ahora están sobrecargadas (porque son demasiado lentas). Bueno, y Excel como «solución empresarial universal. En realidad sólo debería tratarse de «sustituir y reemplazar lo más rápidamente posible, pase lo que pase».
La relación visual entre Access y Navision es tan grande que los primeros cursos de diseño para el nuevo generador de informes de Navision se hicieron con... Access 🙂 "Bajo el techo", por supuesto, Access no tiene nada que envidiar a Navision ni a Business Central. Ni entonces, ni mucho menos hoy en día.
Una razón simple para el fracaso es, por ejemplo, simplemente la presión del tiempo debido a la necesidad. La presión del tiempo surge, por ejemplo, porque ya no hay piezas para el AS400, nadie sabe «dónde se encuentra realmente este AS/400 en la empresa» (¡En serio! ¡Con experiencia!), o/y el anterior especialista interno en AS/400 o Crossbasic/Netbasic (antes Business Basic) por fin se jubila. O, también popular por la premura de tiempo: Porque ya se ha jubilado. En el mejor de los casos. En el peor, muerto.
Entonces se pone difícil encontrar un sustituto de acceso o de gama media. Se busca un socio con urgencia que "haga el cambio rápido, fácil y barato". ¿Y entonces? Todo se viene abajo. ¿Por qué? ¿Qué hacen los viejos ordenadores de gama media y mainframe de Lidl o Liqui-Molly , un Haribo, un Otto o una Deutschen Post mucho mejor o diferente que un moderno sistema de gestión de mercancías como Navision / Business Central en un hardware más o menos estandarizado de la tienda de bricolaje?
Spoiler alert: NO es la manera en que un AS400 integra elementos gráficos, correos o tiendas web. De todos modos, estas soluciones suelen reconocerse de inmediato como "bridas puestas" o "puestas encima" o "simplemente no se puede hacer de otro modo" (pero... ¡funcionan!).
Sustituir una plataforma de sistema basada en datos por una nueva solución también basada en datos, como Navision (Business Central), debería ser en realidad muy fácil? Puedo sustituir fácilmente una camioneta Mercedes por una Ford.
Entonces, ¿cuáles son los obstáculos que hacen fracasar los proyectos de sustitución de AS400, Access, Dbase o SNI Comet?
Relación temprana de AS400 & Navision Dynamics & Microsoft Business Central 365
En el mundo Business Central de hoy en día, esto sin duda ya no se sabe. Pero el servidor de bases de datos de Navision (en aquel entonces Navision Dynamics) ¡ya funcionaba de forma nativa en el AS/400!
Alrededor del año 2000, se ofreció una versión AS/400 del servidor de base de datos nativo Navision. Esta versión de Navision supuso una revolución en su momento, ¡y no pequeña! Mientras que los intentos de SQL 2.01 y 3.01 de Navision en aquel momento eran más bien lamentables («tortura» era también un término obvio), el AS/400 (AS400) dio al servidor de base de datos nativo de Navision (no existía Business Central en aquel momento) un increíble aumento de rendimiento. El servidor de base de datos nativo siempre ha sido increíblemente rápido, y Microsoft tuvo que esforzarse mucho para mapear gradualmente el modelo SIFT (el núcleo tecnológico de Flowfields) en el servidor SQL.
La base de datos nativa de Navision (¡en esencia todavía la versión de 1993!) estaba construida de forma muy sencilla. Su único problema en aquel momento: sólo podía bloquear tablas. Y debido a una garantía de contabilidad completa, cada proceso de contabilización comenzaba con un bloqueo de tabla en las posiciones de artículo (tabla 32) o en la tabla de posición de contabilización (tabla 17).
Esto significa: en cuanto alguien de la casa contabilizaba una hoja de entrada de contabilidad financiera, una hoja de entrada de artículos, una orden de compra o una factura de ventas, cualquier otro proceso de contabilización estaba condenado a esperar a que finalizara el proceso de contabilización anterior. Y unido a los errores mayores, menores y más pequeños de programador/diseño, todo el mundo en ventas se daba cuenta cuando la contabilidad financiera volvía a contabilizar los extractos bancarios. No tenía por qué ser así, pero también entonces había malos programadores de Navision 🙂 .
Y entonces llegó la versión del servidor de base de datos Navision nativo para AS400... lo cual, por cierto, no fue nada difícil: ya existía desde hacía tiempo un servidor Unix para Navision, por lo que el paso al i5 o al AS400 fue muy pequeño. Nada impedía sustituirlo o ampliarlo.
Y este servidor lo tenía todo. Mientras que 80-120 usuarios en una base de datos Navision se consideraba "bastante factible" (una paráfrasis de "casi"), con el AS400, Navision lanzó de repente 150, 200, 250 y, finalmente, 400 usuarios cada mes (Microsoft era "sólo" un socio estratégico hasta entonces, todavía no el proveedor del nombre). Sin un cambio en el código del programa Navision C/Side (CSide), el AS400 mostró el hardware de servidor establecido donde más se lleva el Barthel.
Y el servidor SQL de Microsoft no podía competir con este servidor de bases de datos nativo en Windows, Unix, OS/2 (¡sí, también había uno!) ni siquiera con el AS/400. Esta es la razón por la que esta rama en particular se interrumpió inmediatamente en el AS400 cuando Microsoft compró Navision en 2002. Y gradualmente todos los servidores nativos de Navision fueron reemplazados por un claro enfoque en el servidor MS-SQL. Una lástima.
Efectos de familiaridad y aversión a la pérdida
Como se ha descrito anteriormente, puede que simplemente sea necesario desde el punto de vista técnico u organizativo sustituir un sistema ERP existente (independientemente de si se trata de un AS400, Siemens Nixdorf, Quattro, Dbase, Oracle, Baan, Sage KHK, Lexware...) por una solución ERP moderna (Navision Financials Attain ya no está disponible como opción, así que esperemos que Microsoft Business Central 365 🙂 ). Y: Quizás esto ya lo tengan claro muchos empleados y más aún la dirección....
Pero: usted y su personal se han acostumbrado a la solución actual. Saben cómo pueden (o deben) tratar los errores existentes. Especialmente la dirección, pero también los empleados que llevan mucho tiempo en la empresa, suelen rehuir el reaprendizaje. Además, están todas las historias de ladrones que han oído en otras implantaciones de ERP. Quizás la experiencia con una implantación ya iniciada pero fallida de un nuevo sistema ERP también juegue un papel negativo en los sentimientos (emociones).
Teme el esfuerzo adicional, el cambio, otro fracaso, los gastos adicionales, las horas extraordinarias... tal vez incluso teme darse cuenta de que está montando un caballo muerto, y a un gran coste.
Esto nos lleva a...
Los puntos más importantes para el éxito de los sistemas anteriores
Los antiguos sistemas no eran ni mejores ni más mágicos que las técnicas disponibles hoy en día. La principal ventaja ya entonces era la profunda integración de la base de datos/gestión de datos en los lenguajes disponibles para la programación como Cobol y RPG bajo el System36 o AS400 (hoy System i) por parte de IBM y en el Business Basic por parte de Siemens Nixdorf Quattro Pro (con la planificación de recursos empresariales y contabilidad financiera Comet). Algo más moderno esto también se refiere a Access, algo más histórico también dBase, Filemaker & Clipper programas.
Independientemente de si se trata de sistemas de gestión de mercancías más modernos (como VLEX Plus) y, en algunos casos, de contabilidad financiera en el AS/400 (por ejemplo, la solución de gestión de almacenes de Manhattan Associates para IBM i (WMi), el sistema de gestión de mercancías BP de Baierl und Partner, el software ERP Frida de Command u Oxaion): Todos ellos se benefician de la profunda integración de DB2 o DB/400 en la solución global AS400 (o ISeries moderna).
Así que los desarrolladores de estos sistemas nunca tuvieron que preocuparse seriamente por la gestión de datos, el procesamiento de datos o la recuperación de datos: Los datos simplemente iban al archivo de datos (DB2 en el AS400, archivos en el SNI Quattro Pro). Y por orden, simplemente reaparecían, y en un orden predecible y predeterminable. Con los sistemas más antiguos de IBM y SNI con pantallas hoy muy viejas, pero rápidas y fiables.
Si ya ha tratado con Navision o Business Central, esto debería sonarle muy familiar: Especialmente en la versión Blue ("Dos-Navision") y en las versiones heredadas de Navision hasta Navision Dynamics 2009R2, Navision tiene exactamente la misma magia... o más bien la misma ventaja tecnológica que hizo que los programas Cobol & RPG reales y visibles para el operador del AS400 y el Business Basic de las aplicaciones (predominantes) Comet tuvieran tanto éxito, fueran tan fiables y (para aquellos tiempos) increíblemente rápidos.
Este parentesco de la programación basada en datos hace que la sustitución, una migración desde un Comet o un AS400 ¡sea tan inesperadamente fácil! ¿Todavía conoce dBase y Clipper? El mismo enfoque basado en datos también controla un AS400 y Navision / Business Central. Con Navision Financials Dynamics o Microsoft Business Central BC365, el SGA (sistema de gestión de almacenes) ya está incluido en el ERP - lo único que falta es la conexión comparativamente sencilla a un sistema de transporte.
Creado por informáticos
Esta tecnología básica, este almacenamiento de datos o base de datos (mapeada en el Siemens Nixdorf Quattro mediante llamadas en el sistema de archivos), fue desarrollada por mentes maestras de la informática como Edgar Codd .
Como la capacidad de cálculo y, sobre todo, el acceso a datos almacenados a largo plazo, como los discos duros, no estaban disponibles en cantidades ilimitadas en aquella época, estos sistemas de bases de datos se recortaron al máximo rendimiento del hardware subyacente, esencialmente no modificable. Del mismo modo que hoy en día los juegos de las videoconsolas se diseñan para explotar al máximo el hardware disponible.
 |
Con esto, los desarrolladores de sistemas, es decir, los arquitectos del System36, más tarde del AS400 y del SNI, construyeron los fundamentos para desarrollar programas eficaces y basados en datos. Cualquiera que construyera sobre estos fundamentos podía beneficiarse del complejísimo trabajo previo de los arquitectos de sistemas... si conocía y respetaba las limitaciones de los sistemas.
Modificado por expertos
Los sistemas de gestión de mercancías, contabilidad financiera y nóminas que más tarde se construyeron sobre estos fundamentos normalmente estaban al menos supervisados por expertos en los respectivos campos, cuando no programados ellos mismos.
Aquí no ha cambiado nada de mi declaración de los 90: Tengo más posibilidades de hacer un programador suficientemente bueno de un contable que un contable suficientemente bueno de un programador. Así era también en aquel tiempo, gracias al trabajo previo de los desarrolladores del sistema.
Las condiciones generales en las que se movían los programas en aquella época ya venían dadas por el modelo de base de datos del SNI Quattro o AS400. Ni siquiera era posible una modificación en determinados aspectos, por ejemplo, una consulta con o sin filtrado sin índice (una especificación de ordenación).
Por supuesto, aún se podía seleccionar un filtro erróneo o un índice inadecuado (clasificación por defecto). Pero el sistema lo castigaba con tiempos de respuesta desorbitados que hasta el peor programador se daba cuenta enseguida de que había metido la pata.
Hasta el día de hoy, esta es una razón para que de vez en cuando pruebe desarrollos en servidores con muy pocos núcleos y muy poca RAM. Si la caché o el hardware tienen que guardar lo que el programador/desarrollador ha doblado previamente, ya es demasiado tartde. Si te das cuenta de esto lo antes posible (pero tienes que haber tirado unas cuantas reglas básicas al viento de antemano.), al menos puedes guardarlo. Esto significa: puedes o debes reconsiderar el desarrollo.
Recortado para mayor eficiencia
Los sistemas antiguos, como un IBM AS400, un System36 o un SystemR, estaban, al igual que un Siemens Nixdorf Quattro, 8860 o 8870 con el sistema de gestión de mercancías Comet, coordinados entre sí desde el principio. Los desarrolladores conocían las condiciones marco, las limitaciones, pero por supuesto también las ingeniosas posibilidades de los sistemas. Como éstos se movían por estrechos carriles, el periodo de formación de los programadores era a menudo asombrosamente corto y la calidad de las aplicaciones escritas era a menudo (no siempre, por supuesto) de un nivel muy alto.
Debido a las especificaciones de los sistemas, también había una guía de usuario muy consistente. Desde el punto de vista actual, esto resulta anacrónico, un insulto al ojo y al dedo índice acostumbrado a los clics del ratón. Pero se reconocía sistemáticamente en todo el sistema. En todo Comet se aplicaba lo siguiente: F3 crea un nuevo registro de datos (pedido, cliente, condición de entrega), F4 borra un registro de datos. No importaba en qué programa te encontraras. Si todavía está familiarizado con "DOS-Navision" (la versión azul) o el "viejo Navision" (Windows-Navision desde la versión 1.3, 20.1 hasta la versión 2009R2), seguro que lo reconocerá 🙂 ...
Puede encontrar más información sobre este tema aquí.
Los errores más comunes de los nuevos sistemas
Se puede cometer un número increíble de errores. Pero los más comunes son los que se cometen al migrar/actualizar desde un antiguo sistema ERP que se va a sustituir. Esto no sólo se aplica a los viejos AS400, System i u otros programas basados en Cobol, RPG o Business Basic. Estos pecados capitales afectan a casi todas las migraciones de software. Sin embargo, por razones obvias, me referiré directamente a mi experiencia en operaciones de rescate de migraciones a Navision o Business Central 365.
Porque esto es un realidad: En mi tiempo como consultor autónomo (freelance) de Navision / Business Central, formador, programador, experto, nunca me han llamado para una migración de Navision / Business Central (BC). Sólo me han buscado y encontrado cuando en realidad era demasiado tarde.
Sólo en ese caso, según mi experiencia, los responsables de la toma de decisiones están dispuestos a escuchar mis conceptos. En muchas ocasiones, el resultado era un comienzo completamente nuevo.
Uso de "soluciones industriales"
El pecado capital por excelencia. De verdad. Desde que tengo contacto con Navision, y esto es desde 1993, sólo he sufrido con estas "soluciones industriales". Por eso aquí sólo utilizo este término entre comillas.
¿Por qué pienso tan poco de estas "soluciones industriales"? Hay que saber lo siguiente:
¿Cómo se crean las "soluciones industriales"?
Navision / Business Central "out of the box" ya puede hacer una cantidad increíble de cosas: entrada de pedidos, gestión de inventario en cualquier número de almacenes, direcciones de entrega ilimitadas, transferencias de existencias incluso entre naves ("sitios de la empresa"), contabilidad de costes, contabilidad dimensional (centros de coste y unidades de coste. Esto es algo para principiantes como Datev, Diamand, H&S... ¡Navision / Business Central ha sido capaz de manejar cualquier número de dimensiones contables durante décadas! No sólo 2. Podría dedicar un día entero sólo a esto... ¡Esto no tiene rival en el mundo de la contabilidad financiera!!), cálculos de precios complicados (¡pero en realidad no hay cálculo de márgenes en el estándar!), liquidaciones de agentes, evaluaciones, análisis ABC (bueno... con ajustes mínimos).
Navision / Business Central puede imprimir facturas "out of the box", enviar albaranes por correo, las nuevas versiones a partir del RTC pueden crear directamente PDFs y correos desde la aplicación (las antiguas también, con un poco de ayuda…).
La (desde mi punto de vista) mejor, más simple y más eficiente contabilidad financiera también está siempre ahí.
Así que cada vendedor de Navision o consultor de Business Central y cada casa de sistemas puede crecer así. De todos modos, siempre está ahí, ¡y siempre funciona! Desde el principio. Sólo tiene que instalarlo y podrá -en principio- gestionar una empresa según GOB por primera vez. Incluso la logica GdPDU esta preparada. El sistema conoce UVA's. Configurarlo un poco, tal vez poner en un SKR03 real o SKR04, y ya está.
Y entonces un comerciante de madera, un vendedor de coches, un carnicero, un productor de alimentos, una empresa de gestión de edificios viene a una casa de sistemas y dice: "Todo eso está muy bien, pero seguimos necesitando la siguiente función:"
Y la casa de sistemas dijo: OK, dénos dinero por ello, entonces adaptaremos su Navision Dynamics o Microsoft Business Central exactamente a estos deseos, para que ambos estemos contentos.
Y el cliente daba dinero. Y la casa del sistema hizo lo que se le dijo. Y ambos vivieron felices para siempre hasta que...
...Sí. Aquí es donde empieza la miseria. La casa del sistema pensó: Oooh, así que tenemos adaptaciones demasiado regordetas de la variedad poderosa. ¿Podemos convertirlas en oro otra vez? Y la casa del sistema dice: Tenemos una "solución industrial" para los vendedores de coches/carniceros/madera/comercio inmobiliario...
Pero en la mayoría de los casos ocurría que la casa de sistemas no tenía conocimientos básicos de esta industria. ¿Cómo podían hacerlo? Al fin, sólo realizaban los ajustes en 2-20 semanas que el cliente solicitaba de forma más o menos cualificada. Y la casa de sistemas los aplicaba de forma más o menos cualificada.
Y entonces pasó lo que tenía que pasar: El siguiente cliente llega, lee el anuncio "solución industrial" y... ¡compra!
Entonces, el cliente se da cuenta rápida y dolorosamente de que los procesos empresariales que propuso su predecesor (¿se acuerda? El primer cliente especializado de la casa de sistemas...) no se ajustan en absoluto a él. Esto causa problemas y ajustes adicionales y, por tanto, costes adicionales. Llega un momento en que todo se va al carajo.
Ahora la casa de sistemas tiene una "solución industrial" que cada vez tiene menos que ver con el elegante, rápido y sin errores Navision o Business Central que Microsoft grabó en su día en el DVD.
Pero eso no molesta al vendedor de BC. Ha olido el aire de la mañana, o más exactamente: el dinero. Y que alguien lo repita: el dinero no apesta. Y así llega otro cliente, dejando un sistema aún más torcido para los siguientes clientes.
Mientras tanto, los desarrolladores se cambian en la casa del sistema, los programadores inexpertos rompen aún más, etc. etc.
Es precisamente otra como se crean las "soluciones industriales".
¿Cuál es el problema de las "soluciones industriales"?
Pretenden ser capaces de mapear los problemas de toda una industria en un único paquete. Sin embargo, estos paquetes se han alejado demasiado del Navision / Business Central original, y contienen terribles errores de programación bajo la superficie (pero a veces también directamente visibles), que se están extendiendo en cada vez más instalaciones de clientes.
Además, el mercado, el cliente y la casa de sistemas tienden a sobrecargar a los clientes. Puede que el vigésimo vendedor de coches sólo necesite un pequeño ajuste del estándar exactamente para sus procedimientos (procesos). Pero se le sirve un Navision o Business Central 365 con errores, y ahora se supone que debe hacerse amigo de él.
¡No va a funcionar!
Esta es una especialidad del mercado de Navision / Business Central! En el pasado, las soluciones industriales eran creadas por desarrolladores cualificados que se sentaban con consultores cualificados y clientes seleccionados, analizaban los detalles específicos del sector y luego los aplicaban de forma muy específica.
Por lo general, una empresa de software sólo tiene capacidad suficiente para dar soporte a un único sector, por ejemplo, peluquerías, talleres de reparación de coches, artesanos o bancos. Así, por parte del proveedor de software, se acumuló una enorme experiencia del sector respectivo.
Muchas veces, expertos del sector respectivo trabajan o trabajaban directamente en la casa de software para mediar entre clientes y desarrolladores, o para traducir. No todo era mejor en el pasado. En realidad, si somos sinceros, muy pocas cosas eran mejores. Excepto quizá el domingo. Antes era domingo, ahora es lunes. Pero este hecho de que los paquetes de la industria, que se puede escribir sin ", realmente se adaptaba a la industria respectiva: ESTO si era mejor.
Hoy en día - y especialmente en el entorno Navision / Business Central - se ha convertido esencialmente en: "Ya hemos atendido a uno o dos clientes de este sector". Aunque ninguno de los empleados siga trabajando en la casa de sistemas. Y los "conocimientos específicos del sector" se han reducido a "hay mucho dinero que ganar".
Uso de programadores en lugar de informáticos
En efecto, no se trata de una objeción, sino de una gran diferencia. Los sistemas básicos anteriores (por ejemplo, Navision / Business Central "out of the box", Trampolin, aswaw400 (as/waw 400), Oxaion, Portolan, Perform, LFS400, Charisma, Assistent... en el AS400, Comet (¿había alguna alternativa? ) en el Siemens Nixdorf Quattro Pro 8870, 8860 con Business Basic (o los derivados Cross Basic, Surfbasic y NetBasic) o sistemas completamente diferentes como Steeb, fueron y son desarrollados como versiones básicas en estrecha colaboración entre especialistas en aplicaciones e informáticos.
De acuerdo, Microsoft está desgarrado, se nota en la calidad y en el (in)sentido de las nuevas funciones.
Así, las versiones básicas de los respectivos sistemas de gestión de mercancías eran (y, de hecho, son) muy ágiles y estables.
Sólo con la modificación de los programadores, que ya no conocen muchos de los fundamentos de la informática, estos sistemas se vuelven más lentos y propensos a errores.
Esto no era ni es un gran problema en las algunas empresas.
Si el "dios de la informática" hace un rasguño en "su" planificación de recursos empresariales o contabilidad financiera (ERP) con un destornillador, (normalmente) puede entender muy bien cuál ha sido la causa y revertir o corregir su cambio.
Pero si un programador que no conoce el contexto de un cambio y que aún no ha entendido la aplicación básica, por ejemplo Navision o Business Central, hace un cambio de este tipo... ¡Caramba! ....
Y si este cambio luego tiene errores no visibles y estos se entregan a muchos clientes.... ¡Oh cielos!...
Y cuando este programador se vaya de la casa del sistema y un sucesor aún menos experimentado siga retocando estos programas ya rotos... ¡Oh, cielos! ¡Oh, Dios! ¡Oh, Dios!...
Uso de vendedores en lugar de asesores
En el pasado, estos sistemas eran vendidos por los clásicos "vendedores de neveras en el polo norte". En lugar de eso, el cliente pedía una cita para una demostración y las primeras conversaciones ya se mantenían con especialistas, asesores expertos, que conocían su producto de cabo a rabo. De este modo, las expectativas del cliente se corrigieron inmediatamente a lo que era factible y los requisitos (de modificación) también se corrigieron a lo que era razonable, asequible y factible desde un punto de vista realista. De este modo, la conclusión del contrato ya podía aclarar para ambas partes lo que se entregaría. Y también: Que no.
Por desgracia, los elevados márgenes de contribución que eran habituales en la venta de software en los años 90 también atrajeron a vendedores que no entendían el producto real, que no entendían al cliente y que no podían mediar entre el cliente y el desarrollador. Al cliente se le prometía (y se le promete) la luna... y al desarrollador se le dice: ya lo harás tú. Eso debe dejar tierra quemada... y eso es exactamente lo que hace a menudo.
No es raro que los clientes busquen su salvación contratando ellos mismos al programador, irremediablemente sobrecargado, para ahorrar lo que aún se pueda ahorrar. Y en la casa de sistemas se contrata a un nuevo programador inexperto, quizá unos euros más barato, que no tiene ni idea de Navision / Business Central (todavía)... y tampoco de la "solución sectorial". ¡Bingo!
Tiene que volver a ser como antes
La tozudez (aquí apenas hay un buen eufemismo, a veces hay que recurrir al "fanatismo") de los anteriores usuarios de mainframe, ya sea AS400, Comet o Quattro Pro, también es legendaria en este tipo de proyectos.
"Sí, claro que queremos que todo sea moderno y realmente bonito. Por favor, avísenos. Pero al final todo tiene que ser como antes, si no, no podemos trabajar". Como ve, prefiero utilizar palabras sinceras en lugar de irme por las ramas.
Mi experiencia más reciente a este respecto fue en una fábrica de papel de la región de Kassel. Después de configurar los formularios de facturación en Navision, se escribieron algunas facturas de prueba. Casi todas con uno o pocos céntimos de desviación. Eso resultó ser una larga tarde...
Después de varias horas por fin encontré el error: El Siemens Nixdorf Quattro Pro, con Comet por supuesto, ¡estaba calculando mal! Tenía un error de cálculo no descubierto hasta entonces con los descuentos por grupo. Pude calcularlo con una calculadora en las facturas originales.
El comentario del director: "Siempre lo hemos hecho así, tenemos que seguir haciéndolo así". Tiré los bolígrafos y los impresos a un lado y, a partir de entonces, puse en práctica todo lo que el director quería que fuera "como antes". Y no hice más sugerencias de mejora.
Con y por personas que se resisten a recibir consejos no debes perder tiempo. De todos modos, no se les da las gracias y no se puede cambiar nada en esas empresas. Esta forma de pensar siempre se extiende por toda la empresa, esa es mi observación.
Por supuesto, también puede introducir con éxito Navision / Business Central en este tipo de empresas. Especialmente las herramientas hasta BC 14 hacen estos productos más adecuados que cualquier competidor en el mercado. El proyecto que se acaba de describir también se implementó y el error descrito todavía está incorporado en la versión 2013 de Navision en 2022. En ningún otro lugar he experimentado este "siempre lo hemos hecho así" de forma tan inflexible como entre los usuarios de sistemas mainframe.
Aquí usted, como cliente, tiene que hacerse la siguiente pregunta: "¿Realmente queremos que todo vuelva a ser como antes?". Le costará muchos euros más, prolongará considerablemente el cambio y su sistema se volverá -como antes, como "siempre ha sido así"- prácticamente imposible de actualizar. No importa lo que le hayan prometido o prometiera antes.
Desde Business Central 15, algunas de las cosas más apreciadas de su antiguo AS400 o Siemens Nixdorf Quattro Pro Comet simplemente ya no se podrán implementar dentro de la aplicación básica. Aquí, incluso un pequeño "esto tiene que volver a ser como antes" puede suponer un esfuerzo increíble para el desarrollador. Se puede conseguir mucho por dinero...
Al fin como consultor también tengo que ser justo y verlo desde la perspectiva de los anteriores usuarios del mainframe: Los bólidos del sótano han estado trabajando con cambios mínimos a menudo durante décadas "exactamente de esta manera en que siempre lo hemos hecho" y toda la empresa se ha asentado a su alrededor. Esto introduce formas de trabajar y soluciones y las solidifica de una manera que a menudo es ajena a los desarrolladores de Navision / Business Central.
En "nuestro" mundo, vivimos de la dinámica y el cambio, no del "siempre lo hemos hecho así". En una sustitución de mainframe, por tanto, chocan verdaderos mundos paradigmáticos. Aquí es tanto más importante abordar de antemano los puntos fuertes y débiles y también señalar las imposibilidades. Todo lo que se descuide en la fase previa caerá después sobre los hombros de los socios del proyecto.
La OPORTUNIDAD a través de un cambio, una nueva introducción
Si ha llegado hasta aquí, es que ya ha pensado en ello. Sus clientes quieren facturas en PDF o archivos EDIfact. Su tienda web parece casera... y quizá lo sea. Los nuevos empleados tardan una eternidad en aprender combinaciones numéricas inútiles, abreviaturas poco intuitivas, complicadas soluciones para errores conocidos. Es posible que ya no puedan hacer copias de seguridad de los datos porque hay un error perpetuo acechando en la base de datos. No pueden cambiar a la tecnología PC o a un sistema operativo moderno por razones técnicas. Necesita nuevas interfaces para los informes, o tiene que hacer diversas soluciones y evaluaciones en Excel o Word. Puede que incluso tenga en casa a un consultor de gestión que le haya descrito claramente con palabras muchos de los cuellos de botella de su TI actual... O que usted mismo haya reconocido exactamente esto durante un cambio de perspectiva: Su TI está anticuada, su empresa se resiente de ello, su competidor le huye, le arrebata clientes con mejores servicios, mejores prestaciones. O sus empleados necesitan tanto tiempo para ocuparse de las deficiencias de su TI que usted necesita nuevo personal administrativo sólo por este motivo. Estos análisis sugieren que debe modernizar su entorno informático y la planificación de recursos de su empresa.
Y así no preguntamos...
¿Cómo hacerlo correctamente?
En realidad, el resumen es sencillo: Un poco de humildad. Un poco de humildad ante el sistema crecido que se va a sustituir. Pero también ante el nuevo sistema (que se va a utilizar), por ejemplo (pero no sólo) Navision o Microsoft Business Central 365. A partir de ahí, todo lo demás se sigue casi solo. Por ejemplo:
Respeto por la TI
Asegúrese de obtener el apoyo de su supervisor de TI. Atención. No tiene por qué ser necesariamente el responsable de PED. Averigüe quién ayuda realmente y puede ayudar cuando no se puede reservar un trabajo. Sus compañeros de trabajo suelen saberlo. El énfasis está en conempleados.Supervisores muchas veces ya no tienen suficiente conexión con el trabajo. Por eso se les llama líderes y no trabajadores. También en este caso la excepción confirma la regla.
Si el informático está muy interesado en el nuevo sistema de gestión de mercancías
¡Qué suerte tienes!
Esto ocurre muy raramente (véase el punto siguiente). Manténgalo en línea. Dele responsabilidad en los proyectos. Dele responsabilidades. Inclúyale en todas las reuniones. Envíele a cursos de formación. No intentes "derribarle" con el nuevo sistema ERP sólo porque tu vendedor (véase más arriba) te haya dicho que "no necesitarás TI en el futuro", ahora todo es mucho más barato en la nube.“
Esta promesa nunca se cumple. Nunca.
Si el responsable informático no está nada interesado en el nuevo ERP
Esta suele ser la situación inicial. Posiblemente ya condicionada por la edad de su responsable informático. A menudo, estas sustituciones de soluciones antiguas sólo se desencadenan por la inminente jubilación del anterior responsable de TI. A veces también después.
Durante décadas, el mantenimiento y la modernización de las TI se han dejado en un segundo plano, se han tomado a la ligera. Y entonces llega el mensaje: "Eh, jefe, ¿aún estoy invitado a la próxima fiesta de Navidad?
"Por que?"
"Porque para entonces ya estaré jubilado. Y, ¿quién va a ser mi sucesor?".
Y la cabaña ya está en llamas. Y ahora, muy rápidamente, con todas tus fuerzas, instala un sistema sucesor... Pero con un comienzo lento. Hasta que sea demasiado tarde. Ya sabes cómo es...
Y este empleado entonces dice: "Oh, soy demasiado viejo para esta mierda". O "Ya no necesito esto, el año que viene me habré ido". O algo similar.
Y tú te quedas ahí, dependiendo de los conocimientos -a menudo inexistentes- de tu nuevo "experto en soluciones sectoriales".
Guarde la buena voluntad de su anterior supervisor de PED. Ofrécele un contrato de consultoría. Un viaje de 3 meses a las Maldivas cuando el nuevo sistema esté en marcha. Un coche de empresa durante los 2 primeros años de jubilación. Lo que sea: manténgalo a bordo, utilice su experiencia para su proyecto. Deje que los recién llegados que van a sustituir a un ERP que ha crecido durante décadas aprendan de él en pocas semanas.
Cada centavo que intente ahorrar en este punto se lo pagará multiplicado por diez a su casa de sistemas en el transcurso del proyecto.
Sin embargo, también se da la situación (ya vivida) de que una empresa quiera aprovechar precisamente esta oportunidad para liberarse del poder del anterior responsable informático. Eso también es posible. Entonces sólo hay que poner la energía suficiente para encontrar a la gente buena en la empresa.
Respeto por los empleados
Sus empleados, sobre todo los que trabajan de verdad, han acumulado mucha experiencia sobre sus procesos durante años. A menudo han encontrado soluciones que ni siquiera el responsable de TI conoce. Tal vez hayan externalizado procesos a hojas de cálculo Excel ("TI en la sombra") que ahora urge incorporar a la nueva planificación de recursos empresariales. Integre a sus mejores empleados (primero tiene que identificarlos...) en el proceso del proyecto.
Respeto por los procesos de trabajo
Los programadores no suelen entender nada de sus procedimientos / procesos. Sólo leen la descripción del trabajo del vendedor (véase más arriba) y luego programan lo que han entendido de ella.
¿Le gustaba jugar de niño a "Silent Post" y morirse de risa al final?
Un jefe de departamento que no vive los procesos explica a un comercial que no conoce la empresa cómo hay que hacer una tarea. El comercial que no conoce ni su empresa ni Navision / Business Central explica a un programador, que apenas conoce ninguna de las dos cosas, lo que tiene que hacer. Y este pobre programador siempre es el culpable al final cuando el resultado no tiene mucho que ver con la realidad.
Post silencioso para adultos y con dinero en juego....
Respeto de su propia aplicación
Especialmente como joven, me pica el deseo de mostrar al cliente lo buenos que son Navision Dynamics y Business Central en comparación con las antiguas aplicaciones Comet y AS400.
"Claro que lo haremos, será rápido".
Es muy fácil perderse en esto.
Prácticamente todos los desarrolladores de Navision que han trabajado para más de dos empresas han ampliado alguna vez el campo de descripción del artículo. Y durante semanas, meses o años, han caído ante sus pies algunas hojas de contabilidad que tenían un problema con él.
También era bastante fácil desactivar "Datos por empresa", por ejemplo, para la tabla de clientes 18 o la tabla de cuentas de mayor 15 o, muy popular, la tabla de artículos 27. Y sólo en el transcurso del proyecto, el desarrollador más entusiasta se dio cuenta del enorme desastre que él (o ella) había iniciado en realidad.
Afortunadamente, Microsoft ha puesto fin a esta situación. Desgraciadamente con daños colaterales masivos, de modo que ahora la (casi siempre necesaria) visualización de nombre 2 & descripción 2 en docenas de páginas es trabajo de un día...y un buen ejercicio de dedos para los primeros pasos de extensión.
Respeto del servidor de bases de datos
Seré valiente: el 90% de las personas que realizan ajustes en Navision o Business Central no tienen ni idea de cómo el servidor de base de datos recopila los datos necesarios. Valiente, porque creo que el 90% sigue siendo muy poco.
"Transacciones": Quien no conozca esta palabra no debe sorprenderse cuando incluso cambios supuestamente pequeños en un campo de flujo, una página, una tecla a partir de entonces retrasan todo el ERP. Y quien piense que una "transacción" es una manipulación de datos agrupados que sólo puede realizarse en su totalidad o no realizarse en absoluto, está confundiendo la diferencia entre transacciones de base de datos/disco duro/reservas.
Respeto a la regla de oro
En general, no sólo para AS/400 (as400), RPG, Cobol, Navision, Comet, se pueden obtener básicamente 3 tipos de calidad de servicio en el mercado:
- Bien
- Barato
- Rapido
Dentro de ciertos límites, puede comprar estas combinaciones en el mercado:
- Bien & Baratono es Rápido.
- Bien & Rapidono es Barato.
- Rapido & Baratono es Bueno.
- Bien, Rapido & Baratono es posible.
Cuestionar críticamente la propia aplicación y los procesos anteriores
No es casualidad ni arbitrariedad que este artículo aparezca en último lugar.
La calidad de Navision / Business Central también es cada vez peor, 100% compatible con Microsoft.
Flowfields en listas, ordenación arbitraria en tablas arbitrarias, emulación de claves sin retroalimentación al desarrollador: sí, técnicamente es genial que esto sea posible. Pero no es posible en una empresa real.
A menudo se dice: "El hardware es demasiado débil".
No es No. Los requisitos son sencillamente poco realistas.
¿Reservación?¡Qué molesto! ¿Cómo se ha podido llegar a esto, a profundizar tanto en un mal sistema?
Regulación de los rodamientos? Una obra desde hace 20 años. Ver también gleitender-einstandspreis-in-navision-business-central
¿Facturaanticipada? Siempre puede ser más complicado, debió de pensar alguien... y luego lo complicó aún más. ¡Y eso sin contar con el impuesto mínimo ACT! Para el 98% de los clientes basta con una confirmación de pedido, en la que la palabra "confirmación de pedido" puede cambiarse por las palabras "factura pro forma". Incluso para las entregas en el extranjero.
Salario... Una obra eterna. Un apunte muy muy serio: No hagas salarios en Navision. No. No lo hagáis. Nunca!
OCI & EDIfact? ¿Alguien conoce todavía el servidor BizzTalk de Microsoft? ¿Existe todavía? Todo basura. Microsoft nunca ha tenido una solución EDIfact adecuada. Otros pueden hacerlo mejor.
A pesar de todo el entusiasmo por Navision Dynamics o Business Central, hay que ser consciente de que este gran sistema tiene sus límites. Y es mejor saber cuáles son esos límites.
Pero lo fantástico es que esto no se aplica a la migración de programas AS/400 (as400) o Comet, ¡ya sea desde RPG, Cobol o BusinessBasic (NETbasic, CrossBasic)! ¡Incluso antiguos programas dBase y Clipper! ¡Lo que estos sistemas antiguos podían hacer, Navision y Business Central lo pueden hacer desde hace mucho tiempo!
Y si no: Dynamics y Business Central se hicieron para coser rápida y eficazmente los "bordes de oro que faltaban" a la supergestión de mercancías y a la hermosa contabilidad financiera.
Créeme.
(Imagen aportada por MHMcCabe)
Tiempo estimado de lectura: 36 minutos
Español 
Deutsch 
English