Autor: Equipo Vesubio

Tu ingeniero TIC es un saldo de horas para operar lo que ya tienes —y lo que construimos—: incidencias, pequeños cambios, copias y criterio. No es un ticket a una mesa remota ni un contrato de horas que se inventa al final de mes.

¿Qué entra en el saldo?

Lo que se puede hacer sin reabrir un proyecto: un fallo, un ajuste, una copia, una decisión de si conviene tocar o no. Desde 2009 operamos así con empresas que no quieren un departamento interno y no quieren perder al interlocutor. Las cifras que podemos afirmar: más de cien clientes y más de ciento cincuenta proyectos. No hay un SLA 24/7 en esta pieza.

¿Cuándo no es este servicio?

Cuando hay que construir un flujo nuevo, implantar un ERP o publicar una web de captación. Entonces se abre la ficha de software, Odoo o WordPress. El saldo no sustituye un análisis. El análisis, si hace falta, se cuenta aparte.

¿Quién atiende?

El mismo equipo que conoce el sistema. Sin pasar por una cola anónima. Si el trabajo es de servidor —DNS, VPS, acceso—, se apoya en servidores. Si es de un proceso que aún no existe, se para y se plantea el proyecto.

La ficha de tu ingeniero TIC marca el límite. Si tienes una necesidad concreta, cuéntanosla.

Administrar servidores, para nosotros, es operar el VPS donde vive lo que construimos: DNS, copias, actualizaciones y acceso. No es un datacenter propio ni una tarifa de hosting de catálogo.

¿Por qué el mismo equipo que construye?

Porque el que conoce el panel, la API o la web es el que sabe qué se puede caer y cómo recuperarlo. 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 en un VPS bien operado, 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 esta ficha?

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—, la ficha es tu ingeniero TIC.

La ficha de servidores y hosting explica el encaje. El mismo criterio aparece en las fichas de Proyectos cuando el hosting lo opera Vesubio.

La IA en empresa sirve cuando hay un proceso concreto —clasificar, extraer, citar un documento— y se puede comprobar el resultado. No sirve «tener IA». El modelo se elige después del caso.

¿Un proceso, no un asistente genérico?

Un equipo consulta procedimientos internos y el asistente cita el documento, no inventa la norma. Un albarán se lee y el dato entra al sistema. Un ticket se clasifica para que no se pierda. Si no hay un sitio donde comprobar si acertó, no hay proyecto: hay una demo.

¿Local o en un servicio?

Si el documento no puede salir de la red de la empresa, 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é se puede afirmar?

Que el dato o la cita se pueden revisar. Que el puente con el sistema, si existe, avisa si falla. Que no prometemos un porcentaje de acierto genérico. 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 caso de albaranes está en Albaranes que no se teclean enteros.

Una integración sirve cuando dos sistemas ya existen y el dato tiene que pasar de uno a otro sin rehacerlos. 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. El interlocutor de la aplicación y el de la API es el mismo.

¿Qué no es una integración?

No es «conectar todo con todo». No es un bus corporativo ni una plataforma de iPaaS que vendamos aparte. 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. Ver servidores.

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

Odoo conviene cuando hay que ordenar facturación, compras y stock —y el equipo puede adoptar la herramienta—. No pedimos «todos los módulos»: pedimos el flujo que hoy se atasca. Somos partner a través de Automa-tic; no vendemos el badge.

¿Qué se implanta de verdad?

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

¿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. Entonces se mira software a medida o una API. Si el equipo no va a adoptar la pantalla, el módulo no sirve.

¿Qué se puede afirmar del resultado?

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

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

Una app de empresa sirve cuando clientes o el equipo necesitan usarla de verdad: en el teléfono, con pagos, avisos o datos que ya viven en tu ERP o CRM. No vendemos un framework; se elige nativo, multiplataforma o web encapsulada según dispositivos, tiendas y vida útil.

¿Nativo, multiplataforma o web?

Nativo 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. Web encapsulada —o una PWA— cuando el usuario es el equipo y el canal es el navegador. El prototipo de parte sin tienda cubre ese último caso; no se vende como app entregada.

¿Cuándo no hace falta una app?

