Y, sin embargo, lo es. El modo en el que Glassfish trabaja con logs es peculiar y guarda algún oscuro secreto.  Sólo te pido dos cosas:

1. 1. Cinco minutos de tu tiempo para que juzgues si lo he conseguido.
   2. Que, para vivir una experiencia completa, escuches la canción ‘Old Souls‘ de la banda sonora de Origen mientras lees el artículo.

Lo peor que te puede pasar es que salgas de aquí aprendiendo algo nuevo y, por supuesto, siempre puedes tirarme tomates virtuales en los comentarios del artículo.  ¿Te animas?

EL MISTERIO DE LAS TRAZAS INEXPLICABLES

Como parte de mi asedio y conquista al entorno de trabajo de STORETTO, comencé a estudiar nuestro sistema de traza y la configuración del mismo. Parecía algo relativamente sencillo (una configuración típica de log4j) Sin embargo, algo no encajaba. Ni las trazas aparecían por donde debían ni tenían el formato que queríamos. Nada se parecía ni remotamente a lo que teníamos configurado.

Tampoco entendía por qué el equipo de STORETTO había configurado el sistema de log4j habitual de la compañía mediante una variable de sistema, en vez de colocar el fichero de configuración en el classpath de la aplicación.

¿Qué estaba pasando? ¿Era todo esto real o era un sueño? ¿Estaba soñando dentro de un sueño? ¿Cómo distinguir la realidad del sueño?

Como en el anterior caso de las JSPX desestructuradas, yo tenía un poco más de tiempo disponible que el equipo para comprender qué estábamos haciendo y por qué lo estábamos haciendo. Lo que averigüé fue SORPRENDENTE.

FRAMEWORK DE LOGGING DE GLASSFISH

Antes de nada, era importante conocer qué sistema de registro de trazas utiliza Glassfish y cómo funciona el mismo.

He resumido todo lo que se necesita saber en un par de párrafos:

Glassfish utiliza para su sistema de trazas la implementación por defecto de la especificación JSR-047, una API de logging, y recomienda el uso de la misma, aunque permite el uso de otras como Apache Commons Logging o log4j.

El uso de la API de logging del JDK implica varias cosas a tener en cuenta:

1. Se basa en un sistema de Handlers, clases que heredan de java.util.logging.Handler y que son los que encapsulan tanto la lógica de publicación de trazas como la configuración de las mismas.
2. Estableciendo un level o nivel por Handler podemos establecer el nivel mínimo de traza que queremos que recoja el HANDLER. Estableciendo un nivel determinado se recogerán todas las trazas de ese nivel y de los niveles superiores jerárquicamente (para conocer más sobre los nieles de traza, pinchar aquí). También se puede establecer el nivel mínimo de traza por paquete de clases, independientemente del nivel implementado por paquete (se usará la configuración más restrictiva)
3. Además del nivel, se puede establecer un control secundario y opcional sobre lo que se registra o no, mediante la asignación de un filtro o Filter (clase que hereda de java.util.logging.Filter) a un Handler. Un Filter, básicamente, implementa un método isLoggeable que devuelve un booleano que indica si un log se debe trazar o no.
4. Si se quiere formatear las trazas generadas con alguna estructura especifica, se debe implementar un Formatter (clase que herede java.util.logging.Formatter) y asignarlo al Handler deseado.
5. Toda esta configuración se hace a través de un fichero denominado logging.properties

La primera diferencia que chocará a todos los que venimos de usar log4j es que todo se configura programándolo. Es decir, no tienes una manera de poder configurar de forma flexible el formato de tus trazas. Si quieres un Formatter que saque el patrón de tu traza de un fichero de propiedades, vas a tener que programártelo.

TRABAJANDO CON LOG4J

¿Son mis logs reales o sólo un sueño?

