Transformación Digital: Tu empresa es una empresa de software

Fuimos invitados a exponer al Postítulo de Gestión Informática de la Universidad Católica de Chile sobre Transformación Digital.  Ésta es una serie de artículos en base a dicha charla y algunos de sus slides. Es bastante contenido, pero lo hemos divido para su fácil lectura. Que lo disfruten 🙂

El software se sigue comiendo el mundo

Marc Andreessen escribió el 2011 una columna muy influencial en el Wall Street Journal: “El software se está comiendo el mundo”. Cada vez más industrias y negocios se ejecutan mediante software y entregan servicios online. Amazon mató a Borders, el mayor distribuidor de libros en EEUU, y hoy amenaza al retail tradicional. Netflix mató a Blockbuster, y hoy con su negocio de streaming y producción de series amenaza a los gigantes del cable y la televisión.

En Chile a Feria del Disco le pasó lo mismo.

Y Amazon y Netflix son — por supuesto — empresas de software. Por algo Amazon Web Services es el proveedor cloud más grande del mundo… y Netflix uno de sus mayores clientes.

Andreessen nos hizo ver que la industria discográfica hoy trabaja para generarle contenido a empresas de software (Spotify, Apple iTunes). Que la empresa que amenazó el dominio de Disney fue Pixar, una empresa donde el software era una competencia core. Sabemos que Google genera sus ingresos en la industria publicitaria, pero nadie se engaña: ¡es una empresa de software! Facebook, LinkedIn, PayPal, eBay, Skype: puras empresas de software que para el 2011 ya se habían comido un trozo del mundo.

Pero esto no para: Uber y AirBnB no eran conocidas el 2011 y hoy se comen el mundo del transporte y hotelería en todos lados. Apple Music es una novedad post 2011. Bitcoin y todo el ecosistema de empresas alrededor de esta tecnología tienen a toda la industria financiera preocupada. Coursera en educación, Slack en comunicación, Stripe en pagos, Snapchat en redes sociales publicidad y medios. SurveyMonkey le quita un pedazo de la torta a los Adimark de todo el mundo. Y así suma y sigue.

¿Y en Latinoamérica? Cuesta más encontrarlas, pero hay casos como MercadoLibre, Platzi o PortalInmobiliario que, con todas las particularidades de la región, igual se comen un trocito del mundo. Y hasta los monopolios tienen que armar un negocio de software si se quieren mantener vivos:

Transbank es una empresa de software, a pesar de la página web de la década pasada que se ve aquí.

Transbank es una empresa de software, a pesar de que la página web con look retro nos sugiera lo contrario.

¿Por qué cuesta encontrar casos en Latinoamérica?  Primero, porque en tecnología e innovación vamos retrasados. Y segundo porque la globalización no perdona: Google y Facebook también se comen a los medios publicitarios de Latinoamérica, Netflix es responsable de que uno vea menos televisión por cable aunque viva en Chile, nuestra estadía en Lima la buscamos por AirBnB, y usamos Uber al viajar por Santiago y por Bogotá.

Empresas de software que se comen el mundo. La mota borrosa arriba a la derecha son las empresas latinoamericanas que encontramos.

Empresas de software que se comen el mundo. Arriba a la derecha pusimos empresas que lo hacen en latinoamérica. Pero si tuviéramos que ponerlas a escala ocuparían uno o dos pixeles.

¿Y por qué el software se come el mundo ahora? Las tecnologías para construir este tipo de empresas están más maduras, y los canales son mucho más numerosos. Se espera en los próximos 10 años a 5.000 millones de usuarios con smartphones. Las herramientas de programación de software y los servicios basados en Internet facilitan la creación de industrias que operan en mercados más amplios y con menores inversiones en infraestructuras y empleados.

Es importante ver la magnitud de la transformación que conlleva esta digitalización y globalización simultánea. Así podremos entender…

La nueva realidad

Las empresas que no sepan jugar en el mundo del software son los puntitos

Las empresas que no sepan de software son los puntitos que se come el mono amarillo.

Así de simple. Es cosa de mirar alrededor, incluso en empresas “tradicionales”: toda la logística de Walmart (una de sus ventajas competitivas) es software. El revenue management de las aerolíneas (parte vital de su supervivencia) es software. La industria del petróleo lidera áreas de supercomputación y modelamiento en software porque lo necesitan para ver donde hacen sus apuestas para perforar y bombear. Para qué hablar de la industria financiera.

