Gobierno Digital y Transformación Digital

Por qué esto importa para el valor público

Cada organismo público ahora ejecuta al menos un servicio digital, y la mayoría de los líderes pueden señalar un análisis de viabilidad que prometía menor coste, procesamiento más rápido, y ciudadanos más contentos. Demasiados de esos casos entregaron solo el primero de los tres. Un proceso digitalizado que todavía enruta un caso atípico a través de cinco departamentos no está transformado; es el mismo proceso fragmentado vistiendo un frente más rápido, y el ciudadano todavía experimenta la fragmentación, solo que ahora detrás de un formulario que parecía simple.

La presión de digitalizar solo se ha intensificado: los presupuestos son más ajustados, menos personal procesa formularios en papel, y los ciudadanos que hacen banca y compras en línea razonablemente esperan una experiencia comparable de una renovación de licencia o una reclamación de beneficio. Al mismo tiempo, una minoría real de ciudadanos no puede, o no quiere, transaccionar en línea en absoluto, y una estrategia digital-primero perseguida descuidadamente convierte una cola en un mostrador en una barrera permanente para exactamente las personas a las que existe para alcanzar un servicio público.

Aquí es donde el gobierno digital se cruza directamente con la teoría del valor público. Un programa de transformación digital puede fortalecer la capacidad operativa de un servicio —la tercera pata del triángulo estratégico de Mark Moore (véase el Tema 1.2 — El Triángulo Estratégico: Legitimidad, Valor, y Capacidad)— mientras silenciosamente erosiona la legitimidad y el apoyo, si el rediseño deja atrás a los ciudadanos menos capaces de defenderse por sí mismos. La tarea del líder no es elegir entre eficiencia digital e inclusión; es diseñar un servicio donde ambas sean verdad a la vez, y saber, con evidencia en lugar de suposición, si eso realmente está ocurriendo.

El Tema 3.1 situó la gobernanza de la era digital en una tipología más amplia de paradigmas administrativos —jerarquía, mercado, red, y plataforma— y argumentó que su movimiento definitorio es reintegrar lo que las olas de reforma anteriores habían fragmentado (véase el Tema 3.1 — Sistemas y Modelos de Administración Pública). Este tema lleva ese paradigma a la práctica: cómo se diseña un servicio en torno a la necesidad de un ciudadano, a qué compromete a una organización una estrategia de entrega digital-primero, y cómo la infraestructura compartida permite que muchos servicios dejen de reinventar cada uno los mismos componentes.

Conceptos fundamentales

El gobierno digital, a veces llamado gobierno electrónico, es el uso de la tecnología de la información para entregar servicios públicos y realizar transacciones entre el gobierno, los ciudadanos, las empresas, y los propios empleados del gobierno que solían requerir un formulario en papel, una visita a un mostrador, o una llamada telefónica. El término abarca todo desde un sitio web de información estático hasta un servicio completamente transaccional completado de principio a fin en línea; este tema se ocupa del extremo transaccional de ese espectro, y el cambio organizacional que exigen los buenos servicios transaccionales.

El diseño de servicio es la disciplina de diseñar la totalidad de un servicio —la interfaz digital, el proceso de trastienda de apoyo, el personal que maneja excepciones, y los canales físicos o telefónicos junto al digital— como una única experiencia coherente en lugar de proyectos separados que resultan no entrar en conflicto demasiado mal. El diseño de servicio toma prestada una herramienta central de la gestión de operaciones, el plano de servicio, que mapea cada paso que da un ciudadano frente a cada paso que da una organización entre bastidores para apoyarlo, haciendo visibles las transferencias donde realmente ocurren la mayoría de los fallos digitales.

