ERP mas IA: conectar Odoo y cubrir los huecos que el ERP no llega a cubrir

Casi todas las empresas industriales que han implantado un ERP llegan al mismo punto: el sistema funciona, el dato de facturacion es fiable, y sin embargo la operacion diaria sigue sostenida por correos, mensajes y hojas de calculo. No es un fallo del ERP; es que hay procesos que ningun ERP estandar cubre bien porque son conversacionales, dependen de criterio humano o viven fuera de la empresa. Este articulo explica cuales son esos huecos en fachadas, aluminio, vidrio y manufactura, como se cubren con IA sin duplicar la verdad y como se conectan las dos capas por API sin poner en riesgo el sistema que sostiene la contabilidad.

El ERP es el sistema macro, no el sistema completo

Un ERP hace muy bien lo que fue disenado para hacer: guardar los maestros de articulos, clientes y proveedores; registrar pedidos, albaranes y facturas; llevar inventario y costes; y cerrar la contabilidad. Es la columna vertebral, y nada de lo que se cuenta aqui pretende sustituirlo. Implantar o cambiar un ERP es un proyecto de otra naturaleza y de otro presupuesto.

El problema aparece cuando se confunde el ERP con la totalidad de la operacion. Un pedido de compra bien registrado no dice nada de las tres semanas de conversacion con el proveedor que hicieron falta para llegar a el. Una orden de fabricacion no contiene la discusion sobre si ese color de lacado es el mismo de la fase anterior. Una certificacion aprobada no refleja el acta de la reunion en la que se acordaron las unidades.

Todo ese trabajo existe, consume horas y determina la calidad del dato que acaba dentro del ERP. Pero vive fuera: en el correo, en WhatsApp, en hojas de calculo personales y en carpetas compartidas. Llamarlo desorden no ayuda; en la mayoria de los casos no es desorden, es la unica forma practica que ha encontrado el equipo de hacer un trabajo que el ERP no modela.

La propuesta razonable es sencilla: el ERP sigue siendo la fuente de verdad de lo que ya es un hecho contable u operativo; la capa de IA cubre el trabajo previo y conversacional; y las dos se conectan por API en una direccion muy controlada. Ni se duplica el ERP ni se convierte la IA en un segundo sistema de gestion.

Los siete procesos que suelen quedar fuera del ERP

Estos son los huecos que aparecen una y otra vez en empresas de fachadas, aluminio, vidrio y manufactura. Ninguno es exotico: todos condicionan plazos, margenes o cobros.

1. Seguimiento de proformas

Se piden proformas a varios proveedores, llegan por correo en formatos distintos, algunas no llegan nunca y el comparativo se hace a mano en una hoja. El ERP registra el pedido final, no el proceso de conseguirlo. Mientras tanto, nadie sabe cuantas proformas estan pendientes de respuesta ni cuales caducan esta semana.

2. Levantamientos de obra

Las medidas reales tomadas en obra corrigen las de proyecto. Llegan en fotos, croquis a mano, notas de voz y hojas. Esa informacion condiciona el despiece y el corte, pero rara vez tiene un sitio formal antes de convertirse en una orden de fabricacion.

3. Validaciones de color y serie

Que RAL exacto, que acabado, que serie de perfil, que tipo de vidrio y con que composicion. Son decisiones que se cierran por correo con el cliente o la constructora y que, si se pierden, producen material fabricado que hay que rehacer. El ERP guarda el codigo de articulo, no la conversacion que lo justifica.

4. Solicitudes a suplidores de otros paises

Plazos de fabricacion, minimos de pedido, incoterms, documentacion de importacion y tiempos de transito y aduana viven en hilos de correo con varias personas y en varios idiomas. El ERP conoce la fecha prometida, no como se negocio ni los avisos de retraso que llegaron por el camino.

5. Aprobaciones por correo o WhatsApp

El cliente aprueba un plano con un "ok, adelante" en un mensaje. Un jefe de obra autoriza un extra por telefono. Meses despues, cuando hay discusion, hay que reconstruir esas aprobaciones a mano.

6. Actas y minutas

En las reuniones semanales de obra se acuerdan plazos, responsables y penalizaciones. Si nadie levanta acta, los acuerdos se evaporan; si alguien la levanta, suele quedarse en su bandeja de enviados.

7. Avisos de obra

