Autor: Pedro Cortizo

Migrar o recuperar Odoo vale cuando la versión se ha quedado atrás, la base se puede leer y el equipo aún usa unos módulos concretos. No vale copiar «todo» a ciegas. Vesubio no es partner oficial de Odoo. Lo es Automa-tic, nuestro grupo. Implantamos y adaptamos a través de ellos.

¿Se puede leer lo que hay?

Si hay copias, módulos conocidos y alguien que explica ventas, compras o stock, se puede acotar. Si nadie sabe qué hay instalado ni qué dato es de verdad, primero se inventaría. Recuperar no es adivinar.

¿Migrar o reimplantar?

Migrar cuando el flujo actual sirve y solo cambia la versión o el servidor. Reimplantar cuando el producto se usó como disfraz: demasiados módulos, nadie adopta la pantalla. En ambos casos se enciende lo que se usa. El resto queda apagado.

¿Cuándo no seguir con Odoo?

Cuando el proceso es tan propio que el ERP no lo cubre, o cuando lo que falta es un puente con un sistema que ya funciona. Entonces se mira software a medida o una API. Si el equipo no va a adoptar la pantalla, migrar no arregla nada.

La ficha de producto está en Odoo.

Mantener WordPress en una empresa es actualizar, copiar y no dejar que un plugin rompa la edición. No es «dejarlo publicado». El equipo publica; alguien opera el resto.

¿Qué hay que operar?

Núcleo, temas y plugins. Copias. DNS y el VPS si lo operamos. Tamaños de imagen acotados para que la portada no se hinche. Si solo el proveedor puede tocar la web, no estáis manteniendo: estáis esperando un ticket.

¿Quién edita y quién parchea?

El equipo edita páginas. El interlocutor parchea y decide si un plugin entra o se quita. Mezclar las dos cosas en el mismo cambio es como se rompe el diseño. WordPress no es un ERP disfrazado: si el flujo pide estados y permisos, no se resuelve a plugins.

¿Saldo o proyecto?

Un fallo, una actualización, una copia: saldo. Una web nueva o un rediseño de captación: proyecto. El horario es laborable. No hay un turno 24/7 detrás de la portada.

Para construir o rehacer la web, WordPress profesional. Los evolutivos van al ingeniero TIC. Si un empleado no entra a editar o al correo, tu informático.

Ingeniero TIC (Desde 60 €/h + IVA) para sistemas y evolutivos. Informático (Desde 36 €/h + IVA) para soporte a empleados. Ticket suelto cuando te vale una mesa remota y no te importa perder contexto. No hay atención 24/7.

¿Ingeniero, informático o los dos?

El ingeniero mira infra, servidores, plataformas, SaaS, CRM, ERP, IA y si una novedad aplica a tu caso. El informático atiende a tus empleados: correo, configuraciones, conectividad, accesos y permisos. Un interlocutor que conoce el organigrama. Muchas empresas usan los dos. El saldo es el mismo; se descuenta a la tarifa de quien interviene.

¿Saldo o ticket?

Saldo cuando quieres contexto y horas que no caducan: mínimo 0,5 h, laborables 9–17. Ticket cuando te vale una mesa remota y no te importa empezar de cero cada vez. El ticket no guarda organigrama ni sistemas.

¿Cuándo no es este servicio?

Cuando hay que construir un flujo nuevo, implantar un ERP o publicar una web de captación. El saldo no sustituye un análisis. El análisis, si hace falta, se cuenta aparte. Atención 24/7 tampoco.

Las fichas: tu ingeniero TIC y tu informático. Cifras: más de cien clientes y más de ciento cincuenta proyectos, camino desde 2003 y marca 2009.

Extrae documentos con IA cuando el volumen de PDF o fotos justifica dejar de teclear líneas, y una persona puede revisar antes de que el dato entre al sistema. Si no hay revisión humana, no hay proceso: hay una demo.

