Categorías
Sin categoría Estrategia digital

Cómo lograr la transformación digital en tu empresa

Para lograr la Transformación Digital de nuestra compañía no solo debemos limitarnos a implantar elementos tecnológicos, la Transformación Digital utilizará la tecnología como medio para mejorar los procesos de la compañía, haciéndolos más eficientes y aportando un mayor valor a la cadena de valor del cliente. Se podría decir que la Transformación Digital se basa en tres ejes principales: Tecnología, Procesos y Personas. Unidos por un mismo punto, el cliente.

En el libro Lidera la Transformación Digital con éxito encontraremos al menos 10 recomendaciones sobre cómo lograr la transformación digital:

  1. Definir un plan de transformación realista, donde se recojan los objetivos a conseguir y las diferentes iniciativas para alcanzarlo. Básicamente marcará el rumbo que deberemos seguir a lo largo de los próximos años. Al fijar unos objetivos de negocio alcanzables, estaremos facilitando que las inversiones que se hagan durante la implantación tengan la mayor efectividad.
  2. Definir una estrategia digital, tener un criterio sobre cómo afrontar los diferentes retos tecnológicos con los que nos enfrentaremos, como el cloud, producto VS desarrollo a medida, cómo migrar/mantener los sistemas legacy, cómo atacar el Shadow IT, …
  3. Disponer del apoyo del comité de dirección, habrá momentos de tensión y su apoyo será vital para la continuidad. Si los objetivos buscan soportar al negocio, éstos deberán ser participes de la iniciativa y sobre todo de apoyarla.
  4. Realizar un plan de comunicación a toda las compañía, todo el mundo debe ser participe de lo que se está haciendo y generar confianza. Por naturaleza, los cambios generan rechazo, un buen plan de comunicación basado en la transparencia reducirá el rechazo inicial al generar confianza.
  5. Identificar agentes del cambio, necesarios para impulsar las iniciativas y a los decisores clave. Tanto en los equipos de TI como de negocio. No vale con tener la mejor solución tecnológica, será necesaria impulsarla entre los diferentes stackeholders, esto no se consigue simplemente con órdenes de arriba abajo. Los agentes del cambio serán aquellas personas con capacidad de liderazgo para impulsar las iniciativas, conseguirse aliados que a su vez hagan de promotores al resto de usuarios, en definitiva, usuarios que sientan el proyecto como un reto.
  6. Disponer de un equipo de TI preparado, motivado y con orientación a cliente. Ya no es suficiente con un equipo clásico de TI donde su mayor motivación sea mantener vivos los sistemas. Los departamentos TI deben ser parte de los agentes, serán principales líderes de los proyectos, pero sin llegar a ser los dueños del proyecto. Para eso, deben entender las necesidades del negocio y trasladarlo al mundo tecnológico.
  7. Orientación a resultados y estructura, cambiar los modelos de competencias para orientarlos a resultados y roles. La ausencia de indicadores de rendimiento y estructuras organizativas complejas serán los mayores impedimentos que hagan avanzar la transformación. La agilidad en la toma de decisiones basada en la delegación y confianza, la colaboración basada en roles y no especialidades funcionales como los departamentos o áreas y disponer de un objetivo común medible, facilitarán la transformación.
  8. Hacer participe a los negocios, deben sentir que forman parte del proyecto, no es un proyecto exclusivo de TI. Aunque el departamento de TI deba ser líder principal de los proyectos, los dueños deberían ser los negocios. Es un proyecto de todos y no meramente tecnológico.
  9. Identificar métricas de rendimiento, con las que poder validar que las iniciativas tienen un impacto en los objetivos marcados. Lo que no se mide, no se valora. Los planes de transformación requieren de mucho tiempo hasta poder ver los resultados. Disponer de unas métricas ayudará a validar que vamos bien y que tiene sentido lo que estamos haciendo
  10. Apoyarse en el marco Agile y una PMO, para se efectivos en las diferentes acciones aportando resultados lo antes posible.

Sigue leyendo sobre estrategia digital:

Categorías
Estrategia digital

Fases de la transformación digital

La implantación de la Transformación Digital se basa consta de diferentes fases que requerirán de muchos años hasta ser implantada y asimilada completamente por la compañía. Recordemos que la Transformación Digital no solo abarca la digitalización de los procesos, también requiere de un cambio de modelo de los procesos y sobre todo, la forma de colaborar y comunicarse de nuestros empleados.

A la hora de plantear un proyecto de transformación Digital en nuestra compañía deberemos pasar por un ciclo con las siguientes fases:

  1. Ideación, donde identificaremos los objetivos a conseguir con las diferentes iniciativas del plan de Transformación. En esta fase nos centramos a alto nivel en el «por qué» abordamos un proceso de Transformación y la visión de los objetivos que queremos conseguir con su implantación. En esta fase estaremos definiendo la base del Plan de Transformación sobre el que se detallarán las diferentes iniciativas que harán posible alcanzar esos objetivos. También nos permitirá mantener el foco durante el proceso de implantación del Plan, evitando dar bandazos en la estrategia que a la larga impidan conseguir los objetivos marcados.
  2. Diseño del Plan, donde definiremos en detalle el Plan de Acción a seguir para conseguir los objetivos marcados. Normalmente requiere de un estudio previo para conocer la situación actual de los sistemas de información sobre el que buscar opciones de mejora alineadas con la visión. Se detallarán todas las iniciativas identificadas, así como el presupuesto necesario, recursos y tiempos. Un elemento diferenciador para realizar un seguimiento del éxito de la iniciativa será el haber identificado previamente KPIs objetivo con los que poder contrastar una vez implementada la iniciativa.
  3. Aprobación, En la que se buscará la aprobación y apoyo de la dirección, consejo o VC resultando en una aprobación de unos presupuestos y un plan financiero. El apoyo incondicional de la dirección al Plan será un factor clave en el éxito del proyecto.
  4. Implantación de iniciativas, consiste en llevar a cabo las diferentes iniciativas definidas en el Plan. Durante esta fase será clave disponer de un equipo de TI motivado y preparado. La comunicación a la compañía del plan a seguir y los motivos/objetivos a conseguir disminuirá el rechazo al cambio por parte de los diferentes stackeholders.
  5. Revisión del Plan, donde periódicamente se revisará el Plan con intención de o bien realizar un cambio de rumbo o bien plantear un nuevo Plan que de continuidad al anterior. Un Plan a 2-3 años es tiempo más que suficiente para validar y replantear el proyecto de Transformación, pero tengamos en cuenta que una verdadera transformación digital requerirá de muchos años.
