Service Designer en gobernanza digital: cómo diseñamos un modelo de priorización para el BID

Como Service Designer & UX Lead en Continuum, lideré durante 7 meses el diseño del primer modelo de gobernanza digital para el ciclo operativo del BID: un Playbook de +150 páginas con lenguaje común, roles definidos, fórmula de priorización objetiva y un proceso de 6 etapas — co-creado con 26 stakeholders de 9 áreas y validado ante la directiva de Operaciones, IT y Change Management. El indicador más honesto de impacto: la implementación quedó condicionada a la contratación de los perfiles que el modelo definió. Eso no es un entregable archivado — es una hoja de ruta que el banco tomó en serio.

Banco Interamericano de Desarrollo (BID)

Service Designer & UX Lead

2023 (7 meses)

Remoto para BID USA

Scroll

AGILE GOVERNANCE MODEL FOR OPERATIONS

UJM del modelo y sus partes

El problema

Una caja negra que afectaba la gestión y la confianza

El BID estaba en medio de una transformación digital con el objetivo de convertirse en un banco orientado a resultados.
El equipo de tecnología (ITE) recibía solicitudes de mejora de sistemas digitales desde múltiples vicepresidencias sin ningún proceso estandarizado: unas llegaban por el sistema formal Convergence, otras por email, otras en reuniones de pasillo.
No existían categorías claras, criterios de priorización ni visibilidad del proceso para los solicitantes.

Equipos invertían meses en desarrollar propuestas que luego eran despriorizadas sin explicación. Las decisiones quedaban en manos de comités que «no terminaban en nada». La gente empezó a saltarse los canales formales para ejecutar por su cuenta. El problema no era solo de proceso — era de confianza institucional.

La restricción más crítica: el BID estaba rediseñando simultáneamente su modelo operativo de ITE, y los cambios estructurales que eso implicaría — nuevos roles, nuevas responsabilidades — aún no estaban definidos cuando comenzamos. Diseñar para un estado organizacional que no existe todavía no tiene manual.

El Insight

Cuando el proceso es burocrático lo lógico era saltárselo

Condujimos 26 entrevistas en profundidad con miembros del banco en roles que iban desde analistas operacionales hasta especialistas IT senior, distribuidos en áreas como VPC, ORP, VPFI, TE, SPD y ADS.

El objetivo de las entrevistas era entender cómo llegaban actualmente las solicitudes tecnológicas a ITE, qué criterios se usaban para priorizarlas, qué fricción experimentaban los solicitantes y qué workarounds habían desarrollado los equipos para sortear el proceso formal.

Paralelamente, hicimos benchmark de modelos de gobernanza digital en otras organizaciones multilaterales y analizamos frameworks globales de priorización de iniciativas digitales. Sintetizamos los hallazgos en 4 clusters:
User Centric, Transparent, Efficient, Measurable. Pero el hallazgo más poderoso no cabía en ninguna categoría limpia.

1

las personas tratan de evitar la burocracia

«Lo que hicimos fue saltarnos ese comité y hacerlo ágil.»
· Entrevistado, área de operaciones Las personas no evitaban el proceso por indisciplina — lo evitaban porque era racionalmente más eficiente hacerlo. Cualquier modelo nuevo corría el riesgo de convertirse en otro comité que nadie usaría. Esto reorientó nuestra hipótesis por completo: el objetivo no era construir un proceso más robusto, sino construir el proceso más liviano posible que aún garantizara transparencia, trazabilidad y priorización objetiva. La asincronía no era una preferencia de diseño, era una condición para que el modelo se instalara.

Decisiones y tradeoffs

Decisiones para un entorno cambiante

1

Diseñar para la incertidumbre, no para el estado actual

Teníamos dos opciones: diseñar el modelo para la estructura organizacional existente (más simple, más rápido) o diseñarlo de forma modular para que sobreviviera a la reestructuración que ITE deseaba implementar. Como equipo elegimos la segunda. Esto implicó diseñar múltiples escenarios de implementación, documentar explícitamente qué componentes dependían de decisiones estructurales pendientes y cuáles podían activarse independientemente.

Un modelo que no quedaría obsoleto antes de implementarse.

Mayor complejidad de entrega y más fricción en la co-creación.

2

Asincronía primero, instancia sincrónica solo para divergencias

La evidencia fue contundente: el banco era experto en crear comités con demasiada gente que terminaban paralizando decisiones. Diseñamos el modelo para que la priorización ocurriera de forma asíncrona mediante una fórmula objetiva automatizable, y la instancia sincrónica fuera convocada únicamente ante divergencias entre equipos. Reducir la cantidad de reuniones obligatorias, era el principio de diseño más crítico.