¿El cuello es copiar o decidir?

Si alguien lee el papel y teclea, la extracción asistida puede proponer líneas. Si el problema es un flujo que no existe —estados, permisos, excepciones—, primero hay que construir ese flujo. La IA no abre un chat suelto. Trabaja sobre el documento.

¿Qué pasa si el modelo duda?

El dato no entra. Una API propone. Una persona publica. Escaneos malos y tablas rotas fallan: el límite se dice antes, no después de una factura mal hecha.

¿Local o un servicio?

Si el documento no puede salir de la red, el modelo se prueba en casa. Si el volumen o el tipo de archivo piden un servicio, se dice. El modelo se elige después del caso.

El marco está en IA para empresas. Un ejemplo de enfoque está en Albaranes que no se teclean enteros.

Opera el VPS cuando hay que cubrir DNS, copias, actualizaciones y acceso de lo que construimos. Contratar solo hosting basta cuando otro ya opera y tú no tocas el servidor. No es un datacenter propio ni una tarifa de catálogo.

¿Quién conoce lo que se puede caer?

Quien construyó el panel, la API o la web. Sin un interlocutor para contenido y servidor, cada incidente se convierte en un ticket entre dos proveedores. Aquí el saldo es el mismo.

¿Un VPS basta para varios servicios?

A volumen bajo, web, API y worker pueden convivir, con contenedores y reinicio controlado. Si el worker come CPU o hay que aislar, no. El lab Un VPS con contenedores deja escrito ese criterio. No hay una cifra de uptime en esta pieza.

¿Qué no cubre operar?

No cubre un cloud de marca blanca ni un SLA 24/7. Cubre operar lo que construimos cuando el volumen aún es uno. El acceso remoto va por túnel, sin abrir de más. Si el caso es de acompañamiento continuo —no solo el servidor—, mira el ingeniero TIC.

La ficha de servidores y hosting explica el encaje. Si hay que evolucionar sistemas, tu ingeniero TIC. Si un empleado no entra al correo o a una herramienta, tu informático.

El primer proceso para IA es uno concreto —clasificar, extraer, citar un documento— que se puede comprobar. Siempre con revisión humana. El modelo se elige después del caso. No sirve «tener IA».

¿Hay un sitio donde comprobar si acertó?

Un equipo consulta procedimientos y el asistente cita el documento, no inventa la norma. Un albarán se lee y el dato se propone al sistema. Un ticket se clasifica para que no se pierda. Si nadie revisa, no hay proyecto: hay una demo.

¿Local o en un servicio?

Si el documento no puede salir de la red, el modelo se prueba en local. El lab IA local sobre un PDF interno cubre esa pregunta. Si el volumen o el tipo de tarea piden un servicio, se dice. No hay una tarifa de «IA» en esta pieza.

¿Qué no se quita?

La revisión humana. El dato o la cita se pueden revisar. El puente, si existe, avisa si falla. Si el caso se puede contar, está en Proyectos; si aún se está midiendo, en Labs.

La ficha de IA para empresas marca el límite. Un ejemplo de albaranes está en Albaranes que no se teclean enteros.

Conecta lo que hay cuando dos sistemas ya existen y el dato tiene que pasar de uno a otro. Rehazlo cuando el destino no tiene API usable, o cuando el flujo ni siquiera tiene un sitio donde nacer. El puente escribe; si falla, avisa. No se finge que el dato llegó.

¿Primero el uso o primero el puente?

Primero el uso. Si el equipo no tiene un sitio donde crear el pedido o el parte, la API no resuelve nada. Cuando el flujo está claro, el puente lleva el dato al sistema que ya opera: facturación, ERP, CRM.

¿Qué no es conectar?

No es «conectar todo con todo». No es un bus corporativo ni una plataforma de iPaaS. Es el tramo que falta para que un estado —pedido, parte, albarán— exista en los dos lados. Si el sistema destino no tiene API usable, se dice. No se inventa un conector.