Incidencias, roturas, faltas de material, cambios de acceso a la grua, paradas de la constructora. Llegan al movil de tres personas distintas y no dejan rastro estructurado en ningun sitio.

Por que esos huecos degradan el dato del ERP

Una objecion comun de direccion es que esos procesos son informales por naturaleza y no pasa nada por dejarlos asi. La realidad es que cada hueco se paga dentro del ERP, con retraso y con intereses.

• Datos que entran tarde. El pedido se registra cuando ya se cerro todo, asi que durante semanas la carga de compras prevista no existe en el sistema y la planificacion trabaja a ciegas.
• Datos que entran incompletos. Se crea el articulo con el color aproximado porque la validacion exacta esta en un correo que nadie encuentra, y el error se descubre en fabrica.
• Datos sin contexto. El ERP dice que la fecha comprometida cambio, pero no por que, y esa causa es justamente lo que permitiria evitar la proxima vez.
• Trabajo duplicado. Alguien vuelve a teclear en el ERP lo que ya estaba escrito en un correo, con la tasa de error que eso implica.
• Decisiones sin evidencia. Cuando hay reclamacion, reconstruir quien aprobo que y cuando cuesta dias de trabajo de personas caras.

Visto asi, la capa de IA no es un capricho tecnologico: es lo que impide que la informacion se pierda entre el momento en que ocurre y el momento en que alguien la teclea. Y su objetivo principal no es generar texto, sino capturar hechos con evidencia y ponerlos donde se puedan usar.

Que es una API, en cristiano

Una API es una puerta de servicio del sistema. Igual que el ERP tiene una pantalla por la que entran las personas, tiene una puerta por la que pueden entrar otros programas, con su propia llave y con reglas sobre lo que pueden hacer una vez dentro.

Cuatro ideas bastan para entenderse con el informatico o con el partner del ERP sin ser tecnico:

• Peticion y respuesta. Un programa pide algo concreto ("dame los pedidos de compra del proyecto P-2451") y el ERP responde con esos datos en un formato que otro programa entiende. No hay magia ni interpretacion: si el dato no esta, no se inventa.
• Lectura y escritura. Algunas peticiones solo consultan. Otras crean o modifican registros. Son dos mundos con riesgos muy distintos y conviene tratarlos por separado desde el primer dia.
• Usuario tecnico. La API no entra "como el ERP": entra como un usuario, con sus permisos. Si ese usuario puede borrar facturas, un error de programacion puede borrar facturas.
• Trazabilidad. Toda accion hecha por la API debe quedar registrada como hecha por ese usuario tecnico, para poder auditarla despues.

En el caso concreto de Odoo, existe una API externa documentada que permite leer y escribir en los modelos del sistema desde fuera. No hace falta que entiendas los detalles del protocolo; si hace falta que sepas que existe, que esta documentada y que tu partner puede habilitarla. Si estas en fase de elegir sistema, hay criterios concretos en como elegir un ERP con API robusta.

Autenticacion, permisos minimos y entorno de pruebas

Aqui es donde se gana o se pierde la tranquilidad. Tres decisiones que hay que tomar antes de conectar nada.

Autenticacion

Nunca se usa la cuenta personal de nadie. Se crea un usuario tecnico dedicado para cada integracion, con su propia credencial, de forma que si algo falla se pueda desactivar sin afectar a personas. Las credenciales no viajan por correo ni se guardan en hojas de calculo: se guardan donde el equipo de sistemas guarde el resto de secretos. Si tu ERP soporta autorizacion mediante OAuth 2.0, mejor; si trabaja con claves de API, basta con rotarlas periodicamente.

Permisos minimos

El usuario tecnico solo debe poder hacer lo que la integracion necesita. Si el panel solo consulta pedidos y facturas, ese usuario tiene permiso de lectura sobre esos modelos y nada mas. Ni acceso a nominas, ni a contabilidad, ni a datos de personal. Esta regla parece obvia y se incumple en la mayoria de integraciones improvisadas, donde se usa un usuario administrador "para que funcione ya".

Entorno de pruebas

Ninguna integracion se prueba contra el sistema en produccion. Se pide al partner una copia de pruebas con datos reales o anonimizados, se valida ahi todo el comportamiento, incluidos los fallos, y solo despues se pasa a produccion. Probar en vivo es como cortar perfil sin plantilla: sale bien muchas veces, y cuando sale mal el coste es desproporcionado.