Fases de la Transformación Digital

Conoce cómo conseguir la Transformación Digital

Categorías
COVID-19

Teletrabajo o Trabajo remoto

El confinamiento nos ha obligado a buscar nuevos modelos de trabajo, colaboración y consumo para reducir el riesgo de contagios. Produciéndose un nuevo modelo de trabajo distribuido, sobre el que tenemos nuevos retos y oportunidades.

Este es un artículo de la temática Transformación Digital después del COVID-19

La palabra “Teletrabajo” ha estado destinada durante mucho tiempo a grandes compañías o se le ha relacionado con empresas tecnológicas, donde principalmente se asociaba como un beneficio social de las compañías o un mecanismo de recompensa, más que por pertenecer a la cultura de la compañía.   

Uno de los primeros efectos del COVID-19 ha sido el impulso que ha provocado sobre los modelos de trabajo remoto en la totalidad de las compañías (que podían desempañar su actividad de forma remota). De pronto, se ha dado un salto exponencial, que de otro modo hubiera tardado muchos años en producirse.

Parece que el teletrabajo ha venido para quedarse, pero sin embargo, el teletrabajo que hemos vivido durante el período de confinamiento provocado por el COVID-19 dista mucho de lo que se entendía hasta el momento como teletrabajo. La conciliación familiar en hogares poco preparados para un largo confinamiento, la falta de medios tecnológicos, la falta de equipamientos, la poca destreza digital de muchos empleados y por supuesto, la falta de experiencia previa de trabajar en un modelo totalmente remoto sin posibilidad de contacto físico ha derivado en muchos problemas como: altos niveles de estrés, aislamiento profesional, desconfianza de los managers, desapego a la compañía, … 

En definitiva, se ha producido una situación tan compleja de llevar en el día a día, que el trabajo remoto, en lugar de percibirse como algo positivo por parte de los empleados, se ha percibido en muchas ocasiones como un castigo.

«la situación experimentada durante los períodos de confinamiento del COVID-19 se puede considerar como trabajo remoto y no como teletrabajo«

Pero diferenciemos entre teletrabajo y trabajo remoto. El primero, se podría decir que coincide con el concepto que teníamos pre-COVID19 de trabajar durante un periodo puntual fuera de la oficina, (desde nuestra casa, la playa, …). Todas las tareas de gestión y operativas (e incluso de comunicación) seguían realizándose principalmente desde la oficina y solo se aplicaba el teletrabajo como algo puntual o excepcional. Por otro lado, el trabajo remoto consiste en la posibilidad de desempeñar nuestro trabajo de una forma relativamente autónoma, alejados de la oficina durante períodos prolongados de tiempo, con un modelo basado en objetivos y autogestión. En este modelo la excepción es desplazarse a los centros de trabajo.

Por tanto, se podría decir que la situación experimentada durante los períodos de confinamiento del COVID-19 se puede considerar como trabajo remoto y no como teletrabajo.

Entre los beneficios de la implantación del trabajo remoto como punto a destacar es el de poder conseguir reducciones directas en los costes asociados a los espacios de trabajo, bien por liberar espacios o por incrementos de hasta un 40% de la capacidad de la plantilla para los mismos espacios (combinando modelos on-site y remotos).

Al mismo tiempo, aquellos equipos que implantaron el trabajo remoto en períodos pre-Covid, llegaron a ser hasta un 35% más productivos versus modelos puramente on-site. Los tiempos de desplazamientos, interrupciones y el estrés, se destacan entre los factores que más afectan a la productividad en modelos on-site. Siendo el trabajo remoto una preferencia de hasta un 44% de los empleados consultados en estudios realizados por Gartner.

Al quitar la limitación geográfica cercana a nuestros centros de trabajo se abre la posibilidad de incorporar nuevos perfiles (internos o subcontratados) a los que hasta ahora era casi inviable, aumentando así la flexibilidad de crecimiento y construir compañías culturalmente más diversas.

El trabajo remoto tiene una serie de peculiaridades respecto al teletrabajo que nos obligan a prestar atención a aspectos como:

Impulso de la tecnología como facilitador

Es sin duda uno de los primeros efectos que muchas compañías han iniciado durante el período de confinamiento, bien sea mediante dotación de equipamiento, aumento en las capacidades de las redes de comunicaciones, sistemas de gestión, …

Es el momento en el que los departamentos de TI deben demostrar su valor en la compañía y, al mismo tiempo, se debe entender que la inversión en procesos de digitalización es necesaria para la continuidad del negocio.

Generación de entornos de confianza

Los managers deben apostar un modelo de autogestión y trabajo por objetivos, donde permita a los miembros del equipo trabajar en el horario y las forma en la que mejor desempeñe su trabajo. La definición de objetivos permitirá poner foco en lo realmente importante y tener una meta. En especial para aquellos managers acostumbrados al micro-management o a la falta de planificación. En un modelo remoto es imposible tener controlado al milímetro lo que hacen los empleados.

Las compañías con fuertes estructuras jerárquiquas y procesos complejos, derivarán en situaciones donde para los empleados sea casi imposible disponer de esa autogestión que se le pueda exigir en un modelo remoto, ya que, en muchas ocasiones, ni tendrá la capacidad de decisión ni tendrá un sentimiento de responsabilidad que le lleve a tomar decisiones. Por el contrario, aquellas compañías que hayan apostado por estructuras más horizontales, basadas en objetivos comunes y roles, tendrán una mayor facilidad de adaptación a la hora de embarcarse en modelos de trabajo remoto.

Potenciar la comunicación

La ausencia de contacto físico y la falta de modelos por objetivos derivará en una falta de confianza entre los miembros de los equipos. Se hace necesario cuidar esas relaciones profesional-personal que hubiéramos tenido al cruzarnos en un pasillo, subiendo el ascensor o justo al comienzo de una reunión. La comunicación a través de una pantalla puede transformarse en relaciones frías y malas interpretaciones.