Y si vas a ser (o ya eres) una empresa de software, ¿estás preparado para competir mano a mano, globalmente, con otras empresas de software? ¿Sabes crear software de primer nivel? Ahí estará la ventaja competitiva del futuro. O la razón de tu derrota, como le acaba de pasar a DHL.

Siguiente entrega: Las Empresas Digitales también se Transforman.

Antes ir a los tips de cómo diagnosticar y mejorar las prácticas de las áreas TI de tu empresa o actualizar su estrategia a un mundo digital, en el próximo artículo de esta serie veremos un caso de Transformación Digital muy ilustrativo y con el que podremos hacer paralelos con nuestros dolores y posibles soluciones. La sorpresa del caso que les contaremos es que la empresa transformada no es una corporación muy antigua, ni la clásica empresa de átomos que tiene que aprender de bits. Hablaremos de Facebook, cuyo naciente imperio construido sobre la web “clásica” fue seriamente amenazado por la revolución de los smartphones.

Suscríbete a nuestro newsletter de tecnología+negocios+diseño y sé el primero en enterarte cuando publiquemos el siguiente artículo de esta serie. 

Lo que UX y Service Design podrían hacer por el sector público

En un artículo anterior sobre la falta de UX en Latinoamérica mencioné de pasadita el sector público y de cómo tienen relegado el diseño a poco más que concursos de afiches y de sillas. Y mientras, a medida que avanza el tiempo, más y más empresas privadas van entendiendo la importancia de invertir en UX (con variados grados de éxito), el sector público sigue igual de estancado.

Es especialmente preocupante por dos razones: (1) el Estado, sus entidades y servicios afectan universalmente a todos, sin excepción; y (2) el Estado funciona con nuestra plata, y hoy nuestra plata está siendo malgastada en servicios y canales pobres y deficientes.

El ejemplo de gov.uk en el Reino Unido es emblemático, pero no tanto por el rediseño del sitio en sí, sino por todo lo que trae detrás: criterios de diseño universales, una reestructuración de los servicios públicos y una cultura centrada en servir mejor a los ciudadanos que hizo posible el equivalente a un Ministerio del Diseño.

Y por otro lado, el “sector público” es mucho más que meramente los servicios centrales del gobierno; finalmente, las municipalidades, las autoridades tributarias, los consulados, los hospitales públicos, la policía o los tribunales de justicia impactan tanto o más directamente en la vida de los ciudadanos.

En casi todos los gobiernos latinoamericanos han surgido iniciativas para mejorar la comunicación con los ciudadanos (como Chile Atiende), pero sin una cultura que impregne a los estamentos antes mencionados, la “experiencia ciudadana” seguirá siendo pobre.

Las municipalidades, las autoridades tributarias, los consulados, los hospitales públicos, la policía o los tribunales de justicia también son parte del “sector público” que necesita rediseño

Hemos mejorado, por supuesto; pero la rapidez y la magnitud de las mejoras siguen estando continuamente por detrás del avance tecnológico del resto del mundo, e incluso me atrevo a decir que la brecha está aumentando. ¿Por qué el Estado beca iniciativas de investigación tecnológica y no es capaz de aplicarlas sobre sí mismo?

Tal vez falta tener más a la vista los beneficios que podría traer invertir en rediseñar y digitalizar los servicios públicos usando UX y Service Design. Aquí van algunas ideas, que espero que eventualmente alcancen a las personas correctas:

Reducción de burocracia

Aquí en Perú intentamos una vez con Continuum postular a una licitación para un rediseño de un sitio Web de un sistema público de salud. Fue debut y despedida: la cantidad de tiempo que perdimos en interpretar un documento de requerimientos de 45 páginas y tener que llenar requisitos absurdos, tales como una “Declaración Jurada de que El Equipo Cuenta Con Experiencia En Diseño Web“, nos quitó todo el entusiasmo. Y nos dimos cuenta que los procesos de licitación del Estado están optimizados para favorecer al proveedor mediocre: ése que no cobra tan caro pero tampoco es tan malo, y que tiene tiempo para llenar y presentar papeleos.