El diseño centrado en el usuario es la disciplina más estrecha, anidada dentro del diseño de servicio, de diseñar una interacción específica —un formulario, una página, una aplicación— en torno a las necesidades, capacidades, y modelos mentales de las personas que la usarán, establecidos mediante investigación directa con ellas en lugar de asumidos desde dentro de la organización. El diseño centrado en el usuario insiste en que las personas que construyen un servicio están estructuralmente peor posicionadas para juzgar si es usable, porque ya saben qué hace cada botón; solo probar con personas que aún no lo saben cierra esa brecha.

Digital-primero, a veces formalizado como digital-por-defecto, es una estrategia de entrega bajo la cual el canal digital se construye para ser la mejor, y usualmente la única activamente promovida, forma de completar una transacción, con otros canales retenidos para personas que no pueden usarlo. La estrategia es una compensación genuina, no una ganancia de eficiencia gratuita: concentra la inversión en un canal, lo que puede producir un servicio dramáticamente mejor para la mayoría, pero solo crea valor público si la organización es igualmente deliberada sobre a quién no alcanza el canal digital.

La exclusión digital es la condición de ser incapaz, por razones de acceso, habilidad, confianza, discapacidad, idioma, o circunstancia, de completar una transacción mediante un canal digital, incluso donde se ofrece uno —una instancia a nivel de servicio de la brecha digital más amplia, el patrón más amplio de acceso desigual a la tecnología digital a través del ingreso, la educación, la geografía, y la edad. El digital asistido es la provisión deliberada de ayuda humana —por teléfono, en persona, o mediante un intermediario de confianza— para personas que experimentan exclusión digital, diseñada como una parte de primera clase del servicio en lugar de un respaldo residual para el que nadie planifica capacidad.

El gobierno como plataforma es el patrón, nombrado y defendido por el comentarista tecnológico Tim O'Reilly en 2010, de construir un pequeño número de piezas compartidas y reutilizables de infraestructura —comúnmente la verificación de identidad, los pagos, las notificaciones, y el intercambio de documentos— una vez, con un alto estándar, de modo que se puedan construir muchos servicios individuales sobre ellas en lugar de que cada uno reconstruya su propia versión. La capa de intercambio de datos X-Road de Estonia, construida desde 2001 y desde entonces adoptada o adaptada por varios otros países, es una instancia del mundo real ampliamente citada del patrón a escala nacional. Los estándares de intercambio de datos e interoperabilidad que permiten a los componentes compartidos intercambiar información de forma segura a través de límites organizacionales son su propio tema sustancial (véase el Tema 5.4 — Datos del Sector Público, Interoperabilidad, y Datos Abiertos); este tema trata el gobierno como plataforma como un patrón de diseño de servicio y gobernanza, mientras las elecciones de ingeniería de cómo se construyen, compran, o modernizan tales componentes pertenecen al lado de entrega de software del tema (véase el Tema 5.3 — Ingeniería de Software y Plataformas del Sector Público).

La identidad digital es un componente de plataforma compartida fundacional: una forma verificada y reutilizable de establecer que un usuario en línea es quien afirma ser, construida una vez de modo que un servicio de impuestos, un servicio de beneficios, y un servicio de licencias no resuelvan cada uno la verificación de identidad independientemente. Los esquemas de identidad digital van desde números de identidad nacional centralizados hasta sistemas federados en los que varios verificadores independientes cada uno avala a un usuario, y la elección entre ellos conlleva consecuencias para la privacidad, la resiliencia, y la confianza que una evaluación puramente técnica pasará por alto.

Los estándares de servicio digital son conjuntos codificados de principios, usualmente emparejados con una puerta de evaluación independiente antes de que un servicio pueda lanzarse o escalar, que un número creciente de gobiernos usan para mantener a los equipos de entrega frente a una barra común: comenzar con las necesidades del usuario, probar con usuarios reales, construir iterativamente, y hacer accesible el servicio a personas con discapacidades. Son un mecanismo de gobernanza tanto como de diseño, porque dan a una función digital central la autoridad de detener el lanzamiento de un servicio que no ha cumplido la barra —usualmente la única influencia que hace de un estándar más que aspiracional. El Government Digital Service (GDS) del Reino Unido, establecido en 2011, es un ejemplo original ampliamente estudiado de una unidad central que mantiene a los departamentos frente a exactamente este tipo de estándar publicado.