Los managers tienen en este caso un papel muy importante a la hora de mantener esa comunicación, deben dedicar algo de tiempo todas las semanas para hablar con todo su equipo, tanto en grupo como de forma individual. Es importante que la otra persona sienta que su trabajo tiene un objetivo superior y que forma parte de un equipo.

Otra forma de mejorar los vínculos de confianza es habilitar la webcam durante las videoconferencias, esto facilita la empatía entre las personas y permite dar la sensación de confianza.

También la comunicación del CEO hacia el resto de la compañía se hace imprescindible en estos momentos, una ausencia de comunicados corporativos generará desconfianza y malentendidos.

No debemos olvidarnos de la comunicación entre equipos para buscar sinergias, dependencias e identificar riesgos. Si ya de por sí este tipo de comunicaciones son importantes, aún más será en modelo remotos, por lo que no tengamos miedo en organizar estos puntos de encuentro de forma recurrente y en períodos cortos.

Engagement de los manager con el equipo

A lo largo del libro se ha comentado como los managers o mandos intermedios actúan de palanca a la hora de implantar cualquier medida de transformación. Del mismo modo, en modelos remotos, éstos serán clave para mantener el engagement de los empleados.

Acciones como los onte to one (reuniones 1 a 1), reuniones de equipo o reuniones informales (café virtual), tienen un impacto directo en esta relación del empleado con la compañía. El empleado se siente parte del equipo y reduciendo el aislamiento profesional.

Será necesario disponer de nuevos skills de gestión y de coaching que hasta ahora posiblemente no se tuvieran, ya hemos comentado como metodologías ágiles y centradas en objetivos contribuyen a facilitar la adopción de cambios. Pero también deberán empoderar a los equipos en la toma de decisiones y responsabilidades.

Respetar los horarios y forzar los descansos

Será una de las medidas que toda la compañía deberá incorporar a su cultura, de otro modo, se estará potenciando un sobre esfuerzo y quemazón de los empleados que derivará en problemas mayores a largo plazo.

Es imprescindible que todo el mundo, (directivos, managers, técnicos, administrativos, …) respeten los horarios de trabajo y los tiempos de descanso, tanto hacia los demás como ellos mismo. Trabajar fuera de la oficina no implica que pasemos 24 horas trabajando.

Sin embargo, aquellos que hayan decidido delegar en una autogestión del tiempo y horario tendrán que tener en cuenta la sincronización de los miembros de los equipos, deben existir ciertos parámetros o límites que definan las reglas del juego. Por llevar el ejemplo a un extremo, no es viable que una persona comience su jornada de trabajo a las 6 de la mañana y otra persona de su mismo equipo lo haga a las 8 de la tarde.

Modelos de trabajo basado en objetivos y rendimiento

Es posible aprovechar el momento para implantar nuevos modelos funcionales u operativos basados en el cumplimiento de objetivos corporativos y de equipo (OKRs). La esencia de los OKRs es el de alinear los esfuerzos y el foco de todas las acciones de la compañía con los objetivos corporativos.

Este tipo de modelos tienen como principal tarea “medir”, medir los costes, ingresos, el tiempo invertido, la calidad, … en función del área tendremos diferentes indicadores, pero en esencia, requiere disponer de mecanismos de medición con los que poder comprobar el cumplimiento de los objetivos.

No siempre se disponen de las herramientas para conseguir los indicadores con los que tener la visión completa, pero podemos comenzar con algunos poco indicadores con los que validar el modelo e interiorizar la esencia del modelo.

Políticas de trabajo remoto y revisión de competencias

Será necesario dar forma y orden a este nuevo modelo de trabajo a través de la definición de políticas de trabajo remoto. Especificando por cada rol las condiciones en las que puede desempeñar su trabajo de forma remota, sus obligaciones y los requisitos del entorno de trabajo.

Ya hemos comentado previamente como el cambio de orientación a resultados implicará un replanteamiento de los roles y de las competencias definidas previamente por los departamentos de RRHH. Este tipo de cambios no son inmediatos y generan tensiones, por lo que prestemos mucha atención a las expectativas de los miembros de nuestros equipos ante un cambio organizativo y de funciones.

Potenciar la seguridad de la información

La deslocalización de todos los empleados accediendo a los sistemas de información de la compañía desde redes poco seguras y dispositivos sin ningún tipo de control conllevan altos riesgos en brechas de seguridad y fugas de información.

Muchas compañías y organismo públicos no disponían de los medios de comunicación para un modelo de trabajo remoto de forma generalizada. La apertura de los sistemas a través de VPNs o escritorios virtuales solo ha proporcionado los mecanismos con los que poder continuar trabajando, pero se hace necesario por parte de los departamentos de TI seguir implantando herramientas y procesos que garanticen la seguridad de la información, a nivel de confidencialidad, integridad, disponibilidad y autenticación. Por supuesto, realizar programas de concienciación que permitan a los usuarios adquirir destreza necesaria para gestionar la información y detectar posibles intentos de fraude.

Este es un artículo de la temática Transformación Digital después del COVID-19

Categorías
COVID-19

Transición a la “nueva normalidad”

Encontraremos diferentes estrategias de TI para conseguir la recuperación de las compañías: Contención del gasto y continuidad del negocio, Vuelta a la esencia y nuevas oportunidades.

Este es un artículo de la temática Transformación Digital después del COVID-19

Uno de los primeros efectos que trajo el COVID-19 por la gran mayoría de las compañías fue el hecho de «necesitar» (en la medida de los posible) un modelo de Teletrabajo para el que muchas, no estaban preparadas tecnológica ni organizativamente. Por otro lado, en los picos del confinamiento hacia Abril del 2020 se produjo una parada masiva de proyectos en todos los ámbitos como medida de precaución ante la incertidumbre de los acontecimientos, cancelaciones, despidos/ertes masivos, …

La situación a corto y medio plazo pasará por dos elementos básicos:

  • Asegurar la salud de las personas (aproximación “People First”)
  • La continuidad del negocio.

A través del incremento de medidas de higiene y distanciamiento social, se irán cambiando muchas de los pequeños actos cotidianos a los que asumíamos como algo natural, de manera que en la suma de todos ellos se compondrá la denominada “nueva normalidad”.