Para trabajar con log4j en Glassfish v2 se recomendaba configurar la librería de traza como librería del sistema para evitar problemas con el classloading pero esto ya no puede hacerse con Glassfish v3 así que la solución pasa por indicar al servidor la ruta del fichero de configuración de log4j.

En log4j se configuran Appender (el equivalente de los Handler en JSR-047) El Appender típico que todo el mundo utiliza al desarrollar es el org.apache.log4j.ConsoleAppender, que publica los logs en la salida por defecto de System.out.

El problema es que las trazas no salen por la consola habitual que esperamos todos los programadores sino en un fichero server.log que se encuentra en la ruta /midominio/logs/.

Eso es bastante fácil de explicar porque  ese fichero es la salida por defecto del servidor, así que, ésa es su consola.

Lo que no tiene ni pies ni cabeza es que nuestras trazas salgan con el formato de las trazas de la API de logging de JDK o, más exactamente, envueltas por su formato, puesto que nuestro traza aparece… pero sólo como parte del mensaje de la traza de logging del JDK.

Bueno… podemos pensar que, de alguna manera, el sistema está ignorando nuestra configuración de log4j. Sin embargo, si configuramos cualquier otro Appender, por ejemplo uno que publique en un fichero inception.log, log4j funciona PERFECTAMENTE.

¿Entonces? ¿Qué está pasando? ¿Por qué salen todas mis trazas rodeadas de almohadillas ‘#’  y con un retorno de carro cuando las publico por consola?

LA SOLUCIÓN AL MISTERIO

No, no estamos soñando. Nuestras trazas son reales y nuestra configuración también. No estamos haciendo nada mal. Simplemente, alguien ha estado jugando con nosotros. Alguien ha estado haciendo trampas.

Glassfish, utiliza una implementación propia y sobrescrita del objeto System cuyo método out devuelve un PrintWriter que redirige todas las salidas al sistema de logging del servidor. Probadlo, hacer un System.out.println en una clase desplegada en Glassfish. No sólo aparecerá en la salida por defecto -server.log- sino que, además, aparecerá con el formato específico del sistema de logging.

Lo más grave de todo esto es que System es una clase final. Es decir, que no puede ser extendida, precisamente para evitar lo que Glassfish ha conseguido: que nuestro código tenga un comportamiento extraño y nos desconcierte. Que nos tengamos que frotar los ojos para comprobar que no estamos soñando.

De acuerdo, Glassfish nos ha engañado pero ahora, después de leer este artículo sabemos cómo vencerlo:

• ¿Queremos modificar el formato de las trazas del servidor? Implementaremos nuestro propio Formatter y se lo asignaremos al ConsoleHandler del fichero logging.properties
• ¿Queremos que nuestras propias trazas no se mezclen con las del servidor? Nos olvidaremos de utilizar el ConsoleAppender
• ¿Queremos que sólo nuestras trazas de error salgan en la salida por defecto del servidor? Podremos utilizar un ConsoleAppender y configurarlo en nuestro log4j.properties para que sólo registre trazas de nivel ERROR o superiores (recordad que sea cual sea el nivel de traza de log4j, la salida se publicará en System.out y el logging de JAVA las publicará por defecto como trazas de nivel INFO)

Glassfish ha luchado contra nosotros y ha perdido, por lo menos a nivel de logging. Nosotros le dominamos. No él, a nosotros. Y, desde luego, no estamos soñando… ¿o sí?

BONILINKS:

• Gente despotricando sobre el tweaking de System de Glassfish
• Gente flipando con el comportamiento de System.out
• La fuente del UniformLogFormatter (o el origen del formato de traza infernal de Glassfish)
• Información Oficial de Glassfish sobre configuración de logging, donde se les olvida comentar lo del asuntillo del System.out…
• Información para entender lo básico de la API Java Logging

Artículos relacionados:

1. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (III) Tercera parte del tutorial sobre como utilizar transacciones y bloqueos...
2. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (II) Segunda parte del tutorial sobre como utilizar transacciones y bloqueos...
3. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (I) Un sencillo tutorial sobre como utilizar transacciones y bloqueos con...