Mejores prácticas

1. Comience cada rediseño de servicio desde la necesidad del ciudadano, expresada en sus propias palabras, no desde el mapa de proceso interno de la agencia. Entreviste u observe a personas realmente intentando completar la transacción antes de dibujar un único wireframe; la brecha entre cómo describe el personal un proceso y cómo lo experimenta un ciudadano usualmente es donde vive la oportunidad de rediseño.
2. Prototipe y pruebe con usuarios reales antes de comprometerse con la construcción de producción. Un prototipo en papel probado con diez personas de la población de usuarios real encuentra más problemas de usabilidad, más rápido y más barato, que un sistema terminado probado con nadie hasta el lanzamiento.
3. Adopte un estándar de servicio digital con una puerta de evaluación genuina, no una lista de verificación que nadie hace cumplir. Un estándar solo cambia el comportamiento si a un servicio se le puede decir que no antes de que se lance; publique los criterios y dé al organismo evaluador la autoridad de aplicarlos.
4. Diseñe el canal de digital asistido como parte del servicio desde el primer día, dotado de recursos y medido como se hace el canal digital. Trate la línea telefónica, el trabajador de alcance comunitario, o el terminal de biblioteca apoyado por personal capacitado como un canal diseñado con sus propios niveles de servicio, no una válvula de emergencia improvisada después de que lleguen quejas.
5. Mida la exclusión digital directamente para cada servicio, en lugar de asumir que aplican los promedios nacionales. La población que no puede completar una reclamación de beneficios en línea no es la misma población que no puede renovar una licencia comercial en línea; mida los usuarios y no usuarios reales de cada servicio, y actualice la estimación a medida que cambian el servicio y su población.
6. Construya los componentes de plataforma compartida una vez y exija, no meramente permita, que los servicios los reutilicen. Un componente compartido de identidad o pagos que los equipos son libres de ignorar será ignorado por el equipo bajo la mayor presión de entrega, lo que derrota el propósito; la reutilización necesita ser la ruta predeterminada, con un proceso de excepción documentado para el raro caso en que genuinamente no encaje.
7. Dé a cada componente de plataforma compartida un propietario de producto nombrado y responsable con una hoja de ruta pública. Un servicio compartido sin propietario visible acumula defectos no abordados y tiempo de inactividad no explicado que los equipos consumidores individuales no tienen poder de arreglar, lo que erosiona la confianza en la reutilización más rápido que casi cualquier otra cosa.
8. Use equipos de entrega pequeños, facultados, y multifuncionales en lugar de programas secuenciales grandes para servicios orientados al ciudadano. Un equipo que incluye investigación de usuarios, diseño, ingeniería, y experiencia de política juntos, trabajando en ciclos iterativos cortos asociados con el desarrollo ágil de software, puede corregir el rumbo sobre evidencia en vivo de una forma que no puede un programa estructurado en torno a una especificación fija y una única fecha de lanzamiento.
9. Publique los datos de desempeño para servicios en vivo abiertamente, incluyendo los números incómodos. Las métricas transparentes sobre tasas de finalización, tiempos de espera, y demanda de digital asistido crean presión externa para seguir mejorando un servicio después del lanzamiento, cuando la atención interna típicamente ya se ha movido a la próxima prioridad.
10. Construya la accesibilidad desde el primer prototipo, frente a un estándar reconocido, en lugar de adaptarla retroactivamente antes del lanzamiento. La accesibilidad adaptada retroactivamente es cara, incompleta, y usualmente se descubre solo cuando un ciudadano con una discapacidad no puede completar en absoluto una transacción legalmente requerida.
11. Mantenga abierto el canal no digital hasta que la evidencia de digital asistido, no una fecha límite en un plan, muestre que es seguro retirarlo. Cerrar un canal en papel o mostrador en una fecha fija, independientemente de cuántas personas todavía dependan de él, convierte un hito de entrega en un evento de exclusión.
12. Trate un servicio mínimo viable, no un producto mínimo viable, como la unidad de lanzamiento. Un servicio solo es viable para el lanzamiento cuando su ruta de digital asistido, su manejo de excepciones, y sus protecciones de datos están listos junto al frente digital, no meramente cuando funcionan las pantallas de camino feliz.

