archivo

Archivo de la etiqueta: reducción de costes

La reducción de costes no va en dirección opuesta a la generación de valor.

Tal vez el problema podría estar inicialmente en una mala gestión de los recursos económicos disponibles, si bien, si no se cambian comportamientos, enfoques y estrategias a todos los niveles, muy difícilmente se conseguirá que la reducción de costes vayan de la mano de una mayor capacidad de generar valor.

Y eso ha pasado una y otra vez en este período de crisis, en el cual, se ha optado por lo fácil que es recortar, sin que exista un plan alternativo que tenga como objetivo hacer las cosas mejor y siempre es posible, si se tiene una mínima capacidad de autocrítica, de hacer las cosas mejor.

Para Michael Bolton (traducción libre): “Si estás implacablemente centrado en la reducción de costes,rápidamente te convertirás en alguien ajeno a las oportunidades que permitan aumentar el valor”.

Esta reflexión va en la línea de lo comentado anteriormente, es decir, si tu objetivo único es recortar, sin centrarte en el crecimiento, enfocarás tu atención en eso y no en los cambios necesarios para invertir la tendencia de la organización porque la misma tendrá, tal vez, menos costes pero seguirá sin crecer y, lo más probable, es que como sigue sin hacerse nada para adaptarse al nuevo contexto, la situación no hará más que empeorar, lo que llevará inexorablemente a la realización de nuevos recortes. Hasta que ya no quede más que recortar.

En el campo de los proyectos de desarrollo de software, muchas organizaciones están optando por recortar la inversión. De entrada no es ni bueno ni malo, racionalizar la inversión, habría que analizar cada situación en particular.

El problema nos lo encontramos en el momento en que a proyectos concretos se les mete la tijeras, sin que vaya de la mano de una recorte proporcional en las expectativas. Ese desequilibrio solo puede moderarse a costa del esfuerzo de los que participan en el proyecto, que incluso haciéndolo muy bien, no podrán, en todos los casos, hacer un producto satisfactorio porque precisamente los recortes han obligado a hacer un sobreesfuerzo y a renunciar a ciertos patrones de calidad que han impactado en la capacidad de generar valor en cada iteración del producto.

El escenario actual del negocio del desarrollo de software no es nada alentador:

1) Se ha reducido el número de contrataciones.
2) Las contrataciones (por regla general) van más ajustadas presupuestariamente.
3) Para ganar dichas contrataciones hay que hacer rebajas (importantes en algunos casos) sobre presupuestos de contratación ya de por sí no proporcionados con los trabajos a realizar.
4) En los años de bonanza económica, el número de empresas de desarrollo de software ha crecido y no solo eso, la mayoría de ellas han aumentado en estructura (es decir hay más empresas y encima más grandes). Contra todas ellas hay que pelear para conseguir negocio.

También es cierto que cuando se inicie la recuperación económica, las variables 1) y 2) llevarán también una tendencia ascendente y se pasará de una situación crítica como la actual a una situación con mejores espectativas.

Pero mientras eso sucede hay que sobrevivir (estoy seguro que incluso en situaciones de crisis como la actual hay empresas que siguen creciendo, aunque en la mayoría de los casos, la pendiente será mucho menos pronunciada) y adaptarse a las circunstancias.

¿Están todas las empresas igual de preparadas para sobrevivir a la crisis? Evidentemente no. Algunas variables que considero favorables para que una empresa sea menos vulnerable, son las siguientes:

