Showing posts with label Arquitectura empresarial. Show all posts
Showing posts with label Arquitectura empresarial. Show all posts

Tuesday, September 6, 2016

¿Cómo convertir la inversión tecnológica en transformación organizacional verificable?

Arquitectura empresarial · Arquitectura TI · Transformación organizacional

Por Diego Iván Oliveros Acosta · 2016


La transformación digital se instala con fuerza en el lenguaje de gobiernos y empresas. Sin embargo, aparece una paradoja: nunca ha sido tan fácil adquirir tecnología y, al mismo tiempo, tan difícil convertirla en mejores capacidades, servicios y decisiones.

El problema no era —y todavía no es— la falta de herramientas. El problema aparece cuando una organización digitaliza formularios, compra plataformas, migra infraestructura o crea aplicaciones sin comprender qué debe transformar en su negocio, qué información necesita gobernar y qué capacidades debe desarrollar para sostener el cambio.

La tesis de este artículo es directa: la tecnología puede modernizar una actividad aislada, pero la arquitectura es la que permite convertir múltiples cambios en una transformación coherente y verificable. Sin arquitectura, la innovación produce proyectos; con arquitectura, puede producir capacidades.

Lo digital deja de ser solamente tecnológico

El World Development Report 2016: Digital Dividends del Banco Mundial plantea una advertencia fundamental: la rápida difusión de internet y las tecnologías digitales no garantiza por sí misma crecimiento, mejores empleos ni servicios públicos más efectivos. Para producir beneficios amplios son necesarios elementos complementarios como instituciones responsables, capacidades humanas y condiciones organizacionales adecuadas.

La Declaración de Cancún de la OCDE reconoce la economía digital como impulsora de innovación, crecimiento y bienestar, pero vincula ese potencial con confianza, apertura, habilidades, acceso e inclusión. El mensaje es claro: la transformación no puede explicarse únicamente mediante infraestructura o software.

En Colombia, MinTIC presenta un instrumento para apoyar la construcción del Plan Estratégico de Tecnologías de la Información —PETI— y lo define como el medio para expresar la estrategia de TI y articularla con los objetivos institucionales. El Marco de Referencia de Arquitectura TI organiza esta gestión mediante dominios de estrategia, gobierno, información, sistemas de información, servicios tecnológicos, y uso y apropiación.

Estos desarrollos revelan un cambio de enfoque: la conversación debe pasar de comprar tecnología a gobernar la transformación.

Digitalizar una tarea no equivale a transformar una capacidad

Una organización digitaliza cuando sustituye un medio analógico por uno tecnológico: convierte un formulario en una pantalla, un archivo físico en un repositorio o una reunión presencial en una videollamada. Estas acciones pueden generar eficiencia, pero no necesariamente modifican la capacidad organizacional que produce el resultado.

Transformar exige una pregunta diferente: ¿qué debe poder hacer la organización que hoy no puede hacer, o qué necesita hacer de una manera sustancialmente mejor? La respuesta puede requerir cambios simultáneos en procesos, roles, reglas, información, aplicaciones, infraestructura, medición y cultura.

Por ejemplo, instalar una herramienta de gestión de clientes no crea por sí sola una capacidad de relacionamiento. Si ventas, servicio y mercadeo conservan definiciones distintas de cliente; si los datos están duplicados; si nadie responde por su calidad; y si cada área mide un resultado diferente, la plataforma solo hará más visible la fragmentación existente.

La tecnología no corrige automáticamente el diseño de la organización. Con frecuencia, automatiza sus contradicciones y las hace operar a mayor velocidad.

Cinco señales de innovación sin arquitectura

1. El portafolio crece, pero las capacidades no cambian

La organización puede mostrar numerosos proyectos, pilotos y adquisiciones, pero no explicar qué capacidad empresarial mejora cada iniciativa ni mediante qué indicador se demostrará el cambio. Se mide la ejecución del presupuesto, no la transformación obtenida.

2. Cada solución crea una nueva isla

