Artículo · Decisión de compra
Service as software: qué es y en qué se diferencia del SaaS
Service as software es un modelo en el que compras el trabajo hecho, no la herramienta para hacerlo. El software deja de ser una licencia que tu equipo maneja y pasa a ser el workforce que ejecuta la operación en segundo plano: agentes que hacen la tarea y un proveedor que los mantiene. Tú contratas el resultado (casos resueltos, expedientes preparados, un proceso operando con niveles de servicio) y el proveedor absorbe el ciclo técnico que hay detrás. Es la inversión del modelo SaaS, y cambia sobre todo quién hace el trabajo.
La inversión del modelo SaaS
En el modelo SaaS clásico, compras acceso a una herramienta y tu equipo hace el trabajo con ella. La factura mide licencias o consumo. El proveedor mantiene el producto común y tú aportas los usuarios, configuras el flujo, integras tus sistemas y sigues siendo responsable de ejecutar la operación. El software es una palanca que multiplica el trabajo de tu gente, pero el trabajo sigue siendo de tu gente.
Service as software da la vuelta a esa relación. El software ya no es la herramienta que usa una persona: es la persona, en el sentido de que ejecuta la tarea. La factura se acerca al resultado y no al asiento. El proveedor no te entrega una aplicación para que la operes. Opera él la capacidad y responde por lo que produce. Lo que compras no es la posibilidad de hacer el trabajo, sino el trabajo. Esta es la tesis comercial que sostiene el modelo de Arkatai, y la desarrollo como decisión de compra en comprar o construir IA.
| SaaS | Service as software | |
|---|---|---|
| Qué compras | Acceso a una herramienta | El resultado del trabajo |
| Quién hace el trabajo | Tu equipo, con el software | El software, mantenido por el proveedor |
| Qué mide la factura | Licencias o consumo | Resultado o capacidad operativa |
| Quién configura e integra | El cliente | El proveedor |
| Quién mantiene el ciclo técnico | El cliente | El proveedor |
En qué se diferencia del BPO
La subcontratación de procesos de negocio (BPO) también te vende un resultado: entregas un proceso a un tercero y este lo ejecuta con su gente. El parecido termina ahí. El BPO escala con personas: para hacer el doble de trabajo, contrata al doble de personas, y su economía sigue las horas y los salarios. Service as software escala con software: el mismo sistema absorbe más volumen sin una plantilla proporcional, y el trabajo repetible se productiza dentro de la plataforma.
La diferencia práctica se nota en la traza y en la mejora. Un proceso ejecutado por software deja registro de cada decisión (qué recibió, qué regla aplicó, qué hizo), lo que permite auditarlo con un detalle que un proceso manual rara vez ofrece. Y la mejora va en dos planos. Los patrones que se repiten entre clientes refuerzan la plataforma común, y las métricas de cada ejecución (calidad, coste, tiempo, excepciones) mejoran tu proceso concreto de forma continua. En un BPO, el conocimiento vive en las personas que ejecutan; si rotan, parte de la capacidad se va con ellas.
En qué se diferencia de la consultoría
Una consultora vende un proyecto: un análisis, un diseño o una implantación con fecha de fin. Al terminar, recibes entregables y una decisión pendiente: quién opera y mantiene lo construido. El software, si lo hubo, es tuyo para operarlo, con el coste y el riesgo que eso implica. La consultoría responde por la calidad del trabajo entregado, no por que la operación siga funcionando el mes siguiente.
Service as software no entrega un proyecto que después alguien tenga que operar: mantiene la operación funcionando como servicio recurrente. La prueba para distinguir un modelo del otro es simple. Si el proveedor conserva y mantiene una plataforma común, responde por un servicio continuo y convierte los patrones de cada despliegue en mejoras del núcleo, es service as software. Si cada cliente recibe un proyecto aislado y toda mejora exige reconstruirlo, sigue siendo consultoría con otro nombre. He desarrollado esta distinción, con la figura del forward-deployed engineer en el centro, en qué es un forward-deployed engineer y en equipo interno, consultora o forward-deployed engineers.
Quién asume el ciclo técnico, y por qué eso lo cambia todo
El argumento de fondo no es semántico. Muchas empresas medianas no tienen un departamento de producto y tecnología capaz de mantener agentes, evaluaciones, integraciones y cambios de modelo al ritmo actual, y montarlo es una función nueva con su coste fijo y su riesgo de rotación. Ese ciclo técnico (probar modelos nuevos, rehacer evaluaciones, mantener conectores, gobernar permisos y trazas) no para nunca, porque los modelos cambian y el proceso cambia.
Service as software existe porque ese ciclo puede vivir fuera del cliente. El proveedor lo absorbe: cuando sale un modelo mejor o más barato, lo evalúa y lo sustituye sin que el cliente tenga que tocar nada, tratando los modelos como componentes intercambiables. El cliente conserva lo que sí es suyo (dirigir sus datos y sus decisiones de negocio) y se ahorra construir una plantilla técnica para operar la tecnología. La contrapartida real es una dependencia del operador, que hay que reconocer y contratar bien: quién es propietario de qué, cómo se mide el servicio y qué te llevas si sales. Trato esos criterios de compra en cómo elegir proveedor de agentes, el precio en cuánto cuesta implantar agentes de IA y el retorno en ROI de la IA en operaciones.
Que este trabajo específico ocurra durante el despliegue no significa que recibas una base de código a medida. El proveedor conserva la plataforma y productiza dentro de ella lo que se repite, y tú diriges el negocio. Ese es el fondo de la fase custom, y el punto de entrada al conjunto es agentes de IA para empresas.
Preguntas frecuentes
¿Qué es service as software?
Un modelo en el que compras el trabajo ejecutado en lugar de la herramienta para ejecutarlo. El software actúa como el workforce que hace la tarea y el proveedor lo mantiene, y tú contratas el resultado o la capacidad operativa. Invierte el modelo SaaS: en lugar de comprar acceso y hacer tú el trabajo, compras el trabajo hecho.
¿En qué se diferencia service as software de SaaS?
En SaaS compras acceso a una herramienta y tu equipo hace el trabajo con ella, y la factura mide licencias. En service as software el software hace el trabajo, el proveedor mantiene el sistema y la factura se acerca al resultado. Cambia sobre todo quién ejecuta y quién asume el mantenimiento técnico.
¿No es lo mismo que subcontratar un proceso (BPO)?
No. El BPO escala con personas y su conocimiento vive en quienes ejecutan. Service as software escala con software, deja traza de cada decisión y productiza lo repetible dentro de la plataforma. Ambos te venden un resultado, pero la unidad que crece es distinta: personas frente a software.
¿Quién mantiene la tecnología en service as software?
El proveedor. Absorbe el ciclo técnico completo: probar y sustituir modelos, rehacer evaluaciones, mantener integraciones y gobernar permisos y trazas. El cliente dirige sus datos y sus decisiones de negocio y designa un responsable del proceso, pero no necesita montar un departamento técnico para operar el sistema.