archivo

Archivo de la etiqueta: proveedores

El nivel 3 de CMMI extiende el área de proceso del nivel 2 denominada Gestión de acuerdos con proveedores.

En el anterior nivel el objetivo principalmente era gestionar esos acuerdos, sin olvidarnos del proceso que permite llevarnos a los mismos, de la adquisición de esos productos o servicios y de la aceptación de los mismos.

En este nivel los objetivos son los mismos aunque con un enfoque más formal, más estratégico y con una visión más allá del alcance de un proyecto (o de un conjunto de ellos).

Este área de proceso se ocupa desde el método para la analizar proveedores potenciales de productos o servicios, evaluarlos y seleccionarlo hasta la verificación del cumplimiento de los compromisos fijados con los mismos y la posibilidad de revisar, si fuera necesario, los acuerdos adoptados con determinados proveedores.

Cuando se realiza un presupuesto o una propuesta de colaboración a un cliente para la realización de un servicio de desarrollo de software, se debe hacer siempre, desde el punto de vista económico, teniendo en cuentas dos aspectos:

– El coste objetivo que tiene la realización del servicio. Es decir, cuál es el esfuerzo que se estima necesario para realizarlo en condiciones normales y con el nivel de calidad exigido internamente por la empresa y por el cliente. En este coste objetivo ya está implícitos los beneficios que la empresa de desarrollo de software espera de un proyecto. ¿Qué después se consigue hacer el servicio en un menor número de horas sin reducir el nivel de calidad? Pues mejor que mejor y habrá que valorar positivamente al equipo de personas que ha participado en él y que ha conseguido un beneficio superior al esperado.

– El buffer de seguridad. El coste objetivo se basa en un proyecto de desarrollo de software realizado en condiciones normales, sin tener en cuenta las características del cliente en general (formas de pago, infraestructura y cultura tecnolóǵica) y de sus usuarios y directores técnicos en particular, además de cualquier otro factor externo que hubiera que tener en cuenta (es importante hacer enfasis en lo de externo, es decir, circunstancias que están fuera de la empresa que va a desarrollar el software). Este buffer de seguridad previene de contratiempos e intentar poner en salvaguarda el beneficio objetivo que se espera obtener en el proyecto. Como es lógico este buffer dependerá del tipo de cliente y será mayor en unos casos que en otros.

Abusar del buffer de seguridad, es decir, sobredimensionar el coste de un proyecto por encima del umbral de riesgo, tiene el riesgo de que no te acepten la oferta y lo que es peor, que el cliente piense que le estás tomando el pelo, por lo que hay que intentar se lo más justo posible en este aspecto. Por otro lado, la reducción del buffer de seguridad, su eliminación o incluso la realización de rebajas sobre el coste objetivo, también debe analizarse convenientemente, ya que en el momento en que se realizan estos descuentos, estamos atacando directamente a las expectativas de beneficio, se incrementa la posibilidad de que se produzcan pérdidas, de que sea necesario un sobreesfuerzo por parte de los miembros del equipo de proyecto y a la posible calidad del resultado final.

Al final una empresa tiene que vender si quiere seguir subsistiendo, eso es lógico, pero siempre que tenga la posibilidad de poder negociar un precio, recomiendo que se tenga en cuenta de manera objetiva la aplicación del buffer de seguridad. Por otro lado como el coste es la suma del coste objetivo más el buffer de seguridad, cuanto menores sean los costes de producción, en más casos se podrá aplicar los buffers de seguridad sin perder competitividad.

La no existencia de sistemas abiertos provocaba, como es lógico, una incertidumbre muy grande en las organizaciones, ya que la adquisición de una solución hardware resultaba toda una apuesta, ya que suponían una inversión importante y estaban a merced del fabricante. Imaginemos la siguiente situación, una empresa contrata una infraestructura hardware que con el software adecuado permite almacenar las compras y ventas que realiza, la empresa está muy contenta con dicha infraestructura ya que soporta perfectamente los requerimientos que se necesitan, además también está contenta con el fabricante porque tiene un servicio de atención al cliente excelente. Sin embargo resulta que un buen día el fabricante decide que deja de dar soporte a dicha infraestructura ya que ha sacado dos o tres familias de equipamiento más avanzado y conviene promocionarlo. La empresa si quiere reducir riesgos (ya que si falla algún componente hardware no va a encontrar recambio) tendrá que realizar una inversión en una nueva infraestructura que sí se encuentre soportada por el fabricante.

Esto creaba de forma totalmente evidente una auténtica cautividad ante el proveedor, ya que la evolución de las infraestructuras informáticas de una organización estaban totalmente supeditadas a la estrategia comercial del proveedor. En el ejemplo que he puesto por lo menos existía la posibilidad de migrar a una versión superior, imaginemos que el fabricante hubiera declarado quiebra y cerrado la línea de producción, esto hubiera obligado en aquella época a cambiar de proveedor, a cambiar el software y a una costosa y compleja migración de datos.

Esta situación de poder de los fabricantes (que interesaba, como es lógico a aquellos a los que les iba bien) minaba absolutamente la competencia, la posibilidad de componer una infraestructura de servidores, comunicaciones y demás componentes hardware y aplicaciones con productos de diferentes proveedores, lo que permitiría reducir costes y conducir a una situación más lógica, en la que los departamentos TIC decidieran con mayor libertad cuál debía ser su estrategia.

La relación cliente/proveedor en los procesos de desarrollo de software presenta como situación ideal, el equilibrio.

Este equilibrio se basa:

1) En que si el cliente desea en cualquier momento cambiar de proveedor, lo pueda hacer sin poner en riesgo su negocio o lo que es lo mismo, que el tiempo en que tarde el nuevo proveedor en conocer el negocio, el software desarrollado y su tecnología sea inferior a un umbral que se establezca como tiempo límite razonable.

2) En que el proveedor si lo desea, una vez finalizada sus obligaciones contractuales, pueda desligarse del cliente por la circunstacia que sea: no le resulta rentable, no es una línea de negocio que quiera seguir potenciando, etc…

Esa situación de equilibrio, casi nunca existe y de ella tratan de sacar tajada proveedores y clientes:

1) Si un proveedor sabe que el cliente no va a poder encontrar un sustituto que le garantice el éxito o la continuidad del servicio, puede hacerse fuerte exigiendo unas contraprestaciones económicas más elevadas y/o reduciendo la calidad del servicio..

2) Si un cliente sabe que un proveedor tiene una fuerte dependencia económica de él, intentará conseguir condiciones más favorables: mejores precios, acuerdos de nivel de servicio más exigentes, etc…

En un proceso de desarrollo de software las prisas son muy malas, ya que influyen en la calidad del producto.

Si eres cliente, marca plazos sensatos, si eres proveedor, lleva un ritmo constante en el proyecto y no lo dejes todo para el final y sobre todo si eres proveedor y ves que no se va a cumplir los plazos, habla con el cliente, si éste es sensato entenderá ante una justificación razonable un retraso en el proyecto, ya que todos los clientes lo que queremos es que el producto que se entregue sea de calidad.