Para este proyecto en concreto, para este cliente en concreto, elegimos una combinación de implementación en Big Bang y una pseudo-implementación en Paralelo. Hoy, se comienza a trabajar en el nuevo sistema y se abandona definitivamente el antiguo.

Según se acerca la hora H del día D, no puedes evitar preguntarte: ¿Elegimos la estrategia correcta o elegimos la única estrategia posible? En este artículo, intentaré explicar las distintas estrategias de entrada en producción y cómo la realidad choca brutalmente con el dogmatismo académico.

ESTRATEGIAS DE ENTRADA EN PRODUCCIÓN

Como “entrada en producción” se conoce al momento de puesta en marcha de una aplicación y/o servicio. Existen tres estrategias básicas de entrada en producción:

1. Big Bang. La implementación en Big Bang impone que el cambio del sistema antiguo al nuevo se produce en una fecha determinada. Todo el mundo comienza a usar el nuevo sistema en el mismo momento y el antiguo sistema no volverá a ser usado desde entonces.
2. En Fases. La implementación en fases implica la entrada en producción en varias fases en distintos periodos de tiempo. Implica definir qué parte de la nueva aplicación comprenderá cada fase y la convivencia entre la nueva aplicación y la antigua, hasta que la última de las fases se haya completado.
3. En Paralelo. La implementación en paralelo supone el trabajo simultáneo con el antiguo y el nuevo sistema durante un determinado periodo de tiempo para minimizar riesgos. Si se alcanzan los objetivos del nuevo sistema, se abandona el antiguo.

PROS Y CONTRAS DE CADA ESTRATEGIA

Cada estrategia tiene sus pros y sus contras, pero, al final, todo es cuestión -como casi siempre- de tiempo y dinero.

No se discute que la estrategia de implementación que minimiza el riesgo sea el Paralelo. El problema es que dispara los costes. Para poder implementar en paralelo, es necesario que los usuarios hagan su trabajo dos veces: en el antiguo sistema y en el nuevo. O se contrata nuevo personal o se sobrecarga al actual. En cualquier caso, es necesaria una inversión en recursos humanos.

En una situación intermedia, está la implementación en Fases. Eso sí, la elección de esta estrategia implica asumir el coste derivado del desarrollo específico para permitir la convivencia entre el antiguo y el nuevo sistema. Este desarrollo específico tiene una esperanza de vida completamente acotada: será directamente tirado a la basura en cuanto la totalidad del nuevo sistema entre en producción.

Finalmente, la estrategia en Big Bang es la más barata… y la que más riesgo conlleva. No hay que hacer ningún desarrollo específico para que convivan los dos sistemas y tampoco supone ningún coste en recursos humanos. Eso sí, el riesgo de que algo vaya mal -muy mal- en la entrada en producción sube exponencialmente.

UN CASO REAL: STORETTO

Os explicaré cuál ha sido la estrategia de entrada en producción de storetto, un caso real y que he vivido de primera mano como Jefe de Proyecto.

Storetto tiene la particularidad de entrar en producción junto con nuestro otro producto, ERP S1. Sin embargo, mientras éste ya ha sido probado y está funcionando en varios clientes, ésta es la primera vez que storetto entra en producción.

La entrada en producción de ERP S1 se hace con una estrategia de Big Bang, puesto que se confía en la solidez del producto y era inviable una puesta en marcha por Fases. La aplicación que sustituye ERP S1 es un antiguo ERP legado y escasamente documentado desarrollado en 4GL/Informix. Comunicar y conseguir que las dos aplicaciones trabajaran en paralelo suponía un coste que nadie quiso asumir. Así que no quedó más opción que el Big Bang.