Anade una cuarta pieza que casi nadie pide y siempre se agradece: un registro propio de todo lo que la integracion hace. Fecha, accion, resultado. Cuando un dia alguien pregunte por que se modifico un registro, esa lista responde en un minuto.

Quien es responsable de que

Las integraciones fracasan mas por falta de duenos que por dificultad tecnica. Conviene escribir esta tabla antes de empezar y pegarla en el documento del proyecto.

El ultimo punto merece insistencia. Una actualizacion del ERP puede cambiar nombres de campos y romper una integracion sin que nadie se entere hasta que faltan datos en el panel. Pide por escrito que te avisen antes de actualizar, y deja una comprobacion automatica que verifique cada manana que la conexion responde y que los datos llegan con la forma esperada.

Los cuatro patrones de integracion

Casi todo lo que necesita una empresa industrial cabe en cuatro patrones, ordenados de menor a mayor riesgo. La recomendacion es recorrerlos en ese orden y no saltarse ninguno.

Lectura

Es el patron con el que hay que empezar siempre. Permite construir paneles, resumenes y alertas sin ningun riesgo para el sistema. Ademas sirve de prueba: si la lectura funciona de forma estable durante un mes, la conexion es solida.

Alertas

Combinan datos del ERP con datos de fuera (fechas de montaje, plazos de proveedor, partes de obra) y avisan a una persona concreta. No modifican nada. Son, con diferencia, el patron con mejor relacion entre esfuerzo y beneficio.

Informes

Resumenes periodicos, comparativos de proformas, documentos de seguimiento. Aqui la IA aporta redaccion y sintesis, pero el dato numerico debe venir del ERP sin reinterpretaciones; pide siempre que el informe indique de donde sale cada cifra.

Escritura controlada

El unico patron que modifica el ERP, y el que exige mas disciplina. Tres condiciones innegociables: se escribe siempre en estado borrador para que una persona confirme; se escribe solo en los modelos acordados; y cada escritura queda registrada con su origen. Un ejemplo razonable es crear la solicitud de compra en borrador a partir de una proforma validada. Un ejemplo temerario es modificar precios de tarifa automaticamente.

Que pedirle al partner del ERP y que resolver por fuera

Una de las decisiones que mas dinero ahorra es saber que pedir a quien. La regla general: al partner del ERP se le pide lo que toca el nucleo del sistema; por fuera se resuelve lo que es conversacional, cambiante o especifico de tu forma de trabajar.

Pidele al partner del ERP:

• Habilitar la API y crear los usuarios tecnicos con permisos minimos.
• Un entorno de pruebas con datos representativos.
• La documentacion de los modelos y campos que vas a usar, con sus nombres exactos.
• Aviso previo de actualizaciones que puedan romper la conexion.
• Campos adicionales en los modelos, cuando de verdad hagan falta, para guardar el identificador de obra o la referencia del proceso externo.
• Los desarrollos que afecten a facturacion, contabilidad o fiscalidad. Eso no se toca por fuera.

Resuelve por fuera:

• Seguimiento de proformas y comparativos de proveedor.
• Lectura y clasificacion de correos y mensajes de obra.
• Actas, minutas y resumenes de reunion.
• Paneles de trazabilidad y alertas operativas.
• Captura de partes de obra y levantamientos.
• Cualquier proceso que vayas a cambiar tres veces en seis meses mientras encuentras la forma buena.

Ese ultimo criterio es el mas util de todos. Lo que todavia esta cambiando no debe convertirse en un desarrollo a medida dentro del ERP, porque cada iteracion cuesta dinero y tiempo de un tercero. Cuando el proceso se estabiliza y demuestra su valor, entonces se plantea si merece la pena llevarlo dentro. Es exactamente el enfoque de automatizacion progresiva de procesos.

Riesgos reales y como evitarlos

Duplicar la verdad

Es el riesgo numero uno. Ocurre cuando la capa de IA guarda su propia version de datos que ya existen en el ERP: sus fechas de entrega, sus importes, su estado de pedido. A las pocas semanas los dos sistemas discrepan y la empresa tiene dos verdades y ninguna confianza.