¿Dónde se ve el fallo?

En el registro y en el aviso. Si el puente no pudo escribir, el equipo lo sabe. El hosting y las colas, cuando hacen falta, los opera quien construye.

La ficha de integraciones y APIs explica el encaje. Un puente de pedidos está en Pedidos con estado, no con Excel.

Ordena la gestión con Odoo cuando hay que facturar, comprar y controlar stock —y el equipo puede adoptar la pantalla—. No todos los módulos de golpe. Vesubio no es partner oficial de Odoo. Lo es Automa-tic, nuestro grupo. Implantamos y adaptamos a través de ellos.

¿Qué se enciende?

El flujo que hoy se atasca. Se mira cómo facturáis, compráis o controláis stock, qué hay ya en Odoo y dónde se para el equipo. Se implanta con entregables que se puedan usar. Una guía corta para quien lo usa cada día. No un catálogo de apps activadas.

¿Cuándo no es Odoo?

Cuando el proceso es tan propio que el producto se convierte en un disfraz. O cuando lo que falta es un puente con un sistema que ya funciona. Si el equipo no va a adoptar la pantalla, el módulo no sirve.

¿Qué se puede afirmar?

Ventas, compras y almacén ven el mismo stock si ese era el encaje. No hay un ERP «completo» ni un plazo de implantación genérico. El hosting, si lo operamos, queda en el mismo saldo.

La ficha de Odoo marca el límite. Un ejemplo de implantación acotada está en Odoo solo donde se usa.

PWA cuando el usuario es el equipo y el canal es el navegador. Nativa cuando el hardware, las tiendas o la vida útil lo piden. Multiplataforma cuando el mismo flujo vale en iOS y Android y no hay que pelearse con el dispositivo. No se elige un framework por moda.

¿Hace falta una app?

Sí cuando clientes o el equipo la usan de verdad: en el teléfono, con pagos, avisos o datos que ya viven en tu ERP o CRM. No cuando el trabajo cabe en una web que se usa en el móvil. Si es de técnicos en ruta, el teléfono es el lugar de trabajo: abrir, rellenar, enviar.

¿PWA o tienda?

La PWA cubre un parte interno. El prototipo de parte sin tienda cubre esa pregunta; no se vende como app entregada. Si hay que ir a tienda, notificaciones nativas o hardware del teléfono, ya no es PWA.

¿Qué va detrás?

La API lleva el parte o el pedido al sistema que ya existía. Primero el uso, después el puente. Si falla, avisa.

La ficha de apps móviles explica el enfoque. En tienda: idiliq y Escuela Fuentes. Un parte interno, sin tienda, está en Partes que se cierran en el sitio.

Una web editable que convierta es una que se encuentra, se edita sin romper el diseño y se mide por leads y por uso real en el móvil. No por un eslogan de laboratorio. Si el objetivo es un proceso de negocio, no es esta ficha.

¿Qué tiene que hacer la web?

Captar, dejar que el equipo publique y permitir medir. Si no aparece, tarda o solo la toca quien la montó, el problema no es «cambiar de theme». Es decidir esas tres cosas y construir para eso. El método interno (Bloqs) sirve para no inflar el front; no es un producto aparte.

¿Qué medir?

Si llega quien tiene que llegar. Si la portada carga en el móvil. Si el equipo publica sin un intermediario. La portada se mide. No hay una cifra de laboratorio que valga para cualquier sitio. WordPress no es el sitio para un ERP disfrazado de plugins.

¿Cuándo no es WordPress?

Cuando el equipo necesita estados, permisos o un flujo que no es publicar páginas. Entonces se mira software a medida o Laravel. El servidor —DNS, copias, VPS— lo opera el mismo interlocutor. Sin datacenter propio.

La ficha de WordPress profesional marca el límite y lista webs publicadas. Un enfoque anónimo está en Web corporativa que el equipo puede editar.