Supongo que nadie se escandalizará si digo que la mayoría de los planes de negocio (BP) elaborados por emprendedores y/o profesionales del entorno sirven de poca o ninguna ayuda a la hora de dirigir el proyecto de creación de una nueva empresa. Por lo general, un BP se hace, se encuaderna y se guarda en un cajón. Años después aparece, lo revisas y te echas unas risas. Sencillamente, la incertidumbre que rodea la puesta en marcha de una empresa es de tal calibre que no hay estimación o predicción que sobreviva intacta más allá de algunos meses [¿semanas? ¿según salga de la impresora?]. No es que las proyecciones a 3 o 5 años sean pura patraña, es que hay problemas con las previsiones a 1 año.
Pero no hablo sólo de las cifras. He visto una y otra vez como el equipo emprendedor ha tenido que ir adaptando sus estrategias, su modelo de generación de ingresos o, incluso, la propia idea del negocio en el primer año de vida. Y me refiero a empresas que han ganado premios en certámenes de Entrepreneurship, que han obtenido un NEOTEC o un préstamo participativo de ENISA y/o que están participadas por Capital Riesgo. Es decir, estoy hablando de start-ups que han hecho sus deberes, han dedicado un tiempo y/o unos recursos preciosos a la elaboración de impecables planes de negocio [que muy pocos leerán, como sabemos].
Entre todos [profesores, consultores, profesionales del mundo del capital riesgo, empleados de entidades financieras, etc] mantenemos vivas una serie de prácticas que, en el mejor de los casos, aportan poco valor a ninguna de las partes interesadas.
¿Cómo debe enfocarse, en mi opinión, la creación de una empresa? Hablo del enfoque más adecuado para la gestión de ese esfuerzo, del proyecto [puesto que eso es lo que es] que dará lugar al nacimiento de una nueva iniciativa empresarial. ¿Qué requisitos debe cumplir? Algo he comentado anteriormente. Debe ser un enfoque robusto, que permita cometer errores. Debe ser adaptable, proporcionar planes fácilmente modificables, que se amolden a las circunstancias al tiempo que proporcionen un marco de trabajo adecuado para el equipo de emprendedores. Debe ser un proceso ligero, que no imponga al generalmente desbordado emprendedor una carga adicional de [inútil] trabajo. Debe partir de la base de que es imposible conocer el futuro, que el Cambio es inevitable. Que habrá sorpresas.
En definitiva, debe ser un enfoque ágil. En otras palabras, creo que todas las start-ups, pero especialmente las más innovadoras, deberían gestionarse en sus primeros meses de vida con SCRUM o alguna otra metodología ágil. De hecho, eso es lo que recomiendo a los equipos de emprendedores que tutelo.
¿Cómo se lleva esto a la práctica? Los enfoques ágiles se caracterizan por ser iterativos [se desarrollan en ciclos, por lo general de no muy larga duración] e incrementales [cada ciclo proporciona más y más valor al proyecto], además de tremendamente colaborativos. Los emprendedores deben planificar ciclos cortos de ejecución, centrarse en cada ciclo en aquello que les permita obtener ingresos cuanto antes e inspeccionar con frecuencia los resultados que van consiguiendo, para adaptar el plan en función del desarrollo de los acontecimientos [de hecho, los Inversores deberían hacer lo mismo, pero eso lo contaré en otra entrada].
En realidad, hay que hablar de"planes", en plural, porque trabajando con SCRUM u otras metodologías ágiles, se hace necesario planificar con distintos horizontes temporales: de 3 a 6 meses para los grandes hitos o "releases" [Release Planning], de 2 a 4 semanas para las entregas frecuentes que aumentan progresivamente el valor obtenido [Sprint Planning o Iteration Planning] y de una jornada de trabajo para el día a día [Daily Scrum]. Pero estos "planes" no tienen nada que ver con los mamotretos de 50, 70, 100 páginas que a menudo se ven obligados a desarrollar los emprendedores. Bastan un par de documentos muy sencillos para crearlos y mantenerlos. Básicamente, un par de listados en los que se recogen los entregables requeridos, las tareas necesarias para conseguirlos, así como algo de información para medir el progreso del trabajo. Hablo de unas 5 páginas [y a veces ni eso: una pared y un montón de post-its hacen igual de bien el trabajo].
Estos "planes" se inspeccionan con frecuencia, concretamente, al finalizar cada iteración o cada "release". Además, el equipo se reúne diariamente para comentar cómo va el trabajo, lo que han conseguido, lo que esperan conseguir, los problemas que se están encontrando en el camino. Se realiza un seguimiento estrecho de los avances del proyecto. La comunicación es fluida, de manera que la situación es conocida por todos, en todo momento.
Describir con detalle la aplicación de SCRUM a la gestión emprendedora me llevaría mucho tiempo, son cientos, literalmente, los detalles que tendría que tratar, por ejemplo con relación a la estimación ágil del esfuerzo y/o de los plazos, el seguimiento mediante burn charts y otras técnicas, la creación de un entorno de trabajo comunicante y muchas otras cosas. Por otro lado, hay abundante material en la web sobre todo ello. Para el que no lo conozca, la Scrum Guide elaborada por los 'inventores' del método está disponible gratuitamente en Scrum.org [última versión de noviembre 2009]. Incluso hay una traducción al español.
He utilizado este enfoque de trabajo con aproximadamente una decena de grupos de emprendedores, la mayor parte del tiempo sin que ellos fueran siquiera conscientes de estar utilizando un "método ágil". He visto que funciona, mucho mejor que los sistemas "más ortodoxos" enseñados en nuestras escuelas de negocios o empleados por los técnicos de entidades financieras o Administraciones [la mayoría de los cuales, por cierto, no ha montado nunca una empresa]. Recientemente he empezado otro cometido de consultoría, junto con un buen amigo, en el que estamos aplicando este enfoque en el lanzamiento de una start-up absolutamente innovadora. Eso es lo que me ha animado a escribir esta entrada.
Desde aquí animo a todos los implicados a reflexionar sobre estas ideas y/o, mejor aún, a ponerlas en práctica.
Gracias por tu comentario :-)
Y sí, a ver si entre todos conseguimos que algunas cosas cambien :-)
Posted by: Mario | 03/05/2010 at 10:54 AM
Mario, ya lo comentaremos en persona, pero si estuviera en una charla oyendo lo que acabas de decir ahora mismo estaría gritando "Bravo!" y aplaudiendo :) Totalmente de acuerdo contigo, un post magnífico. A ver si hacemos que algo cambie. Un saludo.
Posted by: Zalakain | 03/05/2010 at 09:12 AM
Muy interesante.
Creo que el problema de base es la confusión respecto a para qué sirve el Plan de Negocio. No es para ayudar al emprendedor, es para justificar el sueldo de todos los que lo piden. Y que necesitan algo que tengan cierta apariencia de estabilidad y verosimilitud para justificar sus meteduras de pata… Y claro, llegan a creerse que lo que les sirve a ellos le sirve al emprendedor… Y el emprendedor primerizo, pica como un pardillo porque le parece que esa gente tiene que saber lo que hace…
C’est la vie…
Posted by: Jaizki | 01/21/2010 at 11:18 AM
Me verás a menudo. Ya sabes que me interesa tu pensamiento. Sólo un deseo, si alguna vez nos toca tomar decisiones procuremos no caer en lo que criticamos (no pedir el típico BP y estar abiertos al cambio)
Posted by: David García Raya | 01/17/2010 at 05:45 PM
Hombre, David, qué sorpresa encontrarte por aquí :-) Pues esa pregunta que haces me la llevo haciendo yo muchos años, compañero. ¿Por qué seguimos todos enseñando, recomendando, requiriendo enfoques y/o metodologías que la experiencia demuestra inadecuados? No lo sé. Un ejemplo reciente. Una amiga quiere solicitar un aval a Aval Madrid. Le exigen un plan de negocio. Desde la AJE le proporcionan una plantilla para que elabore ese plan, asegurándole de que ese es el modelo que esperan recibir en AM. Pues amigo, tendrías que ver la plantilla!!!
Así no hay manera.
Mi respuesta a esa pregunta es... la causa debe ser la misma por la que cualquier otra innovación, en general [te remito a mi célebre post "Escorbuto", publicado en estas mismas páginas] tarda un tiempo incomprensible en ser adoptada. Creo que las personas al cargo de las instituciones que llevan las riendas de las sociedades pertenecen en su mayoría a esa categoría de personas con aversión al riesgo que se denominan "laggards". Dicho de otra manera, los que toman las decisiones, los que "mandan", no están interesados en que las cosas cambien. Luchan permanentemente para ralentizar el cambio. Lo hacen porque están cómodos con el status quo, pero no sólo por eso; lo hacen también porque sus modelos mentales son muy rígidos. De hecho, están ciegos a las ventajas que pueda traer tal o cual innovación. Es por eso que la sociedad siempre va por delante de sus legisladores, por ejemplo, o por delante de los académicos de la lengua, o de sus gobernantes, o de los "grandes" empresarios, etc.
De todas formas, hay sociedades y Sociedades. No todos los pueblos o naciones son igualmente "impermeables" al cambio.
Posted by: Mario | 01/17/2010 at 05:26 PM
Me parece buena idea. Realmente lo que haces es aplicar el "sentido común". En una organización viva con un entorno cambiante (cada vez más cambiante y en menos tiempo), de poco sirve fosilizar planes trianuales que luego la realidad se ocupa de dejar inservibles. Pero la cuestión es: si esto parace lógico y evidente, ¿por qué seguimos empeñados en mantener el mismo esquema en BP?. Si las empresas conocen (o pueden cocner) cuales son las herramientas útiles para el "manejo" de su capital humano, ¿por qué hacen lo contrario?. Creo que en el día a día reaccionamos de forma impulsiva, con funcionamiento y soluciones "tradicionales" y dedicando poco tiempo a pensar, alejándonos de todo esto que propones.
Posted by: David García Raya | 01/17/2010 at 01:44 PM
Joserra, gracias por tu comentario.
Creo que alguna vez te comenté que mi experiencia en metodologías ágiles es SOBRE TODO fuera del ámbito del desarrollo software. He utilizado metodologías ágiles en I+D+i, en selección de Recursos Humanos, en elaboración de presupuestos y control presupuestario, en entornos de fabricación (make to order), como estrategia para inversiones en start-ups o en creación de empresas. En cada caso tienes que hacer un trabajo de selección de técnicas y metodologías, a veces procedentes de otras disciplinas [ej., Buffer Management de TOC], pero siempre manteniéndote fiel a los principios fundamentales.
Cuando quieras hablamos un día de todo esto. Con una cerveza, claro.
Posted by: Mario | 01/16/2010 at 12:29 PM
En agile-spain, que hablamos de las metodologías ágiles en el desarrollo de software, cada vez se pregunta más por su aplicación en otros tipos de proyectos. La verdad que esta aplicación que comentas, parece muy provechosa, veo la creación de una empresa como una innovación al fin y al cabo.
Para conseguir objetivos difusos, o lejanos, funcionan muy bien ponerse metas pequeñas y a corto plazo. Scrum ha conseguido popularizarse para dar el empujón definitivo a las ágiles.
Y tomo nota ;)
Posted by: Joserra | 01/15/2010 at 10:30 PM
Amalio, gracias por tu comentario. Estaría encantado de conocer algo más de lo que estás haciendo o has hecho en este sentido. Cuando quieras dedicamos un rato a intercambiar impresiones :-)
Posted by: Mario | 01/15/2010 at 02:36 PM
Por cierto, JM, olvidé comentarte los problemas que sí me he encontrado... por ejemplo, Scrum está pensado para que lo utilice un equipo de personas cualificadas, profesionalmente 'maduras' [no me refiero a la edad, sino a disciplina, etc] y formadas en la metodología. Esto último, la formación, puedo proporcionarlo hasta cierto punto, pero no lo primero.
Además, el trabajo no depende, como en el caso del desarrollo soft, exclusivamente del equipo de desarrollo, sino que frecuentemente depende de plazos marcados por la Administración o terceros como VCs o proveedores. Pero esto se puede resolver.
Posted by: Mario | 01/15/2010 at 02:34 PM
Excelente, entrada, Mario. Estamos en la misma linea, suscribo casi todos tus planteamientos. Precisamente llevo en estos dias hablando de estos temas, en alguna formación que he dado, e insistiendo en la necesidad de aligerar los planes de negocio, y concederle la importancia que merecen. Pienso que algunos emprendedores necesitan PN más largos, como herramienta de aprendizaje, mientras que otros más cortos. En cualquier caso, el PN se debe concebir desde la optica de "build to think" más que desde la perspectiva "build to communicate" en la que siempre se insiste. Enhorabuena por el post, es muy util!!!
Posted by: Amalio A. Rey | 01/15/2010 at 01:41 PM
JM, gracias por tu comentario.
Conozco Lean, por supuesto. De hecho, lo conozco de cuando no era Lean, sino Toyota Production System. He aplicado principios de lo que ahora se llama Lean [Manufacturing]tanto en entornos de producción como de servicio desde mediados de los 90. Prácticamente la panoplia al completo, desde las 5S hasta el Kanban. Desde el Value Stream Map hasta el "equilibrado de líneas" [craso error, como demuestra TOC] No hay ninguna razón para que un proyecto de start-up no pueda beneficiarse de la aplicación de estos principios, es cierto.
Eso sí, a lo que me refiero en este post es a la gestión del proyecto de creación y desarrollo de la empresa en sus primer(os) año(s) de vida. Créeme, este escenario también lo conozco muy bien. No estoy hablando de una empresa madura que se plantea un CMMI, sino del período que va desde la idea hasta, por decir algo, la estabilización de la generación de Free Cash Flow, un período que según la naturaleza de la iniciativa puede llevar desde unos pocos meses a varios años.
Como consecuencia de los sucesivos ciclos de Release Planning, Iteration Planning, etc, el equipo emprendedor [típicamente no más de 5 personas] irá desarrollando e implantando procesos más "elaborados" de gestión, según sus necesidades. Por ejemplo, todos los relacionados con el manejo de la tesorería, en el sentido más amplio del término [desde compras a facturación]. Por ejemplo, los relacionados con la identificación de necesidades de recursos, en general, y de RRHH en particular.
Como digo, la definición más formal de esos procesos surgirá de forma natural, demandada por las circunstancias de la empresa según se desarrolle.
En el diseño de esos procesos, por supuesto, podrán tener en cuenta principios de Lean y, si son listos, de TOC.
De nuevo, gracias por tu comentario... creo que ahora está más claro :-)
Posted by: Mario | 01/15/2010 at 11:51 AM
Mario, como bien dices, la aplicación de SCRUM a nivel de gestión de empresa es sin duda, mucho más inteligente que seguir las prácticas absurdas que se suelen exigir (y se siguen practicando sin rechistar).
Sin embargo, piensa que SCRUM se diseñó para gestión de proyectos, y aunque podemos considerar la empresa como un proyecto (al fin y al cabo, es un macro-proyecto, compuesto de micro-proyectos), quizá a nivel de gestión global encajen mejor los principios de Lean, que funcionan más como un modelo adaptable que como un conjunto de prácticas definidas.
De hecho, empresas high-maturity-agile (: suelen utilizar Lean para la capa de negocio, SCRUM para la de proyectos y Extreme Programming para la capa técnica (más o menos las tres áreas fundamentables que propone ScrumManager)
Estupendo post, como siempre.
Un saludo!
JM
Posted by: JM | 01/15/2010 at 09:52 AM