En el caso de storetto, la aplicación sustituida era la misma, aunque se concibió como un proyecto diferente a ERP S1 y con arquitectura propia. La implementación en Big Bang quedó descartada por el altísimo riesgo que conllevaba. No sólo por ser la primera entrada en producción de storetto, sino por las especiales características de la misma: se ejecuta en un entorno hostil, utiliza radiofrecuencia, implementa un módulo de comunicación complejo con ERP S1 y, sobre todo, trabaja en tiempo real.

Por mucha metodología y teoría, una Entrada en Producción no deja de tener la emoción e incertidumbre de mandar un hombre a la luna

La implementación en fases también era inviable porque la nueva aplicación rompe radicalmente con el concepto y diseño de la antigua. Mientras que el antiguo sistema se basaba en el trabajo manual con papel  e impreso y su posterior mecanización por parte de administrativos, el nuevo delega todo el trabajo en los propios operarios del almacén, mediante el uso de terminales de carretillas y radiofrecuencia. Se intenta eliminar casi por completo el papel en los procesos internos e introduce nuevas funcionalidades principales como la trazabilidad alimentaria.

Así, la opción recomendada era la entrada en Paralelo, pero éste no ha sido un paralelo “real”, puesto que el trabajo con la parte de administración, el dominio funcional que cubrirá el ERP S1 no ha podido probarse con el nuevo sistema (recordemos, entra en Big Bang). Además, el paralelo ha sido “progresivo”. En vez de manejar todo el almacén por completo con storetto desde el primer día, hemos ido incorporando productos poco a poco. Al principio, empezamos con una referencia y… hasta un día antes de la implementación, no han trabajado con todos los artículos e inventario que maneja el almacén que entra en producción. ¿Por qué? Por lo de siempre: falta de tiempo del personal del almacén o, lo que es lo mismo, dinero. Al final, todo se traduce en dinero.

Nuestra obligación como informáticos es informar de todas las soluciones posibles y proponer la que creamos más adecuada. La decisión, como casi siempre, la toman los directivos o el cliente, que analizan el coste frente al riesgo.

¿Que qué tal saldrá la entrada en producción de hoy? Espero que bien, aunque eso sí, seguro que aparece algún contratiempo. Estamos hablando de proyectos gigantescos con miles de clases, la casuística a probar es infinita. Si estáis interesados en saber más, espero vuestro feedback en los comentarios.

1. “Yo te hago una página web en 2 minutos“: Calificar como trabajo menor todo lo que tiene que ver con diseño, maquetación, usabilidad e interfaz de usuario
2. “¿Contabilidad? Yo soy informático, no contable“: Despreciar el conocimiento funcional o know-how y perseguir únicamente la excelencia técnica

Con el tiempo, la realidad te va poniendo en tu sitio y te das cuenta de que puedes tener una aplicación con los bytecodes más limpios y relucientes, pero el cliente -ese ser extraño que paga las facturas- pensará que todo es una patata si la interfaz no es bien bonita y tiene colores y todas esas cosas. Por otro lado, programar sin tener la menor idea de lo que quiere un cliente te hace depender de un analista que te traduzca sus necesidades a tu idioma y limita tu papel al de chimpancé que golpea teclas a la voz de su amo. Chimpancé cualificado, pero chimpancé al fin y al cabo. No aportas nada al negocio, que es, por si no te habías dado cuenta, donde está la pasta.

Hace poco, mi amigo Jeroclo el espartano me mandó un enlace sobre el almacén de Amazon en Milton Keynes, cerca de Londres. Algo tan -supuestamente- aburrido y poco motivador como la gestión de almacenes parecía adquirir glamour y caché 2.0 cuando metías la palabra “Amazon” de por medio.  De repente, me di cuenta de que, ¡vaya! ¡yo desarrollo software para almacenes! y… ¡Vaya! ¡Esto es un blog corporativo! Así que me he decidido a escribir una serie de artículos sobre gestión de almacenes, desde el punto de vista del desarrollo informático, en los que intentaré explicaros por qué, a pesar de su engañosa simplicidad, es uno de los proyectos más difíciles que puedes llegar a afrontar y cuáles son los retos y oportunidades que representa.