Diseñar un proceso mas ligero por sobre una mecánica rígida

La tensión: varios stakeholders querían mayor representación en las decisiones. Defendimos la decisión con los datos de las propias entrevistas.

3

Roles bien definidos aunque generaran fricción

El modelo necesitaba roles nuevos: un Request Management Team, un Model Owner, una instancia de decisión lean. Podíamos dejarlos abstractos para dar flexibilidad, o definirlos con precisión aunque eso implicara cuestionar si el banco podría llenarlos. Elegimos la segunda: roles bien especificados, con criterios de selección y perfilamiento explícitos. Generó múltiples iteraciones con stakeholders BID para ajustar alcances, pero resultó en un modelo honesto sobre lo que requería para funcionar.

Roles validados por diferentes actores y departamentos involucrados para distintos escenarios

Requirió un esfuerzo adicional para convocar, iterar y validar cada ajuste

El proceso

Desde la investigación al Playbook

Fase 1
Investigación cualitativa
Para definir el alcance de los principios, los procesos y las partes interesadas incluidos en el modelo de gobernanza, nos sumergimos en la fase de investigación cualitativa en la que participaron 26 miembros pertenecientes a 9 áreas del BID quienes desempeñan diferentes funciones en unidades de negocio relacionadas con las operaciones. Estos participantes compartieron sus experiencias, expectativas y áreas de oportunidad en relación con la formulación de un nuevo modelo.
Temas:
- Función en el ciclo operativo
- Los procesos empresariales y su soporte digital
- Protocolos actuales
- Puntos débiles, expectativas y áreas de oportunidad
Entregables:
→ Key Findings Report sintetizado en 4 clusters (User Centric, Transparent, Efficient, Measurable)
→ Ops Digital Cycle Map
Clusterización

Bajda y análisis de entrevistas

Clusterización

Bajda y análisis de entrevistas

Principios del Modelo

Research output
Fase 2
Benchmark

Compilación de modelos de gobernanza en otras organizaciones multilaterales + frameworks de priorización globales.
Entregable → Benchmark Report

Componentes generales

Comparativa de Modelos
Fase 3
Mapeo del contexto operacional

Levantamiento del ciclo digital operacional del banco (préstamos con garantía soberana) mapeando todos los sistemas utilizados en el proceso, entendiendo cuales se encuentran activos, obsoletos, el nivel de deuda técnica y de soporte que requieren, y con esto para entender qué necesidades cabrían dentro del modelo.
Entregable → Ops Digital Cycle Map

Scroll

Ops Digital Cycle Map
Fase 4
Co-creación con stakeholders
Realización de 3 workshops con 12 actores clave del BID, que nos permitieron iterar y obtener los componentes claves del modelo:
- Arquetipos de usuario del modelo (Navigator, Creator, Business Rules Owner),
- Categorías de solicitudes aceptadas por el modelo,
- Criterios de priorización para las solicitudes
Entregable → Workshop Reports
Value definition

Usuarios del modelo

Criterios de priorizacion

Categorías de solicitud
Fase 5
Prueba de concepto

Condujimos una sesión de validación moderada sobre el prototipo del formulario de ingreso de solicitudes, con 5 usuarios responsables de sistemas del ciclo operativo (system owners). El objetivo no era medir usabilidad, sino exponer ambigüedades de lenguaje y supuestos incorrectos en la arquitectura de cada pregunta antes de abrir el formulario a usuarios finales.

Qué revisamos: alcance del modelo, información disponible para cada perfil, campos cualitativos solicitados, e interacción necesaria entre perfiles técnicos y de negocio.
Tres patrones de feedback se repitieron:

Preguntas de respuesta única en contextos que requerían múltiple selección, tipo de demanda, usuarios impactados, problemas generados, objetivos estratégicos. Ajustadas a redacción en plural y selección múltiple.

Lenguaje técnico que inducía interpretaciones erróneas, por ejemplo, «Business contact» y «Technology contact» eran demasiado abiertos; fueron reformulados para apuntar a roles específicos (persona del equipo de producto / rol funcional ITE asignado).
Campos de impacto con alcance excesivo — «¿Cuántos clientes/empleados se beneficiarían?» se entendía como todos los potenciales. Acotado a «beneficiarios directos desde el día uno de la implementación».

El hallazgo más estratégico no fue una iteración de diseño: una pregunta sobre consistencia entre marcos de política y sistemas reveló que hoy no existe forma de medirla en el banco. El output fue una recomendación de gobernanza al cliente. Implementar indicadores por marco de política, trascendiendo al alcance inicial del formulario.