Aunque ya se empiezan avanzar en los planes y medidas, sigue existiendo una gran incertidumbre en cuanto a la evolución de los mercados y muchos procesos pre-Covid19. Como punto de referencia es posible fijarnos en las medidas y escenarios planteados en otras ciudades Europeas o asiáticas, ya que fueron una de las primeras en salir del confinamiento e implementar diferentes medidas como:

  • Higiene excesiva y control de empleados.
  • Potenciar el uso de la tecnología como un dinamizador y facilitador de los negocios.
  • Reestructuración del puesto de trabajo y de los espacios compartidos.

Con la reestructuración del puesto de trabajo muchas compañías buscarán conseguir:

  1. Reducción del riesgo de los trabajadores, tomando el trabajo remoto como una medida preferente para los empleados (siempre que sea viable).
  • Modelos híbridos, donde se combine el trabajo remoto con el trabajo on-site, con el objetivo de fortalecer las relaciones entre empleados.

Los espacios físicos también sufrirán un importante proceso de redefinición, buscando siempre:

  • Maximizar la distancia entre empleados, tanto en los puestos de trabajo, salas de reuniones y zonas de esparcimiento/utilities.
  • Elementos de protección y detección, como la imposición del uso de mascarillas, guantes o detectores de temperatura.
  • Recurrir a turnos de trabajo on-site para distribuir los riesgos dentro de los propios equipos, además de reducir los aforos en los centros de trabajo.
  • Herramientas de reserva de espacio de trabajo, (desk management), con el objetivo de controlar el aforo, planificar las medidas de higiene, reducir riesgos y disponer de una trazabilidad ante contagios.

Desde el punto de vista de estrategias en inversiones en TI, nos encontraremos con diferentes aproximaciones en función de la situación de la compañía y del momento. Podríamos distinguir al menos tres fases diferentes:

Una primera fase producida al comienzo de la pandemia:

  • Contención de los gastos y reducción de costes, paralizando inversiones y reduciendo el consumo en servicios TI con el objetivo de mejorar las cuentas de la compañía, destinando la mayor cantidad de recursos posibles a mantener a flote la compañía.
  • Continuidad del negocio, destinando gran parte de los recursos a aquellos proyectos o servicios básicos que permitan la continuidad del negocio. En algunos casos la inversión se ha centrado a bajo nivel, con el objetivo de mantener las infraestructuras de comunicación, contingencia y seguridad. Inversiones en conexiones VPN, ampliación de ancho de banda o migración de workloads al Cloud son algunos ejemplos.

En otros casos, la continuidad del negocio se reflejará en plataformas o servicios orientados directamente a dar servicio al cliente debido a la imposibilidad del contacto físico (por ejemplo, la implantación de un eCommerce).

La segunda fase o “vuelta a la esencia”, enfocada a fortalecer las líneas de negocio clave de la compañía:

  • Foco en servicios core, priorizando funcionalidades y proyectos donde realmente la compañía tiene una posición de ventaja. Al disponer de recursos limitados, estos se deberán aprovechar en aquellos servicios que realmente mantienen a flote a la compañía.

Una tercera fase, donde, una vez garantizados los servicios esenciales, aparecerán nuevos retos y oportunidades de crecimiento:

  • Nuevas oportunidades, muchas compañías encuentran en situaciones de crisis nuevas oportunidades de abrir mercados o bien lanzar nuevos productos que anteriormente serían implantables.
  • Replanteamiento de inversiones, el impacto económico y social que se está produciendo de forma tan vertiginosa obligará a replantear muchos de las estrategias de las compañías, así como sus planes de Transformación Digital. Para lo que se revisarán los nuevos objetivos, resultando en nuevas iniciativas.

Desde el punto de vista organizativo, a medio plazo veremos como se producen muchos cambios organizativos en especial en aquellas compañías que han apostado por un modelo de trabajo remoto. El modelo de trabajo remoto obligará a replantear estructuras y procesos muchas veces orientados a relaciones físicas, sin embargo, la orientación a resultados y modelos estructurales basados en roles serán algunos de los retos con los que se encontrarán muchas compañías, en especial los departamentos de RRHH.

Este es un artículo de la temática Transformación Digital después del COVID-19

Categorías
Metodología Estrategia digital

De Proyecto de software a Producto Digital

Desde hace unos años existe una tendencia en las compañías de aprovechar los recursos destinados a un proyecto de software internos para convertirlos en un producto digital. Los motivos son variados, algunas compañías intentan abrir nuevos modelos de negocio, otras rentabilizar la inversión realizada o incluso ofrecer la misma calidad al usuario interno que la que se ofrece a un cliente final. Según Sriram Narayan en el artículo “Products Over Projects”, entre las ventajas organizativas que encontraríamos al orientar un proyecto en producto se encuentran:

  • Habilidad en adaptación rápida.
  • Reducir los ciclos de tiempo End-to-end.
  • Ser capaces de iterar.
  • Integridad de arquitectura.
  • Construir equipos motivados y con un propósito.

Pero “¿Qué factores diferencian a un proyecto de un producto?. Se podría decir que un producto parte como un proyecto que pretende resolver un problema, pero con el objetivo de poder “utilizarse” para diferentes clientes a lo largo del tiempo. De ahí que las nuevas funcionalidades de los productos se centren en resolver problemas o aportar valor al mayor número de clientes posibles, en lugar de a un área de negocio o departamento concreto como podría ocurrir en un proyecto. Pero cuando hablamos de enfocar el proyecto para que pueda “reutilizarse” no estamos hablando de construir un framework o plataforma con la que poder hacer más proyectos, si no el de orientar todas las funcionalidades y arquitectura a un propósito más global sobre el que poder definir un modelo de servicio.

Valor o funcionalidad

Cuando se implementa un proyecto para uso interno, las funcionalidades se enfocan en resolver la problemática de nuestro cliente interno, puede haber más o menos usuarios, pero solo debemos preocuparnos de un único cliente. Sin embargo, al crear un producto tendremos la necesidad de cubrir las problemáticas de diferentes tipos de clientes, cuanto más amplio sea el sector al que vaya dirigido el producto, mayor complejidad tendremos para poder cubrir las diferentes casuísticas. Con un producto, orientaremos las funcionalidades al valor percibido en lugar de a otros factores más relacionados con optimización de costes o resolución de problemas.