Cuando el trabajo cabe en una web que se usa en el móvil, o cuando el sistema de gestión ya se adopta. Si el caso es de clientes, pagos o escaparate, la app tiene que ganarse el sitio. Si es de técnicos en ruta, el teléfono es el lugar de trabajo: abrir, rellenar, enviar.

¿Qué se conecta 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. El interlocutor de la app y el de la integración es el mismo.

La ficha de apps móviles explica el enfoque. Un caso de partes en campo está en Partes que se cierran en el sitio.

WordPress profesional, para nosotros, es una web que se encuentra, carga en el móvil y se edita sin romper el diseño. Lo usamos cuando el objetivo es visibilidad y leads, no cuando el proceso de negocio pide una aplicación a medida.

¿Qué problema resuelve de verdad?

Si tu sitio no aparece, tarda o solo lo puede tocar quien lo montó, el problema no es «cambiar de theme». Es decidir qué tiene que hacer la web y construirla para eso: captación, edición y medida. El método interno que usamos (Bloqs) sirve para no inflar el front; no es un producto que vendamos aparte.

¿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. WordPress no es el sitio para un ERP disfrazado de plugins.

¿Qué se puede afirmar de la portada?

La portada se mide. No prometemos una cifra de Lighthouse genérica. El equipo publica sin pasar por un intermediario. El servidor —DNS, copias, VPS— lo opera el mismo interlocutor. Sin datacenter propio.

La ficha de WordPress profesional marca el límite. Un caso de edición por el equipo está en Web corporativa que el equipo puede editar.

Laravel encaja cuando hay que construir una aplicación o una API que el equipo va a usar cada día y que tiene que evolucionar sin romper lo que ya funciona. No es un CMS ni un atajo para una web de captación.

¿Para qué sirve Laravel aquí?

Para paneles, colas, trabajos programados y APIs con estados claros. Oficina y almacén ven el mismo pedido. Un flujo nuevo se añade por entregable, no de golpe. Si lo que necesitas es visibilidad y leads, la ficha es WordPress profesional, no esta.

¿Cuándo no es Laravel?

Cuando el proceso cabe en un ERP que el equipo puede adoptar, o cuando el canal es el teléfono y el trabajo ocurre en ruta. Entonces se mira Odoo o apps. Laravel no sustituye un sistema que ya ordena facturas y stock si ese sistema se usa de verdad.

¿Cómo se evoluciona sin romper?

Se toca por entregables y se deja el entorno estable. El puente con facturación u otro sistema, si hace falta, es una API que avisa si falla: no se finge que el dato llegó. El hosting lo opera el mismo equipo que construye.

La ficha de Laravel detalla el encaje. Un ejemplo de panel con estados está en Pedidos con estado, no con Excel.

El software a medida conviene cuando un proceso de tu empresa no cabe en una herramienta de catálogo: reglas propias, datos que no se pueden perder y gente que ya trabaja de una forma. Antes de escribir código se decide si conviene construir, adaptar o integrar.

¿Cuándo no basta un paquete?

Un ERP, un CRM o un WordPress bien montado cubren muchos casos. Dejan de bastar cuando el flujo es vuestro: estados que no existen en el producto, permisos que no se pueden simular con roles genéricos, o un dato que tiene que coincidir entre oficina y almacén. Ahí el problema no es «cambiar de herramienta». Es decidir qué proceso hay que sostener.

¿Construir, adaptar o integrar?

No partimos de un lenguaje. Partimos de lo que te está costando tiempo, errores o control. A veces el resultado es una aplicación nueva. A veces es Laravel sobre algo que ya tienes. A veces es conectar lo que hay con una API. El interlocutor es el mismo: el que analiza es el que desarrolla y el que opera.

¿Qué se entrega y qué no?

Se entrega un proceso usable por el equipo, no solo un repositorio. Permisos, estados e informes que se puedan explicar. No prometemos un plazo cerrado ni un precio por pantalla: el alcance sale del análisis. Si el caso se puede contar, la ficha vive en Proyectos.

La ficha de software a medida explica cuándo conviene y cuándo no. Si el proceso es de gestión estándar, mira antes Odoo.