Volvemos al ruedo con una interesante y desafiante nota que nos envío Alan Levy, del curso semanal de Management Estratégico. Plantea desde la miopía de mercado una discusión sobre los fines del negocio, que muchas veces se confunden con medios y así se pervierte el enfoque para hacerlos productivamente (a los negocios). El fuerte énfasis técnico de muchas empresas y el paradigma dominante de los profesionales expertos en su rama de conocimiento pero no en su aplicación de negocios, llevan a esta confusión de mercado. Mariano Morresi
¿Qué quieren los clientes de las empresas de software? Fines y medios.
Muchas empresas de software creen que los clientes quieren programas.
Hacer soft no es un fin en sí mismo, es un medio; y ganar dinero tampoco debería ser un fin, sino una consecuencia.
A mayor número de clientes satisfechos, y con mayor nivel de calidad en sus soluciones, mayor volumen de negocio y mayores expectativas de crecimiento.
El objetivo de la empresa no debería ser crear software, sino soluciones; y no debería hacer programas para ganar dinero, sino ganar dinero porque hace programas.
Las empresas que truecan las consecuencias por el fin, construyen culturas con mensajes erróneos.
Sus departamentos se alinean con un fin: ganar dinero, y cumplen los objetivos de facturación vendiendo “programas” (o lo que sea) sin pararse a analizar los problemas de los clientes.
Los gestores de los proyectos se centran en cumplir las fechas de entrega, asignando todos los programadores posibles a los proyectos retrasados.
Normalmente las fechas no encajan con las previsiones, y los programas no terminan de contentar a clientes que piden cambios por no tener lo que necesitan.
Al analizar la rentabilidad se ve que los retrasos aumentan los costes, y merman el beneficio esperado.
Los departamentos comerciales ponen a los programadores como culpables de estos retrasos, y ellos se defienden diciendo que negocio cierra agendas sin saber si se podrán cumplir.
Hace algunos meses fui testigo de cómo una empresa de software cerraba, tras muchos problemas, un proyecto con una desviación de agenda y presupuesto de un 400%.
Inicialmente se vendió como un sistema de gestión integral que debía estar funcionando en 6 meses. Era una operación con la que el departamento comercial conseguía dos objetivos: el de facturación trimestral, y la incorporación de un cliente importante a la cartera de la compañía.
Por eso, cuando el cliente dijo de cuándo dinero disponía, y la fecha en la que el sistema debía estar funcionando, la empresa de software le hizo un presupuesto con un cronograma que encajaba como un guante.
En 6 meses estaría todo terminado. En julio y agosto: obtención, análisis y especificación de requisitos, de septiembre a noviembre desarrollo, y en diciembre instalación y pruebas.
El 1 de enero funcionando. ¡Justo lo que el cliente quería!.
El departamento de ventas, con su mejor criterio consideró:
- Se trata de una operación importante, y aunque es seguro que cuando los ingenieros vean las fechas se quejarán, bien merece la pena poner a los mejores programadores, y el número que sea necesario, para que esté en enero.
- El presupuesto es posible que se quede algo estrecho, pero con esta operación, conseguiremos el contrato de las dos fases siguientes, y una buena cuenta.
En enero el programa no estuvo disponible, y lo que fue aún peor, el cliente, al iniciar su nuevo negocio descubrió que necesitaba funcionalidades que no se habían contemplado.
Las tareas de requisitos no se habían realizado para conocer las necesidades del negocio del cliente, sino para hacer el documento de requisitos, obligatorio según los procesos de desarrollo.
Las deficiencias de los requisitos, y las modificaciones introducidas llevaron, en enero, a tirar todo el código y comenzar con un nuevo diseño de arquitectura y datos.
Tras un rosario de vicisitudes y trabajo en constante presión de fechas, el cliente, disgustado y cansado, validó finalmente el trabajo en abril ¡del año siguiente!.
Lo que inicialmente debía haber durado 6 meses se prolongó durante 22, y en la misma proporción, los costes del proyecto.
Tras los casi dos años de retrasos, el cliente quedó muy descontento con la empresa de software, cuya falta de profesionalidad le había obligado a demorar sus planes de negocio, y a introducir medidas de contingencia de última hora para realizar operaciones mensuales y otros procesos previstos en el sistema que constantemente retrasaba su fecha de implantación.
Las tensiones entre el departamento comercial, gestión de proyectos y programación tampoco resultaron agradables.
El único beneficio que se puede extraer de estas experiencias es emplearlas para aprender. Aunque en la realidad, las tiranteces que generan y las tensiones personales hacen difíciles los análisis objetivos, y frecuentemente no se llega más allá de achacar a las circunstancias y a la culpa de otros la responsabilidad.
Analizando este caso, y tantos otros similares… ¿dónde diríamos que se encuentra la responsabilidad?.
- ¿En el departamento comercial?
- ¿En la falta de comunicación entre desarrolladores y vendedores durante la estimación de proyecto?.
- ¿En el trabajo deficiente o lento de los ingenieros?.
- ¿En la gestión del proyecto?...
Estas suelen ser las líneas de análisis tras los fracasos de los proyectos; pero lo cierto es que los aludidos consideran que cumplieron bien su trabajo y alcanzaron sus objetivos.
El departamento comercial cerró el presupuesto del año satisfactoriamente y aumentó la cartera de clientes, y los programadores trabajaron denodadamente, alargando sus jornadas diarias de trabajo a fines de semana y horas extras.
Por estas razones, el equipo, e incluso los gestores de la empresa, que saben del interés y dedicación de su personal, concluyen reafirmándose una vez más en el convencimiento de que son “gajes” de nuestra profesión. Las cosas en este negocio suelen ser así y poco se puede hacer.
Pero… ¿Quién pensó en el cliente?.
¿Quién tenía como objetivo su éxito. ¿Conocer y analizar las necesidades de su negocio, y trabajar con él en el diseño e implantación de las soluciones?.
La conclusión no es compleja: todo el personal hizo lo que debía hacer, y si hubiera que buscar un responsable, habría que dirigir la mirada hacia las instancias altas de dirección.
Los objetivos de los departamentos no estaban alineados entre sí, ni respondían a una estrategia coherente. Ninguno de ellos tenía como fin solucionar los problemas del cliente.
Orientación al cliente no es amabilidad, cortesía, o incluso servilismo.
Por supuesto que debe dispensar amabilidad y cortesía a su cliente, pero lo que además se espera de una empresa profesional de software es que haga suyo el problema del cliente.
Más allá incluso de lograr clientes satisfechos, se trata de conseguir clientes con éxito.
Que nuestro trabajo sea una de las razones del éxito de su negocio.
Hacer soft no es un fin en sí mismo, es un medio; y ganar dinero tampoco debería ser un fin, sino una consecuencia.
A mayor número de clientes satisfechos, y con mayor nivel de calidad en sus soluciones, mayor volumen de negocio y mayores expectativas de crecimiento.
El objetivo de la empresa no debería ser crear software, sino soluciones; y no debería hacer programas para ganar dinero, sino ganar dinero porque hace programas.
Las empresas que truecan las consecuencias por el fin, construyen culturas con mensajes erróneos.
Sus departamentos se alinean con un fin: ganar dinero, y cumplen los objetivos de facturación vendiendo “programas” (o lo que sea) sin pararse a analizar los problemas de los clientes.
Los gestores de los proyectos se centran en cumplir las fechas de entrega, asignando todos los programadores posibles a los proyectos retrasados.
Normalmente las fechas no encajan con las previsiones, y los programas no terminan de contentar a clientes que piden cambios por no tener lo que necesitan.
Al analizar la rentabilidad se ve que los retrasos aumentan los costes, y merman el beneficio esperado.
Los departamentos comerciales ponen a los programadores como culpables de estos retrasos, y ellos se defienden diciendo que negocio cierra agendas sin saber si se podrán cumplir.
Hace algunos meses fui testigo de cómo una empresa de software cerraba, tras muchos problemas, un proyecto con una desviación de agenda y presupuesto de un 400%.
Inicialmente se vendió como un sistema de gestión integral que debía estar funcionando en 6 meses. Era una operación con la que el departamento comercial conseguía dos objetivos: el de facturación trimestral, y la incorporación de un cliente importante a la cartera de la compañía.
Por eso, cuando el cliente dijo de cuándo dinero disponía, y la fecha en la que el sistema debía estar funcionando, la empresa de software le hizo un presupuesto con un cronograma que encajaba como un guante.
En 6 meses estaría todo terminado. En julio y agosto: obtención, análisis y especificación de requisitos, de septiembre a noviembre desarrollo, y en diciembre instalación y pruebas.
El 1 de enero funcionando. ¡Justo lo que el cliente quería!.
El departamento de ventas, con su mejor criterio consideró:
- Se trata de una operación importante, y aunque es seguro que cuando los ingenieros vean las fechas se quejarán, bien merece la pena poner a los mejores programadores, y el número que sea necesario, para que esté en enero.
- El presupuesto es posible que se quede algo estrecho, pero con esta operación, conseguiremos el contrato de las dos fases siguientes, y una buena cuenta.
En enero el programa no estuvo disponible, y lo que fue aún peor, el cliente, al iniciar su nuevo negocio descubrió que necesitaba funcionalidades que no se habían contemplado.
Las tareas de requisitos no se habían realizado para conocer las necesidades del negocio del cliente, sino para hacer el documento de requisitos, obligatorio según los procesos de desarrollo.
Las deficiencias de los requisitos, y las modificaciones introducidas llevaron, en enero, a tirar todo el código y comenzar con un nuevo diseño de arquitectura y datos.
Tras un rosario de vicisitudes y trabajo en constante presión de fechas, el cliente, disgustado y cansado, validó finalmente el trabajo en abril ¡del año siguiente!.
Lo que inicialmente debía haber durado 6 meses se prolongó durante 22, y en la misma proporción, los costes del proyecto.
Tras los casi dos años de retrasos, el cliente quedó muy descontento con la empresa de software, cuya falta de profesionalidad le había obligado a demorar sus planes de negocio, y a introducir medidas de contingencia de última hora para realizar operaciones mensuales y otros procesos previstos en el sistema que constantemente retrasaba su fecha de implantación.
Las tensiones entre el departamento comercial, gestión de proyectos y programación tampoco resultaron agradables.
El único beneficio que se puede extraer de estas experiencias es emplearlas para aprender. Aunque en la realidad, las tiranteces que generan y las tensiones personales hacen difíciles los análisis objetivos, y frecuentemente no se llega más allá de achacar a las circunstancias y a la culpa de otros la responsabilidad.
Analizando este caso, y tantos otros similares… ¿dónde diríamos que se encuentra la responsabilidad?.
- ¿En el departamento comercial?
- ¿En la falta de comunicación entre desarrolladores y vendedores durante la estimación de proyecto?.
- ¿En el trabajo deficiente o lento de los ingenieros?.
- ¿En la gestión del proyecto?...
Estas suelen ser las líneas de análisis tras los fracasos de los proyectos; pero lo cierto es que los aludidos consideran que cumplieron bien su trabajo y alcanzaron sus objetivos.
El departamento comercial cerró el presupuesto del año satisfactoriamente y aumentó la cartera de clientes, y los programadores trabajaron denodadamente, alargando sus jornadas diarias de trabajo a fines de semana y horas extras.
Por estas razones, el equipo, e incluso los gestores de la empresa, que saben del interés y dedicación de su personal, concluyen reafirmándose una vez más en el convencimiento de que son “gajes” de nuestra profesión. Las cosas en este negocio suelen ser así y poco se puede hacer.
Pero… ¿Quién pensó en el cliente?.
¿Quién tenía como objetivo su éxito. ¿Conocer y analizar las necesidades de su negocio, y trabajar con él en el diseño e implantación de las soluciones?.
La conclusión no es compleja: todo el personal hizo lo que debía hacer, y si hubiera que buscar un responsable, habría que dirigir la mirada hacia las instancias altas de dirección.
Los objetivos de los departamentos no estaban alineados entre sí, ni respondían a una estrategia coherente. Ninguno de ellos tenía como fin solucionar los problemas del cliente.
Orientación al cliente no es amabilidad, cortesía, o incluso servilismo.
Por supuesto que debe dispensar amabilidad y cortesía a su cliente, pero lo que además se espera de una empresa profesional de software es que haga suyo el problema del cliente.
Más allá incluso de lograr clientes satisfechos, se trata de conseguir clientes con éxito.
Que nuestro trabajo sea una de las razones del éxito de su negocio.
Autor: Juan Palacio
Fuente: Versión Cero - http://www.versioncero.com/articulo/475/nuestros-clientes-no-quieren-programas
Fuente: Versión Cero - http://www.versioncero.com/articulo/475/nuestros-clientes-no-quieren-programas
A nosotros nos pasaba lo mismo, eramos una empresa de ingenieros y nuestro producto eran proyectos para cada cliente (diseño de instalaciones de energía). Primero nos sesgó el enfoque técnico y luego nos fuimos al otro extremo con lo netamente financiero. No tener en claro nuestra visión, enfocada al cliente, fue determinante para no haber mucho mejores negocios...
ResponderEliminar