Preguntas para discutir con su equipo

¿Sabemos, con evidencia directa en lugar de suposición, quién no puede usar nuestro servicio digital de mayor volumen, y qué le pasa hoy? La mayoría de las organizaciones pueden describir el desempeño de su canal digital en detalle y a sus usuarios no digitales solo en términos generales, si acaso. Use esta pregunta para averiguar si alguien realmente ha medido quién está excluido de un servicio específico, en lugar de citar una estadística nacional de brecha digital que puede no describir en absoluto la población de este servicio. Discuta qué canal usan actualmente esos ciudadanos excluidos, si está adecuadamente dotado de recursos, y quién posee asegurarse de que siga siendo así. Trate una respuesta segura sin evidencia detrás como una señal de alerta, no una garantía.

¿Qué partes de nuestro patrimonio tecnológico estamos construyendo por separado hoy que en cambio podrían construirse una vez como un componente de plataforma compartida? La verificación de identidad, los pagos, las notificaciones, y la carga de documentos comúnmente se reconstruyen dentro de servicios individuales incluso donde ya existe una versión compartida en otro lugar de la misma organización o sector. Use esta pregunta para inventariar dónde está ocurriendo la duplicación y sea honesto sobre por qué: necesidad técnica genuina, accidente histórico, o la desconfianza razonable de un equipo de que un servicio compartido será lo suficientemente confiable para depender de él. Discuta qué se necesitaría, técnica y organizacionalmente, para consolidar primero la duplicación más clara. Esta es una pregunta de gobernanza tanto como de ingeniería.

¿Hemos probado este servicio con usuarios significativamente diferentes de las personas que lo construyeron? Un equipo que es joven, cómodo con la tecnología, y fluido en la propia jerga de la organización sistemáticamente pasará por alto problemas que golpean inmediatamente a un usuario mayor, menos confiado, o que no habla el idioma nativamente. Use esta pregunta para comprobar quién realmente estaba en la sala durante la investigación de usuarios, no solo cuántas sesiones se realizaron. Discuta si la investigación incluyó a personas con discapacidades, personas con baja confianza digital, y personas que no hablan el idioma principal del servicio como primer idioma. Si la respuesta honesta es que las pruebas fueron convenientes en lugar de representativas, trate las afirmaciones de usabilidad del servicio como no probadas.

Si rediseñáramos este servicio hoy, completamente en torno a la necesidad del ciudadano, ¿qué dejaríamos de pedirle que hiciera? La mayoría de los servicios digitales heredados todavía piden a un ciudadano que sepa a qué departamento acercarse, qué número de referencia citar, o qué formulario corresponde a su situación —conocimiento organizacional que un servicio bien diseñado llevaría en nombre del ciudadano en cambio. Use esta pregunta para recorrer los pasos actuales de su servicio y preguntar, para cada uno, si existe para servir la necesidad del ciudadano o la estructura interna de la organización. Discuta qué necesitaría cambiar en la trastienda, no solo en el frente, para eliminar cada paso que falla esa prueba.

