Business Driven: la revolución pendiente en IT.

¿Tienes atribuciones de negocio en tu compañía? Pues, ¡sorpresa! Se está celebrando una gran fiesta en tu honor y no te han invitado. Así es, si la compañía en la que trabajas tiene cierto tamaño es posible que se estén gastando en este momento millones de euros en tecnología y software para “ayudar al negocio” y tú, que eres el negocio, no estás involucrado.

No solo hablamos de productos digitales y aplicaciones específicas y localizadas, hablamos de grandes modernizaciones de arquitectura, grandes remodelaciones del core, desmantelamiento del legacy, renovaciones completas de ERP, ecos de la transformación digital que nunca termina.

La consultoría de software no parece contar con el mayor de los prestigios, no solemos ser los profesores estrella en clases de posgrado, ni somos portada de revistas de negocios, pero sí sabemos mejor que la mayoría en qué y cómo se está invirtiendo el dinero en términos de transformación digital. Una cosa que he visto repetidamente durante 13 años trabajando en esta industria es la enorme ruptura que hay entre “el negocio” y “la tecnología” y no veo visos de cambio.

Son Villarriba y Villabajo, Moriarty y Holmes, el Betis y el Sevilla, agua y aceite… inserte su analogía. El problema, más allá de la broma, es que esto afecta negativamente a los resultados, haciendo que buena parte de las mencionadas inversiones se malgaste.

La desconexión entre IT y el negocio

Las personas responsables de los grandes proyectos de IT suelen involucrar al negocio lo mínimo por varios motivos:

• Presupuesto propio: prefieren gastar su presupuesto en sus propios desafíos.
• Perspectiva de inversión o gasto: para IT, la tecnología es una inversión. Para el negocio es un gasto y, como mucho, un medio necesario.
• Temor a expectativas irreales: suelen temer lo que llaman (con cierta sorna) “la carta a los Reyes Magos”, pedidos inalcanzables por parte del negocio.
• Retos internos distintos: IT tiene objetivos como “apagar el AS400” o “llevar servicios a la nube”, que no suelen alinearse tan directamente con las metas de negocio.
• Conocimiento del negocio: IT considera que ya sabe todo lo necesario del negocio y que ya están trabajando para él.

Por otro lado, el negocio percibe a su equipo de tecnología como:

• Costoso: todo les suele parecer caro.
• Lento: los proyectos de IT tardan demasiado en implementarse.
• Sensación de dependencia: el negocio se siente “cautivo” del departamento IT interno, mientras que con proveedores externos siente pueden exigir más.
• Falto de empatía: consideran que los equipos de IT son insensibles a la presión y urgencia competitiva del negocio.
• Presupuesto propio: al igual que IT, prefieren invertir su presupuesto a su manera.

El negocio no sabe explicarse ni salir de este ciclo

Todo el mundo cree saber lo suficiente de negocio. Es un concepto que, como al diseño, le resulta difícil exponer sus motivaciones y su valor.

El estudio del conocimiento ha tratado este tema y ayuda a explicar por qué se produce este fenómeno cuando hablamos de conocimiento contextual, conceptual o sistémico. El conocimiento de negocio cae dentro de lo que Michael Polanyi ya llamó en los 60 “conocimiento tácito”, sintetizado en la frase “Sabemos más de lo que somos capaces de decir”. Este conocimiento tiene un alto componente individual, subjetivo, contextual y conceptual en contrapartida con el “conocimiento explícito” de tecnología que es mucho más objetivo, transferible y formalizable.

A diferencia de este conocimiento “disperso”, la tecnología tiene la ventaja añadida de que está funcionando hoy, ahora mismo, y el negocio, sobre todo el nuevo negocio, es en parte una promesa de valor a futuro. Mal asunto en época de inmediatez y métricas descontextualizadas.

Pero el mayor de los problemas es no saber explicar bien todas las caras de la palabra “negocio”.

Diferencia entre requisitos de negocio, objetivos de negocio y reglas de negocio

