Inicio Make Text BiggerMake Text SmallerReset Text Size
¿Cómo se decide la compra software? Imprimir E-mail
Valoración del artículo: / 10
MaloBueno 
28.08.2005
vendedorHace algún tiempo, el director general de la filial de un importante grupo empresarial español, acudió a la industria del software para encargar el desarrollo de un sistema que gestionara la práctica totalidad de los procesos de una nueva línea de negocio.
Esta persona estaba preocupada, porque disponía de un presupuesto cerrado, se encontraba ya en junio y el nuevo sistema debía estar desarrollado y en funcionamiento en enero del año siguiente.
Pero afortunadamente... Tuvo suerte. O al menos eso creyó tras entrevistarse con el representante comercial de una importante empresa de desarrollo de software. La fortuna había puesto en su camino la solución ideal, y a las personas capaces de realizarla.
La empresa de soft, tras escuchar sus necesidades, restricciones de fechas y presupuesto; le sorprendió gratamente con la solución a su problema: podían desarrollar un programa sin exceder ni el presupuesto, ni las felchas.

El presupuesto pareció algo ajustado, pero el proveedor consideró que podía estrechar su margen comercial, porque la relación que iniciaba con tan importante cliente lo compensaría en operaciones posteriores; y en cuanto al cronograma, había dimensionado un equipo con las personas para llevar a cabo el plan necesario: En julio se llevaría a cabo el análisis de requisitos. De agosto a noviembre, el desarrollo de la aplicación, y en diciembre la instalación y pruebas del sistema.

Aunque el director de la empresa cliente sabía que las agendas estaban muy ajustadas, en el fondo no le importaba si al final la entrega se demoraba algunas semanas.

A poca experiencia que se tenga en el negocio del software, uno se puede imaginar cuál fue el futuro de este proyecto, y de la prometedora relación comercial que iniciaba.
Después de un año de retrasos (en enero, pero del año siguiente) el sistema seguía programándose, y sin funcionar. Cliente y proveedor se amenazaban con los tribunales...
El director general de la empresa cliente fue cesado por decisión del grupo empresarial matriz. La empresa de software perdió una importante suma en esta operación, y lo más importante: prestigio y credibilidad profesional.

Una cosa que siempre me ha sorprendido de nuestra industria es la ligereza con la que muchos de nuestros clientes llegan a cerrar importantes operaciones comerciales, aunque estoy convencido de que una parte importante de culpa la tenemos nosotros, al construir departamentos comerciales "nacidos para vender", no "para solucionar problemas".

Los dos párrafos siguientes, extraídos de "La Agenda" de Michel Hammer definen muy bien una situación bastante frecuente de nuestra industria:

"Vender" esos sistemas, implica mucho más que una comida que paga el vendedor al responsable de compras. Es necesario analizar y determinar las necesidades del cliente. Habrá que diseñar un sistema que cubra esas necesidades, calcular su coste, y evaluar su viabilidad, rentabilidad y coherencia con la estrategia empresarial del fabricante...
Tal como lo percibía otro de los departamentos, la sección de ventas "nunca veía un negocio que no le gustase". Por poco claro que estuviese el resultado, o por incierto que fuese el beneficio, perseguían el posible pedido hasta su más amargo final. Ansiosos por superar a los competidores, los representantes de ventas a menudo ofertaban al cliente un precio, antes de que alguien tuviese la más mínima idea de lo que iba a costar el sistema. (En esta empresa, el lamento común era que lo que se decía en los cinco primeros minutos de la primera visita de venta comprometía a la empresa durante los tres años siguientes).

Artículos relacionados
Trackback(0)
Comentarios (4)Add Comment
...
escrito por Invitado, August 28, 2005
habían dimensionado un equipo con las personas para llevar a cabo el plan necesario: En julio se llevaría a cabo el análisis de requisitos. De agosto a noviembre, el desarrollo de la aplicación, y en diciembre la instalación y pruebas del sistema.


si los plazos se ponen antes de realizar el análisis de requisitos el desastre, salvo milagro, esta más que asegurado. A pesar de que esto resulta algo obvio he visto cometer este error inumerables veces, pero da igual, "hay que hacerlo como sea que este cliente es muy importante y bla,bla,bla... esta era la fecha cliente que el cliente nos daba como limite y hemos tenido que aceptarla... vosotros podeis chicos!!", y claro todos los clientes son "muy importantes" así que al final la excepción se transforma en norma de trabajo y la situación se repite ad infinitum.

Donde trabajo actualmente las cosas funcionan de modo ligeramente diferente pero con las mismas consecuencias. el proceso sería algo así:

- El comercial entabla las primeras conversaciones con el cliente y escribe un documento con las necesidades del cliente, esto no es por supuesto una toma de requisitos ya que ni el cliente suele conocer todos los detalles (es un directivo que en realidad sabe poco acerca de lo que realmente tienen que hacer la aplicación) ni el comercial es un técnico que sea capaz de ver las dificultades que se plantearán en el desarrollo ni es capaz tampoco de hacer al cliente las preguntas adecuadas.

- A partir de este documento que elabora el comercial se pide a algún análista que realize una valación aproximada de plazos, personal necesario etc,etc. Sin tener en la mano los detalles del proyecto esta valoración no es más que una pantomima que se hace el técnico tiene que hacer practicamente a ciegas.

- En función de esta valoración que en realidad no sirve para nada si el cliente esta de acuerdo se firman un plazos con fechas concretas de entrega, es decir, a partir de un documento realizado sin ninguna rigurosidad ni seriedad se compromete la empresa por escrito.

- luego viene la toma de requisitos de verdad (más o menos porque dependiendo del interlocutor por parte de la empresa cliente y otros factores esta fase suele ser un desastre también, pero esto sería otro tema...), el desarrollo y cuando dios quiera la entrega...

Lo sorprendente es que alguna vez se logre cumplir un plazo o un cliente quede satisfecho.

D
Y en la mia, y en la de todos
escrito por Invitado, August 30, 2005
En mi empresa aún es peor. Creo que ponen siempre monto del contrato y la fecha en una comida con el cliente.
¿Cómo pueden hacer siempre lo mismo todas las empresas?
¿Alguno trabaja con un método que sea bueno?
Y entonces, c߳mo hay que hacerlo?
escrito por Invitado, October 21, 2005
Está claro que la manera que comentan ustedes no es la correcta pero veo que TODOS nos quejamos ... ¿hay alguien que pueda proponer la manera ideal teniendo en cuenta TODOS los intereses que hay en un desarrollo (empresarial, comercial y técnico)?

Los carpinteros y los panaderos entregan su producto a diario y a tiempo porque llevan cientos de años haciéndolo.

La informática es aún un "arte en pañales", señores ... nos queda mucho por mejorar !
Separar contratos
escrito por Maurcio Laverde, September 11, 2008
Lo ideal:
Separar en dos contratos:
1. Un contrato para levantamento de requerimientos (con herramientas formales UML no carta al niño Dios).
2. Otro contrato con planeacion y estimaciones independientes según los requerimientos hechos en el primer contrato.

Puede que cada contrato lo realicen empresas independientes pero siempre con herramientas formales UML y personas especializadas en "levantamento de requerimientos de proyectos de software" especificamente. Generalmente TIENE que ser un Ingeniero de Software.

Escribir comentario

busy
 
< Anterior   Siguiente >
Advertisement

Advertisement



Amigos de Navegápolis

Registrado en Safe Creative