¿Quién posee la fiabilidad, la seguridad, y la hoja de ruta de cada componente de plataforma compartida del que dependen nuestros servicios, y reconocería ese nombre cada equipo dependiente? La infraestructura compartida sin un propietario claramente responsable tiende a mantenerse reactivamente, por quien esté menos ocupado cuando se rompe, lo cual es una base pobre para servicios que cada vez más la tratan como crítica. Use esta pregunta para comprobar si los equipos dependientes realmente podrían nombrar hoy quién posee su componente de identidad, pagos, o notificación. Discuta qué ocurre, operativamente y en términos de rendición de cuentas pública, si ese componente falla durante un período pico como una fecha límite de presentación o una fecha de pago de beneficios.

Cuando describimos un servicio como digital por defecto, ¿queremos decir que es el mejor canal, o el único que realmente estamos dotando de recursos? Estas suenan idénticas en un documento de estrategia y son completamente diferentes en la práctica: la primera es una elección legítima de diseño de servicio emparejada con una alternativa dotada de recursos, y la segunda es una decisión de recorte de costes vistiendo una justificación de diseño de servicio. Use esta pregunta para examinar la última decisión importante de cambio de canal que tomó su organización y pregunte honestamente cuál de las dos realmente fue. Discuta qué evidencia las distinguiría, y si esa evidencia se recopiló antes o solo después de que se tomó la decisión.

En la práctica: un ejemplo de valor público

Una autoridad de transporte regional —ficticia, ilustrativa de un patrón en lugar de un informe sobre ningún organismo real— ejecutaba un esquema de pase de viaje concesional para residentes mayores y discapacitados, administrado mediante un formulario de solicitud en papel que había que enviar por correo con documentos de apoyo y procesar a mano. El procesamiento tomaba, en promedio, seis semanas, los solicitantes frecuentemente enviaban los documentos de apoyo equivocados porque las instrucciones del formulario estaban escritas en lenguaje administrativo que nadie fuera de la autoridad realmente usaba, y un atraso creciente estaba generando un flujo constante de quejas a los miembros de junta electos.

La nueva líder digital de la autoridad resistió el primer instinto obvio, que era encargar una versión en línea del formulario existente. En cambio, el equipo pasó tres semanas observando a los solicitantes completar el proceso en papel, en sus hogares y en centros comunitarios, antes de escribir una línea de especificación digital. Encontraron que el mayor problema del formulario en papel no era que fuera papel; era que el formulario asumía conocimiento que no tenía el solicitante, listaba los documentos de apoyo en una secuencia que no coincidía con cómo las personas naturalmente los reunían, y no daba forma de comprobar el estado de la solicitud aparte de una llamada telefónica a un centro de llamadas sobrecargado.

El servicio rediseñado movió a la mayoría de los solicitantes a un formulario en línea que pedía información en el orden en que las personas naturalmente la tenían a mano, explicaba en lenguaje llano por qué se necesitaba cada documento, y permitía a un solicitante comprobar el estado en cualquier momento —pero el equipo trató el canal de digital asistido como un problema de diseño igualmente serio, no una ocurrencia tardía. Se asociaron con la red de centros comunitarios de la región, varios de los cuales eran organizaciones del sector social ya confiadas por los residentes mayores, capacitando al personal ahí para ayudar a los residentes a completar el mismo formulario digital en un terminal compartido en lugar de revertir al papel, y mantuvieron un canal de papel genuino abierto, dotado de recursos a un nivel fijado por la demanda medida en lugar de por un supuesto de que la demanda simplemente desaparecería.

Para la verificación de identidad, la autoridad reutilizó un componente de identidad digital que ya había construido el gobierno nacional para servicios de impuestos y beneficios, en lugar de construir el suyo propio —una elección explícita de gobierno como plataforma que ahorró meses de tiempo de desarrollo y dio a los solicitantes una experiencia de verificación que algunos de ellos ya habían usado en otro lugar. Dieciocho meses después del lanzamiento, el tiempo de procesamiento para solicitudes en línea había caído de seis semanas a cuatro días; las solicitudes de digital asistido y en papel, ahora una minoría del total pero todavía varios miles al año, se rastreaban con el mismo objetivo de nivel de servicio que el canal digital, y la autoridad podía informar, con datos realmente medidos en lugar de una estimación, exactamente cuántos residentes todavía dependían de cada canal y por qué.