Aunque el 70% de la audiencia de este blog son desarrolladores java radicales poco o nada interesado en estos temas (el 30% restante son mi madre y mi abuela), os animo a que sigáis leyendo. Estoy seguro de que lo encontraréis interesante.

1. (PEQUEÑA) INTRODUCCIÓN A LA LOGÍSTICA Y AL SOFTWARE QUE LA CONTROLA

Tranquilos, no voy a escribir un ensayo exhaustivo sobre software de almacenes, eso daría para un libro. Ya que habéis llegado hasta aquí, os compensaré haciendo lo más corto y ameno posible este artículo. Sólo haré una pequeña introducción sobre como es el software de gestión de almacenes.

La Gestión de Almacenes se encuadra dentro del área de Logística de una compañía. La RAE define la logística como el conjunto de medios y métodos necesarios para llevar a cabo la organización de una empresa, o de un servicio, especialmente de distribución. Hablando claro, el área que se encarga de conseguir los bienes que necesita una empresa para producir sus productos y servicios, almacenar dichos bienes y los obtenidos en el proceso productivo de dicha empresa y, finalmente, distribuirlos a los clientes.

Dentro de todo este berenjenal nos podemos encontrar dos tipos de software.

1. Software gestor de almacenes (SGA o, en inglés, WMS de Warehouse Management Software)
2. Software gestor de cadena de suministro (SGC o, en inglés, SCM de Supply Chain Management)

La principal diferencia entre un SGA y un SGC es su alcance funcional. Mientras que un SGA controla las entradas y salidas de mercancía de un almacén y la gestión de dicha mercancía dentro del mismo; un SGC gestiona desde los pedidos a proveedores a los repartos y consumos de los clientes. Por poneros un ejemplo clarificador: mediante un SGC puedo controlar el consumo medio diario de una determinada mercancía, tener configurado el tiempo máximo de abastecimiento que me da mi proveedor y, en base a dichos datos, poder calcular un Stock Mínimo que debo tener en el almacén para no correr riesgo de sufrir una rotura de stock o, lo que es lo mismo, quedarme sin mercancía para servir a mis clientes (la peor pesadilla que puede sufrir una empresa: vender -que es lo verdaderamente complicado- y no poder servir)

2. PUES PARECE MUY SENCILLO ¿POR QUÉ DICES QUE ES TAN COMPLICADO?

Así trabajan un SGA y un SGC, abrazaditos :)

La logística se basa en la Teoría de la Caja de Zapatos: metes un zapato, sacas un zapato, pero la realidad se complica. BASTANTE.

Cualquier diseño de un sistema informático se basa en un conjunto de inputs o entrada de datos esperados y de outputs o datos producidos por el sistema según los inputs recibidos. El problema es que, cuando diseñas un sistema para una cadena de suministro, tienes que tener en cuenta que puedes tener un número infinito de inputs. Os pongo un ejemplo, tú pides a un proveedor una mercancía y te manda menos, o más… o incluso OTRA. Pero, aún es peor, un proveedor puede mandarte mercancía aunque no le hayas pedido nada. Una vez que recibes la mercancía, te pueden pasar mil cosas más: que la mercancía esté rota, o que no esté porque la hayan robado, o que el operario que registró la entrada se equivocara en el conteo… infinitas posibilidades. Porque en estas aplicaciones no trabajas con datos sino con mercancía real, que puede desaparecer, aparecer o transformarse sin destruirse, como la energía. Parece que la Teoría de la Caja de Zapatos se va complicando, ¿verdad?