Las áreas resuelven necesidades legítimas mediante aplicaciones independientes, identidades separadas, integraciones puntuales y datos duplicados. El resultado parece ágil al comienzo, pero aumenta los costos de operación, seguridad, análisis y evolución.

3. El dato no tiene dueño ni significado común

Cuando cliente, producto, estudiante, proveedor, trámite o proyecto significan algo distinto para cada sistema, la organización no posee una base confiable para automatizar ni decidir. La arquitectura de información deja de ser un asunto técnico y se convierte en una condición para gobernar.

4. La adopción se deja para el final

Se diseña la solución y, poco antes de ponerla en operación, se pregunta cómo capacitar a los usuarios. Sin participación, responsabilidades, incentivos y apropiación, la tecnología puede estar disponible y la capacidad seguir sin existir.

5. La arquitectura se reduce a diagramas

Documentar componentes es útil, pero insuficiente. La arquitectura debe orientar decisiones: qué se conserva, qué se transforma, qué se integra, qué se retira, qué riesgo se acepta y en qué secuencia se invierte. Si no modifica prioridades ni restricciones, el diagrama no está gobernando nada.

La arquitectura como sistema de decisiones

La arquitectura empresarial conecta la estrategia con las capacidades necesarias para ejecutarla. La arquitectura de información establece conceptos, responsabilidades y flujos confiables. La arquitectura de aplicaciones define cómo cooperan las soluciones. La arquitectura tecnológica proporciona plataformas, infraestructura y controles. La arquitectura de seguridad protege los objetivos y activos a lo largo de todos estos dominios.

El Marco de Referencia de Arquitectura TI Colombia ofrece una estructura especialmente pertinente para esta discusión. Sus seis dominios —Estrategia TI, Gobierno TI, Información, Sistemas de Información, Servicios Tecnológicos, y Uso y Apropiación— obligan a mirar la transformación de forma integral. Su valor no consiste en diligenciar instrumentos por obligación, sino en mantener una conversación disciplinada entre situación actual, estado objetivo, brechas, oportunidades, riesgos, responsables e indicadores.

Una arquitectura útil debe responder, como mínimo, seis preguntas:

  1. ¿Qué resultado estratégico necesita producir la organización?
  2. ¿Qué capacidades empresariales permiten obtenerlo?
  3. ¿Qué procesos, información y actores sostienen esas capacidades?
  4. ¿Qué soluciones tecnológicas deben conservarse, integrarse, construirse o retirarse?
  5. ¿Qué brechas, dependencias y riesgos condicionan la transición?
  6. ¿Qué secuencia de iniciativas produce valor sin perder control?

Estas preguntas evitan dos errores frecuentes: comenzar por la herramienta y confundir la arquitectura objetivo con una lista de deseos.

Del PETI documental al PETI ejecutable

El PETI puede ser un instrumento poderoso cuando expresa decisiones, prioridades y responsabilidades. Pierde valor cuando se redacta para cumplir una obligación, se desconecta del presupuesto o se formula sin participación de las áreas misionales.

Un PETI ejecutable no debería limitarse a enumerar proyectos. Debe explicar la relación entre objetivos institucionales, capacidades, información, servicios, sistemas, infraestructura, seguridad, talento e inversión. También debe definir indicadores que permitan saber si la transformación ocurrió, no solamente si el proyecto terminó.

Una reflexión desde la práctica

Esta discusión no es solamente metodológica. En mi experiencia como arquitecto y consultor TIC participo en un diagnóstico de arquitectura AS-IS/TO-BE y en la formulación del PETI para el Ministerio de Relaciones Exteriores, con acompañamiento al Ministerio TIC. El ejercicio confirma que un plan estratégico adquiere valor cuando permite relacionar la realidad institucional con un estado objetivo posible y convertir las brechas en una secuencia de decisiones.

Trabajar con el Marco de Referencia de Arquitectura TI Colombia también muestra que la transformación no puede quedar bajo responsabilidad exclusiva del área de tecnología. Estrategia, gobierno, información, sistemas, servicios y apropiación se afectan mutuamente. Por eso, el PETI necesita participación de las áreas misionales, respaldo directivo y criterios que permitan priorizar más allá de la urgencia operativa.