Cuatro lentes sectoriales

Gobierno local

Las autoridades locales entregan los servicios de mayor volumen y más cara a cara en el gobierno —beneficios, vivienda, residuos, bibliotecas, atención social— lo que las hace el nivel donde la exclusión digital es más visible y más costosa de equivocar, porque la población con más probabilidad de necesitar un servicio local en persona a menudo es la población con menos probabilidad de estar cómoda en línea. La ventaja del gobierno local es la proximidad: los centros comunitarios, las bibliotecas, y las organizaciones voluntarias locales ya existen como una red de digital asistido de confianza, si la autoridad diseña servicios para trabajar con ellos en lugar de en torno a ellos. Su desventaja es la escala: una única autoridad rara vez tiene el presupuesto o la capacidad de ingeniería para construir ella misma componentes de plataforma compartida, así que su capacidad de reutilizar un servicio regional o nacional de identidad, pagos, o notificación, en lugar de construir un equivalente local más débil, determina en gran medida qué puede entregar.

Gobierno nacional

Las administraciones nacionales usualmente son el único nivel de gobierno con la escala para justificar construir infraestructura de plataforma genuinamente compartida —identidad, pagos, notificaciones— y la autoridad, en principio, para mandatar su reutilización entre departamentos. En la práctica, esa autoridad frecuentemente se disputa: el mandato de una unidad digital central de exigir la reutilización habitualmente choca con la autoridad presupuestaria de un departamento, la fecha límite de entrega, y el escepticismo razonable sobre depender de infraestructura que no controla, haciendo eco de la tensión más amplia entre la jerarquía y la coordinación de plataforma en la tipología de paradigma (véase el Tema 3.1 — Sistemas y Modelos de Administración Pública). Los países que sostienen una función digital central con autoridad real sobre los estándares y la reutilización de plataforma —un patrón que rastrea el Índice de Gobierno Digital de la OCDE entre países miembros, en adhesión, y socios— tienden a mostrar menos sistemas duplicados y calidad de servicio más consistente entre departamentos, aunque el índice también muestra que esta autoridad se construye de forma desigual incluso entre gobiernos bien dotados de recursos.

Sector social y sin ánimo de lucro

Las organizaciones sin ánimo de lucro y comunitarias ocupan dos roles distintos en el gobierno digital, y confundirlos causa daño real: frecuentemente son el canal de digital asistido de último recurso para ciudadanos excluidos de un servicio gubernamental, absorbiendo un coste y un deber de cuidado que nunca se encargó ni financió formalmente, y cada vez más se espera que construyan sus propios servicios digitales frente a un estándar moldeado por las mismas expectativas de usuario, con una fracción del presupuesto de ingeniería de un departamento gubernamental. Una organización del sector social de la que una agencia gubernamental silenciosamente ha llegado a depender para apoyo de digital asistido merece una relación explícita, e idealmente financiada, en lugar de un supuesto de que la buena voluntad y la alineación de misión absorberán la demanda indefinidamente.

Multilateral e internacional

Los organismos de desarrollo multilaterales tratan el gobierno digital sustancialmente como un asunto de desarrollo y gestión de finanzas públicas: el programa GovTech del Banco Mundial, por ejemplo, enmarca la reforma de administración pública habilitada por tecnología como central para la efectividad gubernamental en países de ingreso bajo y medio, no como un lujo reservado para los más ricos. La identidad digital a menudo es la vanguardia de este trabajo, porque una plataforma de identidad confiable e inclusiva es una precondición para entregar casi cualquier otro servicio digital a escala, y sus elecciones de diseño —centralizada o federada, biométrica o basada en credenciales— conllevan consecuencias para la inclusión financiera y las libertades civiles que sopesan los socios de desarrollo junto a la pura eficiencia de entrega. El sistema de identidad biométrica Aadhaar de India, el esquema más grande de su tipo, ilustra tanto el alcance que puede lograr tal plataforma como las compensaciones disputadas de privacidad y exclusión que plantea a escala nacional. La interoperabilidad transfronteriza sigue siendo el problema no resuelto más difícil a esta escala: la identidad digital de un ciudadano, una vez verificada, rara vez se transfiere limpiamente a través de un límite nacional, lo que limita cuán lejos puede extenderse actualmente el patrón de plataforma más allá de una única jurisdicción.