Otro punto a tener en cuenta es el Trabajo en Tiempo Real. La gente del almacén trabaja con tu sistema en tiempo real. Si algo va mal no puedes decir “espera que te lo miro cuando tenga un rato” porque a lo mejor eso supone tener a 6 chicarrones del norte y a un trailer de 40 toneladas parados en la puerta de tu almacén. Creedme, hasta que no has lidiado con un carretillero soliviantado de 2×2 metros no sabes lo que es tratar con usuarios difíciles.  Y, por supuesto, todos los trabajos se hacen en paralelo. Ya puedes hacer que hasta tu javascript sea ThreadSafe porque las tareas se suelen hacer entre múltiples usuarios al mismo tiempo.

Por último, os hablaré del Trabajo en Ambiente Hostil. Y es que, tu aplicación, no va a estar corriendo en un servidor atacado por cómodos oficinistas y ejecutivos desde sus Mac de diseño, sino por operarios que trabajan de sol a sol en un almacén donde hace un frío que pela, a través de terminales de mano o de carretilla que se comunican mediante un WI-FI industrial que debe soportar -en movimiento- obstáculos -como estanterías de hierro- y que cuentan, como mucho, con una interfaz táctil de 7 pulgadas.

Os reto a que cojáis a vuestro gurú del diseño y la usabilidad y lo pongáis a desarrollar interfaces táctiles que contengan toda la información necesaria y que puedan ser manejadas por tipos que llevan GUANTES de faena. Creedme, es… difícil.

3. EBRI FIDBAK GÜIL BI (ESPESIALI) APRESIERIT

Suficiente por hoy.

Aunque no lo suelo pedir, cualquier comentario y/o sugerencia será especialmente apreciado porque no tengo ni idea de lo mucho o poco que os puede interesar conocer más del ámbito funcional de la Cadena de Suministro y de muchas otras aplicaciones corporativas en las que estoy embarcado (ERP, CRM, etc…). Por eso, os ruego que me hagáis llegar vuestras opiniones. Buenas o malas, seguro que todas son constructivas.

El caso es que, hace un par de fines de semana, volvieron a preguntarme “pero tú, David, ¿exactamente qué haces?” Y, como siempre, resoplé y puse los ojos en blanco. No es que me importe contar lo que hago pero, a veces, es muy frustrante intentar explicárselo a alguien que no sea informático sin aburrirle con una perorata de hora y media. El problema es que,me han hecho la misma pregunta muchas veces y, por increíble que parezca, en algunas ocasiones incluso dentro de mi propia empresa. Hace dos días, tomando un café, un compañero me preguntó de nuevo “pero tú, David, ¿exactamente qué haces?” :) .

Reflexionando sobre el tema, me di cuenta de que éste es un blog corporativo y, como tal, nació como un canal de comunicación con todos mis compañeros -desperdigados por toda España y parte de Latinoamérica- y gente relacionada con mi actividad profesional: clientes, proveedores y camaradas picateclas. Así que, voy a intentar explicar exactamente lo que hago y porqué lo hago. Si alguien me lo vuelve a preguntar, siempre podré remitirle el enlace a este post. Si a ti te interesa, pulsa en “Leer más”

Trabajo como Jefe de Proyecto en SIXSERVIX, una compañía del Grupo VARMA. El Grupo VARMA se dedica a importar y distribuir bebidas y, aunque no lo sepáis, la mayoría sois clientes nuestros. Cada vez que os bebáis una copa de Ron Barceló, Cutty Sark, Jack Daniel’s o Cointreau, por poner un ejemplo, estáis consumiendo nuestros productos. También si os preparáis unas palomitas MicroPop USA para ver una peli en casa, o si os coméis una caja de galletas Walker’s, incluso si alimentáis a vuestros bebés con los potitos ecológicos Hipp, estáis consumiendo productos de la empresa donde trabajo.