El valor percibido es un concepto curioso, que depende en gran medida de cómo perciben los clientes nuestro producto o una funcionalidad más que en su comportamiento o prestaciones. El valor percibido podría decirse que son todos aquellos elementos o características por las que un cliente adquiere o sigue utilizándolo nuestro producto. Para una misma funcionalidad, el valor percibido puede ser muy diferente por clientes diferentes. Unos, pueden apreciar más la capacidad de uso, otros, su rendimiento, otros valorarán el precio y otros, simplemente por la marca.

Es un error muy común creer saber lo que quiere el cliente, pensar que una nueva funcionalidad pueda ser percibida por los usuarios como algo muy útil requiere de objetividad, de cifras. Con un proyecto, la percepción se basa en recoger el feedback de un grupo limitado de usuarios, pero con un producto, se hace complicado conocer la percepción de todos los clientes. Durante mucho tiempo se han utilizado mecanismos para recoger feedback como puedan ser las encuestas o focus groups para determinar si una funcionalidad tendrá un impacto importante en los usuarios, pero se ha demostrado que los usuarios no se comportan igual en contextos en los que se sienten observados que en su entorno habitual. Es por eso que recurriremos al uso de herramientas de monitorización con las que poder medir el comportamiento de los usuarios, conocer las funcionalidades más utilizadas, cómo las utilizan o para qué las utilizan. Por tanto, a la hora de lanzar nuevas funcionalidades, es recomendable enfocarlas como un MVP sobre el que observaremos el comportamiento y aceptación de los usuarios para decidir si darle continuidad o bien modificar la funcionalidad inicialmente ideada.

Cuando un producto se inicia exclusivamente para uso interno, ¿cuál será el valor percibido entonces por nuestro cliente interno?. En este caso, una opción sería operar todo el proyecto como si se tratara de un cliente externo, desde el principio hasta el fin. De este modo, no solo nos centraremos en la implementación del producto, también en toda la operativa necesaria en los procesos de definición de producto, acciones comerciales y la post-venta/soporte. La clave también puede estar en conseguir que el Product Owner pertenezca a un área/departamento diferente del cliente interno, de manera que pueda tener una visión más amplia del producto al no tener una dependencia directa del área interna.

La figura del Product Owner y Product Manager

En un producto toma especial importancia la figura del Product Owner (PO) o Product Manager (PM), a la hora de priorizar e identificar nuevas funcionalidades orientadas a aportar valor, sobre todo, a entender el proceso. Un proceso basado en la experimentación, la medición y el incremento iterativo. El PO/PM no solo debe conocer el negocio, también debe entender las diferentes metodologías.

El PO deberá ser el mayor defensor del producto, un PO poco motivado no luchará por asegurar la continuidad del producto, que no se quede en un mero proyecto. En una corporate el PO deberá “pelear” con los diferentes procesos de la compañía para conseguir captar presupuesto, lanzar campañas de marketing, definir los procesos de soporte, … y lo más importante de todo, que la dirección entienda el valor del producto para que le den el apoyo necesario.

El PO también se encargará de participar en la definición del roadmap. El roadmap es una herramienta muy útil con la que compartir con los diferentes stackeholders la visión del producto. Un buen roadmap ofrecerá la visión en diferentes contextos: estrategia de negocio, funcional y técnico.

La captación de presupuesto en una corporate dependerá en gran medida de los resultados obtenidos durante el año anterior, por lo que suele ser complejo hacer entender a la dirección un modelo basado en la experimentación. El PO deberá trabajar entonces muy de cerca de la dirección para ayudar a traducir los procesos y la estrategia a los resultados. Disponer de un roadmap realista y con diferentes visiones facilitará la aprobación de presupuestos para las diferentes fases.

Por el contrario, la aprobación de presupuesto en un proyecto estará acotado a unos objetivos definidos en fases previas a su implementación a partir de business case que, en la mayoría de los casos diferirán de la realidad una vez puesto en marcha.

Metodologías

Existen diferentes metodologías y marcos de trabajo que podemos aplicar a nuestro producto para cada una de las fases en la que nos encontremos. Personalmente me encanta el concepto de Lean Startup, con el que ofrecer valor al cliente lo antes posible con el mínimo de desperdicio, utilizando un proceso de experimentación, medición y aprendizaje.

Si bien Lean Startup puede ser el marco principal, podemos aplicar otras metodologías como Design Thinking para idealizar y definir nuevas funcionalidades o SCRUM/KANBAN para la implementación de las features.

Cualquiera de los marcos que escojamos deberá ir en consonancia con el roadmap, la dirección o los inversores querrán entender cómo se están invirtiendo los recursos.

Estrategia de negocio

Otra complejidad adicional que tiene producto frente a un proyecto es la necesidad de definir una estrategia de negocio. No basta con tener una buena idea o realizar la mejor implementación técnica, construir un producto requerirá tener en mente aspectos como:

  1. El mercado
  2. En qué nos diferenciaremos del resto de producto.
  3. A qué público está dirigido.
  4. Modelo de uso
  5. Modelo de pricing.
  6. Modelo de distribución.

Estos aspectos determinarán en gran medida el grado de penetración de nuestro producto en el mercado. Podremos tener el mejor producto del mercado, pero si no tenemos una buena propuesta adaptada al mercado y el público objetivo, no seremos competitivos.

Como primer punto, trataremos de entender el mercado al que irá dirigido nuestro producto/servicio, identificando la competencia y su estado, las barreras de entrada, la tipología de clientes, … Lo ideal es que nos centremos en mercados similares al core de nuestra compañía o a nuestro expertise. Algunas compañías intentan diversificar mercados creando nuevos productos en mercados en los que no son expertos, lo que aumenta el riesgo a no entender las verdaderas necesidades del mercado y sus problemáticas.

En ciertas ocasiones puede ocurrir que nuestro producto no encaje en ningún mercado existente, puede que no exista debido al grado de innovación de nuestro producto, en lo que se denomina un océano azul. Este será el escenario ideal, aunque muy pocos son capaces de conseguirlo.

