Software As People

El chiste que no es un chiste

SAP son las siglas de Systeme, Anwendungen und Produkte. Sistemas, aplicaciones y productos. Nació en 1972 con una promesa muy concreta para la época: si construyes un sistema lo bastante grande y lo bastante genérico, puedes venderlo a miles de empresas distintas sin tener que rehacerlo cada vez. Esa lógica funcionó tan bien que se convirtió en el modelo por defecto de toda la industria del software durante cincuenta años. Primero con licencias on-premise, después con SaaS: Software as a Service. El "as a Service" no es casualidad, es la clave de todo el modelo. Un servicio estandarizado, pensado para el mayor número de clientes posible, donde eres tú quien se adapta al software y no al revés.

Durante mucho tiempo esa fue la única opción razonable. Construir software a medida para cada cliente era carísimo. Cada línea de código costaba horas de un programador, y esas horas solo se amortizaban si el mismo producto servía para mil empresas parecidas. De ahí los formularios genéricos, los flujos de trabajo que "casi" encajan con cómo trabaja tu equipo, los módulos que sobran y las funciones que faltan. No es que las empresas de software no entendieran a sus clientes. Es que no podían permitirse construir un traje a medida para cada uno.

Eso es lo que ha empezado a romperse.

Lo que cambia con la IA

La IA generativa no es una mejora incremental sobre el desarrollo de software. Es un cambio en la estructura de costes que sostenía todo el modelo anterior. Cuando el coste marginal de escribir, adaptar y mantener código baja de forma tan brusca, deja de tener sentido forzar a cien equipos distintos a usar el mismo formulario porque "así se amortiza mejor". De repente resulta más barato construir un sistema que encaje con cómo trabaja de verdad un equipo concreto que enseñarle a ese equipo a trabajar como espera el sistema.

Ahí es donde entra la otra lectura de las siglas SAP. Si el software ya no necesita ser genérico para ser rentable, deja de tener sentido pensarlo "as a Service". Puede pensarse as People: construido alrededor de cómo piensa, habla y trabaja un grupo concreto de personas, no alrededor de un caso de uso medio que en realidad no representa a nadie.

No es una idea nueva del todo. El software a medida siempre ha existido, para quien podía pagarlo. Lo que cambia ahora es que ese "quien podía pagarlo" deja de ser solo la gran corporación con presupuesto de seis cifras para un ERP. Una pyme, un hotel independiente, un equipo de cinco personas, puede tener hoy un sistema pensado exactamente para su forma de trabajar, sin que eso implique un proyecto de implantación de un año.

Dónde se nota esto en la práctica

En el sector hotelero, donde trabajamos desde Roomtability® | Strategy & Tech for Hotels, esta diferencia es muy visible. La mayoría del stack tecnológico de un hotel —PMS, channel manager, motor de reservas, CRM— sigue funcionando bajo la lógica clásica de SaaS: un producto genérico, pensado para adaptarse a hoteles de treinta a trescientas habitaciones, con o sin restaurante, con o sin spa, en cualquier país. El resultado es previsible: cada hotel usa un 30% de las funciones que paga, y para el otro 70% de su operativa real acaba tirando de hojas de Excel, WhatsApp y memoria del equipo.

El planteamiento cambia cuando la pregunta deja de ser "¿qué PMS del mercado se parece más a lo que necesitamos?" y pasa a ser "¿qué necesita exactamente este equipo, con esta plantilla, con estas características del Hotel, con esta forma concreta de gestionar el housekeeping?". Ahí ya no se trata de elegir entre productos cerrados, sino de construir el flujo específico: la vista de reservas que necesita esa persona, el sistema de seguimiento de cancelaciones que encaja con cómo lo hacen hoy, la automatización que responde a un problema real de ese hotel y no a un caso de uso teórico de un producto pensado para diez mil clientes distintos.

Eso es Software as People en la práctica. No un producto que el hotel tiene que aprender a usar, sino un sistema construido a partir de cómo ya trabaja el equipo.

Lo que esto implica

Si esto se sostiene, el valor en la consultoría tecnológica se desplaza. Ya no está tanto en saber qué producto del mercado recomendar, sino en saber diseñar el sistema correcto para un equipo concreto: entender cómo trabaja de verdad esa gente, dónde pierden tiempo, qué información necesitan y cuándo, y construir exactamente eso. El software deja de ser un molde al que hay que encajar la operativa, y pasa a ser un reflejo de esa operativa.

No todo el software se va a construir así, ni tiene sentido que lo haga. Hay procesos genéricos de verdad —motor de reservas, contabilidad, nóminas, según qué infraestructura— donde la estandarización sigue siendo la opción sensata ahora mismo. Pero para todo lo que define cómo trabaja realmente un equipo, para la capa de experiencia y de operación diaria, la pregunta ya no es si se puede permitir un sistema a medida. La pregunta es por qué seguir forzando a las personas a adaptarse a un software que nunca fue pensado para ellas, cuando ya no hace falta.

SAP nació para servir a las empresas a través de sistemas, aplicaciones y productos genéricos. La siguiente etapa quizás no sea mejorar ese modelo, sino invertirlo: sistemas, aplicaciones y productos construidos a partir de las personas que los van a usar.