La burocracia es esencialmente una manera ineficiente de lidiar con la desconfianza. Añadimos reglas, requisitos, validaciones y trámites porque necesitamos asegurarnos el doble y el triple que no nos mienten y no intentan defraudarnos. Pero mirando los índices de corrupción de nuestros países, no pareciera que el llenado de formatos y declaraciones juradas esté ayudando de mucho. Y el problema es que servicios diseñados sobre la base de la desconfianza generan malas relaciones con los ciudadanos que sí son honestos: y es ahí donde vemos filas de personas enojadas y cansadas, atendidas por otros igualmente enojados y cansados funcionarios.

La UX bien entendida apunta principalmente a la simplificación. Y una gran cantidad de simplificación puede ser obtenida al diseñar en base a la confianza. No sacamos nada con rediseñar nuestros formularios para que se vean más bonitos, si dichos formularios siguen pidiendo información innecesaria o redundante.

La UX bien entendida apunta principalmente a la simplificación

Esto es relevante porque una buena parte de la complejidad que añade la burocracia al funcionamiento de los servicios es cognitiva. Los formularios, documentos e incluso las instituciones están etiquetados con códigos y siglas que sólo le son familiares a los funcionarios y no a los ciudadanos: “Acérquese al DER para pedir el formulario F-004 que luego tiene que presentar en DIMED de 9:00 a 10:00” es el tipo de frases con las que todos alguna vez nos hemos topado.

Rediseñar usando nomenclaturas más amigables contribuye a reducir la complejidad percibida, incluso en casos donde no es posible reducir el papeleo. Pero para lograr ese tipo de empatía, necesitas trabajar en él; investigar, entrevistar, hacer card-sorting, prototipar, testear e iterar. La manera de trabajar y el día a día de los servicios públicos no tienen ningún espacio dedicado a la escucha y a la mejora continua.

La burocracia es una manera ineficiente de lidiar con la desconfianza

Mayor eficiencia operacional

Intentar sacar patente municipal en Las Condes (Santiago) puede ser mareante para el que no tiene experiencia. Primero tienes que sacar número y esperar tu atención en un módulo, donde te entregan un formulario que tienes que llenar para luego sacar número en el módulo del lado, donde con dicho formulario solicitas un certificado de propiedad que luego vuelves a presentar en el primer módulo. Cuando me sucedió, lo primero que pensé es: ¿por qué diablos no se pasan esa información internamente? ¿Por qué tengo que ir yo a hacer dos filas para pedir documentos que están en las mismas oficinas atendidas por las mismas personas? Y estamos hablando de una de las municipalidades emblemáticas por su modernidad y una de las con más recursos de Chile.

La transformación digital siempre es mirada con recelo por quienes hoy ganan su sueldo gracias a la burocracia: el empleado de la Mesa de Partes, el que entrega los números de atención, el que timbra documentos en secretaría, ninguno quiere verse en la calle por culpa de un computador. Pero lo cierto es que mejorar la eficiencia operacional permitiría que dichas personas pudieran dedicarse a atender casos complejos: incluso teniendo servicios muy eficientes, inevitablemente hay casos que rompen la regla y que requieren atención y dedicación de un humano. Hoy en día dichos casos reciben atenciones lentas, o lo que es peor, pasan por otros procedimientos estandarizados que no son los adecuados. Sucede lo mismo con usuarios de edad avanzada que no se sienten a gusto con los canales digitales, las personas analfabetas, los discapacitados y otros ciudadanos que se beneficiarían de una atención más personalizada.

Por ende, nadie pierde: los recursos de tiempo y personas que se liberan se siguen necesitando y permitirían lograr una atención aún más rápida y humana.

Ganar eficiencia operacional permitiría atender mejor a los ciudadanos con casos complejos o necesidades especiales

Un ciudadano mejor predispuesto

En Perú, para poder hacer mis trámites de residencia, debo ir a tres lugares distintos a obtener tres certificados de antecedentes (previa ida adicional a pagar el derecho de trámite al Banco de la Nación) que, ciertamente, Migraciones podría obtener en 30 segundos con una consulta digital, si dichas instituciones estuvieran mejor integradas (por ejemplo, mediante APIs a través de las cuales pudieran consultar información cruzada).

El funcionario público no necesariamente tiene la motivación para cambiar esto. Mientras les presenten los papeles correctos, el hecho de que el postulante haya hecho 4 filas y perdido un día entero para obtener certificados no les influye en mucho. Y dicha apatía institucional resiente a los ciudadanos, que sienten que las instituciones públicas sólo velan por sí mismas. Y razón no les falta.

