Desarrollo de software. La tiranía del proveedor
En un artículo anterior hice referencia a la tiranía del cliente, cuando este aprovecha de forma abusiva la posición de dependencia de una proveedor respecto de los ingresos que le proporcionan sus contratos, ya que una buena parte de la facturación procede del mismo.
Esta tiranía también la podemos encontrar al revés, cuando un proveedor se encarga del desarrollo y mantenimiento de sistemas de información críticos para el negocio o para un aspecto concreto del mismo y el conocimiento necesario para poder cambiar de proveedor no está debidamente transferido al cliente y/o no está documentado (todo esto se ve agravado exponencialmente si en el caso de un desarrollo a medida no hay un control adecuado de versiones y del código fuente).
Como en el caso de la tiranía del cliente, el principal responsable no es quien ejerce la posición de poder sino quién ha propiciado las condiciones para que esa posición de poder exista. Es cómodo para un cliente depender de pocos clientes que te aseguren ingresos fijos y también lo es para un cliente trabajar con una serie de proveedores fijos que cumplen con su cometido y no te dan problemas.
Pero este ambiente idílico, funciona si todo va bien, pero ya sabemos de voluble es el mercado y nuestro negocio. Puede haber relaciones de años que se terminen degradando y se rompa el equilibrio en el que todo parece marchar, ahí es cuando empiezan los problemas, ahí es cuando pueden aparecer este tipo de situaciones.
Si un proveedor se siente fuerte, podrá empezar a exigir precios superiores a los que venía percibiendo, sin más justificación (real) que la de ganar más dinero, podrá empezar a reducir su nivel de calidad, a reducir su nivel de compromiso y lo peor de todo es que se termina tragando más y más porque te tienen bien agarrado por donde todos sabemos.
Llegado el momento tendrás que plantearte seriamente continuar con el proveedor. Lo mismo no lo puedes hacer de manera inmediata porque se puede resentir tu negocio, pero sí que se tienen que establecer los mecanismos para que el conocimiento no se encuentre exclusivamente en él.
Pingback: Desarrollo de software. Diversificación y equilibrio entre clientes y proveedores « Jummp