El siguiente punto será definir los elementos por los que nos diferenciaremos del resto de productos del mercado: en costes, precio, funcionalidad, eficiencia. Si por ejemplo decidimos ser competitivos a nivel de prestaciones funcional, será complejo que podamos competir en precio. Si por el contrario decidimos ser líderes en precios, no seremos los mejores en eficiencia o innovación. Cualquiera de las opciones serán válidas siempre que nos especialicemos en una de las áreas, dar cambios bruscos en la estrategia puede provocar que no se entienda nuestra propuesta de valor.

Conocer el público al que va dirigido (segmentación) asegura un mayor impacto en las acciones comerciales y de captación. Con el lanzamiento de un nuevo producto no podemos pretender llegar a todas las tipologías de clientes potenciales, siendo preferible comenzar identificando un conjunto de potenciales clientes muy reducido, pero muy asequible (que conozcamos bien, cercano,…), con el objetivo de validar nuestra propuesta antes de escalar al resto de sectores. En los productos digitales la clave estará en conseguir escalar a un coste reducido, pero debemos hacerlo en el momento adecuado.

Otro factor importante que tendrá implicaciones técnicas,de soporte y distribución será decidir el modelo de uso de nuestro producto, como SaaS, suscripción o adquisición.

El modelo de pricing (tiered pricing) ayudará a entender mejor nuestra oferta. Existen diferentes estrategias de pricing en productos digitales, pero lo realmente importante será tener una propuesta clara unida a la estrategia y la operativa.

Por último, quedaría por definir un modelo de distribución con el que podamos ampliar nuestra fuerza de venta, pero sin perder nuestros estándares de calidad y valores. En productos maduros es común apoyarse en un modelo de partners, que aunque puede tener sus ventajas a la hora de escalar, debemos asegurarnos de haber construido antes un buen plan que permita al partner entender el producto, que entienda los mensajes y los valores.

El ciclo de vida

El ciclo de vida de un proyecto es muy diferente al de un producto, la principal diferencia radica en cómo varía los modelos de adopción a lo largo del tiempo. Si en un proyecto debemos enfocarnos en que los usuarios entiendan las funcionalidades y la incorporen en sus procesos, en un producto, el proceso de adopción dependerá del momento de vida del mercado en el que nos encontremos, siendo los early adopters los primeros usuarios que aceptarán un producto incompleto con la ventaja de ser los primeros en poder utilizarlo (fase de introducción). A medida que avance la penetración del producto en el mercado evolucionará a las fases de crecimiento, madurez hasta terminar en el declive.

The Product Life Cycle: A Guide from Start to Finish | Geile/Leon Marketing  Communications
Ilustración de assignmentpoint.com/business/marketing-business/product-life-cycle.html

La continuidad del producto

Una vez puesto en marcha un sistema comienza la fase de explotación, fase en la que deberemos dedicar recursos a mantener el sistema en funcionamiento. En el caso de un producto, existen varios factores adicionales relacionados con el servicio post-venta del cliente que debemos tener en cuenta como:

  • Soporte a clientes finales: es necesario un soporte 24×7? Qué tipo de herramientas de ticketing utiliaremos para el siguiemiento de los casos de soporte?, cómo se pondrá un cliente en contacto con el servicio de soporte? Se atenderán dudas funcionales? Existirá un sistema de KB?, …
  • Cumplimiento de SLA: cuáles serán los niveles de servicio que ofreceremos? Niveles de disponibilidad?, qué tiempo de resolución de incidencias dispondremos?, cuáles serán las contraprestaciones en caso de incumplimiento?, qué sistemas de contingencia dispondremos?, …
  • Niveles de calidad del servicio: cómo mediremos la calidad del servicio ofrecido en su conjunto?, qué mecanismos de control introduciremos para mantener los niveles mínimos definidos?

Métricas

Los KPIs de rendimiento para un proyecto se centran principalmente en la velocidad de los equipos a la hora de hacer el delivery de nuevas funcionalidades y de la calidad de las mismas. Sin embargo, en un producto, las métricas suelen estar orientadas a cómo se comporta nuestro producto, desde un punto de vista de ventas, adopción, retención y calidad del servicio.

Las métricas estarán my asociadas a la estrategia elegida, no siempre será importante el volumen de clientes nuevos, factores como el churn rate, el valor del ticket medio y coste de adquisición serán indicadores con los que tengamos que jugar para entender lo que está sucediendo.

Crear producto desde una corporate

El tipo de compañía puede afectar en gran medida a la evolución y ritmo del nuevo producto. Podemos pensar que solo las compañías de tipo “startup” son las únicas que pueden crear producto, pero son las compañías consolidadas en un mercado o corporate las que realmente tienen muchas posibilidad de crear nuevos productos/servicios sobre mercados existentes.

Sin embargo, la creación de nuevos productos en corporates debe cumplir con los procesos definidos en la casa, cuanto más grande sea la compañía, mayor complejidad nos encontraremos. Esto puede afectarnos a aspectos como: aprobación de presupuestos, promoción del producto, niveles de seguridad, definición de SLAs o acuerdos comerciales.

Por otro lado, la apuesta de las coporate por la creación de nuevos productos sirve como mecanismo de innovación en la compañía, fuerza a abrir nuevos modelos de negocio con el objetivo de diversificar o afianzar una posición. Algunas compañías deciden apostar por la creación de producto in-house, es decir, con personal propio, lo que conlleva un mayor esfuerzo por la cantidad de procesos necesarios para construirlo. Otras, sin embargo, invierten en colaboraciones/compras de startups, pequeñas soluciones con un gran potencial dentro de la estrategia de la compañía que pueden desarrollarse inicialmente fuera de la compañía para ser absorbida posteriormente se haya validado el modelo.

Categorías
Metodología

Lecciones aprendidas al aplicar metodologías ágiles en un proyecto de implantación ERP

Estas son algunas de las  reflexiones que hemos compartido en el pasado #beERDays bajo la perspectiva inicial de la charla del pasado D365 Saturday, donde ya comentábamos las opciones de aplicar SCRUM en un proyecto de Dynamics 365, pero ahora con la experiencia de aplicarlo en un proyecto más amplio en #Aenor.