Como se evita: la capa de IA no guarda copia de lo que el ERP ya sabe. Lo lee cuando lo necesita y lo muestra con su marca de origen y hora. Solo guarda lo que el ERP no tiene: el hilo de la proforma, la aprobacion del cliente, el acta, el parte de obra.

Escribir en el ERP sin control

Una automatizacion que crea o modifica registros sin supervision empieza bien y acaba con doscientos registros erroneos que alguien limpia a mano, o peor, con datos contables alterados. Como se evita: escritura solo en borrador, solo en modelos acordados, con limite de volumen por ejecucion (si intenta crear cincuenta registros de golpe, se para y avisa) y con registro de cada accion. Y un interruptor de emergencia: desactivar el usuario tecnico debe bastar para detenerlo todo.

Otros cuatro que conviene mirar

• Dependencia de una sola persona. Si solo una persona entiende la integracion, tienes un problema de continuidad. Documenta y forma a un segundo.
• Exposicion de datos sensibles. Margenes, condiciones comerciales y datos personales no tienen por que salir. Limita campos desde el principio y usa codigos en lugar de nombres cuando sea posible.
• Silencio en caso de fallo. Una integracion que deja de funcionar sin avisar es peor que no tenerla: la gente sigue confiando en datos viejos. Comprobacion diaria y aviso si no responde.
• Exceso de alcance inicial. Querer conectar ocho procesos a la vez garantiza que ninguno funcione bien. Uno, estable, y despues el siguiente.

Sobre privacidad, la decision es de direccion y conviene tomarla una vez: cuando la empresa no quiere que cierta informacion salga, se trabaja con los archivos en local y se limita lo que se sube. Esto no es asesoria legal ni fiscal; las obligaciones concretas varian por pais y conviene contrastarlas con tu asesor.

Hoja de decision: esto al ERP, esto a la IA, esto a un panel

Cuando aparece una necesidad nueva, esta tabla evita dos meses de discusion. La pregunta de partida siempre es la misma: este dato, es un hecho consolidado, una conversacion o una vista de otros datos?

Tres reglas para usarla bien. Primera: si un dato puede estar en el ERP, esta en el ERP, y el resto lo lee. Segunda: si es una conversacion, es de la capa de IA, y lo que se consolida despues pasa al ERP en borrador. Tercera: si es un calculo o una vista, es del panel y no se guarda en ningun sitio como si fuera un dato original. El desarrollo de la tercera columna esta en el articulo sobre el panel de trazabilidad de obra.

Tres ejemplos ilustrativos de hueco resuelto

Ejemplos genericos, construidos para ilustrar el patron; no describen a ninguna empresa concreta ni contienen datos reales.

Ejemplo 1: el hilo de proformas

Compras pide precio de un vidrio especial a cuatro proveedores, dos de ellos de otro pais. Las respuestas llegan en PDF, en cuerpo de correo y en una hoja adjunta. Un asistente lee el buzon de compras, detecta que esos mensajes pertenecen a la solicitud abierta, extrae precio, plazo, minimo de pedido e incoterm, y mantiene una tabla comparativa viva. Cuando faltan respuestas, avisa. Cuando compras elige, se crea la solicitud de compra en borrador en el ERP con los datos del proveedor elegido, y una persona la revisa y confirma. El ERP recibe un dato limpio y completo; el hilo con la evidencia queda enlazado.

Ejemplo 2: el levantamiento de obra

El tecnico toma medidas en obra y manda fotos de croquis y una nota de voz. El sistema convierte eso en una tabla de huecos con sus dimensiones, la compara con las medidas de proyecto que ya estan en el ERP y marca las diferencias que superan la tolerancia. Tecnica revisa solo las diferencias marcadas, no las ciento veinte medidas. Al validar, las medidas corregidas pasan al despiece. Nadie ha vuelto a teclear nada.

Ejemplo 3: los avisos de obra

La constructora escribe por WhatsApp que el acceso a la grua estara cortado dos dias. El mensaje se clasifica como aviso de obra con impacto en planificacion, se asocia al proyecto, genera una tarea para el jefe de obra y actualiza el riesgo de la fecha de montaje en el panel. La evidencia queda guardada con fecha. Si mas adelante hay discusion de plazos, existe registro. Es el mismo mecanismo de captura que se detalla en los partes de obra por WhatsApp.

Trucos que ahorran semanas

Empieza por un unico modelo de lectura