Dentro de este totum revolutum se supone que trabajo como Jefe de Proyecto. ¿Qué hace un Jefe de Proyecto? Definir las tareas que quedan pendientes, establecer plannings y fases de entrega, gestionar los recursos (personas, programas, servicios) de los que dispone y vigilar que dichos plannings y el presupuesto de coste del proyecto no sufran desviaciones. Ésa es la teoría pero, en la práctica, lo mismo programo que analizo o evalúo software, hago de preventa o toco la gaita. En cualquier caso, creo adivinar lo que más de uno estará pensando ¿Qué tiene que ver un informático, un Jefe de Proyecto, con potitos ecológicos? Intentaré explicároslo.

SIXSERVIX era lo que los informáticos denominamos “empresa cliente” o “empresa final”. Es decir, una empresa que -a priori- no vive de la informática y donde -de nuevo, a priori- tienes menos presión por hacer las cosas rápido y mal.

Pero esto era demasiado fácil. En vez de dedicarnos a gestionar presupuestos y encargar proyectos, apostamos por desarrollarlos nosotros mismos. En vez de hacer proyectos, quisimos crear productos.  No es que no nos guste el ron, de hecho nos gusta muchísimo :) , pero queremos que nuestros sueldos no dependan del mucho o poco ron que vosotros bebáis sino, para bien o para mal, de nuestra capacidad de crear productos que el mercado -no sólo nuestro grupo de empresas- demande.

Como resultado de todo este esfuerzo, han nacido el ERP S1 y el SCM STORETTO, los dos “niños” que han ocupado la mayor parte de mi tiempo durante los últimos 6 años. Os explicaré qué es cada cosa:

• ERP S1. Lo de ERP viene de Enterprise Resource Planner y, básicamente, es un programa que controla todos y cada uno de los aspectos de una empresa. Desde compras a cobros, pasando por nóminas a contabilidad o liquidación de impuestos. Seguro que conocéis programas que hacen más que bien cada una de esas cosas. Lo bueno de un ERP es que hace que todo esté integrado. Así, cuando en un ERP se calcula la nómina de alguien,  por ejemplo, se genera un asiento contable, se liquidan los impuestos con hacienda y se imprime la nómina en sí. Cuando un directivo consulte un balance de beneficios, éste incluirá automáticamente el gasto de la nómina y, por supuesto, todas las ventas. Otro ejemplo para que podáis entender el nivel de integración: cuando un empleado se pone malo, se registra la baja, el director de RRHH puede consultar los empleados que están de baja o incluso un histórico de las mismas y, de nuevo, si la baja es prolongada, la empresa podrá deducirse dinero de la cotización de la seguridad social, afectando al cálculo de las nóminas. Todo está interconectado y el sistema se alimenta a sí mismo. Un ERP es el software más potente y crítico que se puede construir a nivel empresarial y constituye el corazón del negocio de la empresa que lo utiliza.
• SCM STORETTO. Lo de SCM viene de Supply Chain Management o, lo que es lo mismo, Software Gestor de Cadena de Suministro. Siendo la actividad principal de VARMA la distribución de bebidas y alimentación, es evidente la importancia de tener un buen producto para gestionar la logística. Al contrario de lo que algunos de nuestros compañeros piensan, STORETTO no es sólo un software que gestione almacenes y la mercancía  que hay en los mismos sino que llega mucho mas allá. STORETTO es un SCM porque, por ejemplo, en base al consumo de mercancía que tengas y al tiempo que tarden tus proveedores en reponerla, puede llegar a calcular el número de días que tienes  aseguradas tus ventas y avisarte si hay posibilidades de que rompas tu stock (lo peor que le puede pasar a una empresa es que venda algo y no tenga disponibilidad para servirlo).

Comprendiendo la complejidad y dimensión de un ERP puede que entendáis un poco mejor porqué tardamos casi cinco años en acabarlo y porqué mi barba cada vez tiene más canas.

Por supuesto, intento que el trabajo no me absorba por completo. Me gustan un montón de cosas como viajar, la gastronomía, el cine o los videojuegos, pero eso puede dar para otro post mas largo todavía…

Espero que ahora algunos tengáis un poco más claro qué hago. Sobre todo, si trabajáis conmigo :D