Y es que en muchas ocasiones nos encontramos con que durante la fase comercial, se ha vendido la magia de las metodologías ágiles mediante una serie de slides, que rara vez los decisores entienden en profundidad lo que conlleva. Es aquí, dónde me gustaría comenzar la reflexión, en el momento de empezar el proyecto, cuando el equipo se encuentra con debe aplicar Agile pero nadie antes le ha explicado cómo articularlo en un proyecto real.

Resumen de las lecciones aprendidas al aplicar metodología ágil a un proyecto de implantación de ERP

Deadline vs Proyecto Abierto

Una de las primeras cuestiones que debemos enfrentarnos al comenzar un proyecto de implantación/migración de ERP es sobre el modelo de proyecto, ¿estamos en un proyecto donde tenemos un deadline o en un proyecto abierto sin una fecha fija?.

En la mayoría de las ocasiones, un proyecto de ERP tendrá un deadline debido a la dependencia de los ciclos financieros y la integración con el resto de sistemas del cliente. De modo que, si bien el equipo puede trabajar por sprints, al final el cliente querrá que se implante en una fecha concreta independientemente del estado del backlog y los sprints definidos. Corremos entonces el riesgo de que el cliente pueda malentender que los sprints son pequeñas fases dentro del proyecto y que en la fecha del arranque tendrá “todo”.

Es por eso que debemos hacer entender que en metodologías ágiles el hecho de tener un deadline implica que debemos jugar con el alcance y la capacidad del equipo. Se priorizarán entonces las funcionalidades/requisitos totalmente imprescindibles por encima de aquellos que realmente puedan esperar a después del arranque o bien exista un workaround manual. También podremos ajustar la capacidad del equipo disponible, si bien una vez avanzado el proyecto, no es fácil encajar más miembros en el equipo de forma productiva. Si todo esto no lo explicamos antes de arrancar el proyecto, nos encontraremos en un proyecto clásico de implantación.

Es por eso que debemos enfocarnos en las funcionalidades realmente importantes o que aporten valor. Es muy común que al preguntar a los usuarios éstos quieran todo lo que tenían en el anterior sistema o bien que todo sea automático. En el caso de Dynamics 365 FO, es un producto en cloud en constante actualización donde Microsoft marca el ritmo (concepto One Version), de manera que la aproximación del proyecto debe ser siempre la de implementar el menor número de GAPS posibles. Cualquier funcionalidad que se implemente a medida implica un sobrecoste y una herencia que es probable que en el futuro incluso no sea compatible con el roadmap del producto, pudiendo perder incluso nuevas capacidades del producto.

En muchas ocasiones, adaptarse al producto implicará cambiar el proceso que lleva definido durante muchos años y muy condicionado por el anterior sistema. Por lo que dependerá de la madurez y visión de los Keys users la posibilidad de ajustar los procesos al ERP.

Responsabilidad compartida

Existe una falsa percepción de que simplemente con que el proyecto se apoye por la dirección, el proyecto saldrá adelante. Si bien esto es muy importante, existe una responsabilidad compartida entre los negocios, IT y el proveedor.

Como cliente, estaremos cometiendo un error si lanzamos el proyecto y nos lavamos las manos hasta la fecha de arranque. No debemos confundirnos con que este tipo de proyectos son de IT o del proveedor de turno. Si no conseguimos la implicación de los negocios, del equipo financiero y del equipo de TI del cliente, el proyecto tendrá retrasos o bien será un fracaso. Y es que la implantación de un ERP tiene un impacto en todos los negocios de la empresa y si bien el proveedor puede ser solvente, existe una dependencia muy fuerte de los procesos del cliente y de la colaboración de IT para la extracción de datos, integraciones, …

En mi opinión el proyecto debería estar liderado por Financiero, que será el que defina gran parte del proyecto y el momento de salir a producción. Por otro lado, el equipo de IT debe ser un facilitador dentro del cliente, proporcionando los elementos necesarios al proveedor (datos, entornos, integraciones,…), persiguiendo a negocio, validando los FDD y TDD, identificando riesgo y velando por la buena marcha de los hitos definidos. Por último, los negocios deben colaborar en la definición, aprobación y pruebas de los desarrollos.

La metodología ágil requiere de una implicación constante de los diferentes actores durante todo el proyecto, de modo que cuanto antes los involucremos, menos riesgo tendremos al final del proyecto.

Dependencia con negocio

Un aspecto que diferencia un proyecto ERP de uno tecnológico es la alta dependencia con los negocios, provocando que gran parte de las tareas no se puedan cerrar a expensas del negocio.

Durante la fase de definición podemos encontrarnos con reuniones con muchos interlocutores, donde cada uno aporte una visión sesgada de su negocio y que además no sean decisores. Es por eso que debemos identificar desde el principio del proyecto a los Key users de cada negocio. ¿Cúantos Key Users debemos tener? Cuantos menos, mejor. ¿Qué perfil debe tener el Key User? Deben ser personas que tengan una visión amplia de los procesos de su negocio e incluso del resto de la casa, ágiles a la hora de responder y con capacidad de decisión.

Otros de los factores de un Key user es que deben tener disponibilidad casi en exclusiva al proyecto. Esto, que es algo muy complicado de conseguir, es uno de los factores que afectarán claramente al progreso del proyecto.

Del lado del proveedor, se debe identificar todas aquellas dependencias con negocio durante todo el proyecto y marcar fechas límite para cada una de ellas. Estas fechas no deben ser amplias, ni deben esperarse al final del proyecto, ya que se debe trabajar con los Key users durante todo el proyecto. Por ejemplo, no podemos esperar que los Key Users nos proporcionen todas las plantillas de cargas de datos perfectas al final del proyecto.

Como parte de IT, tendremos que asegurarnos que los Key Users cumplen con sus compromisos y que al mismo tiempo los proveedores proponen un buen planteamiento de proyecto.

Una de las experiencias que hemos aprendido en Aenor es que debe quedar claro desde el principio qué se espera de un Key User y cuales son sus responsabilidades. Aunque se pueda explicar al inicio del proyecto, los usuarios no son plenamente conscientes de las implicaciones hasta pasado un tiempo del proyecto.

Hitos & Sprints