Conecta primero solo los pedidos de compra. Un modelo, lectura, sin escritura. Si eso funciona de forma estable un mes, el resto es repetir el patron. Empezar por diez modelos a la vez no acelera nada: multiplica los puntos de fallo.

Guarda el identificador de obra en los dos lados

El campo que une todo es el codigo de proyecto. Si el ERP no tiene donde guardarlo, pide al partner un campo adicional. Sin esa clave comun, cada consulta se convierte en un ejercicio de adivinanza.

Pide siempre la cita de origen

Cuando un asistente extrae un dato de un correo, debe devolver tambien de que mensaje lo saco. Una instruccion util: "Para cada dato extraido indica el asunto y la fecha del correo del que procede. Si un dato no aparece explicitamente en ningun mensaje, escribe NO CONSTA en vez de deducirlo."

Comprobacion diaria de salud

Una rutina que cada manana consulta un dato conocido y avisa si la respuesta no llega o no tiene la forma esperada. Evita descubrir un fallo tres semanas tarde.

Escribe primero en un campo de notas

Antes de permitir que una automatizacion cree registros, dejala escribir su propuesta en un campo de notas o en un documento aparte durante dos semanas. Comparar lo que habria hecho con lo que hizo una persona es la mejor prueba de calidad que existe, y no cuesta nada.

Documenta en una pagina

Que integracion existe, que usuario tecnico usa, que lee, que escribe, quien la mantiene y a quien avisar si falla. Una pagina. La mayoria de las empresas no la tiene y la echa de menos el dia que algo se rompe. Guardala donde el equipo ya busca las cosas, junto al resto de documentacion interna.

Antes y despues del proceso

No damos cifras de ahorro porque dependen del volumen de proyectos y del punto de partida. Lo que si puedes medir en tu empresa son tres cosas antes y despues: cuantos dias pasan entre que se acuerda una compra y queda registrada en el ERP, cuantas correcciones de datos se hacen al mes, y cuanto tiempo se dedica a reconstruir aprobaciones cuando hay una reclamacion. Con dos semanas de medicion previa tendras una base honesta para decidir; el metodo esta en como medir el retorno de una implantacion de IA.

Como se implementa con Uniamos

Dos formas de trabajar, y las dos terminan con tu equipo manteniendo lo construido sin nosotros. Lo que no hacemos: implantar o sustituir el ERP. El ERP es el sistema macro; nosotros cubrimos lo que no cubre y lo conectamos por API. Tampoco vendemos licencias: la empresa contrata su propia cuenta, de equipo y con un correo generico para que accedan todos, y ayudamos a optimizar el gasto.

Proyecto cerrado

Un entregable concreto, por ejemplo un conector de lectura al ERP con panel y alertas, o el sistema de seguimiento de proformas. Precio cerrado orientativo desde USD 1.500 y hasta unos USD 4.500 segun alcance, ejecutado en uno a tres meses, con puesta en marcha y formacion para que el equipo lo mantenga.

• Semanas 1-2. Mapa de huecos, hoja de decision y acuerdo de alcance con cada responsable.
• Semanas 3-4. Usuario tecnico, permisos minimos, entorno de pruebas y primera lectura estable.
• Semanas 5-6. Panel o informe sobre esa lectura y primeras alertas en funcionamiento.
• Semanas 7-8. El proceso externo elegido funcionando de punta a punta.
• Semanas 9-10. Escritura controlada en borrador, si el caso lo justifica, con limites y registro.
• Semanas 11-12. Documentacion en una pagina, comprobacion diaria de salud, formacion y traspaso.

Paquetes de horas de acompanamiento y formacion

Sesiones de una a dos horas por semana, siempre sobre un proceso real. Cada sesion deja tareas para la semana y empieza revisando lo hecho. Minimo 5 horas. El seguimiento vive en un panel del cliente con resumen de cada sesion, acciones por persona, documentos y enlaces; las sesiones se graban y se entrega la minuta.

5 horas, arranque. Cuentas y accesos, higiene de datos, mapa de huecos y el primer proceso externo automatizado, normalmente el seguimiento de proformas o los avisos de obra. El equipo pierde el miedo.

10 horas, dos o tres procesos y un panel. Se completan dos o tres huecos, se conecta la lectura del ERP y queda un panel funcionando. Al terminar hay un campeon interno entrenado que sabe modificar reglas y anadir campos.