*Nota metodológica: posterior a la primera sesión (dry run) ajustamos la pauta y mejoramos la entrega de contexto previo a los participantes para obtener mejores resultados en las siguientes.

Entregable → Concept Testing Report + Solution proposal canvas

Artefacto para ingreso de solicitud
Fase 6
Diseño del modelo

User Journey Map del proceso de 6 etapas, definición de actores e interacciones, fórmula de priorización, instancia de decisión, milestones de comunicación
Entregable → Diagramas de flujo y blueprints

Alineamiento estratégico

Ingreso de requerimiento al sistema

Priorización sistémica

Medida del esfuerzo

Sesion asíncrona

Recomendaciones para la ejecición

Solución

Lo que el diseño entregó

El modelo resultante tiene 6 etapas: alineación estratégica y propuesta de solución, ingreso de la solicitud, priorización sistematizada mediante fórmula objetiva, sizing del esfuerzo, aprobación del backlog y recomendaciones para ejecución.

Cada etapa tiene actores definidos, herramientas específicas, indicadores de seguimiento y puntos de comunicación hacia los solicitantes.

Lo más difícil de resolver fue la priorización: diseñar una fórmula que balanceara valor para el usuario, valor para el ciclo operacional, riesgo operativo, riesgo reputacional, complejidad técnica y respaldo institucional, y que fuera lo suficientemente objetiva para reducir el sesgo político, pero lo suficientemente flexible para adaptarse a contextos cambiantes. El modelo también incluye un componente de Change Management con recomendaciones para la adopción gradual, reconociendo que el cambio cultural es tan crítico como el diseño del proceso.

1

Qué se entregó

El paquete final incluyó un Playbook de +150 páginas con la descripción detallada del modelo y su guía de implementación, un deck ejecutivo para distintas audiencias, un glosario de términos definidos en el contexto del modelo, y los artefactos de soporte que sostienen cada decisión: reportes de research, benchmarks, mapas operacionales, journey maps, fórmula de priorización y métricas de éxito.

Ver índice completo de componentes

Investigación

Key Findings Report (4 clusters: User Centric, Transparent, Efficient, Measurable)
Workshop Reports (×3): usuarios, categorías, criterios
Concept Testing Report
Benchmark Report (modelos de gobernanza + frameworks de priorización)
Ops Digital Cycle Map (préstamos con garantía soberana)

Modelo

Actors & interactions
Strategic Alignment Checklist
Solution Proposal Canvas
Request Categories
Request Management Team & Capacity Baseline
Prioritization formula + ejemplo aplicado
Synchronous Decision-Making Instance
Backlog Format
Communication milestones + diagrama
User Journey Map (to-be) del proceso de 6 etapas
Change Management recommendations
Indicadores y métricas de éxito

Comunicación

Playbook completo
Glosario
Deck ejecutivo

Resultados

Impacto alcanzado

El modelo fue presentado a la directiva de Operaciones, IT y Change Management del BID y validado con feedback positivo tanto por el resultado como por la flexibilidad y el proceso de co-creación.Indicadores cualitativos de impacto:

1

Alineación institucional alrededor de 4 principios de diseño

El banco hizo suyos los principios User Centric, Transparent, Efficient y Measurable a lo largo del proceso, usándolos como criterio de decisión más allá del proyecto.

2

Implementación condicionada a la contratación de perfiles específicos

La directiva aceptó que el modelo no podía activarse sin los roles que definimos (Request Management Team, Model Owner, instancia de decisión lean). Señal de que el diseño fue tomado como hoja de ruta real, no como entregable archivado.

3

26 personas de 9 áreas involucradas en investigación y co-creación

Esa amplitud generó una alineación transversal que ningún entregable por sí solo habría logrado, equipos de negocio, tecnología y operaciones llegaron a la presentación final con vocabulario y criterios compartidos.

4

Lenguaje común entre áreas que antes no se hablaban

Los 4 principios y los arquetipos del modelo (Navigator, Creator, Business Rules Owner) quedaron como vocabulario compartido entre negocio y tecnología siendo un activo cultural que sobrevive al proceso mismo.

Reflexión

Lo que aprendí

Hoy rediseñaría las sesiones de co-creación con el banco en formato, cantidad y autonomía. Las que involucraban a perfiles que representaban a sus áreas ante el directorio exigían una facilitación que desbordaba a un equipo pequeño. Incorporaría desde el inicio a un especialista en gobernanza organizacional y a un service designer senior adicional, condiciones a perfeccionar cuando para trabajar con la profundidad que un cliente de esta envergadura requiere. La complejidad del proyecto la fuimos descubriendo en el camino. Hoy la anticiparía en la propuesta.