A la hora de montar la planificación del proyecto, debido a la gran dependencia con otros sistemas y dependencia con tareas de negocio, decidimos trabajar con la dirección con modelo waterfall basado en releases e hitos parciales basada en el backlog previamente trabajado.

Cada uno de los hitos tenía como objetivo adelantar los riesgos de la puesta en producción y comenzar con la adopción del nuevo sistema por parte de los usuarios.

Durante la construcción del backlog, utilizamos LCS como sistema de gestión del ciclo de desarrollo de Dynamics 365. El problema que nos encontramos fue que por cada funcionalidad nos aparecieron una gran cantidad de tareas a realizar generando sprints inmanejables. En realidad estas tarea había que realizarlas, pero se volvía complicado poder realizar un seguimiento y planificación para cientos de historias de usuario. Al mismo tiempo, nos encontrábamos con que los consultores no eran capaces de cerrar historias de usuario debido a las dependencias con negocio o incluso IT.

De modo que decidimos separar el backlog en dos, una parte relacionada con el equipo funcional dejaría de utilizar sprints para trabajar en un modelo KANBAN y por otro lado seguir trabajando por sprints con el equipo de desarrollo.

Comunicación

Comunicación, comunicación y más comunicación.  No me estoy refiriendo solo a reuniones de seguimiento o a el uso de herramientas como Teams, si no a cómo debemos conseguir que fluya la información entre los negocios, los business partners, DP’s y el equipo.

En nuestro caso, nuestro proyecto está compuesto por más de 30 personas agrupados en tres equipos diferentes (IT AENOR, CRM y ERP), por lo que la comunicación y el seguimiento del proyecto se hace vital para llegar al deadline.

No existe una receta mágica para todos los proyectos, en nuestro caso hemos aplicado lo siguiente:

  • Por un lado, hemos incorporado las figuras de Business Partners, personas con un perfil funcional y un conocimiento de los procesos de la casa y los sistemas IT. Estas personas están presentes en todas las reuniones ayudando a cerrar funcionales, validar y comunicar al resto del equipo.
  • Hacemos reuniones semanales con los actores más decisores del proyecto (DP’s, BP, Scrum Master y los Leads de equipo) con el objetivo de revisar cada uno de los bloques del proyecto a nivel funcional/técnico y posibles riesgos.
  • Por otro lado, el equipo de trabajo sigue con las liturgias normales de agile (daily, sprint planning, sprint review y retro). A estas dailies se suman los business partners y el DP, identificando riesgos o gaps de información.
  • Como elemento adicional diferenciador, en nuestro caso hemos conseguido un ambiente en el que los diferentes miembros hablan entre ellos de forma rápida y transversal sin necesidad de reuniones ni jerarquías.

Clave: Scrum Master

Aplicar Agile requiere de cierto grado de madurez del equipo, por lo que si no tenemos esa madurez nos encontraremos con un problema serio al intentar aplicarlo. No me refiero solo a que el equipo entienda los conceptos, si no a que debe interiorizarlo de forma natural.

En nuestro caso incorporamos una figura de Scrum Master que ayuda a los diferentes equipos a aplicar la metodología SCRUM de forma adecuada y facilita que los equipos se centren en lo importante y entiendan el trabajo a realizar.

Debemos ser conscientes que el Scrum Master no es un jefe de proyecto. A la hora de gestionar el proyecto, (en nuestro caso) es el DP el que marca las prioridades, el Scrum Master le ayuda a definir los sprints y asegura que el equipo entiende las historias de usuario implementándolas en los diferentes sprints.

Pero no solo debe entender la metodología el equipo, también debe entenderla los DP’s, gerentes, negocio y dirección.

Categorías
Organización

Equipos multidisciplinares o especializados

Foto Mario Cortés Flores
Mario Cortés Flores

Y es que a la hora de organizar a un equipo este es un aspecto a tener muy en cuenta que influirá en la velocidad de respuesta y comunicación con el cliente.

Cuando hablamos de equipos multidisciplinares nos referimos a un equipo donde se da respuesta a cualquier tipología de proyecto, desde un proyecto web a una aplicación móvil o a un proyecto con Machine Learning. Por otro lado, los equipos especializados, buscan disponer de silos de especialización donde un equipo se dedique a una tecnología o producto en exclusiva.

Pero ¿cuál es mejor?, pues como siempre, depende.

Bajo mi experiencia prefiero trabajar con estructuras planas donde combinemos ambos modelos. En el caso de los equipos multidisciplinares, hemos comprobado que funcionan bien con equipos pequeños de seniors, permitiendo hacer tipos de proyectos muy diferentes que aportan una carga de trabajo constante. Sin embargo, en el caso de los equipos especializados, hemos comprobado que también funcionan bien tanto en equipos grandes como pequeños, pero aportando una a los proyectos experiencia y conocimiento amplio.

Y aunque ambos modelos aportan muchas ventajas, debemos ser muy conscientes de las desventajas:

En los equipos multidisciplinares:

  • Vamos a necesitar de desarrolladores seniors que estén acostumbrados al cambio, ya que van a tener que afrontarse a constante aprendizaje.
  • Las estimaciones serán poco fiables debido a la poca experiencia, por lo que tendremos que asumirla o introducir medidas que amortigüen las desviaciones.
  • Tendremos menos referencias de proyectos similares que ne el momento de la oferta puede ser un factor negativo.

En los equipos dedicados:

  • El equipo se dedicará a un nicho tecnológico, que en caso de ir a menos (por ejemplo Windows Phone), tendremos muchos problemas de encontrar proyectos.
  • Los desarrolladores pueden encontrar cierta monotonía al no encontrar nuevos retos profesionales.
  • En proyectos donde se requiere de una integración con otros sistemas se incrementa el riesgo y las desviaciones por falta de experiencia.
  • Pensado para modelos conocidos previamente, donde tengamos identificadas todas las tareas y los riesgos sean mínimos.

Personalmente creo que la solución se adapta a nuestro caso está en una mezcla de ambos modelos, es decir, tener equipos multidisplinares pero con personas especializadas. De este modo nos aseguramos en dar respuesta global a proyectos pero con la posibilidad de incorporar en cada momento a las personas con el expertise adecuado.