LEDAmc ha adaptado sus metodologías de control de productividad para entornos SAP
Tecnologías de la información: el negocio de los artesanos
A los artesanos se les paga por el tiempo que dedican a producir algo.
En España, este criterio se utiliza para pagar a los proveedores de Desarrollo de Software.
Se pagan miles de millones de euros al año a las Empresas de Desarrollo en función del tiempo que sus técnicos tardan en realizar proyectos de software para sus clientes.
Es un criterio artesanal, preindustrial e ineficiente: se le paga más al que más tarda (en palabras del Director de TI de un banco de implantación nacional: “cuanto más torpe es un técnico, y más tarda en hacer su trabajo, más caro me sale”). Es decir, el propio sistema desincentiva la productividad de los proveedores.
A nadie se le ocurriría valorar el precio de un coche en función del tiempo que le han dedicado unos operarios en Corea a producirlo.
Sin embargo, así es como se valoran y pagan los proyectos de Desarrollo, aunque se realicen en Málaga, en Buenos Aires o en Bombay.
Muy pocos clientes pagan en función de la “cantidad” de software producido. Casi ninguno controla la cantidad de software que se le entrega; ni, por supuesto, si se recibe una cantidad parecida a la que encargó.
Nos movemos, pues, en un entrono que tiene poco que ver con la imagen de sofisticada innovación de las TI. Su propio modelo productivo es mucho más inmaduro que el de las industrias que ayuda a transformar.
¿Es posible avanzar hacia un planteamiento más industrial y más productivo?
LOS ARTESANOS EN TIEMPOS DE CRISIS
En tiempos de crisis, la prioridad de los clientes es bajar los costes. Los contratos de Desarrollo y Mantenimiento de aplicaciones disminuyen, y además bajan las tarifas.
Frente a una bajada de tarifas, el proveedor sólo tiene dos opciones para preservar su margen:
- Bajar los salarios
- Aumentar la productividad
La apuesta generalizada en los tiempos actuales es bajar los salarios. Se intentan mejorar los métodos de trabajo para ser más efectivos; pero como, en general, no se mide el software producido, no se puede medir tampoco el impacto de las mejoras en la productividad, y lo que no se mide, no se puede mejorar.
Sin embargo, si disminuyen los costes salariales, el efecto sobre el margen se mide de inmediato.
De modo que nos queda un único camino: bajar los salarios, que es la salida fácil.
La bajada de costes se suele conseguir de dos formas:
- Incorporando personal local menos experimentado que realiza parte de las actividades de los técnicos de costes más altos.
- Llevando la producción a lugares con salarios más bajos.
La primera medida redunda en una cierta bajada de la calidad (que corresponde, más o menos, a lo que se quiere ahorrar el cliente). La segunda, en la creación de Factorías de Software en lugares donde la preparación profesional es alta, y los salarios bajos (India, Latinoamérica), aunque esta medida trae consigo otros problemas.
Lo único bueno que tienen las crisis es que aceleran los cambios.
¿FACTORIAS DE SOFTWARE O TALLERES DE SOFTWARE?
Las Factorías de Software buscan tres objetivos:
- Reducir los costes salariales.
- Incrementar la productividad por la industrialización del Proceso de Desarrollo.
- Aumentar la estandarización del producto software.
Lo primero es cierto e indiscutible.
Sin embargo, lo segundo, no.
Si una Factoría consigue un aumento de productividad de, digamos un 20% por mejora del proceso ¿Por qué eso no se aplica a unidades de desarrollo en Londres, París o Madrid (donde no hay factorías de software), y sólo se aplica a Buenos Aires, o Bombay?
De hecho, los overheads de las factorías de software impiden repercutir más que un porcentaje de la diferencia de costes laborales al precio final del servicio.
Las factorías de Software no son más productivas, y se paren más a un taller que a una industria: un artesano de éxito contrata a varios operarios que cobran menos para poder producir más a un coste medio inferior.
Pero la producción unitaria no es mayor (producción neta por hora de trabajo). De hecho, el modelo de Factoría sólo funciona si el coste salarial es muy inferior al de origen.
Por supuesto, se introducen cambios en el proceso para facilitar el trabajo en grupo, pero eso no es lo mismo que industrializarlo.
Respecto del tercer objetivo se puede decir que se cumple en parte, ya que si bien es verdad que se introducen cambios obligados por la implantación de un proceso diferente, principalmente dirigidos a la mejor definición de los productos, no es menos cierto que, por sí solos, no generan reducción de actividades, ni en muchos casos mejora de la calidad final.
UN POCO MÁS ALLÁ DE LA ARTESANÍA
(HAY UN MUNDO MÁS ALLÁ DE LA ARTESANÍA)./
Cambiar un modelo artesanal por uno industrial choca con numerosas resistencias.
De los técnicos.
- Resistencia humana al control individual y de grupo.
- Resistencia organizativa a la estandarización real de métodos de trabajo, no de la documentación resultante.
- Resistencia al establecimiento de puntos de control pasa-no pasa previos y de producto.
- Resistencia al establecimiento de un tamaño óptimo de lote que obligue al técnico a cambiar sus métodos de trabajo.
- …
De los usuarios.
- Resistencia a la especificación anticipada y detallada de necesidades y funciones, sobre todo en negocios muy dinámicos y competitivos.
- Resistencias que se originan en la incomprensión del tamaño, y por ende del presupuesto, real de lo solicitado.
- Resistencias originadas en el miedo a no llegar a tiempo al mercado.
- …
Pero también aporta grandes beneficios
Los beneficios que genera un proceso industrial bien establecido y controlado son los siguientes:
- Previsión fiable de coste, plazo y calidad del producto final.
- Medición de alta exactitud de la producción y sus tiempos de proceso, costes por actividad y calidad de productos intermedios y finales.
- Ahorro de costes reales.
- Reducción real de plazos.
- Aumento de la calidad real del producto final.
- Conocimiento de la capacidad real del proceso reproducción de software con el que se está trabajando (ya se interno, externalizado o mixto) y por tanto brinda la capacidad para actuar sobre él, es decir gestionar el proceso.
- Capacidad fiable para implantar un proceso de mejora continua basado en datos estadísticos y no en impresiones, sensaciones y preferencias personales.
- …
Con todas estas ventajas ¿cómo es posible que los gestores no aborden con seriedad este camino?
- Por desconocimiento del mundo a veces impenetrable de los “informáticos”.
- Porque los artesanos no son los mejores candidatos para industrializar la artesanía.
¿CÓMO SE INDUSTRIALIZA LA PRODUCCIÓN DE SOFTWARE?
Como cualquier otra cosa: Empezando por medir la producción.
(¿Alguien se imagina una fábrica de tornillos donde no se puedan contar los tornillos que se producen?).
Existen varias formas de medir la cantidad de software producido. Las más frecuentes son tres:
- Por las funcionalidades que añade al negocio (Puntos Función, el método más estándar, especialmente en USA).
- Por su tamaño y complejidad técnica (Líneas de Código o Puntos Función Automatizados).
- Por otros sistemas intermedios relacionados con el diseño físico de las transacciones (unidades físicas involucradas en un programa)
Todas tienen sus detractores, pero todas funcionan razonablemente bien, sobre todo desde un punto de vista estadístico.
Una vez que se conoce la producción se pueden plantear dos caminos:
- Modelos de mejora de productividad. Si se conoce cuánto se ha producido por cada euro pagado, se pueden establecer estrategias de mejora que aporten beneficios cuantificables.
- Modelos de pago por producción. Son los más avanzados, y en ellos el proveedor recibe un pago en función de la cantidad de producto entregada (como en todas las industrias).
La mejora de la calidad también se debe asociar al software efectivamente producido (y no a valores absolutos, o a esfuerzos) ya que ésta es la única forma de medir la calidad real de un producto.