Desconozco si se hicieron analisis para determinar cual software nos convenia o no, pero se decidio implementar el Microsoft Dynamics AX 2009, para ello, se contacto (tambien desconozco cómo) a una empresa consultora partner de Microsoft (cual debe ser) de la ciudad de Guadalajara.
Empezamos del planteamiento de que el software que actualmente usamos esta limitado y nos cuesta trabajo que siga el ritmo de las necesidades actuales de la compañia. Este software es hecho en casa, por un equipo de 4 ingenieros en sistemas en un trabajo que ha llevado 7 años, desde su analisis, diseño, programacion, implementacion y mantenimiento y mejora. Se entiende que un proyecto de esta naturaleza en realidad no termina nunca, porque siempre se tiene a la mano el codigo fuente para poder hacer modificaciones o mejoras y el personal de desarrollo conoce a la perfeccion las reglas de negocio (incluso, ellos se pudieron haber diseñado algunas) y de operacion de cada area funcional.
Reconociendo que este trabajo no estaba terminado, faltaba por integrar el registro contable y el calculo de la nomina, para ello, se cuenta con sistemas administrativos comerciales.
Digamos entonces que bajo esta optica es cuestionable la necesidad de cambiar de ERP, sin embargo, la estrategia empresarial requiere de mayor dinamismo en la disponibilidad de la informacion, y mas cuanto la base actual permite imaginar indicadores que rayan en la aplicacion de la inteligencia de negocios (Bussines Intelligence), por lo que podriamos considerar como valido que se tomara esta decision.
Otra opcion pudo haber sido fortalecer al Area de TI de la empresa, potenciar el conocimiento que ya se tenia, proporcionar nuevas herrmientas y hacer una reingenieria del ERP. sin embargo, esto no fue considerado por la cupula directiva.
Se inician los trabajos de analisis del negocio por parte de los consultores, se firma un contrato y arrancamos todos con muchos brios.
Inicia el proceso de intercambio de informacion, visitas, cotizaciones de equipo, elaboracion de cronogramas y una serie de reuniones para coordinar el arranque del proyecto.
Finalmente, se llega el momento en el que la empresa consultora da a conocer el Cronograma de actividades para la implementacion del sistema. Un proyecto que en teoria debe durar 4 meses, a solicitud nuestra se pide que sean 6 meses, esto debido a que se atraviesan eventos importantes en la compañia y se empalman con la fecha del arranque, pudiendo entonces ocasionar un caos al momento de iniciar operaciones.
Decidimos ver el lado positivo de esta circunstancia el cual deberia traducirse en una disminucion de estres y carga de trabajo.
Durante una semana los consultores se entrevistaron con representantes de todas las areas funcionales de la empresa, pidieron que previamente se llenaran unos documentos que describieran cada uno de los procesos criticos, acompañados de un diagrama de flujo que pemitiera visualizar todos los posibles escenarios. esta informacion fue entregada en cada entrevista. Tambien se les mostro a ellos en directo como funciona el proceso de produccion, desde el corte, hasta el emsable de piezas y el control de informacion de los productos terminados. se pone especial enfasis en el costo de produccion y en los indicadores que se obtienen actualmente y que permiten medir la eficiencia, costo y productividad de cada uno de los departamentos del piso de produccion.
Al final de la semana, los consultores se llevan los documentos y empiezan a elaborar uno mas complejo que describira como esos procesos seran administrador por el nuevo software.
Al paso de unas semanas, se presenta una tabla que indica para cada proceso si es necesario hacer modificaciones al sistema para adecuarlo o bien las funciones estandar del mismo pueden cubirlo.
Segun este analisis, fueron muy pocos los procesos que deben ser modificados.
Cabe mencionar, que para este momento, ya se habia formado un equipo de implementacion del proyecto, que recibio un curso de manejo del software, este curso duro una semana, en sesiones de aprox 9 horas diarias, y que abarco temas como la configuracion basica, opciones de menu, formularios y funciones comunes, Catalogos de articulos, de clientes, de proveedores, contables. Registro de Ordenes de compra, recepcion de mercancia, registro contable de compras, manejo de inventarios, registro de ordenes de produccion, registro de operaciones y tareas en produccion, registro de consumo de materiales y materias primas, programacion de envios a clientes, registro de Pedidos de los clientes, facturacion, embarques, bancos, cobros, pagos, planeacion financiera y operativa, y un aun largo etc. demasiados temas para verse en una semana, con un manual que si bien consta de varias decenas de paginas, es mas bien una presentacion de Power Point que muestra las impresiones de pantall, pero que tiene muy poca teoria acerca de cada funcion.
Al momento de analizar el documento donde se describen los procesos a modificar, se observa que ciertas funciones, que imprimen resumenes, formatos o papeles de apoyo a la operacion no son considerados como modificables, entonces empieza la discusion, pues mientras el consultor trataba de convencer al equipo de que con la funcion estandar se cubria ese proceso, el equipo por su parte se negaba a adoptar un nuevo formato y a descartar datos que hoy son claves, pero muy particulares de la organizacion y que el sistema no maneja.
Despues de un estira y afloja, se determina que estas funciones se consideran modificables.
Ante la venia del equipo de implementacion se prepara ahora si el cronograma de actividades, el proyecto se divide en 5 fases, de las cuales la primera ya esta cubierta, lo que sigue es elaborar un documento, que con la informacion anterior indique el flujo de las operaciones dentro del sistema. Este documento, al final, sera lo mas parecido a un manual de usuario, y ya trae algunos datos conocidos por nosotros, lo que en un inicio avisora que la empresa de consultoria empieza a conocer a nuestra organizacion, como debe de ser.
El Cronograma....
Como mencione lineas arriba, el proyecto debia tomarnos 6 meses, por lo que para el primer cuatrimestre del 2011 deberia estar funcionando, se toma como fecha de arranque el 4 de Abril, llamó mucho la atencion que a pesar de que se marcaron muchos puntos como modficables, solo se destino una semana de programacion para todas esas tareas. En este punto, se empezaron a formar las primeras dicusiones que han marcado hasta hoy el destino del proyecto.
Inicialmente se divago con temas tan diversos como que la empresa consultora contaba con un equipo de desarrollo altamente capacitado y por eso se preveian tan pocas horas (consideremos que en Mexico por ley se trabajan 48 hrs a la semana, aunque es una practica comun que las empresa tengan jornadas de 45 hrs), alguien mas ingenuo dijo - No te preocupes, en realidad ellos ya tienen todo eso desarrollado, solo se estan haciendo los interesantes para lograr una mayor venta - y lo peor, una Gerenta lo apoyo!, El area de TI de la empresa, considero que eso seria imposible, pues por sentido comun podemos saber que varias empresas del mismo ramo tienen diferentes maneras de trabajar, procedimientos y formas de evaluar que poco o nada tienen que ver al respecto de sus símiles.
Se decidio que se trabajara entonces con la empresa consultora en el Analisis y Documentacion de las modificaciones que se deben hacer al sistema para que este funcione. Al iniciar labores, la consultora pidio que todos los puntos que se requerian fueran clasificacados por orden de importancia para el proyecto, ante lo cual, se le dio preferencia al depto de produccion, posteriormente a Ventas, depues Abastecimientos y al ultimo Administracion y Finanzas.
La consultora nos pidio tambien que antes de consolidar la lista de puntos a desarrollar, hicieramos pruebas del sistema, que verificaramos los diferentes reportes que vienen y que entonces vieramos que puntos podiamos eliminar de esa lista, ellos en realidad seguian defendiendo su postura inicial de que la funcion estandar del sistema cubria nuestras operaciones.
Se hizo entonces una fase de Testing para evaluar de lo general a lo particular todos los diferentes escenarios ante los que el sistema deberia responder. Para ello, la empresa consultora nos proporciono un par de formatos que pretendian ayudar en la planeacion de los escenarios de prueba, mediante una rapida capacitacion al Area de TI, se arranco esta fase del proyecto, la de probar el sistema antes de modificarlo.
La presentacion del formato al equipo de implementacion de la empresa fue un fracaso, debido a que se atraveso el fin de año, a que cada quien tiene que seguir con sus labores diarias y la enorme carga de trabajo al regresar de las vacaciones, hizo que algunos conceptos del formato fueran olvidados, sumado eso a la poca conviccion del equipo por formalizar un aspecto en el que segun comentaban algunas personas "es mas facil picarle, moverle y ver donde truena". Entonces, aunque se hizo un intento porque cada parte del equipo planeara sus pruebas, la verdad no se tuvo exito.
Al reunirnos para revisar el plan de pruebas solo el entonces jefe del Area de Ventas preparo informacion decente, sin embargo, ante la propuesta de que mejor entre todos hicieramos las pruebas en reuniones donde estuviera presente todo el equipo y cada uno fuera alimentando la parte que le tocaba, el formato termino siendo ignorado y se decidio hacerlo de esa manera. con esto, omitimos en realidad una parte del protocolo y las pruebas no fueron correctamente documentadas.
Las Pruebas, una aventura aparte.
La primer reunion empezo con un aire de incertidumbre, empezo a llegar cada uno de los miembros a la sala de juntas, donde el Jefe de TI ya tenia preparada la computadora, el proyector, el pintarron y su libreta de apuntes. Cada uno de los distintos Gerentes y Jefes empezaron a ocupar un lugar. Mayuscula fue la sorpresa cuando el Jefe de TI termina de preparar el equipo, toma un lugar y deja vacio el asiento de la computadora!. Todos se voltearon a ver con cara de interrogacion como diciendo - y ahora?? quien podra ayudarnos-
Entonces el Gerente de Administracion, quien funge como brazo derecho del director y Lider del proyecto dubitativamente toma la batuta y dice: "que les parece si empezamos con registrar un pedido de algun cliente, y luego de ahi corremos la planeacion de compras, registramos ordenes de produccion y hacemos todo el flujo del depto de Abastecimientos?, posteriormente registramos la informacion de produccion y facturamos la venta" todos asintieron, mas porque lo propuso el que porque tuvieran una idea clara de que es lo que tenian que hacer.
El Jefe de TI entonces explico su postura diciendo: Todos los presentes acudimos a un curso de capacitacion en este software, no crean que yo tengo alguna ventaja o conocimiento adicional al de uds, se exactamente lo mismo que saben uds del sistema, tengo las mismas dudas, asi que entre todos debemos ser capaces de apoyarnos y resolver los problemas que se van presentando, pero cada quien debe hacerse responsable de su parte del sistema.
Dicho esto empezamos nuestra aventura de registrar pedidos.
No tardamos 1 minuto en que las dudas empezaran a surgir, por ejemplo, si se captura un kit o juego que es como generalmente el cliente nos pide mercancia, como iba a saber el sistema que tenia que ser una serie de componentes y como se iban a mostrar en el pedido?
Entonces, el Jefe de Ventas que estaba al frente de la computadora dice: eso es tarea de diseño e Ingeniera, asi que pasen!.
Efectivamente, ahora teniamos que ir un paso antes, y el diseñador tomo el control de la computadora y trato de hacer la configuracion de un kit.
Viendo la pantalla de registro el diseñador observo que tenia muchas pestañas, inicia con una vision general, pero hay cerca de 6 pestañas con datos adicionales.
Una vez que alimento los datos que el determina de uno de los componentes, le dio clic en Guardar, y salieron varios avisos, como que deberia de introducir el Grupo de Impuestos del Articulo....
Un silencio incomodo se apodero de la sala de juntas mientras los Contables fruncian el seño, el Jefe de Ingenieria ponia cara de aburrimiento y poco a poco todo volteaban a ver al de TI, al final de cuentas, esto era un sistema y el deberia saber que pasaba.
Efectivamente respondio: debes indicar un grupo de impuestos en la pestaña "configurar"
- Pero yo que se de impuestos?- dijo el Diseñador
- tienes razon, permiteme - respondio el contador y le pidio el control de la computadora.
Reviso la lista de impuestos y entonces dijo - se que debo seleccionar este, pero sabe el sistema que debe calcular la tasa de impuestos correcta?.
y entonces empezo a navegar en el sistema buscando los datos de ese grupo que habia seleccionado.
La desesperacion se empezo a apoderar del resto del equipo, y la empezaron a manifestar en constantes salidas de la sala de juntas para ir por una taza de cafe, otros al sanitario, algunos mas a ver algun pendiente de sus colaboradores.
Despues de media hora, el director dijo: "que les parece si seguimos mañana?" a lo que todos estuvieron de acuerdo y agendamos una reunion para el dia siguiente.
El Jefe de TI se llevo mucha tarea, pues debia resolver las dudas que se plantearon durante los escenarios de pruebas, para que se allanara el camino y pudieran avanzar el dia siguiente.
En resumen el primer dia de pruebas no se pudo registrar correctamente un pedido de un cliente.
La primer leccion.
Diria que la primer leccion aprendida es que este sistema requiere de un trabajo coordinado entre varios deptos de la organizacion, y que al no estar realmente acostumbrados a hacerlo asi, costo mucho trabajo, pues hay una enorme dependencia del depto de TI que generalemente es el piensa y tiene soluciones para todo, sin embargo, tambien empezamos a ver una diferencia: si antes, TI podia resolver los problemas como dijo Ricardo Arjona en su cancion "Mujeres": lo que nos pidan podemos, si no podemos, no existe, y si no existe lo inventamos.
Eso se podia porque existe un pleno conocimiento del sistema que ellos desarrollaron, conocen a la prefeccion la arquitectura de la aplicacion, el diseño de la base de datos, la logica y estructuracion de la programacion y la relacion que hay entre las distintas entidades. Aca eso no es posible, pues ellos tambien deben aprender todo eso de nuevo, y tomando en cuenta que no es un software propiedad de la empresa, el conocimiento y dominio del mismo es una tarea complicada.
Segundo dia de Pruebas.
El segundo dia de pruebas deberia ser mejor, puesto que ya se habian encargado tareas a varias personas con el fin de configurar la informacion de base que se requiere para correr los escenarios que quedaron pendientes el dia anterior. El diseñador y el Jefe de Ingenieria del producto habian cargado informacion de un kit, con sus componentes y los partes de los componentes.
Al empezar a llegar los miembros del equipo a la sala de juntas se escuchaban tambien los mas distintos comentarios:
- Oye, esta complicado este sistema
- Si, pero poco a poco le vamos a ir entendiendo
- Pues se ve mas complicado que el sistema actual
- Aun nos falta mucho por aprender
El Jefe de Ventas tomo su lugar al frente de la computadora y registro un pedido, esta vez, aparentemente sin problemas, fue el turno ahora del Gerente de Produccion quien se encargo de correr la "Planeacion Maestra" del sistema, que debe de sugerir e indicar que se requiere programar produccion y ordenes de compra para poder fabricar el producto que nuestro cliente pidio. Despues de unos instantes, aparecio en una ventana con cerca de 50 mensajes de error!.
-Faltan configuraciones!- dijo el Jefe de TI
- Ahora que?- cuestiono el Gerente de Finanzas.
Obsevando los mensajes, se notó que faltaban configuraciones de locaciones de inventarios, unidades de conversion de medida de las materias primas, y datos de los proveedores.
Frustracion es la palabra que describe perfectamente el estado de animo del equipo en el momento de ver tal cantidad de errores.
Como varios llevaban sus computadoras portatiles, se empezaron a repartir tareas.
Media hora despues se repitio el comportamiento del dia anterior: salidas por cafe, salidas a ver pendientes, desinteres por la reunion.
Se volvio a correr la planeacion y ahora mostro algunos otros mensajes:
- Pero capturamos todos los datos que el sistema nos dice que son obligatorios!- protesto el Jefe de Abastecimientos.
- Propongo que concertemos una Reunion con la consultora para que nos explique que esta pasando y que nos apoyen- sugirio el director, a lo que todos asintieron.
El Gerente de finanzas, lider del proyecto fue el encargado de concertar esa conferencia telefonica y de avisar al resto del equipo de la hora para la reunión.
Por la tarde, nos volvimos a reunir en la sala de juntas,comenzaba a sentirse un aire de enfado entre varios de los miembros del equipo, mientras otros mantenian su espiritu intacto.
- hola, buenas tardes- saludo la consultora.
- hola, te vamos a platicar como nos esta yendo con las pruebas, la verdad es que tenemos varios problemas y no podemos avanzar- tomo la conversacion el Jefe de TI.
Despues de explicar lo acontecido hasta entonces, la consultora dijo: debe revisar, es posible que falten algunas configuraciones, dejame revisarlo y mas tarde te aviso.
De esta manera concluyo entonces la reunion y el equipo quedo a la espera de que se convocara a una nueva sesion en dias posteriores.
Dias despues, la empresa consultora nos notifico que ya podiamos continuar con el plan, esto fue un jueves, por lo que ya se tenain perdidos 4 de los 10 que deberia durar esta etapa.
El viernes se reunion de nuevo el equipo, pero se noto la ausencia de varios miembros que hasta ese momento se veia que no podian tener participacion y que en realidad estaban perdiendo tiempo.
Para no detallar el resto de las dos semanas solo dire que el avance fue escaso, si bien se pudo registrar la orden de venta, correr la planeacion y programar ordenes de produccion, al analizar la informacion de esta surgieron muchas dudas, y esas surgieron porque todos los involucrados esperaban ver datos y formatos conocidos, los cuales chocan definitvamente con el estandar del sistema, lo cual, deberia ser considerado como un punto de desarrollar por los programadores de la empresa consultora.
Inician las discusiones.
Despues de las dos semanas de pruebas, teniamos visita de una semana de parte de los consultores, y lo primero que se hizo fue hacer un borron y cuenta nueva y hacer los escenarios de pruebas con su guia.
Le mostramos lo que ya podiamos hacer y al cuestionar donde se verian ciertos datos e indicadores, asi como cuestionar la eficacia de la planeacion, los argumentos de los consultores fue que ellos recomendaban que en el arranque no se utilizara la planeacion maestra hasta que se dominaran los procesos en su forma manual.
-Pero eso es algo del valor agregado del sistema, y de lo que se considero como ventaja en su adquisiscion- bufo el Gerente de finanzas.
- si, es correcto, y si lo van a tener, pero es mejor esperar a que entiendan el funcionamiento del sistema y despues ya lo dejen hacerlo a el.
- Por otro lado, las graficas de Gantt, que deberian ser una herramienta para ver el avance de la produccion es ilegible- cuestiono el Director de la empresa
-Si, pero eso es porque uds manejan operaciones con tiempos muy pequeños y son muchas
"Obvio" fue el pensamiento de todos los que conocen el proceso de produccion, - y no hay manera de ajustarlo para que sea util?- replico el Director.
-Mmmm, dejame revisarlo con el area de desarrollo- sentecio la consultora.
Se cuestiono acerca del avance en la tarea de revisar los reportes, pero el Jefe de Ingenieria informo que por su parte no habia podido revisar nada porque pues no habiamos podido alimentar informacion para su area.
y el resto de las areas estaba por las mismas, tal fue el caso de Control de Calidad, control de Produccion, Contabilidad y Costos.
Lo que se hizo incapie era que los formatos que usa el depto de control de produccion para el seguimiento de cada pieza de la produccion deberian ser iguales, pues el personal operativo ya esta acostumbrado a ellos y sabe leerlo.
- Es que uds son inflexibles y no quieren adaptarse!- gruño una de las consultoras.
- no, lo que pasa es que asi lo requiero, el que trae el sistema no me sirve!- contesto el Jefe de ingenieria mientras el resto del equipo se quedaba congelado observando la escena.
A pesar de los argumentos que propuso la consultora, esta decidio "doblar las manos" cuando el director le dijo: "Donde puedo ver el tiempo consumido por la produccion por cada area del piso de produccion?" - Ese no es un dato que maneje el sistema, pero deja ver con Programacion que se puede hacer"
En realidad esa fue una estrategia para ganar tiempo, pues una vez mas en semanas posteriores, regresaron con la misma propuesta.
El tiempo se acortaba y la fecha de arranque se veia imposible de alcanzar, por lo que el proyecto fue pospuesto un mes mas.
Eso genero una ligera perdida de credibilidad en la programacion de actividades de los consultores, y se empezo a notar el desconocimiento de la empresa, tambien fue evidente que subestimaron el nivel de expectativas que la empresa tenia.
Mi reflexion es que en este caso, la empresa no migra a un nuevo ERP porque el que tenia fuera malo, sino porque pretendian dar un salto con un producto teoricamente probado. Si bien AX tiene el respaldo de Microsoft, y en la red hay muchos foros, esa informacion es realmente poco util, pues cada partner ya no vende el producto original, sino que vende sus versiones modificadas de acuerdo a sus propias implementaciones, asi, un problema dificilmente puede ser resuelto por un foro, por fuerza tienes que terminar tocando base con el consultor.
El partner podria tener mucha experiencia implementando el software pero la empresa tambien tenia mucho camino recorrido, cada modulo del sistema, cada formato y cada proceso tenia un cumulo de conocimientos detras de si, tenia mucho trabajo, mucha inteligencia y muchas horas de dedicacion de parte de ingenieros, contadores y mas profesionales que entendieron el rumbo del negocio y que en funcion de eso, habian ido dandole forma al sistema de informacion.
Probar o aprobar?.
Posterior a la quincena de pruebas, debe venir la revision y aprobacion de un documento que detalla como es la funcion operativa del sistema aplicada a los procedimientos y actividades de la empresa. La ingenieria de software nos indica que cada etapa del proyecto debe estar sustendada por la solidez de las etapas previas, pero por otra parte, hay plazos que cumplir, lo que genera una dificil situacion para los lideres de proyecto que por una lado saben que si la fase anterior no fue satisfactoria, las demas pueden entonces tener problemas.
En el caso que nos ocupa, esta situacion se dio, la fase de pruebas no fue buena, pero no podiamos detener el avance del proyecto. Uno de los factores de peso a estas alturas, es que la empresa consultora sugirio y recomendo una nueva infraestructura de servidores, que consisitio en una inversion considerable de varias decenas de miles de dolares, factor que al final de cuentas, obliga a que esa inversion retorne.
Se agendo una semana completa para la revision de un documento que contiene cerca de 600 paginas, el cual mas parecido a un manual de usuario indica las funciones del sistema de una manera mas detallada que en el curso que inicialmente se parendio, ademas, la ventaja de tenerlo por escrito es que podemos acudir a el para consultarlo cuantas veces sea necesario.
Las revisiones fueron extenuantes jornadas donde el consultor en turno explicaba el sistema y los demas formulabamos preguntas que en su gran mayoria fueron resueltas, pero que al final de la semana, dejaron modificaciones pendientes a este documento.
Para ser francos, no recuerdo si ese documento fue aprobado o no, supongo que si, como sea, esa firma se torno irrelevante, pues una vez que empezamos a pasar por alto fases del proyecto, que mas daba firmar un documento que de todos modos no seria el definitivo, pues aun faltaban todos los puntos marcados como "modificiaciones al sistema" y sobre los cuales no se habia empezado a trabajar.
Con este nuevo cumulo de informacion recibida, el sistema se ve como algo sumamente complejo y abstracto, (defino "abstraccion" como algo muy dificil, casi imposible de entender, los entendidos de la ingeniera de software sabran a que me refiero con mas precision) lo que nos hace cuestionar nuevamente los tiempos del proyecto.
A estas alturas, de acuerdo al cronograma ampliado, nos quedan cerca de 10 semanas para que se cumpla la fecha de arranque de operaciones.
Se agendo para la siguiente semana el inicio del analisis de los puntos a desarrollar por el equipo de programacion de los consultores, para lo cual, se pidio que se tuviera analizada la prioridad de cada punto, de manera que vayamos trabajando primero en lo mas dificil. Tambien se pidio que se depurara la lista de mas de 60 puntos, para que se viera que es indispensable para el arranque de operaciones y el resto, se irian agregando conforme a la marcha.
Inicia el Analisis.
Inmediatamente el equipo se reunio para establecer las prioridades, pero habia tanto desgaste que fue muy dificil lograr acuerdos, por lo que se decidio que solo 3 personas se encargaran de esta parte, este triunvirato fue conformado por el Lider del proyecto (el Gerente de Finanzas), el Jefe de Ingenieria de producto, como representante y conocedor de las necesidades del area de produccion y el Jefe de TI, quien es el que sabe mejor las vicisitudes que este tipo de tareas traen, y quien deberia hacer la avalacion de los documentos que describen los requierimientos de desarrollo asi como las horas a invertir. Ademas, el Jefe de TI fue el principal desarrollador del sistema de gestion actual y una de las personas que mejor conoce la integracion de procesos en la empresa.
El lunes siguiente, el Jefe de TI llego con una propuesta, en ella describia como prioridad uno lo relacionado con produccion, despues Ventas, en seguida Abastecimientos y por ultimo administracion y finanzas. la propuesta fue aprobada practicamente sin ser revisada ni cuestionada.
Se convoca entonces a una reunion preliminar donde una de las consultoras del area de manufactura y estos tres personajes revisan cada uno de los puntos y estiman el plan de trabajo de esa semana.
Desde un inicio se visualizaba que analizar 35 puntos en una semana, donde hay diferentes complejidades, no seria tarea facil, menos considerando que los consultores del area de finanzas no acudieron, y que una de las consultoras de Logistica y manufactura tampoco, a proposito de ello, se cuestiono a la otra consultora quien respondio con un simple: ella no esta mas en el proyecto. Tiempo despues sabriamos que la vida la llevo a otro horizonte laboral y personal.
Se redujo la lista a aproximadamente 35 puntos a desarrollar, vitales para arrancar operaciones. Obviamente la consultora cuestiono el numero, pero el equipo reducido justifico cada punto.
El dia siguiente empezaria el analsis en forma, por lo que deberian participar los involucrados de cada area, y cual sería el primer punto en el orden? aquel por el que se presento la primer discusion seria. No se trataba de echar sal a la herida, sino que de verdad este es de los ejes sobre los que gira la informacion del depto de produccion, asi que ese no podria ser pasado por alto.
Se convoco al Gerente de produccion, al Director General, al Diseñador y el equipo reducido para empezar una de las fases decisivas en la implementacion del proyecto.
La primer reunion empezo describiendo a la consultora cada uno de los elementos del formato, el cual, conforme ibamos profundizando en el, nos llevaba a explicar toda una fase previa de operaciones.
Este formato es el concentrador del trabajo de varias personas, por una parte el depto de diseño indica las dimensiones de las piezas a fabricar, determina los materiales exactos para hacerlo y en el caso de los materiales compuestos, tambien da indicio de como se debe formar previamente ese material, tambien muestra la forma final de la pieza, luego, el depto de Ingenieria determina por cuales maquinas debe pasar, cuantas personas intervienen en cada centro de trabajo y que grado de conocimientos debe tener, cuanto tiempo debe ser procesada la maquina y que forma debe tomar, determina tambien la merma de materiales que se debe obtener. El jefe de control de produccion tambien indica si hay piezas de un almacen de sobrantes que pueden ser utilizadas para aprovechar mejor el material y los numeros de control tanto de la pieza como de la orden de produccion y el lote exacto de piezas a fabricar. Todo esto en solo una pagina.
La explicacion del formato duro aproximadamente una hora, durante la cual, la consultora fue tomando notas, hacia preguntas y anotaba las respuestas.
Al final de ello dijo: este desarrollo se va a llevar muchas horas, estan seguros?
- Es un formato necesario- sentencio el Lider del proyecto
- sucede que no solo es preparar el formato, hay datos que el sistema no maneja, como el numero de operadores de cada centro de trabajo, o el almacen de piezas sobrantes, por lo que debemos empezar por ahi.- adivirtio la consultora.
- claro, empecemos por analizar los origenes de cada dato y vamos viendo donde los vamos a ir metiendo - propuso el Jefe de TI.
Y empezo la segunda parte de la sesion. Alrededor de las 5 de la tarde terminó de ser analizado el proceso 1 de 35, y quedaban solo 3 dias de analisis. el tiempo invertido nos hacia pensar que se requerian cerca de 3 semanas de analisis.
La consultora pidio entonces tiempo para empezar la redaccion de un documento de analisis de requerimientos y pidio que en los demas dias, por las mañanas analizaramos los puntos y por la tarde le permitieramos documentarlos.
Con cada paso que se da tambien se voltea a ver el cronograma y se entendio que no iba a ser posible arrancar en la fecha señalada, sin embargo, decidimos esperar al avance de la semana para planear una nueva fecha de arranque y entonces reorganizar nuestro plan de proyecto.
Despacio que llevo prisa?
La primer semana de analasis de Requerimientos culmino con un avance de aprox el 30%, y el siguiente paso era la documentacion, revision, cotizacion y autorizacion de cada desarrollo. La siguiente semana seria destinada para esas actividades.
El Lunes transcurrio sin novedad, no hubo llamadas, correos ni comunicacion alguna con los consultores.
El Martes llego un correo electronico con un archivo adjunto, este describia el analisis realizado la semana pasada sobre uno de los puntos, pero oh sorpresa!, no corrrespondia al primero de la lista. Inicialmente pensamos que debido a la complejidad del mismo se tardarian un poco mas.
El Jefe de TI reviso el correo y decidio entonces convocar a una reunion a los otros dos del Triunvirato para analizarlo y enviar observaciones a los consultores. Se concerto la junta para las 4 de la tarde de ese dia.
Una vez en la sala de juntas, el analisis se llevo aprox 45 minutos, el documento tenia unas 7 cuartillas y describian casi correctamente el proceso. De hicieron algunas observaciones y fue mision del Jefe de TI hacerselas llegar a los consultores, pues el documento es mas de caracter tecnico, por lo que el era quien mejor lo comprendia y podria hacerse explicar de una mejor manera.
Esa fue la unica tarea realizada es martes. Inevitablemente volvimos a ver el cronograma y este ritmo de trabajo hacia imposible que faltando 8 semanas para el arranque se pudiera lograr.
Al final de la semana se recibieron 3 documentos de desarrollo mas, pero jamas llego el del primer punto que se trato, que estaba en la cima de las pioridades.
La siguiente semana los consultores visitaron la empresa, vino una nueva consultora, quien tenia categoria de "Junior" y se integraba hacia pocos meses o semanas con la Empresa Consultora. esto representa un par de desventajas, pues ella no conoce en absoluto los procedimientos ni el argot de la empresa y por otra parte, al estar en fase de aprendizaje, tampoco podiamos considerarla para la resolucion de problemas, sin embargo, asi es la vida laboral, unos vienen, otros van.
En la segunda semana se avanzo hasta cubrir el analisis del 50% de los puntos de desarrollo, y el viernes se tuvo una reunion con ellas donde se cuestionaba la fecha de arranque.
- Seria bueno que CONSIDEREN una nueva fecha para el arranque, es poco probable que podamos terminar a tiempo los desarrollos, ademas, no han terminado de probar el sistema- dijo la consultora
- Como podemos probar el sistema si cada vez que le movemos falta alguna configuracion? ademas, necesitamos que esten cubiertos los puntos de desarrollo, porque de nada sirve que practiquemos algo que al final de cuentas no vamos a usar- replico el Jefe de Ingenieria.
- Pero es necesario que vayan perdiendo el miedo y se animen a ver que hace cada boton y cada opcion del menu- constesto en tono suave la consultora.
- Yo creo que nos deberias de actualizar el cronograma y de acuerdo al tiempo que se va a llevar el analisis de requerimientos nos digas cuando podemos arrancar- acoto el Director
- Es que la verdad no pensamos que hubieran tantos puntos, y luego no son sencillos, si todo fuera reporteo sera mas facil, pero uds son demasiado ESPECIALES- menciono la Consultora
- Es solamente lo que necesitamos.... o se puede reducir esa lista?- cuestiono el Director al resto del grupo
- No, es mas, despues de esos puntos aun hay cosas que debemos analizar, pero esto es lo necesario para el arranque- respondio el Jefe de TI
- Bueno, dejenme trabajar en el cronograma y se los hago llegar.
- A que hora lo podrias tener? - pregunto el Gerente de Finanzas
- La prox semana se los entrego - menciono en un tono ligramente molesto la consultora, denotando que se empezaba a producir un roce entre ella y el Gerente de Finanzas.
Por la tarde del viernes las consultoras no regresaron a las oficinas, lo cual representa una perdida de horas valiosas cuando el tiempo apremia.
El triunvirato se reunio informalmente, y el Jefe de TI advirtio que con este ritmo de avance seria imposible arrancar en Mayo siquiera, ya estabamos terminando el mes de Febrero, aun faltaban muchas cosas por preparar y seria imposible que en dos meses, menos el descanso de la semana santa se pudiera avanzar.
Hasta ahora no he mencionado que el sistema se iba a implementar en dos empresas del Grupo, por una parte esta Bitacora se refiere a la implementacion en la Fabrica, mientras que por otro lado, tambien se hacia una tarea similar para implementarlo en la Casa Comercializadora.
Se planteo entonces por parte del Gerente de Finanzas la posibilidad de que arrancara primero la Comercializadora, pues consideramos que tienen una operacion mas tipica. y quedó de revisar ese punto con el Lider de Proyecto de aquella empresa quien es ademas su amigo entrañable.
La presencia del sistema poco a poco empieza a permear al resto de los compañeros de oficina, y en el comedor es recurrente que haya platicas sobre el tema. Es interesante ver como cada quien tiene un punto de vista diferente, pero muy influenciado por dos factores tipicos de la psicologia Industrial: la ceguera de taller y la zona de confort.
La ceguera de taller es cuando uno se acostumbra tanto a trabajar con problemas que aprende a vivir con ellos, no ve su labor desde otra perspectiva, por lo que no considera que pueda haber un cambio ni para bien ni para mal.
La zona de confort es cuando un trabajador domina a tal grado sus tareas que cualquier cambio por minimo que parezca lo estresa e incomoda y trata de evadirlo consciente o inconscientemente.
¿Porque vamos a cambiar de sistema, si el que tenemos nos ha costado mucho trabajo y funciona bien?, ¿si es mejor ese sistema? ¿No vamos a batallar mucho para aprenderlo?¿ Si es conveniente o no? eran preguntas recurrentes en las platicas de sobre mesa.
Los cambios no necesariamente son malos, pero tampoco son necesariamente buenos, pero la organizacion debe tener la capacidad de ser critica, objetiva y lo suficientemente organizada como para promover un cambio con el afan de mejorar su rentabilidad. para ello, el liderazgo y el rol de personas clave son muy importantes.
Un proyecto de 4 meses, que se alargo a 6, ya proyectaba 7 y ante las nuevas circunstancias era dificil pronosticar una fecha de arranque. este tipo de proyecto tan grandes suelen ser desgastantes, pero tambien muy educativos y le permiten ver a los involucrados las fortaleces y debilidades tanto de los individuos como de los equipos de trabajo. El tema esperado de la siguiente semana era la reunion entre los lideres del proyecto y comunicar al Director General el resultado de esa reunion, esperariamos con ansia que llegara el martes, dia en el que nos darian a conocer la decision.
El dia "D"
El martes fue el dia señalado para informar a todo el equipo la resolucion de la fecha de arranque del sistema, poco a poco fueron llegando personal de ambas empresas donde se iba a instalar. El Director General tomo la palabra y dijo: "Despues de analizar el avance del proyecto en ambas empresas, hemos decidido que en Fabrica no arrancaremos en Mayo, sino que sera despues, queremos un arranque de calidad y no es posible lograrlo con tan poco tiempo, sin embargo, en la Comercializadora si estamos en condiciones de hacerlo".
A partir de ese momento todas las fuerzas de los consultores se concentrarian en lograr el arranque en aquella empresa, y dejaba en el aire la fecha en la que la fabrica empezaria operaciones. Para reducir las fricciones que habian con los consultores y allanar el camino para la otra empresa, se decidio suspender temporalmente todo lo relacionado con el sistema hasta nuevo aviso.
El lunes 2 de Mayo seria la fecha del banderazo inicial. se tenian pocas semanas para lograrlo, pero se creian suficientes. sin embargo, la ley de Babagge (aquella que dice que los sistemas nunca estan a tiempo)se cumplio de nuevo, y tuvo que ser postergada unos dias una vez mas, esto debido a que la aprobacion de sus desarrollos tardo mucho, porque no cumplian con la funcion descrita en el documento o bien sobre la marcha debio replantearse la logica.
A finales de mayo el sistema por fin era parte de la operacion, pero hasta la fecha se presentan problemas originados por omisiones en la carga inicial de datos. Esas omisiones fueron provocadas porque los consultores nunca llegaron a comprender el 100% de las operaciones de la empresa y hubo malos entendidos entre lo que la empresa solicitaba, lo que los consultores planteaban como solucion y lo que en realidad hace el sistema.
La experiencia que dejo en la comercializadora el arranque.
El Jefe de TI planteo inicialmente al lider del proyecto que seria bueno que el Triunvirato estuviera como observador durante la ultima semana de trabajos en la comercializadora de manera que viviera en vivo y en directo todas las actividades que se realizan y asi se pudieran anticipar problemas de manera que la fabrica se preparara y los evitara. La propuesta nunca fe aceptada ni rechazada, por lo que se perdio esa oportunidad.
Lo que si se hizo fue convocar a algunos de los miembros del equipo de implementacion de la comercializadora para que platicaran sus experiencias.
Algunos de los puntos mas relevantes es la carga de datos iniciales, especificamente de los catalogos, los cuales se llevan mucho tiempo en preparar pues las plantillas que se usan para el sistema deben estar perfectamente ligadas entre si (son archivos de excel) de manera que si un articulo no tiene algun dato configurado correctamente en alguna plantilla corre el riesgo de que el sistema no lo muestre, no marca error, pero no lo muestra.
Otros aspectos parecidos son la carga de saldos iniciales en contabilidad, todo debe cuadrar a la perfeccion.
Se recomienda que al arranque todo el personal tenga acceso completo al sistema, pues la configuracion de seguridad es algo de lo mas deficiente del sistema, la creacion de grupos de usuarios se comporta muy extraño y si a eso se suma que los mensajes de error del sistema dificilmente sirven para encontrar la causa raiz del problema, es preferible arrancar asi.
Se menciono la importancia de tener bien controlados los horarios de los consultores y que de verdad tenga amplia disposicion, pues en ocasiones, cuando algun error aparecia en el sistema, se les preguntaba y empezaban a resolverlo, pero tras un momento, via internet estaban atendiendo asuntos de otros proyectos que traian con algun otro cliente.
Eso sin mencionar que en esos dias donde las jornadas son largas y facimente se salen del horario laboral, ellos dejan de trabajar cuando llega su hora de salida en su oficina, y no son localizables los fines de semana.
Caras de asombro y risas nerviosas se veian entre el equipo de implementacion en fabrica.
Mes y medio despues, la comercializadora aun no habia podido decir que su sistema estaba funcionando a la perfeccion. Pero uno de los Gerentes finalizo asi:
- El sistema es complicado, se sufre mucho para implementarlo, pero es una fregoneria, es muy bueno y tiene muchas bondades, ya veran como les va a ayudar mucho-
La cara del Jefe de TI de la comercializadora fue de incredulidad ante lo que escuchaba, lo cual no fue una buena señal para algunos miembros del equipo que mientras se retiraban murmuraron: deberia mencionar al menos dos... en pocas palabras, esa opinion no es aun generalizada en la otra empresa, pero aun no se dice la ultima palabra al respecto.
La reanudacion de actividades.
A la siguiente semana una de las consultoras visito la fabrica con la idea de reanudar las labores de analisis de los desarrollos. Pidio que se hiciera un "borron y cuenta nueva" y asi se hizo.
Debido a las fricciones generadas en la etapa anterior habia mucha predisposicion en su contra. el triunvirato decidio replantear la lista de desarrollos y aunque no pudo reducirla si cambio las prioridades.
El Jefe de TI reorganizo la lista por dependencias, es decir, que si un desarrollo dependia de otro entonces primero deberia analizarse aquel que proveria datos, de manera que cada vez fuera mas facil integrar y relacionar cada punto.
La propuesta fue presentada a la consultora, y se le indico que debido a que ese orden en realidad es relativo, ellos podrian decidir su propio orden de programacion.
La actitud de la consultora en esta vez fue muy diferente a la etapa anterior, se veia mas proactiva, conciliadora y abierta a conocer el proceso de la fabrica o al menos a no negar que ciertas caracteristicas podrian ser desarrolladas.
Esta nueva actitud mejoro la relacion y con un plan de trabajo mas flexible, se adelanto mucho la primer semana, analizando cerca de 15 desarrollos. Como las explicaciones de los procesos los hacia el Jefe de TI, el lider del proyecto y el Jefe de Ingenieria se la pasaban bostezando, saliendo de la sala de juntas y muy pocas veces aportando, por lo que el Jefe de TI propuso a sus dos compañeros que seria el quien se encargaria de hacer el analisis, pero que las revisiones de los documentos deberian ser en conjunto, lo cual los otros dos aceptaron.
Al final de la semana, se estimaron mas de 150 horas de programacion, lo cual de acuerdo al esquema de 100 horas por semana que nos dedicaria la empresa consultora seria trabajo para semana y media. por lo que se acordo que la prox semana se enviarian todos los documentos para revision y una vez autorizados, se empezaria a trabajar y la nueva visita de la consultora seria dentro de 3 semanas.
Se le cuestiono porque hizo el viaje ella sola y menciono que la otra consultora ya no era parte del proyecto, y que iba a traer un nuevo consultor. Esta noticia no fue del agrado del equipo, pues nuevamente seria alguien que no tenia idea de lo que se hace en la empresa.
Los documentos empezaron a llegar y por la tarde se hizo la reunion para revision del primero, ni el lider del proyecto ni el jefe de ingeniera cuestionaron nada, el Jefe de TI sabia que habian errores, al ver la actitud del equipo reducido, él les marco donde estaban los errores, en realidad no habian analizado el documento a conciencia. En teoria, 3 cabezas piensan mejor que 1, pero se requiere a las 3 pensando, asi que este tipo de practicas tambien provocan desgaste cuando no se trabaja realmente en equipo.
Cuando llego el segundo documento el Jefe de TI lo reviso, envio las correcciones y una vez que estuvo listo, lo reenvio a los otros dos, solicitandoles que dieran su Vo.Bo., al final de la semana, de los 15 desarrollos se enviaron 5 documentos para autorizacion, con sus 5 correos al Lider del proyecto y al Jefe de Ingenieria, debido a que no hubo respuestas, dudas ni cuestionamientos, el Jefe de TI los firmo, los llevo ante el lider del proyecto y le pidio su firma para enviarlos a la consultora y que empezara a programarlos. previamente ya se habia determinado con precision por parte del equipo de desarrollo de la consultora cuantas horas de programacion serian invertidas y el Jefe de TI daba su aval de esta cantidad.
El nuevo consultor.
La visita del equipo de consultoria estaba proxima, y habia cierta inquietud por la llegada del nuevo consultor. Como cada vez que ellos acuden a las oficinas, se les preparo un par de lugares para que pudieran trabajar comodamente.
A las 9 de la mañana se escucho la voz de la consultora Jefe que saludaba a la recepcionista, el Gerente de Finanzas agudizo su oido para verificar que vienera el nuevo consultor... solo se escucho el sonido de los tacones acercandose a su privado.
Despues de los saludos de rigor se reunion el equipo reducido con ella en la sala de juntas y se reviso el avance del proyecto.
Debido a que se habia tenido un excelente arranque (dada la experiencia anterior) se preveia que el plan del proyecto estaba mas que alcanzable, y esa vision, comparable a aquella que experimentamos cuando despues de un viaje en carretera, al llegar a la cima de alguna colina se ven a lo lejos las luces de la ciudad. Una nueva inyeccion de animo recibio cada parte del equipo, pero la pregunta obligada era: ¿y el nuevo consultor?
- pensamos que vendrias acompañada- dijo el Gerente de Finanzas a la consultora
- si, ese era el plan, solo que no pudimos conseguir boletos de avion para el nuevo consultor, por lo que llegara en la tarde.- respondio la consultora
- no se preocupen llegara, es un hecho jijijiji - dijo en tono amable la consultora suavizando tambien la ya suave relacion de ese momento.
En esta reunion participo ademas del equipo reducido el Gerente de produccion y su asistente, pues se discutirian los desarrollos del sistema donde el estaba involucrdo y se requeria su autorizacion y aprobacion de las mecanicas que el analisis derivara.
Planeacion de la produccion, la cereza del pastel del AX.
Todo fluyó con algo de rapidez hasta que aparecio el tema de la planeacion de la produccion.
El sistema tiene un modulo que permite que en base a las rutas de produccion, los tiempos de manufactura, colas y retardos se estime cuanto tiempo va a pasar una pieza en un centro de trabajo y muestre tanto de manera tabular como en una grafica de Gantt una vision del programa de produccion.
Para el momento en el que se analiaba este punto, el equipo de ingeniera y diseño ya habia cargado informacion real del proceso de un par de productos que se hacen en la fabrica, se alimentaron cantidades exactas de consumo de materiales, se configuraron los tiempos de proceso y se describio perfectamente la operacion, el centro de trabajo, el orden de la produccion que incluye que una pieza vaya de la maquina 1, a la 2, a la 3 y regrese a la 2 (por citar un ejemplo).
Para empezar el debate el Gerente de produccion siguio las instrucciones de la consultora para generar la grafica de Gantt, que representaba la mayor ilusion del Director General que desde hace varios años soñaba con poder ver el estatus de la produccion con "un clic" y tener el poder de informar a los clientes acerca del avance real de su pedido. Este sistema sin duda permiria que se pudiera lograr ese objetivo, y que la empresa pudiera tomar una posicion ventajosa respecto a la competencia.
Todo el personal de fabrica veia con atencion la ventana que indicaba el avance del procesamiento de informacion que hacia el sistema, y conforme se acercaba al 100% se generaba mas expectacion, todos querian ver la grafica que mostraria los problemas que se tienen para medir el avance actual, deberiamos ver literalmente los cuellos de botella y la grafica nos deberia indicar cuales centros de trabajo estan mas "holgados".
Por fin llego el 100%, un par de segundos mas y tendriamos a la vista una herramienta tecnologica que justificaria la inversion realizada, el tiempo, el esfuerzo de muchos prefesionales.
Se abrio una nueva ventana.
En blanco.
El indicador del sistema decia que aun habia intercambio de informacion.
El cursor cambio al reloj de arena, se puso de nuevo el estandar, una vez mas se convirtio en reloj de arena, la expectacion crecia.
Y en esos segundos que parecieron eternos, surgio de las entrañas de los procedimientos y funciones del AX una grafica de Gantt que lleno la pared donde se proyectaba, el resultado de la carga de informacion y la programacion de un lote de produccion estaba por fin a la vista, un panorama grafico de un programa real era ofrecido para uso del Gerente de Produccion.
Produccion a la Italiana.
Varios de los asistentes agudizaron su vista para observar el resultado de la grafica, no estaban muy seguros de lo que estaban viendo. Mientras todos observaban, el Jefe de Ingenieria busco algunas hojas.
-Segura que asi debe salir la grafica?- rompio el silencio el Gerente de Produccion
-Todo depende de la información que metieron - respondió la consultora, aseverando algo que a pesar de ser tan obvio pocas personas no relacionadas con las computadoras comprenden en realidad.
- Pues... creo que esa es una herramienta poco útil.- declaro con ciertas dudas el Gerente de Produccion, esperando que el resto del equipo le apoyara o bien le ayudara a resolverlas.
- Es que metieron demasiada informacion- dijo la consultora.
- Lo que se hizo fue meter informacion real, asi es como nosotros trabajamos, estan todos los procesos de uno de los componentes, ni siquiera del juego completo - increpo el Jefe de Ingenieria.
- Se comprueba lo que alguna vez nos dijeron no?, el Efecto "Spaghetti" de la produccion: rutas sinuosas, con regresos, y donde los caminos de entrecruzan hasta que al final todas, o la mayoria de las piezas terminan en una estacion comun, generalmente de ensamble - acoto el Gerente de Finanzas.
- Exactamente - afirmo el Gerente de Produccion - Pero esto, asi como sale, no me dice nada, no me sirve para nada.
La consultora no se inmuto, o al menos no demostro preocupacion alguna.
-Ahora, imaginense como salen todas las producciones del mes... - menciono el Jefe de Sistemas
-No, solo sale una grafica por orden de produccion. - acoto la consultora.
Algunas risas nerviosas se escucharon de parte del equipo.
-No nos digas eso... pero ustedes pueden hacer algo para que si salgan- dijo en tono bonachon el Gerente de Finanzas.
- No creo...pero podria consultarlo con el equipo de desarrollo.- dijo la consultora mientras por Skype se conectaba con el Jefe de Desarrollo de la empresa consultora.
- No se va a poder - sentencio el Jefe de TI discretamente mientras la consultora escribia rapidamente en su lap top.
- Las graficas de Gantt no sirven para este proposito, si sirven para proyectos donde unas pocas etapas deben ser controladas en el tiempo, pero no para produccion de componentes que a su vez llevan sub-partes, se hace ilegible. explico el Jefe de TI recibiendo la aprobacion del Jefe de Ingenieria.
- Me dicen que no se puede hacer- dijo finalmente la consultora.
Tratando de buscar el lado bueno de la situacion el Gerente de Finanzas pregunto:
- y es posible ver el avance de la produccion?
- No, puedes hacer una reprogramacion arrastrando y soltando las barras, y eso afecta a toda la planeacion del sistema, pero no podrias ver un avance parcial- respondio la consultora haciendo que el animo del grupo cayera.
El problema iba ahora con el Lider del proyecto, que debia explicarle al Director General que las graficas de Gantt no eran lo que el esperaba.
Para poder avanzar se decidio que se siguieran analizando desarrollos.
De fabricantes a cazafantasmas.
El siempre inquieto y dificil de convencer Jefe de Ingenieria reviso una impresion del Gantt que se obtuvo, y repentinamente comento:
- Porque el orden de las operaciones no es el que nosotros le dimos?
- ¿Como? a que te refieres? pregunto la consultora.
- Si, debe empezar en el area de corte, y la grafica muestra la primer operacion en el area de ensamble, eso esta mal. - mostro el Jefe de Ingenieria.
- Ahhh. eso se debe a que el metodo de produccion que escogieron hace que en las listas de materiales, todos los articulos que son subpartes, se "integren" al componente principal, y hace una sola ruta, iniciando con la ruta del componente y luego agrega y reenumera las rutas de cada una de las partes- aclaro la consultora.
Si el equipo aun no salia del shock por la situacion del grafico de gantt, esto no ayudaba mucho.
-Es es un gran problema, eso no se parece en nada a como controlamos la produccion. - reclamo el Jefe de TI.- Te generara un problema con los indicadores por departamento, en el control por piezas, en inventarios, etc- dijo al Gerente de Produccion, el cual asintio y subio una ceja en señal de asombro y desaprobacion de lo que veia.
-¿El metodo que escogimos?- pregunto el Jefe de Ingenieria. - O sea que hya varias formas?.
-Si, pero el problema es que ustedes no se meten a conocer el sistema, por eso no exploran y no saben realmente como funciona- gruño la consultora
- Y como se supone que ibamos a saber eso? no lo explicaron en el curso, o en que parte del Documento que firmamos hace unos meses viene?- increpo el Jefe de Ingenieria.
- No viene, pero es algo que ustedes deberian haber probado y decidir que es lo que mas les convenia- se defendio la consultora.
- no inventes, o sea que aparte debemos de adivinar?.- Se metio en la discusion el Gerente de Finanzas
- no, solo probar el sistema.
-Pero tiene tantas cosas... muchas de las cuales no usamos, otras tantas que no estan claramente explicadas, como puede ser posible eso?- dijo ya con aire de mucho enfado el Gerente de Finanzas.
-Miren, les propongo que nos reunamos por la tarde para decidir como vamos a manejar la produccion, ya que de eso depende el curso de los desarrollos. Hay un concepto que se llama produccion de "fantasmas", se los explico y deciden si funciona para uds o no, que les parece?- propuso la consultora.
El equipo accedio y se agendo una reunion para ese mismo dia por la tarde, se acordo tambien citar al Director General para que estuviera al tanto, pues esta situacion volvio a generar tension entre el equipo y los consultores.... los consultores?? donde quedo el otro consultor?
El consultor perdio un avion, por lo que llegaria hasta ese dia por la noche.
Gasparin al rescate.
La reunion inicio con una breve explicacion de algunas funciones del sistema que en resumen hacen lo siguiente:
Un articulo tipo L-Mat es sujeto de ser programado para produccion, el cual, puede ser marcado como "fantasma" o no. Si es marcado como "fantasma" entonces cuando se haga una orden de produccion, el sistema Integrara todos las listas de materiales propias y de sus componentes tipo L-Mat, excepto donde esos elementos esten marcados como "Produccion" en el Tipo de Linea.
Glosario:
L-Mat: codigo de articulo que se compone de una lista de materiales, comprados o fabricados por la planta, podria llmarse tipo "ensamble", ejemplo: un escritorio, que se compone de una cubierta, patas, hule, tornillos, etc.
Listas de Materiales: Todos los elementos que conforman la L-Mat, pueden contener otros elementos tipo L-Mat, lo que hace que haya varios niveles de Listas de Materiales.
Tipo de Linea: Es la identificacion del comportamiento de cada elemento de la lista de materiales, la cual puede ser "Fantasma", "Produccion", "Articulo" o "Proveedor"
Con este concepto, entonces cuando se programa una orden de produccion del Articulo A, este generara tantas ordenes de produccion "referenciadas" como articulos tipo "Produccion" contenga la lista de Materiales, de manera que asi, no explosiona todas las listas y se puede tener un control individual de partes que corresponden a un ensamble.
- Esto les puede servir?- cuestiono la consultora.
- si podemos controlar cada una de las piezas si- respondio el Jefe de Ingenieria.
- Asi podrian hacerlo-
- No crees que esto nos traiga problemas?- cuestiono ahora la consultora
- Tal vez no problemas, pero si tendran que cambiar la manera en que controlan la produccion- respondio mientras se hacia un silencio tenso.
- No se puede hacer que el sistema trabaje segun lo que nosotros hacemos actualmente- pregunto el director General.
- No, el sistema tiene sus propias funciones que no es facil alterar, ademas tiene un nucleo que no debo tocar, hay cosas que podemos personalizar, pero si llego a tocar ese nucleo de la programacion el sistema se hace inestable. Deben entonces ustedes adaptarse al sistema.- Explico la consultora dejando poco espacio para el debate
- Hagan pruebas con este tipo de control y vean si les sirve- sugirio la consultora.
El Jefe de TI y el Jefe de Ingenieria se pusieron de acuerdo para hacer algunas pruebas en cuanto terminara la reunion, y se acordo que al dia siguiente se presentaria ese resultado al resto del equipo.
Se toco nuevamente el tema de las graficas de Gantt, donde se le explico al Director que no se podia utilizar de esa manera como herramienta de control de la produccion.
-Pero ustedes pueden hacer algo?, una variante o algo adicional para tenerlo?- cuestiono el Director a la consultora.
- No, pero si a ustedes se les ocurre algo, lo podemos evaluar a ver si Desarrollo lo puede hacer- respondio
- Como ves si te avientas algo?- le encomendo el Director al Gerente de Produccion quien asintio con la cabeza.
La reunion termino, con mas dudas que hacia casi un año cuando se firmo el contrato y se tomo la decision de cambiar de sistema. El panorama pinta incierto y es dificil dar marcha atras en este punto, pues ya se habia hecho una inversion de varios miles de dolares en equipo, rentas, instalaciones y consultoria que forzaba a que el proyecto culminara, al menos por la parte economica.
Al dia siguiente se reunio el equipo, y se presentaron las conclusiones de las pruebas.
Se explico que si el dia de hoy, producir un juego de 5 componentes requeria del control de una sola orden de produccion, que contenia cerca de 130 partes, mas lista de materiales a consumir por cada departamento de produccion, ahora se tendrian 135 ordenes de produccion que controlar, de las cuales 130 estaban estarian referenciadas a 5 ordenes distintas que representarian a cada componente.
A pesar de fisicamente la informacion a controlar es la misma, ahora se deben tener muchas pequeñas referencias que incluir.
El Gerente de produccion convencio del Director General de que no era funcional tener una grafica de Gantt ni algun control visual ya que volveriamos a encontrar un spaghetti.
Algunos esperaban que ante un cambio tan radical en una empresa tipicamente familiar y tradicionalista, ademas de las expectativas no se estaban cumpliendo fueran suficientes para que el proyecto se detuviera y se replanteara la necesidad de cambiar de sistema.
Cuando el Director pregunto si estos eran los unicos cambios, el Jefe de TI le contesto:
- No, esto es solo la punta del Iceberg, adapatar el sistema a esta nueva forma de rabajar seguro traera que otras funciones que dependen de este control sean alteradas, mas algunas otras que tal vez ahorita no alcancemos a ver, es complicado pronosticar donde mas nos va a pegar, y si a eso le sumamos que los consultores nos dan informacion a cuentagotas, pues solo sobre la marcha iremos aprendiendo.
- Esta bien, pues veamos que pasa- dijo el Director mientras abandonaba la sala, lo que indicaba que el equipo deberia resolver los problemas que se presentaran y hacer que el sistema funcionara si o si.
Esta actitud decepciono a algunos, que vieron muy poco involucramiento de la cupula directiva en el desarrollo del sistema, y que veian que el Director no alcanzaba a dimensionar lo duro del cambio y los posibles riesgos.
- Yo opino que deberiamos quedarnos con el sistema actual- dijo el Jefe de Ingenieria- a mi nunca me ha convencido este sistema, para que complicamos algo que es complicado y que ya tenemos bien controlado? no veo la necesidad de cambiar. El sistema actual nos da todo lo que queremos, porque cambiar?
Ni el Gerente de Finanzas, el de produccion o el Jefe de TI pudieron responder esa pregunta, el Gerente de Finanzas, al ser familiar y brazo derecho del Director seria el indicado para llevar esta pregunta hasta él, sin embargo, la actitud sumisa que tiene solo con él, hizo pensar al equipo que eso no sucederia, y que al contrario, ahora el Gerente de Finanzas tomaria el rol protagonico para asegurar que el proyecto funcionara.
El nuevo consultor (ahora si).
El dia siguiente guardaba la presentacion del nuevo consultor.
La decision de usar "fantasmas" estaba tomada y la empresa deberia adaptarse a una nueva forma de controlar la produccion. Esta tarea no resultaba facil, pues son muchos años de tener un metodo incluso sistematizado para hacerlo, lo que forzaba que los involucrados deberian de diseñar nuevas mecanicas y modificar procedimientos para lograr el objetivo.
A las 9 de la mañana como es costumbre llego la consultora y una voz varonil la acompañaba, era el nuevo consultor.
Despues de las presentaciones de rigor se inicio la reunion del dia donde se deberia de recuperar algo del tiempo perdido y replantear algunos de los puntos vistos desde la nueva optica de la programacion con "fantasmas".
Paralelamente a esto, el equipo reducido realizaba una sutil y hasta un tanto inconsciente inspeccion de la capacidad analitica del consultor, si bien es cierto que era su primer contacto con la empresa, en estos niveles rapido se identifica si la persona aportara al proyecto o lo entorpecera.
Hubo que dar un repaso a los desarrollos ya planteados y afortunadamente los cambios fueron minimos, por lo que se pudo continuar con aquellos que representan el nucleo del control de la produccion en la empresa.
Recuerdara amable lector al personaje de "Sandy" en "Mi novia Polly", interpretado por Phillip Seymour?, que representa a un actor semidesconocido con aires de grandeza por un papel protagonico en una pelicula de bajo presupuesto. Al final de la pelicula, reemplaza a Ruben Pfeffer (Ben Stiller) en la reunion donde evaluaran el seguro de vida de un multimillonario amante de los deportes extremos, bien, Sandy inicia la reunion literamlente desparramado sobre su silla, y con aire de arrogancia y dominio de la situacion.
Sin el aire de arrogancia, el consultor hizo recordar esa escena de la pelicula, pues mientras todos los demas hablaban el estaba literalmente desparramado en sus silla, ocasionalmente bostezaba y se notaba algo ausente.
La empresa controla su produccion llevando un registro del traspaso entre departamentos de partes de un componente. Un departamento a sus vez, es la suma de varios centros de trabajo, que son operados por una o mas personas. Asi tenemos departamentos como Corte, Ensamble, Pintura, etc.
Pero era deseo del Director General, que con el afan de incrementar la productividad, la medicion se hiciera por cada centro de trabajo, independientemente del departamento al que perteneciera, sin embargo, el gerente de Produccion deseaba seguir teniendo el control por departamento. Entre la consultora, el Jefe de TI y el Jefe de Ingenieria lograron encontrar la solucion para este planteamiento, para ello se usarian las "unidades de produccion" como entidades agrupadoras de centros de trabajo, y las rutas seguirian siendo detalladas (esto ya se manejaba asi).
Despues de 4 hrs de analisis la consultora estuvo en condiciones de poder redactar el documento que plasmara el desarrollo requerido, que por si fuera poco, deberia ser utilizable desde una terminal de Radio Frecuencia, con el fin de capturar en linea conforme cada centro de trabajo fuera terminando partes, para ello, el depto de control de produccion dispone de 5 capturistas que realizan esa tarea.
Por la tarde los consutores deberian presentarse para una reunion en la empresa comercializadora.
- No me da buena espina este nuevo consultor - dijo el Jefe de TI al Gerente de Finanzas.
- No se te hace muy..... pasivo? - agrego él.
- si, muy distante, desinteresado, no dijo nada relevante, por ahi alguna pregunta pero... no se... -
- A ver si no salimos de Guatemala para entrar a Guate Peor- concluyo el Gerente de Finanzas.
- Esperemos llevarnos una agradable sorpresa, pero la verdad no lo creo - remato por su parte el Jefe de TI.
"Que se comporte como Excel no quiere decir que es Excel"
El dia siguiente (miercoles) deparaba mucha tarea, se trataria de avanzar lo mas posible con puntos de desarrollo para que los consultores se llevaran mas horas de programacion.
En resumen se pudieron avanzar con algunos, en los cuales el nuevo consultor tuvo una participacion mas activa, dando algunas muestras de que de verdad conocia el producto, lo cual representaba una ventaja ya que aun sin conocer el proceso de la empresa, podria ser de utilidad su buen conocimiento del Sistema.
El problema vino cuando se llego al punto de la planeacion y control de la produccion semanal.
Cada semana, la Gerencia de Produccion hace una proyeccion de trabajo para cada semana, donde para cada departamento y cada estacion de trabajo se genera una carga de operaciones, las cuales demandaran un cierto consumo de materias primas y materiales, se estiman cuantas horas hombre se van a trabajar y de acuerdo a las horas pagadas via nomina, se obtiene un indicador de productividad (aquel que el Director General quiere elevar).
Primero se analizo la manera de hacer la proyeccion de tiempos y consumos de materiales, lo cual, se llevo cerca de 3 horas de analisis.
El siguiente paso era ver como obtener la carga de trabajo de cada centro.
A mitad de la explicacion, que era proporcionada por el Jefe de TI (como se hizo desde aquella primer revision de documentos y con el "aval" del Jefe de Ingenieria cuando fueran de produccion) la consultora dejo de tomar notas, se quito los lentes y jugueteaba con la para izquierda de los mismos, llevandola ocasioalmente a los dientes y en otra dandole vueltas.
Al terminar la explicacion, dijo:
- Todo esto que estas planteando no lo puede hacer el AX-
Nuevo balde de agua fria
- al menos no asi, tal cual, ustedes bajan todos sus archivos a excel, y ya traen agrupaciones, el AX no lo puede hacer- agregó
- Pero que no es de Microsoft? - cuestiono el Jefe de Ingenieria.
- Si, pero el hecho de que "trabaje como excel", no quiere decir que puede hacer todos lo que si hace Excel, esas agrupaciones no se pueden hacer
- Y no tienen componentes de terceros que puedan ayudar?, supongo que los controles estandar del AX no lo pueden hacer, pero puedes instalar librerías de terceros que lo hagan, tan se puede hacer, que te lo estoy mostrando - reparo el Jefe de TI
- Es posible que con un componente de terceros se pueda, pero primero debemos conseguir licencias, luego aprender a usarlos y aun asi no puedo asegurar que quede como lo quieres - respondió la consultora.
- Les propongo que busquemos una alternativa a ese control, ya sea que ustedes no lo consideren en el arranque, o bien que haya una manera diferente de procesar toda esa información.- agrego la consultora.
- Es que este tipo de vistas son bastante sinópticas, y nos permiten analizar de lo general a lo particular, son analisis dimensionales necesarios para varios niveles de la organizacion- justifico el Jefe de TI, quien defendia el principio de "si lo puedes imaginar, lo puedes programar" y mas cuando ya se habia logrado hacer por el equipo interno de desarrollo lidereado por el y donde incluso el fue el creador del Sistema de Informacion actual.
- si, pero eso definitivamente no podemos hacerlo- sentencio la consultora.
- pues no se si los usuarios esten de acuerdo, debemos consultarlo nuevamente con el director y con el Gerente de Produccion- dijo el Jefe de TI.
- Mira, lo que se me ocurre es que hagamos una interfaz entre tu sistema actual y el AX, de manera que el AX te regrese la informacion que necesitas para que tu sistema genere todas estas vistas, que te parece? - propuso la consultora, mientras el consultor ponia una expresion facial donde intentaba hacer encajar esto que decia la consultora con la necesidad del cliente.
- El problema es que la idea de contar con un nuevo sistema es tambien eliminar el otro que tenias, actualmente tenemos varios sistemas de informacion y la idea es que ahora solo tengamos uno.- dijo el Jefe de TI.
- Entiendo, pero es lo unico que se me ocurre- concluyo la consultora.
- Entonces, en caso de que eso se hiciera, hay cerca de 5 desarrollos de caracteristicas similares, tendriamos que ver que salgan de esa manera todos, que estan relacionadas con el punto del presupuesto y seguimiento de la produccion semanal, por lo que no podemos avanzar hasta decidir eso no?- puso en la mesa el Jefe de TI.
- Asi es, primero deben decidir eso - remato la consultora.
Los Jefes de TI y de Ingenieria salieron meditando la situacion mientras se dirigian a la oficina del Gerente de Finanzas para plantearle el problema y buscar su opinion.
- Pues vamos por el Gerente de Produccion, el director general y reunamonos cuanto antes para decidir- ordeno el Gerente de Finanzas.
Diez minutos despues en la oficina del director General estaban reunidos los Gerentes de Finanzas, de produccion y los Jefes de TI, Ingenieria y Control de produccion.
Los puentes de Madison... no, perdon, quise decir, Microsoft.
-La consultora del Area de Manufactura nos dice que no se pueden obtener reportes como los que manejamos para la medicion de los indicadores de produccion, les resulta sumamente complejo poder hacer reportes con agrupaciones como las hace Excel y nos pide que replanteemos esos puntos - inicio la charla el Jefe de TI
- Una opcion adicional es la de manejar un "puente" entre nuestro sistema actual y el AX para que este ultimo envie la informacion necesaria para que el primero la organice y muestre el reporte.- añadio.
- Sin embargo, esto significa que no podremos deshacernos nunca de nuestro sistema actual- finalizó.
- ¿Que otras opciones tenemos, perdona? - pregunto el Director General
- Pues debido a que ya declararon que no lo pueden hacer desde el AX, tendremos que considerar fuertemente la posibilidad de aceptar su propuesta. - Respondio el Jefe de TI.
- Pero eso es algo que no pueden hacer o no quieren hacerlo? - cuestiono de nuevo el Director.
- Es algo que les resulta muy complejo de hacer, porque dicen que no se pueden hacer esas agrupaciones y que en caso que se pudiera, les llevaria mucho tiempo aprender y otro tanto programarlas- dijo el Jefe de TI
- Pero si nosotros pudimos hacerlo no? o es algo nuevo incluso para nosotros? - pregunto frunciendo el ceño el Director.
- No es nuevo para nosotros, pero aqui usamos lenguajes de programacion diferentes, y herramientas diferentes, ellos solo pueden usar herramientas de Microsoft, o al menos es lo que infieren- alcaro el Jefe de TI.
- Esos puentes, nos pueden causar problemas?- pregunto el Director.
- No en realidad, es solo que el proceso ya no sera tan natural y que debemos interactuar con los dos sistemas-. Repuso el Gerente de Finanzas.
- y tu como lo ves?- le pregunto el Director General.
- Pues creo que podria ser una buena opcion- respondio el Gerente.
- Bien, Adelante, haganlo como propone la consultora- finalizo el Director.
El resto de los presentes se encamino a la salida de la oficina.
- Solo debo aclararle que esta situacion entonces la debemos esperar en muchas de las etapas que faltan, pues principalmente en el Area de Ventas tenemos muchos reportes de este tipo, todos aquellos que usted ha solicitado y en los que pide Analisis Dimensionales, es decir, por Varios Criterios anidados, como Lineas, Modelos, Zonas, clientes, etc. correran la misma suerte- interpuso el Jefe de TI.
El Director volteo a ver al Gerente de Finanzas, quien no se dio cuenta de ello, y con una expresion de duda dijo:
- Ya veremos que pasa mas adelante, debe haber alguna manera de solucionarlo.
- Pero ahi es donde entran los cubos de Informacion no? pregunto el Gerente de Finanzas.
- Si... y no... los cubos son herramientas que al final cumplen el mismo objetivo, pero requieren una preparacion especial y seguro tambien sera algo diferente de lo que actualmente manejamos- respondio el Jefe de TI.
- Con eso lo debemos solucionar- dijo el Gerente de Finanzas, mientras hacia que el resto del equipo saliera de la oficina del director, esto con el fin de que no se siguieran haciendo planteamientos incomodos.
Tomada la decision, entonces se le notifico a los consultores y se acordo seguir trabajando por la tarde.
Aun quedaban algunos desarrollos para el Area de Produccion y el objetivo era documentarlos todos, sin embargo, quedaba poco tiempo para ello, asi que seguro tendria que haber una nueva visita de los consultores pronto.
En la reunion de la tarde se documentaron mas procesos, y los consultores se llevaron cerca de 400 hrs de programacion. Este numero se deberia aterrizar en conjunto con su departamento de desarrollo, pues era solo una estimacion.
La vida sin los consultores.
A partir de la siguiente semana se estuvieron recibiendo por correo electronico los documentos de analisis de requerimientos de cada desarrollo, contabilizando un total de 600 hrs.
Se acordo con el Jefe de TI, que éste deberia preparar el analisis de los procedimientos que requerian de programar un puente.
Al final, fueron 5 procedimientos los que alimentarian a aprox 10 reportes que actualmente se manejan en el sistema de Informacion.
En la siguiente semana se recibieron mas documentos, los cuales, de tiro por viaje presentaban errores, los cuales variaban de forma y fondo. En algunos casos el documento no correspondia exactamente con lo que se planteo durante el analisis, y debido a que ni el Gerente de Finanzas, ni el Jefe de Ingenieria se involucraban en la revision, todos los documentos fueron revisados unica y exclusivamente por el Jefe de TI.
Mayuscula sorpresa fue cuando empezaron a llegar documentos redactados por el nuevo consultor. estos presentaban una estructuracion que ninguno de los otros consultores presentaba, reforzaba sus ideas con graficas, tablas, cuadros sinopticos y diagramas, ademas de una redaccion limpia y clara. es de mencionar que proporcionalmente sus errores fueron menores tambien, por lo que el Jefe de TI informo al Gerente de Finanzas que su percepcion habia sido equivocada, y que este consultor de verdad tenia madera para hacer bien las cosas.
Entre borradores y correcciones, entrevistas via telefonica y via Skype, se lograron documentar las 600 hrs en 3 semanas, en las cuales, no hubo la presencia de los consultores.
A finales de esa tercer semana, la consultora agendo una visita de una semana que tenia como objetivo documentar todos los procesos que faltaban, para tener ya todo el panorama y la cantidad total de horas de programacion, lo que pemitiria determinar una probable fecha de arranque del proyecto.
100 mas 100 no es igual a 200
El lunes, como de costumbre, a las 9 de la mañana que llego la consultora, esta vez sola, se tuvo una reunion para ver el pland e trabajo de la semana.
La consultora indico que se dedicarian 100 horas de programacion por semana para el proyecto, lo que indicaba que con lo que ya estaba documentado y autorizado, se tendria trabajo para 6 semanas, de las cuales, al menos ya deberian ir corriendo dos.
Al final de la reunion, el Jefe de TI fue cuestionado por el Gerente General.
- Entonces cuando vamos a arrancar?
- Segun calculo, lo que falta nos debe llevar unas 300 hrs mas, asi que debemos de estar arrancando por alla del mes de Octubre, no creo que antes- estimo el Jefe de TI
- No nos conviene, debe ser antes, en Septiembre- replico el Gerente
- No creo que eso sea posible, estamos a finales de Junio, son necesarias 7 semanas mas, pero aun hay mucho por hacer una vez que el sistema este preparado segun los desarrollos, y hay pocas cosas con las que se pueda avanzar, incluso, aun hoy, dos semanas despues, no nos han informado que probemos nada.- acoto el Jefe de TI.
Vamos con la consultora otra vez- Repuso el Gerente.
- Crees que podamos arrancar en Septiembre?- cuestiono directamente el Gerente.
- No lo se, depende cuantas horas salgan de los desarrollos que vamos a documentar en esta semana. Yo espero que sean poquitas horas porque los que me lleve estaban muy complicados, si son pocas horas, yo creo que si- explico la Consultora.
- Bueno, al final de la semana platicamos sobre este tema de nuevo. - finalizo el Gerente quien se retiro a su oficina, y el Jefe de TI se quedo con la consultora para inciar el Analisis.
En esa semana se pudieron documentar todos los procesos faltantes, excepto 3, dos de ellos, que el Jefe de TI no consideraba necesario para el arranque y que deberia consultar con el Director General y el nuevo Jefe de Ventas acerca de su real necesidad, y otro que se desprenderia de uno de los puentes que se habian documentado, pero la consultora queria que primero aquel puente que hacia una proyeccion de produccion estuviera terminado, para a partir de ahi documentar el resultado de la proyeccion, Ambos tenian una estructura muy similar en cuanto a la presentacion del resultado.
El mas complicado de todos fue aquel que sirve para la programacion mensual de Embarques. Este presentaba la complicacion de las agrupaciones de nuevo, sin embargo, no se considero conveniente presentar una nueva opcion de puente, sino que la consultora ideo una serie de paneles, con arboles que irian mostrando dinamicamente informacion segun el nodo que se fuera visitando.
Esta opcion era realmente buena y aunque sofisticada, la experiencia del usuario deberia ser sencilla, y mucho mas facil de manejar que el metodo actual del sistema de Informacion que es bastante complejo y debido a la gran cantidad de cambios que se hacen durante la marcha, dificil de controlar.
Durante esa semana empezaron a llegar las notificaciones de que se podian realizar pruebas de algunos puntos, como es de esperarse, el orden no tenia nada que ver ni con las prioridades, ni con el orden de analisis, fueron llegando conforme se iban terminando.
Los pequeños incidentes de las pruebas.
Los primeros desarrollos que se mandaron fueron todos reportes, de pocas horas de programacion, por lo que se avanzaba con cierta fluidez.
Pero el problema vino cuando uno de ellos, requeria cierta "inteligencia" en la programacion, es decir, que el programa tuviera claro que datos regresar segun los datos de entrada.
Uno de estos desarrollos estaba mal, los datos no correspondian con el objetivo ni con lo que estaba planteado en el documento de desarrollo. Se notifico al consultor de la situacion, y despues de analizarlo, llamo por telefono y dijo:
- Esta situacion que vemos aqui amerita una correccion, por lo que les voy a mandar un nuevo documento de desarrollo que explica la correccion que se debe hacer, estos documentos se llaman "incidencias", por este caso, que es un error nuestro, va a ser sin costo, pero esto no quiere decir que todas las incidencias son sin costo, de hecho, esta es la excepcion-
¿"Incidencias"? eso nunca lo explicaron.... el equipo ya sabia que eso podia pasar, pero lo supo porque la empresa comercializadora advirtio de esa sorpresa.
El Jefe de TI tenia entonces la encomienda de evitar en la mayor medida posible la generacion de estas incidencias, o bien que fueran muy costosas. Esto deberia suceder ya que el tenia conocimiento de todos los procesos de la empresa, asi que se esperaba que fuera minima la generacion de estos documentos.
A lo largo del proceso se generaron una 9 incidencias de no mas de 2 horas de programacion.
Sin embargo, hubo un caso donde se requeria que en aquellos desarrollos "puentes" se regresara una tabla que consolida datos de consumos de almacen. Cuando se estuvo probando, y se notifico al consultor que la tabla resultado solo mostraba en ese caso el ultimo registro, el resultado de su analisis y su recomendacion fue el siguiente:
"El documento no contempla la sumatoria en este tipo de casos, por lo que una vez que lo revise con los programadores, dicen que es necesaria una incidencia para hacer que se pueda calcular el acumulado, ya que esto altera el diseño y estructuracion del desarrollo"
El Jefe de TI obviamente puso en tela de juicio ese veredicto, ya que el caso solo ameritaba que se cambiara una instruccion SQL, un par de lineas de codigo adicional y con toda seguridad se podria hacer ese calculo, sin embargo, al final el consultor emitio una incidencia de 2 horas de programacion.
Lento, pero.... Tardado.
El avance en la programacion no fue tan rapido como se esperaba, como ya se menciono, la Ley de Babagge se cumplio una vez mas, y el software no estuvo a tiempo.
Llego la segunda quincena de agosto, y el Jefe de TI elaboro un plan de actividades que presento a la consultora jefe en la que se planteaba como fecha de arranque el 3 de Octubre.
- Este plan se puede lograr siempre y cuando aceleren el proceso de documentacion y desarrollo, se cumplan las 100 hrs semanales que nos prometieron, crees que se pueda hacer esto?- inquirio el Jefe de Ti.
- si, claro, entiendo, pero yo creo que si se puede hacer- respondio la Consultora Jefe
-Ok, entonces necesito que por favor me envies el programa de actividades de los desarrollos, para saber en que fecha estara cada uno y poder planear la fase de pruebas- anadio el Jefe de TI.
- si, claro, te lo envio el lunes- finalizo la consultora.
Llego el lunes y el plan no fue entregado, paso la semana y el viernes llego por correo un nuevo documento para revisar.
Le Jefe de TI notifico esta situacion al lider del proyecto, quien quedo de revisarlo con el Director General.
Las semanas transcurrieron con un avance lento, el Jefe de TI constantemente evaluaba la fecha de arranque, y hacia el 10 se deptiembre convoco a una reunion al equipo reducido.
- Debemos planear una nueva fecha de arranque- aseveró
- Porque no se puede hacer el 3 de Octubre como habian quedado tu y la consultora?,- pregunto el Gerente de Finanzas.
- Porque el avance de la programacion es muy lento, tienen muchas dudas de conceptos que son sencillos, pero lo que yo creo es que en realidad tienen algunos otros proyectos y a este no le estan dedicando el tiempo suficiente- explico el Jefe de TI
- y que propones? - pregunto el Gerente
- Propongo que el arranque sea el 1 de Enero del proximo año. Esto, porque noviembre es un mes muy complicado, ya inicia la parte fuerte del año, donde mayor demanda de producto tenemos, luego viene Diciembre, donde se trabaja mucho tambien, en menos dias por las vacaciones de Navidad, asi que nos conviene empezar en Enero, asi tambien tenemos toda la informacion del ejercicio fiscal en nuestros sistemas actuales, de manera que no debemos tener problemas con el despacho contable externo. - expuso el Jefe de TI
- Ademas, nosotros podriamos limpiar la mitad del piso de produccion, reduciendo el inventario, de esa manera se facilita la carga inicial de produccion en proceso - agrego el Jefe de Ingenieria
- de verdad? - inquirio el Gerente
- Si, con el avance que podemos generar en el area 2 y la rapidez del Area 1, podemos para area 1 una semana antes y dejarla sin inventario. - Explico el Jefe de Ingenieria.
- Pues si se puede lograr, la verdad si nos facilita el trabajo - dijo el Jefe de TI.
- Ok, ahora debemos convencer al Director General- manifesto el Gerente.
Se programo una reunion con el director, la cual se llevaria a cabo dos dias despues.
En esa reunion se expusieron los argumentos anteriores y el Gerente de produccion dijo no estar tan seguro de poder hacerlo.
El Jefe de Ingenieria nuevamente explico que si se podia y dio las razones, con lo que el Gerente dijo:
- Vamos a ver que se puede hacer -
La nueva fecha relajo al equipo, esto les daba mas tiempo para que la empresa consultora a pesar de su lentitud, pudiera terminar la programacion.
Se estimó que a un mes del arranque la empresa consultora habria dispuesto de cerca de 2000 hrs de programacion para realizar 850 que estaban documentadas, con lo cual estaria garantizado el tiempo.
Cercana la fecha inicial planeada (3 de octubre) se comunico al consultora jefe con el Jefe de TI.
- Oye, como van con el arranque?, creo que no se podra lograr en la fecha estipulada no?- dijo con el tono mas calmado que pudo.
- Si, asi es, hay varios factores que nos han afectado, pero el principal es que los desarrollos no han estado a tiempo- respondio el Jefe de TI.
- Si, es que recien mandamos a nuestro Jefe de Desarrollo de vacaciones, dos semanas y eso nos quito tiempo- explico la consultora Jefe
Ese ultimo comentario denota el poco compromiso de la empresa consultora con el proyecto de la empresa.
- Bueno, ya esta y ni modo, te comunico que la nueva fecha de arranque es el 1 de enero, pero esta vez es si o si- sentencio el Jefe de TI
Aceptando esta nueva fecha, y con mas tiempo para programar, se reviso la lista de pendientes y nuevamente se solicito un plan de actividades de los programadores, el cual, para variar, no llego.
Fusion de sistemas. Cuando los puentes estan listos.
Los desarrollos que deberian comunicar el sistema actual con el AX fueron de los que mayor atencion necesitaban, pues se deberia asegurar que el mecansmo diseñado fuera el adecuado para que esa funcion fuera lo mas "transparente" posible para el usuario.
El objetivo de cada desarrollo era entregar un archivo XML donde se encontraria contenido un conjunto de informacion que seria el resultado del analisis. se le pasarian varios parametros (fechas, deptos, etc) y deberia regresar, segun su proposito ciertos datos.
Despues, el Jefe de TI deberia hacer que ese archivo XML lo leyera la aplicacion actual y utilizara el conjunto de informacion en las ubicaciones adecuadas, produjera su propio resultado o producto final, y los usuarios siguieran usando las sofisticadas soluciones con las que actualmente contaban.
Despues de varios intercambios de correos, correcciones, algunas incidencias y mucho tiempo perdido, por fin estuvo listo el primero de los 5 desarrollos planeados.
- Es necesario que hagamos una funcion que utilice el "busssines conector" de AX- propuso el Jefe de Desarrollo de la empresa consultora.
- A mi me parece que seria mejor que hagamos un procedimento almacenado que nos permita llamarlo desde mi aplicacion, y asi es mas "directa" la comunicacion entre los sistemas, y tambien practicamente no afectamos al usuario- replico el Jefe de TI.
- No, eso no se puede. AX no maneja procedimientos almacenados- respondio el Jefe de Desarrollo.
Una expresion de asombro llego al rostro del Jefe de TI, quien decidio no pelear con el jefe de Desarrollo, pues la consultora, al dejar todo en manos de el, tambien lo respaldaba, y no eran momentos para hacer mas rispida la relacion.
El Jefe de TI ya tenia dudas acerca de la real capacidad del equipo de programacion de la empresa consultora, y con este comentario se acabaron de disipar.
Es obvio que el Jefe de TI se referia a procedimientos almacenados en la Base de datos, no en el sistema, sin embargo, el Jefe de Desarrollo realmente desconoce como hacer eso, por lo que entonces, emitio esa respuesta.
De vuelta en el presente, llegaba el momento de tender ese puente y como en la pelicula de Avatar, hacer que dos mundos diferentes se conectaran y fueran uno solo.
Asi que el Jefe de TI empezo a enlazar los modulos.
Despues de un par de horas, seguia pensando que el usuario final tendria que seguir muchos pasos para obtener su producto final. asi que decido por su parte empezar a investigar.
La base de datos del AX esta hecha en SQL Server, por lo que deberia encontrar en la red muchisima informacion al respecto.
Bastaron unas 4 busquedas en Google para que pudiera dar con ejemplos de lo que necesitaba.
Poco a poco empezo a hacer pequeñas pruebas, y al cabo de 4 horas, Voilà! tenia un procedimiento almacenado (funcion de multiples instrucciones que regresa una tabla, en este caso) con el resultado que le arrojaria el Archivo XML.
En poco tiempo logro terminar la aplicacion con el minimo de cambios para el usuario.
Un desarrollo cotizado en 16 horas, el Jefe de TI lo hizo en 13, aun teniendo que destinar tiempo para investigar y aprender como hacerlo.
Esto abre un mundo de posibilidades a la empresa, pues uno de los problemas que se enfrentaran posterior al arranque es el reporteo.
En la actualidad, el sistema cuenta con muchisimos reportes muy peculiares, que el Ax no trae por default y su reporteador es mas de tipo financiero.
Los indicadores, tablas cruzadas y analisis dimensionales se pueden ahcer, pero se requiere una inversion adicional en capacitacion de Cubos OLAP, tiempo en diseñarlos y desarrollarlos.
Los desarrollos casi terminados.
La larga lista de desarrollos poco a poco se fue acortando, el Jefe de TI decidio entonces suspender los trabajos de los 4 desarrollos de interface que estaban pendientes y solo quedan 3 pendientes.
Esto hace que la empresa ya este en el umbral del arranque y se estan planeando las actividades que se deben hacer durante el mes de diciembre.
El retraso en los tiempos de los desarrollos de cualquier manera afecto varios planes. pues no se ha podido probar el sistema con su forma definitiva.
Por su parte, el Jefe de Ingenieria y el Jefe de TI estan preparando la carga de informacion.
Ya se tienen listos los RFC, datos de clientes y proveedores, el catalogo de Articulos y el primer archivo de las rutas de proceso (son 4).
Tambien se tiene informacion lista de los listados de materiales, para empezar a prerarar las plantillas y subirlas.
- Como has visto a los consultores?- pregunto el Directo General al Jefe de TI.
- La verdad, lentos. sus tiempos de respuesta no son los mejores y eso ha hecho que este proyecto sea tan largo, la verdad, creo que no estan a la altura de las expectativas ni de lo que necesitabamos- respondio sin reparos el Jefe de TI.
- Que mal por ellos, deberian ser mas agiles, no?- finalizo el director.
Aun quedan muchas tareas por hacer:
- Terminar de subir la informacion de base
- probar el sistema
- Capacitar a usuarios
- subir informacion contable de arranque
Este ultimo punto reprenseta un dolor de cabeza, pues la empresa no puede dejar sin inventario (como sugirieron los consultores) el piso de produccion.
Aun se debe planear adecuadamente ese punto, para ello, se solicito a los consultores su presencia en las oficinas ( no han tenido visitas desde hace 5 meses), pero han argumentado que no tienen disponibilidad por ahora. pero que se puede hacer via skype.
A Dios rezando y con el mazo dando.
Mientras se trabaja en la definicion de los listados de materiales por parte del Jefe de Ingenieria, el Jefe de TI esta avanzando con la definicion de las rutas de produccion.
Se usan 4 plantillas para hacer esta tarea, donde ya se entrelaza la informacion previamente capturada, es decir, los articulos, sus dimensiones (tamaño, color). Una de las desventajas del modulo que permite cargar la informacion es que cuando hay errores, no los notifica rapido. si avisara e interrumpiera al primer error, se podria hacer mas agil la carga, pero por el contrario, el modulo intenta cargar toda la informacion y es hasta el final cuando muestra los errores generados.
El dia de hoy tambien se notifico al Jefe de Ventas que ya deberian capturar los precios con los que va a arrancar el sistema dentro de 3 semanas.
A las 4:20 P.M, hubo una reunion via Skype entre los consultores de Finanzas, Manufactura, el Gerente de Finanzas y el Jefe de TI. En esta reunion se tocaron puntos referentes a la carga inicial de informacion para el area de produccion.
Realmente es complicado capturar la información de la producción en proceso, asi que se decidio seguir una estrategia donde el "daño" sea minimo.
Los consultores aclararon algunos conceptos, pero el Jefe de TI (que tambien tiene conocimientos en finanzas) propuso al Gerente de Finanzas modificar algunos criterios en el cierre de mes, de manera que se evite una situacion confusa ante una información auditoria fiscal.
El Gerente de Finanzas y los consultores estuvieron de acuerdo con la propuesta y con eso se soluciona esa parte del problema.
El punto que no se pudo resolver satisfactoriamente para la empresa fue el de adelantar captura de produccion, pues precisamente por la integracion contable, se generarian transacciones que alterarian inventarios y costos, asi que esta decidido que la captura iniciara una vez que este cerrado el sistema contable, es decir, unos 3 dias habiles antes del arranque.
El Jefe de TI y el Jefe de ingenieria siguen en su dura tarea de cargar los catalogos iniciales, y eso ha provocado que se cancele una reunion donde se pretendia explicar al equipo todo el funcionamiento del sistema, sin embargo, se debe dar prioridad a la carga de la informacion.
En el resto del dia se esta haciendo la carga del tercer archivo de las rutas de proceso (3/4). El Jefe de TI vigilara mas tarde via remota que la carga se haya hecho correctamente.
Preparando las Listas de Materiales...
El archivo 3/4 cargo satisfactoriamente en el segundo intento, por error, se indico una operacion que no estaba contenida en uno de los catalogos de base asi que mas de 10,000 registros que tenian esa referencia no pudieron ser cargados, pero una vez identificado el error, se pudo subir la informacion.
Al siguiente dia se empezo a trabajar la plantilla no 4, la cual debe indicar el detalle de la operacion de ruta, la cual fue "predefinida" en la plantilla 3, sin embargo, algunas dudas asaltaron al Jefe de TI y decidio comunicarse con el consultor, el cual quedo de revisar la situacion y responderle mas tarde.
Fue necesario replantear la codificacion de los centros de trabajo, pues un desarrollo "choca" inevitablemente en alguna parte.
El Jefe de Ingenieria es de memoria corta y olvido que cuando se definio el desarrollo que esta polarizando esta plantilla, se acordo que se crearia un concepto llamado "grupo de operadores", el cual, tendria relacion con la captura de las operaciones en piso, para asi saber que operador u operadores realizaron que operacion.
Esto no es una funcion natural del Sistema, por lo que se solicito se adecuara.
El riesgo de esto radica en que cualquier movimiento de personal debe ser capturado inmediatamente, modificando los grupos de operadores correspondientes, tanto el grupo al que pertenicia, como el grupo al que ahora pertenecerá.
Hoy, a pocos dias del arranque, el Jefe de Ingenieria dice que eso seria mucho trabajo, porque la plantilla de personal se mueve mucho durante el dia, no son posiciones fijas.
La leccion de esto es que es muy recomendable que todos los acuerdos queden por escrito en una Ficha de resoluciones, aun los internos. Es muy facil aceptar una idea, aun cuando no se entienda bien, pero tarde o temprano, los riesgos se manifiestan y se deben aceptar las consecuencias.
El Gerente de produccion no tomo con agrado la noticia de que no puede empezar a capturar informacion en el sistema antes de la preparacion de saldos contables de fin de año. con una visible molestia fue a donde el Jefe de TI para increparlo.
- ¿Cuando tuvieron esa conferencia con los consultores?-
- Ayer -
- Y porque no se puede capturar como habiamos platicado hace unos dias?
- Porque en el momento de registrar movimientos de produccion se generan transacciones de inventarios y de costos y como el sistema no tendra existencias ni esos parametros, marcara errores- respondio el Jefe de TI
- Entonces no es necesario hacer el inventario de fin de mes-
- Porque no? -
- Para que?, si no lo vamos a capturar en el AX-
- No tiene que ver con eso, el inventario se debe hacer para hacer los calculos de consumo del inventario que se quedara en piso y que una vez cargados los saldos iniciales, estos vayan reconociendo el consumo-
- No... es que es mucha captura....
El Jefe de TI hizo una pausa, no habia mucho que agregar, el Gerente de produccion deberia lidiar con su propio problema, todo el equipo, del cual él es parte, sabia que el gran problema del arranque es produccion y al parecer no tiene intenciones de colaborar entusiastamente.
- Si una herramienta que les pedimos a los consultores se puede desarrollar, esa captura sera mucho mas rapida, pero si no, y lo debemos contemplar, tendra que ser todo de forma manual, registro por registro, operacion por operacion.- explico el Jefe de TI
El Gerente de produccion meneaba la cabeza, se mordia el labio inferior, luego las uñas, fruncia el ceño y miraba al cielo.
- Es que ya les dije a todos que el inventario ya seria desde el AX- dijo el Gerente
el Jefe de TI levanto los hombros en señal de que el no podia hacer nada.
-Pues no, ya valio madres todo- finalizo el Gerente mientras pateaba la silla intentando intimida al Jefe de TI mientras este lo ignoraba y seguia tecleando en la computadora de un usuario a quien precisamente se le estaba instalando el sistema.
El Gerente de Finanzas, lider del proyecto, observo la escena pero no hizo nada por entrometerse.
El Jefe de TI empezo a preparar la informacion de las listas de materiales, en este momento ya esta arriba un 70% de la informacion necesaria para el arranque del sistema, sin embargo, el 30% restante requiere de mucho esfuerzo.
Es un error en este tipo de proyectos, que los directivos no dimensionan el tamaño de las tareas.
En esta empresa, el Depto de TI esta conformado por una sola persona, y en este mes, el ultimo, se requiere el 100% del tiempo del equipo de trabajo. sin embargo, tambien se debe hacer el trabajo normal de cada dia, y aunque todos ven que el Jefe de TI y el Jefe de Ingenieria no tienen ni un minuto de respiro, nadie tiene el valor de apoyarlos.
Ellos, desde hace tiempo que solicitaron asistentes, pero la mentalidad de los empresarios o siempre es precisamente empresarial.
Eso no se puede hacer....
Las listas de materiales por fin quedaron listas, despues de semanas de intenso trabajo, mucho Excel y otro tanto de programacion, se pudo completar la carga de la informacion inicial.
Era tiempo de preparar las rutas.
Las rutas de produccion son parte sensible del proceso de productivo, pues ellas permitiran que el consumo de los materiales se vaya dando conforme se van registrando los diarios de ruta, es decir, las operaciones que se van realizando.
Para esta carga, inicialmente se presentaron 4 archivos, los cuales eran bastante parecidos a los de las listas de materiales, de manera que el 1 y 2 practicamente solo se copiaron.
el 3 y 4 ya tenian mayor complejidad, bueno, en realidad tenian mas informacion, no eran tan complicados.
El Jefe de Ingenieria abusa de su sentido de "practicidad", y aunque aparentemente es lo mismo enumerar "1,2,3..." que "A, B, C..." en realidad no es asi. Un identificador o llave debe ser lo suficientemente breve y descriptivo como para que indique al capturista, usuario o analista de a que se esta refiriendo.
El Jefe de TI propuso al de ingenieria que hiciera una nueva identificacion de los centros de trabajo, a lo que este no quiso hacerla, argumentando que asi estaban bien, que el no veia problema.
Cuando el Jefe de TI empezo a ver como relacionar la informacion del sistema actual con la nueva, vio que era mas conveniente la renumeracion, por lo que aun con la negativa de Ingenieria, decidio hacerla.
Al final, el Jefe de TI termino aceptando la situacion, pues tampoco era un problema mayusculo.
Cuando se estaba preparando el ultimo archivo, Jefe de TI observo que faltaba un campo, el que describia la operacion a realizar. Inmediatamente se puso en contacto con el Consultor quien quedo de enviarle una correccion de la plantilla al dia siguiente.
Mientras analizaba la informacion de las rutas, el Jefe deTI cayó en la cuenta de que no incluyo un registro que la empresa recien habia iniciado, el de saber que Persona realizo que operacion en el piso de produccion.
Cada maquina es operada por una o mas personas, y actualmente se registra la cantidad de piezas que trabajo cada maquina, de manera que al indicar los numeros de operadores de esas maquinas, se sabe que hace cada quien, asi si los trabajadores cambian de maquina, se puede seguir llevando un registro de operaciones por persona.
Este problema fue expuesto al Consultor y a la Consultora Jefe mediante un correo electronico, en él, se proponia ademas que para agilizar este proceso se programara un Trigger en la Base de datos, de manera que se leyera la configuracion del grupo de operadores asociado al diario de ruta e instantaneamente se guardara la relacion de esos operadores con la linea del diario. El Jefe de TI propuso que para ahorrar tiempo, el podria desarrollarlo.
Al dia siguiente, el Jefe de TI tenia varios mensajes del consultor, uno donde explicaba que tardaria algunas horas mas para tener lista la plantilla de carga de las operaciones de ruta, de hecho, tendria que hacer una nueva plantilla, asi que con eso no se podia avanzar.
Una hora despues, el Gerente de produccion busco al Jefe de TI para exponer un nuevo plan para la toma fisica de inventarios, la cual, consistia en parar 3 deptos de la planta y acelerar los dos siguientes, de manera que el inventario se concentrara en un solo depto donde inicia la segunda fase del control del AX, esto facilitaria enormemente la carga inicial.
Una vez que estuvieron de acuerdo, se empezo a trabajar para lograr ese objetivo.
La consultora Jefe llamo por telefono al Jefe de TI para revisar los pendientes.
Una vez conciliados, este le pregunto por el correo del dia anterior donde solicitaba el desarrollo del trigger o su autorizacion para elaborarlo en en su momento.
- Ya te contestaron, no has visto el correo?- dijo la consultora jefe
- No, pero sabes?, ayer tuve problemas con mi correo porque se saturo, enviamelo de nuevo por favor- respondio el Jefe de TI
- Ok, te platico: basicamente Desarrollo dice que no se puede hacer eso que propones, pero ahi te enteraras de las razones que dijo el Jefe de Desarrollo
- De acuerdo, despues de comer lo leere-concluyo el Jefe de TI
Este comentario encendio la ira del Jefe de TI, quien una vez mas tenia que luchar contra las malas costumbres del equipo de desarrollo de los consultores, parece ser que la leccion de los Procedimientos almacenados no habia sido suficiente.
Visiblemente molesto se presento a la mesa junto con sus compañeros, quienes fueron testigos de un enojo pocas veces visto en esa persona.
Despues de comer, el Jefe de TI abrio su correo y leyo:
"Eso que dices no se puede hacer, AX elimina automaticamente todos los aditamentos de la base de datos cada vez que se compila, por eso no podemos hacer triggers, ni clases ni procedimientos que no sean en su lenguaje nativo el X++, no nos podriamos hacer responsables por programacion de ese tipo"
Entonces el Jefe de TI emitio una respuesta energica, donde manifestaba que no estaba de acuerdo con ese argumento puesto que ese dia precisamente se habia compilado la aplicacion para subir unas opciones nuevas y los procedimientos que el habia elaborado dias anteriores aun estaban presentes, le anexo una impresion de pantalla. Este correo fue enviado con copia para la consultora Jefe y desde entonces, no ha recibido ningun correo de ningun consultor, solo ha tenido un par de conversaciones con el de Finanzas.
Toda la informacion arriba!.
Por fin llego el dia en que toda la informacion estuvo lista, no exenta de errores, que fueron detectados y corregidos.
La nueva plantilla requeria de la resolucion de dudas por parte del consultor de manufactura, que en ningun momento respondio mensajes de Skype ni correos. Sin embargo, el Jefe de TI pudo resolver los problemas y cargar la informacion.
El siguiente paso entonces es el de hacer pruebas de todo el sistema, aunque aun faltan algunos desarrollos por instalar, ya se puede probar el 95% del sistema con su forma final.
Durante estas cargas, se generaron inquietudes en el Jefe de TI y el Gerente de Finanzas respecto al calculo del costo.
El sistema actual de la emrpesa fue diseñado para poder hacer del calculo del costo una ventaja competitiva para la empresa, ésta puede decir que tiene uno de los sistemas de costeo mas precisos y justos de su ramo, totalmente justificable y demostrable.
Pero el AX tiene muchas sorpresas y entre ellas, esta precisamente el costo.
Es increible la falta de sensibilidad de los consultores en asuntos tan delicados como este, pues las explicaciones de estos puntos fueron tan ligeras y vagas que se tiene la idea de que es algo que no dominan.
Asi que nuevamente la empresa tiene que buscar por sus propios medios.
El Jefe de TI pudo identificar que faltan algunas configuraciones en los articulos, los centros de trabajo y las rutas, necesarias para que se alimente correctamente la hoja de Gestion de Costos, asi que se dio a la tarea de alimentarlas.
Por su parte el Jefe de Comercializacion empezo a alimentar los precios de los articulos.
Tambien la Jefa de Contabilidad ha empezado a capacitar a su asistente de tesoreria.
el Gerente de produccion y su asistente ya estan muy involucrados en su proceso asi que cada vez mas personas empiezan a ver que es inminente el arranque del nuevo sistema.
Una probadita de todo el sistema
El Gerente de finanzas convoco a una reunion donde se observaria el flujo completo de todo el sistema, seria la prueba de fuego- en palabras de el - del sistema. Se trataria de seguir un orden logico y bastante general de cada proceso dentro del AX.
El encargado de dirigir la sesion seria el Jefe de TI, pues el es quien conoce mejor el sistema.
Uno a uno, los invitados empezaron a llegar, y el control de la computadora portatil de la sala de juntas fue cedido al Jefe de abastecimientos/Ventas.
- Bien, traigo un pedido real, de nuestro principal cliente - indicó
- De acuerdo, capturalo- dijo el Jefe de TI.
El Jefe de Abastecimientos empezo a capturar sin problemas,se registro la orden de venta, se verificaron los precios y descuentos.
El siguiente paso seria generar las ordenes de produccion necesarias para surtir ese pedido al cliente.
El Jefe de Abastecimientos empezo entonces el proceso de planeacion maestra, con el fin de que programara todas las ordenes de compra de los materiales y las ordenes de produccion.
Unos segundos despues, el sistema arrojo una ventana con errores: La configuracion de las conversiones de unidad de medida de unos 8 articulos era incorrecta o no estaba indicada.
Un silencio tenso se hizo, pues se recordaron las sensaciones donde por fuerza se tenia que tocar base con algun consultor, pero en esta ocasion tanto el Jefe de TI como el de abstecimientos sabian que hacer, asi que las correciones se hicieron rapidamente.
Se volvio a correr el proceso y ahora marco error con otras unidades.
Alguien cuestiono: "porque no los marco todos de una sola vez?" y esa es buena pregunta, de la cual no sabemos la respuesta, son de las cosas que acostumbra a hacer el AX.
Como eran muchas las correcciones por hacer se decidio suspender la reunion.
y el Jefe fe TI y el de Abastecimientos se dedicaron a corregir la informacion tanto en la empresa de pruebas como en la "oficial".
Para agilizar el proceso, se decidio que no se hiciera el proceso de todas las ordenes de compra y se agrego inventario desde un Diario de Recuento, asi las producciones tendrian materales para consumirse.
Al estar haciendo este proceso se observo que con algunos materales no se pudo capturar el diario, el error solo decia: el Articulo no tiene parametros de inventario, por lo que el Jefe de TI tomo nota para revisarlo con los consultores.
Al terminar, se reunio de nuevo al equipo
Despues de las correcciones, el proceso se completo, lo que calmo el ambiente en la sala de juntas.
Se reviso la planeacion y se observo que faltan de configurarse los minimos de compra de cada articulo.
El Jefe de Abastecimientos tomo nota de ello.
Llego el turno del Asistente de produccion. Era momento de programar las ordenes de producion.
El procedimiento consistia en Ir al modulo de planeacion, marcar las ordenes de produccion y ponerlas en firme, algo muy sencillo... excepto porque volvio a marcar error. El mensaje decia: "el articulo no tiene parametros de inventario".
el Jefe de TI hizo un cambio rapido de empresa, se fue a otra donde se estan haciendo pruebas y se continuo desde ahi la explicacion, sin embargo, todos sabian que algo andaba mal y se deberia corregir antes de poder continuar.
Se decidio entonces que la reunion fuera terminada, y el Jefe de TI quedo de revisar esos puntos.
La respuesta del consultor fue:
Ah, si, eso es normal, porque como no subes la informacion de base desde el sistema, sino por plantillas, es necesario correr un script para que se liguen los datos de los articulos.
Haberlo dicho antes! Los consultores sabian que ya estaba la informacion arriba, incluso, tenian un cronograma de actividades, donde se especificaban las fechas, la molestia viene entonces porque no comentan este tipo de "detalles" a tiempo?. Esos finos aspectos son la diferencia entre un real consultor y alguien que se llama consultor.
Ya se pudo!.
Al dia siguiente, despues de haberse corrido el famoso script, el Jefe de TI se puso a hacer el flujo completo y esta vez salio practicamente sin problemas!.
Se registro una orden de venta
Se hizo la planeacion
Se colocaron ordenes de compra
Se recibieron tanto la mercancia como la factura
Se reviso el inventario disponible
Se pusieron en firme las ordenes de produccion
Se estimaron. Anque aqui si se observo un detalle, la estimacion no mostro los articulo de la lista de materiales que eran tipo "articulo", al momento, esto aun no ha sido resuelto por los consultores.
Se iniciaron las ordenes de produccion. y aqui se observo que 3 desarrollos no estaban instalados, al final por una configuracion se activaron dos, y por la noche se instalo el tercero.
Se registraron los diarios de ruta y los diarios de listas de materiales
Se notifico como terminada cada op
Se genero inventario de piezas y muebles
Se Programo el embarque
Se realizo el embarque o "picking"
Se facturo y
Se calculo la balanza de comprobacion donde se observo que habia costos registrados, impuestos, saldos con clientes y proveedores.
Esto es un aliciente, pues al menos el proceso, de forma general y sin las variantes, detalles y casos raros que cada organizacion tiene ya pudo correr.
La prox semana vendra el consultor de finanzas a apoyar en la carga de informacion contable, aun hay mucho por hacer, pero se tiene la confianza de que todo salda bien.
El Jefe de TI ya programo una utileria que extrae del sistema anterior los saldos de clientes y proveedores para alimentar el diario de contable.
Viene una semana crucial, es cierto que no se ha realizado el 100% del protocolo que propusieron los consultores, sin embargo, hay confianza de sacar adelante esta empresa.
La leccion bien aprendida es que el valor economico de la consultoria debe ser la mitad del valor cualitativo de la misma. En nuestro caso, ha sido al reves, sin embargo, esperamos sea suficiente para que ello, y el trabajo de unas pocas personas de la compañia logren implmentar con exito este sistema (y no morir en el intento)
Lunes: Captura de Ordenes de Venta.
Este dia se realizo la captura de las ordenes de venta. el personal de Ventas se dedico a capturar cada pedido abierto.
Triste fue la sorpresa cuando el encargado de atencion al cliente dice: Hey!, no encuentro un producto!.
El Jefe de abastecimientos y el Jefe de TI acudieron a su lugar como quien socorre a un accidentado.
¿Cuantos mas has detectado?- pregunto el Jefe de TI.
Pues ahorita solo este, pero es el juego completo, es decir, las 5 piezas.- respondio el encargado.
- Yo tambien encontre otro - menciono la encargada de trafico.
- Demonios!, - ladro el jefe de TI- el director y el diseñador mandaron la lista incompleta!
- Algunos de estos productos ya se habian descontinuado,pero algunos clientes los pidieron y el director dijo que se fabricaran otra vez, aunque algunos tambien tienen mucho tiempo estancados, y no es seguro que se vayan a surtir- comento el encargado de atencion al cliente.
- cuando terminen me pasan una lista de los articulos que faltan- solicitó el Jefe de TI.
Esta semana es de vacaciones para casi toda la organizacion, solo las personas que tienen algo que ver con el nuevo sistema estan trabajando, esto ya no incluye al diseñador porque se penso que esa lista estaba revisada y confirmada.
Lo largo del proyecto y la falta de concienca y dimensionamiento de la tarea que se esta haciendo ha provocado esta situacion.
- al cabo toda la informacion esta en el sistema actual- dijo el Jefe de Ingenieria queriendo consolar al de TI.
- si, pero es un trabajo que ya hice, es el mismo esfuerzo hacerlo para los 30 articulos que faltan que para los 400 que ya procese, se requiere mucha concentracion y labor en excel y en SQL. esto no deberia estar sucediendo- se lamento el de TI- ahora tengo que hacerlo de nuevo, y no me llevo 5 minutos en hacerlo.
Por otro lado, los inventarios de toda la empresa ya estan auditados, asi que se espera que mañana llegue el consultor de finanzas de la empresa consultora y se inicie la carga de los mismos, esta tarea se espera que se lleve 2 o 3 dias.
Tambien, el Jefe de Costos ha revisado la hoja de gestion de costos, y la comprende mejor, aunque no es el modelo mas adecuado para la organizacion, se tratara de convivir con ella.
La parte que no es la mas adecuada es la de la asignacion de los gastos de fabricacion, como bien se dijo con anterioridad, el sistema de computo de la empresa fue diseñado para darle un alto valor al calculo del costo de produccion y una alta precision, con el AX, que costea en base a factores, esto no sucedera.
Suponga el siguiente caso:
Ud estima que gastara 100 USD de salarios en el mes, alimenta un valor para cada hora de produccion, sin embargo, la empresa "produce" mas horas de las esperadas, y el gasto en realidad es de 120 USD.
Financieramente, la diferencia se asigna directamente al Costo de lo Vendido, lo cual, no es un problema.
Pero desde la contabilidad de costos esos 20 USD de diferencia jamas fueron parte de las ordenes de produccion. como sabra la empresa, cual orden de produccion es la que genero ese sobregasto?, podria suceder que una orden de produccion subsidie entonces a otra, o que un producto sea mas barato de lo que en realidad es, o por el contrario, mas caro de lo que se esta estimando.
Si antes, la empresa tenia forma de calcular el costo real de una orden de produccion, a partir del AX, el costo real, no lo es tanto.
Es esto una ventaja?, se esta regresando en el tiempo 8 años, ese problema era el que se tenia antes de que la empresa decidiera hacer su propio sistema de computo.
Martes: Carga de Inventarios de Almacenes.
El dia martes llego a las oficinas el consultor de finanzas, despues de los saludos respectivos, se reunio con el Jefe de TI para revisar el plan de la semana, durante esta revision se acordo tener una pequeña reunion con los contadores de la empresa para planear la carga de los saldos iniciales de contabilidad.
En esta reunion explicó que la carga inicial deberia ser gradual, iniciando por subir inventarios, posteriormente las facturas pendientes de pago de los clientes, luego las pendientes por pagar de proveedores, despues subiria saldos de bancos, contabilidad General y por ultimo se hacen los ajustes finales sobre todo de la parte de impuestos.
Explicaba el consultor que solo dos de sus clientes han podido hacer que la carga inicial cuadre al centavo con la contabilidad de los sistemas anteriores, la segunda empresa de esas fue la empresa comercializadora hermana de la empresa del caso que nos ocupa.
-No esperabamos menos de ellos!. dijo el Jefe de TI.
El proceso a decir verdad es sencillo, pero se hace mucho incapie en que las cargas previas a contabilidad deben cuadrar perfectamente.
Terminando la reunion el Jefe de TI se dispuso a probar la informacion de los articulos que faltaron y que se detectaron durante el lunes, en la captura de ordenes de venta.
Las 15 plantillas subieron con algunos errores en una empresa de pruebas, errores ocasionados en la preparacion de las mismas los cuales se fueron corrigiendo para que suban sin problemas en la empresa definitiva.
Solo una de las plantillas causo errores, el cual fue notificado inmediatamente a los consultores, los cuales estan en proceso de averiguar de que se trata.
No todas las personas de la empresa estan muy conscientes del trabajo que se esta haciendo, y se refleja desde niveles altos de la organizacion hasta el nivel de los usuarios.
Debido a mala administracion, el Analista de costos ha ocupado funciones del depto de RH, esto obviamente ha hecho que haya retrasos en la preparacion de la informacion.
El dia martes deberia estar lista la informacion de inventarios, esto de acuerdo al plan, sin embargo, a las 12 del dia aun no se empezaba la preparacion.
El Jefe de Costos ordeno se le diera prioridad a esta situacion, asi que el Analista de Costos/Encargado de RH debio volver a sus labores normales durante unas horas.
A las 6 :20 de la tarde la informacion estaba lista.
Mientras el Jefe de TI preparaba la plantilla, observo que muchos articulos que tienen inventario no estaban registrados en el nuevo sistema.
Inmediatamente llamo por telefono al Jefe de Abastecimientos (el cual ya habia salido de oficinas) pero èste no le contesto.
Decidio entonces enviar un correo electronico notificandole que de los 951 articulos con inventario en almacenes, solo se tenian 553 registrados, era necesario dar de alta todos los demas.
El Jefe de Abastecimientos pidio le fuera enviado por ese mismo medio la relacion de los articulos para prepararla y subirla el miercoles.
Esto retrasara el plan alrededor de 4 horas. Se espera que el miercoles a las 12 del dia ya esten los inventarios de Almacen en el sistema.
Al final del dia no se pudo lograr el objetivo y el dia miercoles se debera recuperar ese tiempo perdido.
Miercoles.
El equipo de ventas se dedico a la tarea de registrar todos los pedidos en adelante llamados "Ordenes de venta" que tenian pendientes, durante esa captura se encontro que aun no habian sido registrados varios modelos completos, incluyendo sus listas de materiales y rutas.
Este hizo que hubiera un nuevo retraso, y debido a que ya no habia personal del area de produccion, pues se creia que todo habia sido analizado, el Jefe de TI se dedico a obtener la informacion que faltaba.
La empresa consultora envio una serie de plantillas para cargar esa informacion, asi que se debio hacer una nueva preparacion, esta tarea se lleva aprox 1 dia de trabajo, asi que practicamente en esto se ocupo todo el miercoles.
Jueves.
El jueves se presentaron dos personas de produccion con el fin de capturar las ordenes de produccion pendientes, sin embargo, habia varios impedimentos para ellos, primero que habia varios modelos no cargados aun, segundo, que el desarrollo de la impresion de tarjetas de ruta no estaba completo y para rematar, cuando se estaba haciendo la carga de la informacion generada el dia anterior la plantilla de las operaciones de ruta no estaba completa.
Ese dia fue desperdiciado en cuanto a tareas del nuevo sistema se refiere, pero el area de produccion aprovecho el tiempo para poner al dia sus indicadores, anticipando que la prox semana no tendrian suficiente tiempo para hacerlo.
Este dia tambien seria el ultimo que se presentaria el consultor de finanzas, de manera que deberiamos ensayar las cargas de contabilidad.
Primero se preparo informacion de clientes la cual subio sin problemas, o al menos eso parecio, los saldos fueron correctos, y las cuentas afectadas correctamente.
Cuando se subieron proveedores, se tuvo un problema, pues una factura en dolares subio con un tipo de cambio incorrecto, esto debido a que algo pasa en la carga del Ax que se debe indicar el tipo de cambio multiplicado por 100
se reviso entonces la informacion de clientes y aunque era solo informacion en moneda nacional, tambien tenia un tipo de cambio incorrecto.
Afortunadamente el ensayo nos dio este problema, de manera que este punto se tomo en cuenta en la carga definitiva.
Viernes.
Se subio la informacion de todos los articulos que faltaban, pero siguen pendientes todas las operaciones de ruta, pues la plantilla tiene problemas, tambien se observo que ciertos desarrollos requerian ajustes de ultima hora, y la empresa consultora solo trabajo medio dia.
A pesar de ello, se avanzo hasta donde se pudo, y se dejo pendiente solo algunos puntos.
A estas alturas, el desarrollo del registro de las tarjetas de ruta aun no esta listo. Y no se puede arrancar sin el.
En la empresa, el cierre contable del mes de noviembre apenas fue terminado, y se debe trabajar a marchas forzadas con diciembre.
El analista de costos ha hecho un esfuerzo enorme, y lleva un avance excelente, sin embargo, no se salva de trabajar el fin de semana.
Sabado.
El sabado fue una jornada practicamente normal para el Jefe de costos y su analista, se dedicaron todo el dia a calcular el cierre de diciembre y determinar el costo de cada pieza que se subiria al AX.
La plantilla con esta informacion quedo lista a las 5 de la tarde, sin embargo, se deberia esperar la revision que hace el Gerente de finanzas para determinar que estos datos ya son definitivos. La revision se realizaria el domingo.
La jornada termino a las 8:30, y de ahi, cada quien a festejar y recibir el año 2012 con sus familias, muertos de cansancio, muy estresados, pero no hay tiempo para lamentaciones.
Domingo.
El dia anterior, el Jefe de TI se dio cuenta de que datos de las listas de materiales eran incorrectos, y que seria necesario generar una nueva carga de ellas, de manera que en un dia se preparo la informacion, que ascendio a cerca de 35000 registros en excel para redefinir los elementos que consume cada pieza y mueble.
El domingo, el Jefe de TI realizo la carga de esa informacion, fue un trabajo de 4 horas.
Lunes, vispera del arranque....
Este dia pintaba para ser verdaderamente largo, pues se realizaria la carga de los saldos iniciales de contabilidad. Aunque ya algunos estaban ensayados, este dia seria la revision final de saldos y la creacion de los diarios de contabilidad que representarian el real arranque de operaciones.
A las 9 de la mañana llego el consultor de finanzas, el cual jamas habia tenido contacto con la empresa. sin embargo, su ayuda fue realmente util, ya que su actitud para resolver los problemas que se presentan destacan sobre el resto de ellos.
Pasaron las horas y se subio la carga inicial de inventarios sin problemas
Luego, estuvieron listos clientes y proveedores, y aqui ocurrio una situacion que aunque se trato, no pudo evitarse: habia un anticipo de clientes que registrar.
El consultor sugirio esperar hasta que la carga de saldos de contabilidad estuviera lista para ver si esto representaba en realidad un problema.
A las 5:30 de la tarde los contadores estaban terminando de revisar la balanza de comprobacion, la cual representaria el ultimo paso para que el sistema estuviese listo para funcionar.
Un par de horas despues, se confirmo que la informacion podria subir.
Se realizo la carga, con un toque de suspenso pues el Jefe de TI puso como musica de fondo "la marcha imperial de Darth Vader" parte del soundtrack de la Guerra de las Galaxias.
La carga se realizo y entonces el momento que todos esperaban: que las cuentas puente quedaran en cero, eso representaria el 85% del exito de la carga.
Las cuentas de inventarios y proveedores no tuvieron problemas, pero si clientes, precisamente por los saldos del anticipo.
El contador general se puso entonces a analizar la situacion, mientras el resto del personal empezaba a resentir los efectos del cansancio.
A la 11 de la noche, el contador general, haciendo una brillante demostracion del dominio de su area, resolvio correctamente el crucigrama y decidio crear un diario con un par de movimientos que reclasificaran el anticipo.
Ahora solo faltaba cuadrar impuestos, tarea que se llevo aprox 1 hora, y una vez listo, se genero la balanza de comprobacion desde el AX. TODO ESTABA LISTO!.
a las 2 de la mañana el equipo se retiro a sus casas, las actividades del sistema empezarian en 6 horas mas, cuando regresara el resto del personal del descanso de invierno.
En sus marcas, listos....
La primer hora fue de saludos y deseos de un mejor año entre todos los colaboradores de la empresa, nadie realmente se animaba a dar el primer paso en la operacion del nuevo sistema. a las 9 de la mañana llego el consultor y la consultora jefe.
A esa hora tambien entraron en reunion el equipo de implementacion, los supervisores y los capturistas y se delegaron las primeras tareas.
Habria que recuperar el tiempo perdido y agregar todas las ordenes de produccion que se quedaron en piso.
Esta tarea se llevaria aprox medio dia. mientras tanto, los consultores seguina tratando de hacer que funcionara un desarrollo en unas terminales de radio frecuencia, el cual, no completaba el proceso.
El primer dia transcurrio en relativa calma, mostrando que en realidad se estaba en el ojo del huracan.
Dia 2.
El segundo dia fue de mas actividad, se empezaron a crear ordenes de compra, a recibir mercancias, a transferir a los deptos y a registrar ordenes de venta. contabilidad tambien empezo sus tareas, pero produccion aun no arrancaba, el desarrollo de las Terminaes de RF seguia sin funcionar, y la impresion de etiquetas de produccion presentaba fallas debido a que durante la fase de analisis de esos desarrollos no se alcanzo a visualizar el mecanismo completo, y habia datos incompatibles con otras partes del sistema.
La consultora Jefe atendio diligentemente esta situacion haciendo que esas actividades fueran realmente rapidas y eficaces y que en el mismo dia se pudieran corregir.
El segundo dia fue mas intenso, pero produccion no alcanzaba a estar listo.
Dia 3.
El tercer dia produccion tenia que arrancar si o si.
Hacia las 11 de la mañana el desarrollo de las Terminales de RF empezo a funcionar correctamente, asi que empezo la lluvia de informacion de produccion.
Se reunieron en la sala de juntas los capturistas, supervisores, el gerente de produccion y el Jefe de TI para ver la estrategia a seguir para nivelar el estatus de la produccion.
Despues de explicar algunos conceptos, el Jefe de TI capturo los primeros movimientos a manera de muestra y los capturistas, uno a uno, empezo a integrarse.
Durante la revision de algunos de los registros, el Jefe de TI observo que la columna "por serie" de las listas de materiales tenian numeros que iban del 1 al N segun la cantidad de lineas que contenia la lista, ese dato era incorrecto, pues todo deberia tener "1".
Inmediatamente salio de la sala de juntas y desde su computadora hizo una manipulacion de la base de datos para poder actualizar masivamente este dato. sin embargo, no pudo evitar que se generan errores.
Cuando se empezaron a registrar los diarios de tarjeta de ruta, se observo tambien que algunos diarios de lista de seleccion relacionados no se estaban contabilizando, y ahi empezaron los problemas de invenetarios: algunos registros contabilizados para el cierre del año anterior estaban mal.
Tambien se observo que la unidad "pieza" representaba ser un problema, pues no permitia decimales, dado que asi lo configuro el Jefe de Abastecimientos, sin embargo, en la carga de informacion inicial, se consideran fracciones de algunas piezas para la elaboracion de las partes de los ensambles.
Esto fue un conflicto que hizo que los requerimientos de materiales calculados se elvaran, pues si una unidad requeria 0.3 piezas, el sistama consideraba 1, asi, para hacer 30 unidades, en vez de requerir 3 piezas, pedia 30.
El Jefe de TI era obviamente el mas asediado por todos, tenia filas en su oficina para esperar que lo atendieran, situacion que parece injusta puesto que el equipo de implementacion que constaba de 9 personas tenia el mismo nivel de conocimiento del sistema, sin embargo, nadie le apoyo.
Al final del dia, despues de muchos problemas, produccion por fin arranco.
Se cae... se levanta... se cae... se levanta...
El cuarto dia trajo consigo un nuevo problema: la aplicacion de las terminales de RF se caia cada 40 minutos.
Este dia, la consultora Jefe ya se habia retirado, asi que las notificaciones via correo electronico tienen una respuesta mucho mas lenta.
El jefe de TI tendria que estar levantando el servicio cada vez que se requeria de forma manual, esto representa enormes perdidas de tiempo, sobre todo si consideramos que el es el unico que da soporte informatico a toda la empresa y no tiene auxiliares.
Los reportes estandar del AX no son nada amigables con el usuario, no muestran nombres ni descripciones, solo codigos y son generalmente inflexibles, a pesar de que Microsoft "vende" la idea de que son todo lo contrario, asi que esta falta de reportes hace que no se pueda auditar facilmente altos volumenes de informacion como la que genera produccion.
Asi, los usuarios empezaron a registrar dos, tres y hasta cuatro veces algunos diarios, pues el descontrol propio y la falta de candados del sistema permitian esta situacion.
En consecuencia, los consumos de material asociados tambien se registraban varias veces.
Los capturistas y supervisores solo se limitan a preguntar al Jefe de TI: "Como le hacemos?" pero no tienen la actitud proactiva de explorar el sistema y buscar solucionar por su propios medis, aparte de que el resto del equipo tiene una actitud timida y pasiva, donde no colaboran en apoyar al Area de TI.
Llego el fin de semana y con ello, algo de descanso para un equipo agotado...
Cierre de la historia.
Estoy seguro que las aventuras del AX aun no terminan, sera un camino largo y espinoso hasta que haya un momento donde todo volvera a fluir con utilidad y como antes se hacia.
El problema de las terminales de RF fue solucionado una semanas despues.
Surgieron algunos otros problemas relativamente menores, que se han ido solucionando poco a poco.
Ayudó bastante que el Jefe de TI se metio a programar funciones de tabla y triggers en la base de datos para poder sacar adelante otros desarrollos que los consultores calificaron como muy dificiles y costosos.
Al dia de hoy, 14 de febrero, aun no se ha podido cerrar el mes de Enero, porque las ordenes de produccion padres no estan contabilizando las ordenes hijas entonces los costos de ventas estan saliendo incompletos.
Los consultores estan revisando, pero aun no hay respuesta.
Las facturas de mas de un pagina son un problema porque la cadena original sale incompleta.
La falta de un departamento de control de produccion permite que los diarios de lista de seleccion sean un calvario para el depto de costos, pues los supervisores no se preocupan por revisar que su costo sea correcto. y las cargas de trabajo se incrementaron en casi todas las areas, excepto en contabilidad.
Conclusion.
En la particular opinion de quien escribe, este sistema no era adecuado para esta empresa, debido a que no cuenta con muchas funciones que ella necesita. La falta de analisis, la falta de valor para decirle al Director General que estaba tomando una pesima decision con la implementacion de un producto desconocido esta causando muchos problemas.
La empresa retrocedio 6 años en su estructura de tecnologia de informacion, ya que si bien cuenta con un sistema relativamente poderoso, el poder que tiene no sirve para potenciar la inteligencia de negocios de esta empresa, ya que aun debe igualar a su predecesor en personalizacion y control de informacion.
Sistemas de este tipo requieren de una buena disciplina operativa, de usuarios que sean capaces de seguir procedimientos establecidos, de hacerlos valer y de ser responsables por la informacion que ingresan.
Tambien se requiere una adecuada infraestructura de soporte: Personal tecnico calificado y SUFICIENTE para atender a los usuarios.
El viaje ha sido larguisimo, muy duro y hasta hoy, incierto en cuanto a lo que viene.
Por ultimo....
Esta historia aqui relatada es totalmente real, los nombres de las personas, empresa, empresa consultora y algunos puestos de fueron omitidos o cambiados porque la finalidad no es señala a nadie, sino contar una experiencia.
Pongo a su disposicion la siguiente cuenta de correo electronico por si alguien desea hacer alguna pregunta, quisiera algo mas de informacion u orientacion acerca del AX:
cegdgo@gmail.com
Muchas gracias a quienes se tomaron un minuto para leer esta historia, el fin no es entretener, sino informar.
Un abrazo a todos!
2 comentarios:
El ser un Ing. en Sistemas Computacionales (o afines) no siempre es facil, ya que hay que entender de contabilidad, procesos de calidad, nominas, etc. Y todo esto para sobrevivir en una empresa. Lo que mas risa me da es que la gente de la organizacion, piensa que el area de TI siempre debe de saber todo con respecto a las demas areas, ya que "la computadora se usa en todos lados". Aqui lo malo es cuando en este tipo de proyectos se da por hecho que una persona fuera del area conozca al 100% la dinamica de la misma. Es por que muchas veces dicen "Esta fallando el sistema" ó "no hace bien los calculos". Uno desarrolla lo que el cliente (o la organizacion pide), pero muchas veces, ni ellos mismo no saben lo que quieren, aunado a que muchas personas encargadas del desarrollo de Sistemas no saben hacer e interpretar la informacion generada del analisis de requerimientos !!!
Algo fuera de contexto, pero no deja de ser importante...sugiero una imgen para este blog, para que tenga un poco mas de presencia y sea mas llamativo a los Ciber-Lectores.
Publicar un comentario