Modos de fallo comunes

Entrega solo digital que silenciosamente excluye. Una organización rediseña un servicio como digital-primero, mide el éxito por el volumen de cambio de canal, y solo descubre después del lanzamiento cuántos ciudadanos no podían completar la transacción en absoluto. El lanzamiento de Healthcare.gov de Estados Unidos en 2013 es una instancia pública bien documentada de este patrón: un proceso de inscripción en línea obligatorio falló bajo carga y bajo pruebas de usabilidad del mundo real en el momento en que los ciudadanos más lo necesitaban, y el arreglo requirió una movilización de emergencia de talento técnico externo. El coste no es solo los ciudadanos directamente excluidos; es la erosión de legitimidad que sigue cuando un programa digital insignia visiblemente falla a las personas a las que se construyó para servir.

La plataforma que nadie está obligado a usar. Una función central construye un componente compartido genuinamente bueno de identidad, pagos, o notificación, pero la adopción sigue siendo opcional, así que los equipos bajo mayor presión de entrega construyen su propio equivalente más débil en lugar de integrarse con infraestructura que no controlan y no pueden influir. El coste se acumula a lo largo de años en exactamente el paisaje duplicado e inconsistente que el patrón de plataforma se construyó para prevenir, mientras el propio componente compartido se ve privado del uso y la inversión que habrían justificado su presupuesto.

Diseño de servicio que se detiene en la interfaz. Un equipo aplica una habilidad genuina de diseño centrado en el usuario a las pantallas de un formulario mientras deja completamente sin cambios el proceso fragmentado de trastienda detrás de él, produciendo una experiencia orientada al ciudadano que parece coherente justo hasta el punto en que un caso sale del camino feliz —el mismo patrón de barniz digital descrito más generalmente en la tipología de paradigma (véase el Tema 3.1 — Sistemas y Modelos de Administración Pública). El coste es un servicio que se prueba bien en una demostración y falla exactamente donde los ciudadanos con las necesidades más complejas, y a menudo más urgentes, realmente lo encuentran.

El digital asistido tratado como un error de redondeo. Un análisis de viabilidad digital-primero modela en detalle el coste del canal digital y asigna una línea presupuestaria simbólica e infrafinanciada a 'otros canales', sobre un supuesto de que la demanda de digital asistido será pequeña y temporal. El coste sale a la superficie como colas de centro de llamadas, organizaciones comunitarias absorbiendo demanda no financiada, y una población excluida persistente que los propios datos de la organización nunca se diseñaron para ver lo suficientemente claramente como para corregir.

Accesibilidad adaptada retroactivamente al final. La accesibilidad se trata como una comprobación de cumplimiento realizada poco antes del lanzamiento en lugar de una restricción de diseño presente desde el primer prototipo, así que los problemas se encuentran tarde, son caros de arreglar, y a veces no se arreglan antes del lanzamiento en absoluto. El coste recae desproporcionadamente sobre los ciudadanos con discapacidades que intentan una transacción legalmente requerida, y frecuentemente termina en un rediseño costoso, una queja regulatoria, o ambos.

Modelo de madurez

Lista de verificación