El Decreto 415 de 2016 refuerza esta orientación al establecer lineamientos para fortalecer institucionalmente la gestión de las tecnologías y los sistemas de información del Estado. La función de TI deja de entenderse únicamente como soporte: debe contribuir a la planeación, la transformación y el cumplimiento de los objetivos de la entidad.

Una prueba sencilla

Seleccione una iniciativa de transformación y trate de explicar, en una sola página, el objetivo estratégico, la capacidad afectada, el problema actual, la información crítica, las aplicaciones involucradas, los responsables, los riesgos, el indicador y la transición. Si esas relaciones no pueden mostrarse, probablemente existe un proyecto tecnológico, pero todavía no una decisión completa de arquitectura.

¿Cómo demostrar que la transformación ocurrió?

La transformación debe expresarse en resultados observables. Terminar un proyecto, instalar una plataforma o ejecutar el presupuesto demuestra que una iniciativa fue realizada; no demuestra que la organización se transformó.

Para verificarla conviene establecer una línea base antes de intervenir y comparar posteriormente el desempeño de la capacidad. Los indicadores deben relacionar tres niveles: el resultado estratégico que se busca, el cambio operativo que debe producirse y el comportamiento de la solución tecnológica que lo habilita.

Si una organización moderniza su proceso de atención, por ejemplo, no basta con medir la disponibilidad del nuevo sistema. También debe observar tiempos de respuesta, errores, reprocesos, satisfacción, calidad de la información y capacidad para resolver la necesidad del ciudadano o cliente. La tecnología se verifica en su nivel; la transformación se demuestra en el desempeño de la organización.

Una cadena mínima de trazabilidad puede formularse así: objetivo estratégico → capacidad empresarial → cambio requerido → iniciativa tecnológica → indicador de adopción → indicador operativo → resultado organizacional. Cada inversión debería mostrar esta relación antes de ser aprobada y durante su ejecución.

La transformación digital fracasa cuando se administra como una sucesión de compras y proyectos inconexos. Escala cuando existe una arquitectura capaz de conectar propósito, capacidades, información, soluciones, inversión, riesgos y personas. Los dividendos digitales no son automáticos: la innovación sin arquitectura puede producir velocidad; difícilmente producirá dirección.

Pregunta para la comunidad: ¿qué iniciativa de su organización parece exitosa como proyecto tecnológico, pero todavía no demuestra una capacidad empresarial transformada?

Convierta la intención de transformación en una hoja de ruta

Scalapp acompaña diagnósticos de arquitectura empresarial y de TI para relacionar estrategia, capacidades, información, soluciones, brechas y proyectos priorizados.

Conozca el enfoque de consultoría estratégica y arquitectura de Scalapp

También puede leer

Referencias

  1. Banco Mundial. (2016). World Development Report 2016: Digital Dividends. https://www.worldbank.org/en/publication/wdr2016
  2. OCDE. (2016). Declaration on the Digital Economy: Innovation, Growth and Social Prosperity. https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0426
  3. Ministerio de Tecnologías de la Información y las Comunicaciones. (2016). MinTIC lanza nuevo instrumento para apoyar la construcción del Plan Estratégico de Tecnologías de la Información. https://www.mintic.gov.co/portal/historico/w3-article-15399.html
  4. Ministerio de Tecnologías de la Información y las Comunicaciones. (2015). Cómo entender el Marco de Referencia de la Arquitectura TI de Colombia. https://www.mintic.gov.co/portal/historico/w3-article-11331.html
  5. Presidencia de la República de Colombia. (2016). Decreto 415 de 2016: lineamientos para el fortalecimiento institucional en materia de TIC. https://www.funcionpublica.gov.co/eva/gestornormativo/norma.php?i=68717

Sobre el autor. Diego Iván Oliveros Acosta es arquitecto de tecnologías de información, ingeniero de Sistemas y Computación e ingeniero Electrónico, magíster en Arquitecturas de Tecnologías de Información, consultor, investigador y docente universitario. Su trabajo conecta estrategia, información, software y tecnología para gestionar complejidad y transformar organizaciones.