Incluso la misma transformación digital se transforma en un mal chiste cuando sólo puedes acceder a un trámite usando Internet Explorer en Windows, o cuando el sitio es imposible de acceder en un teléfono móvil, o cuando las instrucciones son tan confusas que debes llamar a un call center a que te expliquen. Los sitios Web actuales -mayo 2016- de las autoridades tributarias en Chile y Perú (SIISUNAT, respectivamente), son ejemplos casi caricaturescos del atraso, el mal diseño y los estándares obsoletos. Incluso cuando rediseñan lo hacen mal.

En tiempos donde la confianza en el Estado está por los suelos, rediseñar para ahorrar tiempo, viajes, papeleos y dinero a los ciudadanos tiene el potencial de ejercer un impacto tangible y directo que ninguna campaña comunicacional podría lograr por sí sola.

Y ni hablar de un Estado transparente, con información más fácilmente accesible, donde los mismos ciudadanos, sin necesidad de ser periodistas o analistas de datos, puedan fiscalizar. Hoy en día hay muchos datos públicos que aunque en estricto rigor son accesibles a la ciudadanía, en la práctica es información imposible de consumir por personas no capacitadas. Ahí es donde la UX puede ayudar construyendo, por ejemplo, visualizaciones de datos más amigables, que bajen radicalmente las barreras de entrada para consumir y entender la información.

Mejores instancias democráticas

Muchos estarán familiarizados con el abortado proyecto Cybersyn, la casi-internet del gobierno de Salvador Allende que intentó hacer realidad la utopía informática de un ciber-Estado conducido en tiempo real y con conexión directa con los ciudadanos. En los 70 era efectivamente una utopía, pero en el 2016 es perfectamente posible: los aparatos (computadores, smartphones) y la infraestructura de red (Internet) ya existen en las manos de la gente y sólo basta usarlos.

El voto electrónico tiene sus complejidades y es un tema particularmente sensible al fraude, razón por la cual es entendible la cautela y la demora en implementarlo. Pero hay muchas más formas de conectarse con la ciudadanía que una vez cada cuatro o seis años, en especial para los aspectos cotidianos de la vida pública: los servicios del Estado deberían tener canales sencillos y constantemente abiertos para recolectar feedback, abrir su información a la ciudadanía (el tan mencionado y tan desaprovechado OpenData) y permitir a sus mismos ciudadanos enviar mejoras.

Si uno de los sistema operativos más estables que existen (Linux) ha sido creado y desarrollado con la participación libre de miles de personas, ¿por qué no hacer lo mismo con los servicios públicos? ¿Por qué no tener repositorios open source para los sitios Web, servicios y apps del Estado, y que los ciudadanos puedan enviar correcciones de bugs si así lo desean?

En Estados Unidos el US Digital Service nació de un grupo de ciudadanos, que frustrados con la pésima experiencia del sitio web de Healthcare.gov, decidieron aplicar metodologías y prácticas del ecosistema startup (entre ellas un fuerte énfasis en UX y mejores estándares tecnológicos) al sector público. La clave es que el gobierno estadounidense los acogió y potenció, y hoy están liderando la transformación digital con impacto a millones de personas.

¿Y nosotros?

UX, negocio y tecnología en un solo equipo

¿Cómo llegamos a esto?

Alguien me dijo por ahí: “A veces el sentido común no es tan común como supone ser” lo que me pareció muy cierto. Lo recordé cuando quise empezar a escribir este post, cuyo objetivo es contar como ha evolucionado el proceso de UX que realizamos en Continuum.

En un inicio, nuestros primeros procesos UX no eran tan conectados con lo técnico (qué loco ¿no? si más de la mitad de Continuum son desarrolladores). Algunos del equipo UX que si escribían código eran capaces de aterrizar el diseño en aquello que es factible de implementar; al menos en lo web, donde los frameworks como bootstrap son un gran aliado. Sin embargo, cuando nos pasábamos al lado de diseños nativos para dispositivos móviles, venía el problema.

Por otro lado, a veces nos piden estimar desarrollos para aplicaciones cuyo diseño ya está hecho. Y nos encontramos con que en el diseño de aplicaciones Android se usaron componentes y transiciones que son típicos de un iPhone. Aquí claramente los involucrados en el proyecto eran fans Apple, el diseñador también lo era, o simplemente cuando diseñaron, aún no estaban tan difundidas e interiorizadas las guías gráficas para cada sistema operativo. No se pensó que el usuario Android iba a odiar que lo obligaran a aprender de nuevo algo que él estaba acostumbrado a hacer de otra forma en su celular. Y esto nos pasó también con nuestros propios diseñadores (oh sí, quien esté libre de pecado que tire la primera piedra).

