Esta no es una presentación de tecnología, no está dirigida a la gente de tecnología sino a la parte de negocio, por lo que es importante organizar la información en torno a las decisiones de negocio que están relacionadas con el uso de la tecnología. Por esa razón he tratado de organizar los errores que en base a mi experiencia he visto trabajando con las Corporaciones, startups, diferentes tipos de empresas y organizar los errores en las etapas de negocio porque probablemente tienen más sentido de negocio de esa manera.
Este artículo está extraído de una entrevista que el Prof. Dr. Sven Prüser me realizó para la serie Friday Afternoon Chill-out organizada por UBE Academy el 22/01/2021, que puedes ver completa a continuación (en inglés).
UBE Academy es experta en el campo de la formación en gestión. No sólo dominan su propio campo de especialización, ya sea el liderazgo, la gestión, la estrategia, las operaciones, las ventas y el marketing, la gestión de la cadena de suministro y las finanzas. También saben cómo utilizar las tecnologías modernas para que su empresa esté preparada para el futuro.
Errores en la fase de validación
Este es probablemente el mejor momento para entrar y crear las soluciones adecuadas.
Lo que ocurre con las startups es que suelen buscar ayuda en el lado de la tecnología: ¿cuál es la mejor tecnología a utilizar? ¿cuál es el equipo que podría ayudarles con eso? y tienen mucho entusiasmo como decías. Están encantados con su idea, tienen un gran feedback de sus amigos.
En un momento dado están tan enamorados de su idea que el siguiente paso inevitable es construir la solución de software que apoyará su negocio.
Y este es el mejor momento para pensar en lo que están considerando.
Construir demasiado y demasiado pronto
Van a invertir mucho tiempo y mucho dinero para lanzar esta idea de negocio y desarrollar esta plataforma y, como proveedor de tecnología, creo que eso es genial. Pero probablemente deberían reconsiderarlo y ver si pueden hacer una validación más barata de lo que proponen.
Ese es el mejor enfoque que deberían adoptar antes de entrar en el proceso de construcción de un sistema de software completo.
Hay múltiples maneras de hacerlo. Intenta no sólo sondear el mercado y ver si hay público, sino validar si el precio es correcto, si puedes llegar a los clientes de forma rentable, si tus números y estimaciones pueden ser validados antes de hacer toda esta inversión.
Tal vez puedas intentar utilizar algún tipo de crowdfunding para que, antes de empezar a construir algo, puedas obtener alguna validación de que la gente está dispuesta a mostrar el dinero y pagar por ello, y no sólo decir que la idea es genial.
Mi primera recomendación a la gente es que tenga una visión clara antes de sumergirse en el proceso de construcción de una solución de software.
Errores en la etapa de lanzamiento de las Startups
Lo especial de las start-ups es que no tienen mucho dinero en general, pero sí mucho entusiasmo y flexibilidad.
Externalizar conocimientos de software clave
El primer error que es crítico en esta etapa es subcontratar el conocimiento clave del software.
Y la palabra clave aquí es «clave».
No todas las startups son empresas basadas en la tecnología digital.
Si fabrican zapatos, estupendo. Probablemente necesitarán algunas herramientas digitales para comprar, producir, vender y llevar la administración. Puede que incluso necesiten un sitio de comercio electrónico para ofrecer su producto. Pero pueden seguir haciéndolo a través de otros canales. Así que, en esta situación, el software no es un elemento crítico para el negocio.
Pero cuando se trata de construir una plataforma en la que la propuesta de valor se basa en la existencia de este software, entonces esta parte es crítica para el negocio y si es crítica para el negocio necesitas tener conocimientos de ese elemento clave en tu equipo principal.
Probablemente también necesites un experto en la industria o un experto en marketing si vas a venderlo. Quizás la administración sea importante pero no crítica.
Pero de nuevo, si el software es clave, es importante tener la propiedad de este sistema.
Y esto requiere un CTO en tu equipo principal o al menos con una relación a largo plazo con ellos.
El CTO no tiene por qué ser el desarrollador. Tal vez puedas subcontratar el desarrollo, puedes subcontratar la gestión del proyecto o incluso puedes subcontratar la arquitectura a un consultor.
Pero alguien que esté en el equipo central del nuevo negocio debe estar a cargo de toda la solución técnica que se está construyendo y ser consciente y tener el control de lo que se está creando, de manera que si más adelante se decide cambiar de proveedor el CTO debe ser capaz de gestionar todo este conocimiento.
Desarrollar una solución monolítica
Otro error que he visto es desarrollar una solución monolítica. Es decir, una solución que resuelva todas las necesidades de la empresa.
Hoy en día hay muchas herramientas que cubren diferentes partes del ciclo de vida de la empresa. Puedes encontrar sistemas administrativos, puedes encontrar sistemas de tickets, puedes encontrar CRMs, CMSs, sistemas de mensajería, etc.
Así que, básicamente, puedes intentar construir tu solución de software integrando diferentes herramientas que están en el mercado y que resuelven ciertas necesidades específicas.
Lo que tienes que desarrollar son esos componentes específicos que nadie más ofrece.
Y esto no es sólo por la razón del coste. Es porque esas herramientas específicas serán probablemente mucho más potentes que cualquier cosa que puedas crear, pero también porque te animarán a crear una solución modular. Así, si te replanteas algunas decisiones en el futuro, es mucho más fácil sustituir un módulo por una versión nueva y mejorada que intentar extraer parte de la funcionalidad de una solución monolítica existente.
Plataforma sobredimensionada
Otro error típico es intentar utilizar una plataforma sobredimensionada. Esto significa tratar de elegir una herramienta grande que se adapte a la empresa a medida que ésta crezca.
El negocio ahora mismo es nuevo y probablemente ahora mismo el coste es importante, y el tiempo de comercialización es realmente importante para empezar a vender y empezar a ver su producto en el mercado.
Los grandes sistemas que pueden escalar son probablemente caros, pero también tienen una larga curva de aprendizaje. Así que esto es algo que en este momento puede ser una gran desventaja.
Recomiendo seleccionar la herramienta adecuada para el corto plazo. Más adelante podrás reconsiderar esta decisión y sustituir los componentes que están afectando a tu crecimiento por soluciones más escalables.
Utilizar módulos que bloquean
Por supuesto, todos los componentes que utilices para construir tu sistema deben tener algún tipo de integración, pero tienes que tener cuidado de que esas soluciones no tengan algún tipo de lock-in para ti. Eso significa que, si tienes que sustituirlas más adelante, puedes perder mucha información o mucho tiempo o mucho valor en el proceso.
Debería poder extraer la información del componente con un esfuerzo razonable para pasar a un nuevo sistema.
Un ejemplo de esto es si usted está utilizando un sistema de pago, por ejemplo, PayPal o Stripe. Si luego decides cambiar una de esas soluciones y tienes clientes con pagos recurrentes automatizados, corres el riesgo de tener que renegociar con ellos para que autoricen el nuevo sistema, y esto, dependiendo del servicio que ofrezcas, puede suponer una pérdida de clientes.
Errores en la fase de lanzamiento para empresas establecidas
Por supuesto, también las empresas más grandes intentan a veces lanzar soluciones empresariales.
En esta situación la situación es bastante diferente. Probablemente la empresa ya cuenta con recursos financieros, tiene productos en el mercado y también tiene una historia. Y esta historia probablemente está creando algún tipo de limitación o restricción basada en decisiones anteriores.
No funcionar como una startup
Mi primera recomendación es tratar de evitar ejecutar la nueva iniciativa en función de productos ya establecidos. En la medida de lo posible, trate de ejecutar el nuevo lanzamiento como si fuera una startup.
El proceso es más o menos el mismo que hemos visto anteriormente. Intente crear un equipo central para este nuevo producto que controle los elementos y actividades críticas del lienzo del modelo de negocio. Intentar lanzar el nuevo producto con la solución de software mínima necesaria basada en las necesidades de un producto nuevo y no validado.
Ejecutar como un proyecto secundario
Cree un equipo central que dirija esta parte del proceso. Incluya a aquellas personas que puedan encargarse de las partes críticas del proceso. Por ejemplo, el especialista en el sector, el comercializador y el informático, de nuevo si el software es clave. Y asegúrese de que trabajarán a tiempo completo y centrados en ese proyecto.
Si la fase de lanzamiento se lleva a cabo como un proyecto secundario, existe un alto riesgo de que fracase, incluso si la idea es buena.
Si no hay personas específicas encargadas de estas actividades clave, sino que se diluyen en departamentos que atienden a otras partes de la organización, es muy probable que otras prioridades se impongan y rompan los planes que puedan existir durante el lanzamiento.
No dar libertad
Otro problema típico de las organizaciones es que tienden a exigir que la nueva iniciativa utilice la infraestructura y los servicios comunes que usa el resto de la empresa. Esto significa utilizar servicios de otros departamentos y aplicaciones de uso global.
Normalmente, los dos conceptos van de la mano: para que ese departamento pueda realizar su función, es imprescindible utilizar ese software porque ya está integrado en lo que hace ese departamento.
La cuestión aquí es si estos requisitos ayudarán o dificultarán el desarrollo del nuevo producto.
Hay que tener en cuenta que el nuevo producto aún no ha sido validado y existe el riesgo de que no pase la prueba. Por lo tanto, cualquier esfuerzo por estandarizar su funcionamiento con el del resto de la organización puede ser un esfuerzo inútil.
Por eso es necesario, a priori, dejar libertad de decisión sobre los servicios globales que utilizará la nueva iniciativa y hacer una cuidadosa evaluación coste-beneficio para decidir si es más conveniente utilizar la solución global o si es mejor probar una nueva.
Errores en la fase de crecimiento
En un momento determinado, si el nuevo proyecto o la nueva iniciativa que se está llevando a cabo está probado y ha superado el punto de equilibrio, se pasa a una nueva situación: es un producto establecido que ha pasado a formar parte de la cartera de productos de la organización.
No eliminar los silos
Si ha seguido las recomendaciones anteriores, existe un grave riesgo de que estemos creando silos. Diferentes partes del negocio que no se comunican entre sí.
Este es el punto en el que sugiero intentar fusionar la solución de software construida para el nuevo producto con la del resto de la organización.
Por un lado, es importante conseguir una economía de escala.
No se quiere tener 10 soluciones diferentes para 10 productos diferentes con 10 proveedores diferentes, con 10 arquitecturas diferentes, con 10 conocimientos diferentes.
Así que es importante ponerlos en un solo lugar. No queremos que, si cambian las normas de política de datos, tengamos que cambiarlas en 10 lugares. No queremos que, si una tecnología se queda obsoleta, tengamos que actualizarla en 10 lugares diferentes. Así que es importante hacer un proceso de estandarización, tratando de integrar todo en una sola arquitectura.
No cuestionar la arquitectura
Un segundo problema son las decisiones que tomamos al principio bajo la presión de la velocidad y la incertidumbre. Ahora es el momento de cuestionarlas y ver si son capaces de escalar con el negocio con un coste y esfuerzo razonables.
Así que quizá sea el momento de sustituir el sencillo sistema de contabilidad por una solución SAP.
Porque en este momento está justificado hacer esa inversión de tiempo y dinero en un producto que sabemos que va a estar en nuestra cartera durante mucho tiempo.
Así que ahora es el momento de revisar cada uno de los componentes utilizados (en esta solución no monolítica, recordemos, si no sería mucho más complicado) y valorar si merece la pena seguir con la solución inicial o buscar una nueva.
Esto es así aunque no sea un componente que tenga su equivalente en la arquitectura global de la organización.
No aprovechar los aprendizajes
También hay otra posibilidad a tener en cuenta. Es posible que los componentes que se han utilizado durante el lanzamiento tengan alguna ventaja sobre los que la organización ha utilizado tradicionalmente. En este caso, hay que ser capaz de aprender de esa experiencia, y puede ser el momento de ver si alguno de esos nuevos componentes puede ser realmente una mejora para el resto de la organización.
Tal vez el nuevo componente sea más rápido, tenga una mejor integración, una nueva funcionalidad o un menor coste.
La fase de lanzamiento ha servido para probarlos en un entorno real y ahora puede ser el momento de exportarlos al resto de la organización.
Conclusión
El concepto es que, cuando vayas a lanzar algo, primero decidas qué es lo fundamental y te asegures de que la empresa está centrada en tener esas actividades bajo control, intentes crear un sistema modular, tratando de utilizar la solución más sencilla que puedas encontrar en cada momento, especialmente durante las primeras fases, y luego apliques un proceso de estandarización para aprovechar lo que has aprendido y eliminar los silos y conseguir una economía de escala.
Esta es una recomendación basada en mis experiencias. No tiene por qué ser siempre la mejor estrategia, pero al menos merece la pena tener en cuenta estos criterios y decisiones a la hora de construir soluciones de software.
Lo importante debe ser siempre que las soluciones desarrolladas sirvan al negocio y se ajusten a sus necesidades. Los criterios a largo plazo deben cuestionarse cuando el proyecto es joven y aún no está lo suficientemente maduro como para tener un mínimo de garantías de que podrá alcanzar esa vida a largo plazo.