• Observar o entrevistar a usuarios reales completando el proceso actual antes de especificar un rediseño.
• Prototipar y probar con usuarios representativos de la población completa, incluyendo personas con baja confianza digital y discapacidades.
• Adoptar un estándar de servicio digital con una puerta de evaluación independiente antes del lanzamiento.
• Diseñar y dotar de recursos el canal de digital asistido junto al canal digital, no después de él.
• Medir la exclusión digital para este servicio específico, no solo frente a una estimación nacional general.
• Identificar qué componentes de plataforma (identidad, pagos, notificaciones, intercambio de documentos) ya existen para reutilización antes de construir nuevos.
• Nombrar un propietario responsable y publicar una hoja de ruta para cada componente de plataforma compartida del que dependa el servicio.
• Construir y probar la accesibilidad desde el primer prototipo frente a un estándar reconocido.
• Publicar los datos de desempeño de servicio en vivo, incluyendo las tasas de finalización y la demanda de digital asistido.
• Fijar el retiro de un canal no digital según evidencia de niveles de demanda seguros, no una fecha de calendario fija.
• Confirmar que se ha rediseñado el proceso de trastienda, no solo la interfaz orientada al ciudadano.
• Revisar quién, dentro y fuera de la organización, está actualmente absorbiendo demanda de digital asistido no financiada.

Fuentes clave

• Tim O'Reilly, 'Government as a Platform', Innovations: Technology, Governance, Globalization (MIT Press, 2011) —el argumento originario para la infraestructura gubernamental compartida y reutilizable.
• Patrick Dunleavy, Helen Margetts, Simon Bastow y Jane Tinkler sobre la gobernanza de la era digital (véase el Tema 3.1 — Sistemas y Modelos de Administración Pública para la cita completa) —el paradigma dentro del cual se sitúa la práctica de este tema.
• OCDE, 2023 Digital Government Index —evaluación comparativa de los fundamentos del gobierno digital entre países miembros, en adhesión, y socios.
• Banco Mundial, GovTech Global Partnership —reforma del sector público habilitada por tecnología entre niveles de ingreso.
• UK Government Digital Service, Government Design Principles —un ejemplo publicado de los principios de diseño de un estándar nacional de servicio digital.
• Investigación del Nielsen Norman Group sobre el plano de servicio y sobre el lanzamiento de Healthcare.gov en 2013 —metodología aplicada de diseño de servicio y usabilidad y un caso de fallo documentado.

Referencias

1. E-government — Wikipedia — https://en.wikipedia.org/wiki/E-government
2. Service design — Wikipedia — https://en.wikipedia.org/wiki/Service_design
3. User-centered design — Wikipedia — https://en.wikipedia.org/wiki/User-centered_design
4. Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
5. Digital identity — Wikipedia — https://en.wikipedia.org/wiki/Digital_identity
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. X-Road — Wikipedia — https://en.wikipedia.org/wiki/X-Road
8. Aadhaar — Wikipedia — https://en.wikipedia.org/wiki/Aadhaar
9. Digital era governance — Wikipedia — https://en.wikipedia.org/wiki/Digital_era_governance
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Tim O'Reilly, 'Government as a Platform' — Innovations: Technology, Governance, Globalization / MIT Press — https://direct.mit.edu/itgg/article/6/1/13/9649/Government-as-a-Platform
12. 2023 OECD Digital Government Index — OECD — https://www.oecd.org/en/publications/2023-oecd-digital-government-index_1a89ed5e-en.html
13. GovTech: Putting People First — World Bank — https://www.worldbank.org/en/programs/govtech
14. Government Design Principles — GOV.UK / UK Government Digital Service — https://www.gov.uk/guidance/government-design-principles
15. Service Blueprinting in Practice: Who, When, What — Nielsen Norman Group — https://www.nngroup.com/articles/service-blueprinting-practice/
16. HealthCare.gov's Account Setup: 10 Broken Usability Guidelines — Nielsen Norman Group — https://www.nngroup.com/articles/affordable_care_act_usability_issues/