Lo que cada persona tiene en la cabeza con la palabra “negocio” es muy personal y a menudo se usa como abreviatura de conceptos bien distintos:

• Requisitos de negocio: es la lista de especificaciones y necesidades que el software debe cumplir para considerarse satisfactorio. Contienen dos tipos de requisitos: funcionales (qué debe hacer el software) y no funcionales (rendimiento, seguridad, usabilidad, compatibilidad, legalidad, cumplimiento, mantenimiento…).
• Objetivos de negocio: marcan el rumbo de una empresa o unidad de negocio a medio y largo plazo. Contienen metas específicas y medibles (no simplemente deseos) que la organización se propone alcanzar dentro de un periodo determinado como, por ejemplo, expandirse en un mercado concreto o ganar cuota de mercado en determinado segmento. Estas metas incentivan que todos los esfuerzos de la compañía estén coordinados y se dirijan a lograr los resultados deseados.
• Reglas de negocio: son las políticas, directrices, procesos, procedimientos, condiciones y restricciones que dictan cómo debe operar una organización. Si bien su optimización y refinamiento mejoran la competitividad de una compañía, su finalidad en primera instancia es más descriptiva que propositiva. Son necesarias, pero no te ayudan tanto a ser diferencial en el mercado.

En definitiva, ordenando las ideas: el software debe atender a los requisitos de negocio que idealmente sirven a los objetivos de negocio y que, dentro de un marco de reglas de negocio, buscan mejorar los resultados de negocio. Parece un trabalenguas, pero entender esto es fundamental.

Esto es importante porque, cuando se habla de que “el software sirve al negocio”, es una afirmación cierta pero incompleta. El software siempre funciona atendiendo a unas reglas de negocio, no hay forma de hacerlo de otro modo: el ERP de una compañía tiene un módulo de facturación, un módulo de pricing, un CRM para la gestión de clientes, unos datos maestros, un recomendador para el cross selling… pero todo eso no implica que sirva a los nuevos requisitos del negocio derivados de la presión competitiva del mercado. Y esa es la clave: las organizaciones no separan adecuadamente su rendimiento en el mercado presente y en el mercado futuro.

Business Driven: un win-win para las grandes modernizaciones

Nuestro enfoque Business Driven parte de este entendimiento del problema y plantea un método orientado a que la modernización impacte directamente en los resultados de negocio. Se trata de dar un propósito más elevado a las grandes inversiones IT sacando a la superficie esta suerte de catedrales sumergidas.

En estos procesos, ha de aclararse muy pronto el nivel de ambición e impacto esperado en el negocio futuro y, por tanto, fijarlo con stakeholders clave al inicio del proyecto. No hace falta que sea inamovible en el tiempo, pero sí ha de ser inequívoco y lo más estable posible.

Si se alcanza este tipo de visión, supondrá un reto de innovación y estrategia con diferente método, perfiles y manejo de expectativas, pero el retorno sin duda lo merece por los beneficios que reporta:

• Al negocio le permite influir en el roadmap, lo que también es un reparto de la responsabilidad y una mejor gestión económica.
• Pone dirección clara y detallada a las grandes inversiones, enfocando la modernización al retorno de negocio y no en los activos. En muchas ocasiones, la falta de dirección y concreción hace que la propia modernización naufrague.
• A IT le permite gestionar mejor los cambios. Si hay comunicación hay espacios de debate y argumentación y, por lo tanto, entendimiento y empatía en la toma de decisiones.
• La mejor comunicación con el negocio, además, elimina o reduce drásticamente el shadow IT (software de “estraperlo”, contratado fuera de IT).
• Permite a IT poner en valor los logros alcanzados logrando una clara trazabilidad entre los costosos nuevos activos y el impacto en negocio.

Cuando ambos lados colaboran, uno más uno es mucho más que dos. ¿A qué esperamos para derribar el muro?

Existe una reflexión en el mundo del software, bien sintetizada por Elon Musk, y que nos podemos aplicar para ser mucho más Business Driven: “El mayor error de un ingeniero inteligente es optimizar un componente que no debería existir”.