¿Por qué? Porque por un lado, el diseñador no quiere que su creatividad esté limitada por lo técnico y busca replicar aquello que identifica/cree que está bien resuelto en algún lado. Por otro, el técnico no quiere que el diseñador se vaya en volada diseñando algo que es muy complejo, se puede hacer de una forma más simple, no es factible de implementar, no está acorde a las guías gráficas de cada sistema operativo.

Entonces esta tensión entre el diseño de la interfaz y la implementación comenzó a generar fricción, gracias a los problemas de comunicación. Llegar con una pregunta de ¿Se puede? sin dar mayor contexto a un desarrollador, es tomarlo por sorpresa, le preguntan algo puntual y no entiende el valor que la funcionalidad prestaría al cliente final. Sobre todo si el mismo desarrollador no fue parte del proceso de UX. Ello impidió que sugiriera alguna alternativa en el momento apropiado y casi siempre el diseño estaba bien adelantado cuando llegaba a ser validado técnicamente y se intentaba marcar el check de “es factible”.

Tuvimos que pasar por proyectos UX terminados (con clientes contentos y nosotros también) que al llegar a la fase de estimación/implementación, detectábamos que en el diseño habían quedado cosas afuera y otras que explotaban en la cara del desarrollador (les aparecían sorpresas de diseño que sonaban más a capricho que algo con verdadero valor), para llegar a concluir que de ahora en adelante, incluiremos dentro de nuestro proceso UX a un desarrollador, siempre.

Y así, comenzamos a hacer procesos de experiencia de usuario, con un diseñador UX/líder del equipo más un desarrollador (por nuestra parte). Dependiendo de la naturaleza del proyecto invitamos a uno o más compañeros desarrolladores a participar de las reuniones clave, para que se empapen del por qué se necesita qué y a quien esto hará feliz. Cuando los diseñadores están creando, validan inmediatamente con el desarrollador y éste les aporta feedback valioso de como hacer lo mismo con un menor esfuerzo de implementación, o llegan juntos a encontrar un punto intermedio. Al conectar estos perfiles el equipo se potenció: tanto diseñadores como desarrolladores comenzaron a aprender unos de otros (incluso descubrimos desarrolladores con talento natural para procesos UX) y las ventajas que generó esta unión han sido muchas. Por ejemplo, al estar dentro del proceso tanto los técnicos del cliente como mis compañeros, se logra identificar rápidamente, si la data necesaria para alimentar una vista existe, dónde y cómo está, o saber si es posible proveerla de manera diferente, etc. Es decir, que empiezas a levantar tempranamente qué necesitas antes de siquiera terminar la fase de diseño de interfaz. Y lo que levantas por adelantado va más allá de qué servicios o de qué data vas a necesitar.

La tensión natural entre el diseño y el desarrollo se relajó. Nuestros compañeros desarrolladores se convirtieron en el cable a tierra cuando el diseño era muy soñador. Pero no sólo eso. Los desarrolladores también aprendieron a soñar y a tener la habilidad de ser flexibles, tomándolo como un desafío técnico, comprendiendo aquello que cubre una necesidad, tiene una razón y hace feliz a un usuario de nuestro producto. Si a esto sumamos que en nuestro proceso de UX deben ser partícipes representantes del negocio, entonces ya podrán imaginar el resultado: Negocio, diseño experiencia de usuario y tecnología, todos trabajando juntos para conocer a clientes y sus necesidades, brindando soluciones factibles y que realmente encanten, dando valor al usuario final.

Es así, que descubrimos en la práctica que el trabajo de equipo mejora (nosotros, el cliente e incluso con sus proveedores), se genera espacio para la innovación y los integrantes del equipo crecen al tener acceso a diferentes puntos de vista. Estoy segura continuaremos descubriendo otras ventajas de esta unión; porque seguimos mejorando nuestra forma de hacer las cosas.

¿Por qué no se nos ocurrió antes? ¡si era obvio! –debía haber un desarrollador siendo parte de los procesos de UX–. Simplemente porque a veces el sentido común, no es tan común como supone ser 🙂