1) Fidelización de clientes.
2) Alianzas fuertes con otras empresas del sector.
3) Compromiso de los gestores (en estas circunstancias los trabajadores deben sentirse apoyados por los niveles más altos de la organización y sentir y apreciar que están tomando medidas para reducir el impacto provocado por la reducción del volumen de negocio, como por ejemplo, congelación de sus sueldos y de sus gastos de gestión (no deben ser sólo los trabajadores de base lo que carguen con eso), realización de actividades comerciales, búsqueda de alianzas, preocupación por la situación de los empleados (en algunos casos habrá que prescindir de personal, en otros el número de horas semanales no oficiales se incrementará, etc…).
4) Control de costes y de la productividad. Hay que saber objetivamente dónde se producen los gastos de la empresa (hay que controlar gastos relacionados directa e indirectamente con la producción, así como el conjunto de costes de estructura), qué proyectos son rentables y cuáles un sumidero de dinero, es necesario conocer qué personal es productivo y cuál no (por un lado hay que recompensar (ascensos, incrementos salariales por encima de la media) al personal comprometido y productivo y también si no hubiera más remedio y hubiera que reducir plantilla, ésta debería empezar por los puestos menos necesarios y por el personal menos comprometido y productivo).
5) Compromiso de los trabajadores.
6) Costes de producción por debajo de la media del sector (buena metodología interna de desarrollo, buen framework, buen conjunto de componentes y soluciones reutilizables, buen conocimiento del negocio de los distintos clientes, buena gestión interna y con los clientes de los proyectos, buen nivel técnico de los programadores y analistas programadores, buen nivel de los analistas funcionales, capacidad de reducir costes desviando trabajo a centros nearshore u offshore propios o subcontratados (cuidando que la merma de la calidad de los productos no superen el máximo umbral admisible tanto por la empresa como por los clientes), etc…

La crisis no será eterna y las cosas poco a poco volverán a su cauce, pero es necesario entender que no se puede vivir y gestionar una empresa igual en un período de crisis que en un período de bonanza económica.

He tenido la oportunidad de leer mucho últimamente sobre las factorías de software. Mi opinión sobre la producción industrializada de software, la podéis consultar en este mismo blog en una serie de artículos que dediqué al tema.

Como comentaba en dichos artículos, para mi la producción industrializada de software no existe, simplemente lo que se ha hecho es aplicar una serie de buenas prácticas (en algunos centros) y aplicar una serie de fórmulas para reducir en la medida de lo posible los costes de desarrollo (casi todas ellas basadas en la búsqueda de soluciones que impliquen un menor coste por mano de obra y el apoyo de las instituciones).

Los lectores de mi blog, también saben de mi opinión sobre el mercado TIC y en los últimos tiempos, también he tenido la oportunidad de comprobar que no me equivocaba. En esta época de crisis, las empresas de desarrollo de software van a por todas, utilizando unas políticas muy agresivas de precios.

Si las cosas no cambian o se está muy bien posicionado en el negocio o esto será la ley de la selva, donde sólo los más fuertes sobrevivirán (y aquellos aliados de los más fuertes). No todas las empresas pueden asumir esa guerra de precios sin una pérdida considerable de la calidad de los servicios que se ofrecen. Por este motivo yo que siempre he tenido un gran recelo de las factorías de software, veo que en las circunstancias actuales las empresas que tienen este tipo de recursos están bien posicionadas (siempre y cuando las factorías estén bien gestionadas) para poder competir.

Cuando se habla de factorías de software, se utilizan a menudos los términos Nearshore y Offshore. El primer caso se corresponde a aquellas factorías que se encuentran próximas geográficamente (o que tienen algún rasgo común, como por ejemplo, una franja horaria próxima, el idioma, etc…) a las organizaciones para la cual prestan sus servicios (en algunos casos proyectos concretos, en otros casos outsourcing), el segundo caso se corresponde a factorías más alejadas geográficamente y que en la mayoría de los casos no presenta rasgos comunes con las organizaciones a la que prestan servicio. Como habréis podido ver, existirán casos donde las factorías se puedan considerar Nearshore u Offshore en función de la persona que la defina.

Por regla general, se suele relacionar el Nearshore con soluciones de mayor calidad (y con un mayor coste de producción) y el Offshore con soluciones de menor calidad (y con un menor coste de producción). También hay que tener en cuenta que el Offshore en muchos casos es bastante complicado. Supongamos que situamos una factoría de software en Laos y que a ella desviamos carga de trabajo de programación. Si el análisis funcional está hecho en español, existirán serias dificultades para su interpretación por parte de los programadores del centro.

También hay quien utiliza el término de Inshore, para referirse a factorías de software situadas muy próximas geográficamente (100 kilómetros como mucho) de las organizaciones a las que prestan servicio.

En cualquier caso: Inshore, Nearshore y Offshore, lo importante es que el centro esté bien gestionado, que se utilice un framework de desarrollo común (y que pueda ser lo suficientemente flexible para poder adaptarse en situaciones concretas a especificaciones técnicas de clientes concretos) y que el personal que trabaja en los mismos esté lo más formado posible (y existan unos procesos de formación continua). De esta manera más o menos la calidad de los productos no debería ser tan significativa, ni ser tan distintas (aunque la barrera del idioma, en muchos casos, puede afectar notablemente el resultado del producto). Si la gestión es buena, el framework es común y flexible y se poseen buenos técnicos, los costes de producción se reducirán, dejando prácticamente como aspecto diferencial el nivel adquisitivo de los países donde se encuentre la factoría de software, lo que permitiría pagar sueldos más bajos y por tanto permitir ofertar en los proyectos un mayor número de horas a un menor coste.

Aunque la solución que más me guste sea la Inshore o en su defecto la Nearshore, más que nada porque no me gusta por qué se realiza la deslocalización, ni que se aproveche el nivel de vida de un país para ofrecer salarios varias veces más reducidos que los de nuestro país, no tengo más remedio que reconocer que quien posea la infraestructura y la organización para ofrecer productos con un nivel de calidad aceptable y a unos precios rompedores, tienen todas la de ganar en un mercado tan competitivo como es el del desarrollo de software.