20 horas, programa por areas. Presupuestos, obra, compras y comercial, con conectores al ERP, escritura controlada donde se justifique y manual interno con la hoja de decision y las reglas de gobierno del dato.

Calendario tipico de 10 horas

1. Semana 1 (2 h). Hoja de decision y eleccion del primer hueco. Tarea: reunir veinte ejemplos reales de ese proceso.
2. Semana 2 (2 h). Montaje del proceso externo y pruebas con esos ejemplos. Tarea: usarlo una semana en real.
3. Semana 3 (2 h). Usuario tecnico y primera lectura del ERP en pruebas. Tarea: validar que los datos coinciden.
4. Semana 4 (2 h). Panel con el dato del ERP y dos alertas. Tarea: anotar falsos positivos durante la semana.
5. Semana 5 (2 h). Ajustes, documentacion en una pagina y traspaso al campeon interno.

La filosofia es ensenar a pescar: en tres meses el equipo debe poder hacerlo solo. El detalle del formato esta en formacion en IA con Claude y en los paquetes de 5, 10 y 20 horas para industria; la parte tecnica, en integraciones por API.

Herramientas y costes a septiembre de 2026

Las piezas habituales de esta arquitectura son pocas y ninguna obliga a una inversion grande:

• Modelo de IA para leer correo, clasificar mensajes, comparar proformas y redactar resumenes. Claude ofrece planes de equipo y acceso por su plataforma para desarrolladores con pago por uso para las automatizaciones. A septiembre de 2026 los planes de equipo estan en el orden de unas decenas de dolares por usuario y mes; confirma los precios vigentes en su web. Conviene saber que no existe ninguna certificacion oficial de Anthropic: desconfia de quien diga tenerla.
• ERP: la documentacion de Odoo explica modelos y API externa; si usas otro sistema, pide a tu partner la documentacion equivalente.
• Orquestacion de flujos entre sistemas: n8n o Make, ambas con conectores de correo, hojas y bases de datos.
• Pruebas de API: Postman para verificar peticiones antes de automatizar nada.
• Canales: correo corporativo, Google Workspace y WhatsApp Business Platform para obra y proveedores.
• Documentacion de interfaces: si tu equipo tecnico trabaja con especificaciones, OpenAPI es el estandar habitual para describirlas.

El coste de herramientas de una empresa mediana suele ser inferior al de una jornada de consultoria de ERP. El coste real del proyecto es el tiempo de las personas que conocen el proceso, y ese tiempo hay que reservarlo de verdad en la agenda o el proyecto se alarga.

Que hacer esta semana

1. Lunes. Escribe la lista de los procesos que hoy viven fuera del ERP en tu empresa. Usa los siete de este articulo como punto de partida y anade los tuyos.
2. Martes. Rellena la hoja de decision con esa lista: que va al ERP, que a la capa de IA y que a un panel. Hazlo con el responsable de cada proceso delante, no en solitario.
3. Miercoles. Elige un unico hueco para empezar. Criterio: que duela, que sea repetitivo y que no toque facturacion.
4. Jueves. Escribe al partner de tu ERP y pide tres cosas: si la API esta habilitada, si puede crear un usuario tecnico de solo lectura y si hay entorno de pruebas disponible. Con esas tres respuestas ya sabes por donde puedes ir.
5. Viernes. Reune veinte ejemplos reales del hueco elegido (correos, mensajes, proformas, fotos). Ese material es lo que permite montar y probar el proceso sin inventar casos.
6. Antes de cerrar la semana. Nombra al campeon interno: una persona que conozca el proceso, no necesariamente tecnica, con tiempo asignado.

Si el proceso que eliges es el seguimiento de ofertas o el de compras, tienes el detalle en seguimiento de presupuestos enviados y en compras, proformas, stock y merma.

Preguntas frecuentes

Artículos relacionados

• Guia para implementar IA en empresas de fachadas, aluminio y vidrio
• Panel de control de proyectos de obra con IA
• Como elegir un ERP con API robusta e integrarlo
• Compras, proformas, stock y merma en vidrio y aluminio
• Partes de obra y horas de instaladores por WhatsApp con IA
• Casos de uso de Claude por area en pymes
• Paquetes de formacion de 5, 10 y 20 horas para industria
• Más artículos del blog de Uniamos