Guia Avanzada de Gestion de Adquisiciones

GUA AVANZADA DE
GESTIN DE ADQUISICIONES
Laboratorio Nacional de Calidad del
Software
Marzo 2009

El presente documento cumple con las condiciones de accesibilidad del formato PDF (Portable Document Format).
Se trata de un documento estructurado y etiquetado, provisto de alternativas a todo elemento no textual, marcado de
idioma y orden de lectura adecuado.
Para ampliar informacin sobre la construccin de documentos PDF accesibles puede consultar la gua disponible en la
seccin Accesibilidad >Formacin >Manuales y Guas de la pgina http://www.inteco.es.
Gua avanzada de gestin de adquisiciones 2
NOTA DE EDICIN
Esta gua ha sido desarrollada por el Laboratorio Nacional de Calidad del Software de
INTECO. Esta primera versin ha sido editada en Marzo del 2009.

AVISO LEGAL
CMMIes una marca registrada en la Oficina de Marcas y Patentes de EEUU por la
Universidad Carnegie Mellon
PMBOKes una marca registrada por el Project Management Institute, Inc.
Todas las dems marcas registradas que se mencionan, usan o citan en la presente gua
son propiedad de los respectivos titulares.
INTECO cita estas marcas porque se consideran referentes en los temas que se tratan,
buscando nicamente fines puramente divulgativos. En ningn momento INTECO busca con
su mencin el uso interesado de estas marcas ni manifestar cualquier participacin y/o
autora de las mismas.
Nada de lo contenido en este documento debe ser entendido como concesin, por
implicacin o de otra forma, y cualquier licencia o derecho para las Marcas Registradas
deben tener una autorizacin escrita de los terceros propietarios de la marca.
Por otro lado, INTECO renuncia expresamente a asumir cualquier responsabilidad
relacionada con la publicacin de las Marcas Registradas en este documento en cuanto al
uso de ninguna en particular y se eximen de la responsabilidad de la utilizacin de dichas
Marcas por terceros.
El carcter de todas las guas editadas por INTECO es nicamente formativo, buscando en
todo momento facilitar a los lectores la comprensin, adaptacin y divulgacin de las
disciplinas, metodologas, estndares y normas presentes en el mbito de la calidad del
software.

NDICE
1. INTRODUCCIN 8
1.1. Conceptos 9
1.2. Mejores prcticas 12
2. PROCESO DE GESTIN DE ADQUISICIONES 16
2.1. Planificacin del proceso de adquisicin 16
2.1.1. Estrategia de seleccin de fuentes 17
2.1.2. Definicin de los requisitos 19
2.1.3. Planificar el proceso de oferta 21
2.1.4. Desarrollo de criterios de evaluacin 25
2.2. Solicitud de respuesta a proveedores 30
2.2.1. Buenas prcticas 30
2.2.2. Gestionar el proceso de ofertas 31
2.3. Seleccin de proveedores 35
2.3.1. Aplicar criterios de evaluacin 36
2.3.2. Relaciones con proveedores 41
2.4. Negociaciones 42
2.4.1. Debilidades en las negociaciones 43
2.4.2. La negociacin como proceso de negocio 45
2.4.3. Negociacin inteligente 46
2.4.4. Mejores prcticas en la negociacin 49
2.5. Gestin del proceso de adquisicin 52
2.5.1. Gestin y administracin de contratos 53
2.5.2. Control y monitorizacin de los riesgos 59
2.6. Procedimiento de Cierre del contrato 61
2.6.1. Procedimiento de Cierre Administrativo 62
2.6.2. Verificacin del alcance 63
2.6.3. Obligaciones posteriores 63
2.6.4. Lecciones aprendidas 64
2.6.5. Documentacin de cierre de proyecto 64
3. ENFOQUE DE MODELOS 66
3.1. CMMI-ACQ 66
3.2. IACCM Capability Maturity Model 70

4. ANEXO I: MTODOS DE SOLICITUD DE INFORMACIN 73
4.1. Documento RFI (Request for information) 73
4.1.1. Comenzar la solicitud de informacin 73
4.1.2. Contenido del RFI 74
4.1.3. Revisin, validacin y distribucin 75
4.2. Documento RFP (Request for proposal) 76
4.2.1. Roles y responsabilidades 76
4.2.2. Gestin de RFP 77
5. GLOSARIO 78
6. ACRNIMOS 83
7. REFERENCIAS 85

NDICE DE FIGURAS
Figura 1 Equilibrio de evaluadores del proceso de seleccin de proveedores .................. 40
Figura 2 Pasos clave en la gestin de cambios ................................................................. 58
Figura 3 Proceso de gestin de riesgos ............................................................................ 60
Figura 4 Mejora del proceso de gestin de riesgos ........................................................... 61
Figura 5 Constelaciones de CMMI.................................................................................. 66

NDICE DE TABLAS
Tabla 1 Entradas, salidas y herramientas de la fase de planificacin .............................. 16
Tabla 2 Requisitos como parte del proceso de adquisicin ............................................. 19
Tabla 3 Herramientas y tcnicas para establecer y validar requisitos .............................. 21
Tabla 4 Comparticin de los mtodos de solicitud ........................................................... 24
Tabla 5 Entradas, salidas y herramientas de la solicitud de respuesta a proveedores .... 30
Tabla 6 Entradas, salidas y herramientas de la seleccin de proveedores ...................... 35
Tabla 7 Factores de evaluacin en la visita a la empresa proveedora ............................. 38
Tabla 8 Rendimiento de los proveedores ......................................................................... 39
Tabla 9 Entradas, salidas y herramientas de la fase de negociacin ............................... 43
Tabla 10 Estilos de negociacin ......................................................................................... 48
Tabla 11 Entradas, salidas y herramientas del cierre del contrato ..................................... 62
Tabla 12 Clasificacin de reas de proceso ....................................................................... 67
Tabla 13 ................................................ 68 Descripcin de reas de proceso de adquisicin

1. INTRODUCCIN
Cada vez son ms las organizaciones que adoptan la estrategia de adquirir productos y
servicios a proveedores externos en lugar de desarrollarlos internamente. El objetivo de esta
estrategia es mejorar la eficiencia operativa de la organizacin aprovechando la capacidad
de los proveedores de entregar soluciones de mejor calidad, ms rpido, a menor coste y
con la tecnologa ms adecuada.
Este enfoque es ampliamente utilizado por las administraciones pblicas. Por ello, esta gua
resultar de bastante inters en este sector.
La problemtica de la adquisicin reside en que la organizacin que adquiere los
productos y servicios es quien tiene la responsabilidad final de satisfacer las necesidades
de sus usuarios, mientras que es el proveedor quien va a ejecutar las tareas necesarias
para desarrollar y proporcionar la solucin.
Segn algunos estudios, entre los grandes proyectos de adquisicin de TI (tecnologas de la
informacin), el 25% fracasa en los dos primeros aos y el 50% fracasa en los cinco
primeros aos. Como factores que contribuyen a este fracaso, destacan:
Mala gestin
Incapacidad de articular las necesidades del cliente
Mala definicin de requisitos
Seleccin de proveedores inadecuada
Procesos de contratacin inadecuados
Procedimientos de seleccin de tecnologas insuficientes
Cambios de requisitos incontrolados
La responsabilidad es compartida entre el adquiridor y los proveedores. La mayora de los
fallos en los proyectos se podran evitar si el adquiridor supiera cmo gestionar
adecuadamente la adquisicin con sus proveedores. Un aspecto muy importante para el
xito de la relacin entre adquiridor y proveedor es la comunicacin.
Muchas veces, el adquiridor se desentiende del proyecto una vez que lo contrata a un
proveedor y, despus, se da cuenta demasiado tarde de que el proyecto va retrasado, la
tecnologa elegida no es viable, etc., en definitiva, el proyecto ha fracasado.
El adquiridor es el responsable del proyecto: es quien mantiene una relacin con los
usuarios finales para comprender sus necesidades, realiza la gestin de todo el proyecto y
es responsable de entregar la solucin a los usuarios. Adems, para realizar esta entrega al
usuario de la solucin deseada, el adquiridor es responsable de elegir a los proveedores que
la van a desarrollar y proporcionar de manera que cumpla las necesidades del cliente.

1.1. CONCEPTOS
En este apartado se van a definir ciertos conceptos relacionados con la gestin de
adquisiciones. A continuacin se definen dos de ellos que son clave en este proceso como
son los sistemas abiertos y los productos o componentes COTS (Commercial Off-The-Shelf)
Sistemas abiertos
Un sistema abierto puede definirse como una coleccin de implementaciones de
componentes software y hardware diseados para satisfacer ciertas necesidades y con
interfaces de componente bien definidas y mantenidas pblicamente. Un sistema abierto es
aquel que ha sido construido acorde a unos estndares y tecnologas abiertas y disponibles.
La Organizacin Internacional de Normalizacin (ISO) lo define como todo sistema
informtico capaz de interconectarse con otros de acuerdo con unas normas establecidas.
El Consorcio de fabricantes X/Open especifica que los sistemas abiertos son entornos
diseados e implantados de acuerdo con normas ampliamente divulgadas e independientes
de los fabricantes.
Como caractersticas bsicas en los sistemas abiertos est la combinacin de
interoperabilidad, portabilidad y uso de estndares abiertos.
El uso de estndares y trabajar con sistemas abiertos ofrece las siguientes ventajas:
Interoperabilidad entre ordenadores de cualquier fabricante.
Portabilidad de software en distintos hardware.
Compatibilidad entre diferentes versiones de sistemas operativos.
Escalabilidad del software en diferentes plataformas de hardware.
Mayor provecho de tecnologa.
Mltiples proveedores de hardware y software.
Ambiente estndar de aplicaciones.
Mltiples soluciones disponibles de acuerdo con necesidades especficas.
Mayor disponibilidad de aplicaciones.
Disponibilidad de una base amplia de donde obtener referencia.
La arquitectura abierta permite a las empresas escoger la configuracin que mejor se adapte
a sus necesidades actuales y futuras, pero al mismo tiempo pueden confiar en que a medida
en que sus necesidades vayan cambiando no existirn lmites a la interoperabilidad de sus
sistemas o a la libertad de eleccin.
COTS
Los COTS son componentes software diseados, elaborados y comercializados por terceras
partes, generalmente de bajo precio o de libre distribucin, utilizados por los desarrolladores
de software como partes preexistentes que puede incorporar en su arquitectura.

Un elemento COTS se refiere a un tipo particular de componente software, probado y
validado, caracterizado por ser una entidad comercial, normalmente de grano grueso y que
reside en repositorios software, y que es adquirido mediante compra o alquiler con licencia,
para ser probado, validado e integrado por usuarios de sistemas. (Elemento COTS del SEI,
[Brown y Wallnau, 1998])
Un componente COTS es una unidad de elemento software utilizada para la composicin de
sistemas de software basados en componentes, que puede ser adquirido mediante compra,
licencia, o ser un software de dominio pblico.
Las caractersticas bsicas de los COTS son:
Licencia abierta.
Ofrecido por un proveedor que obtiene un beneficio del mismo.
Es el proveedor quien mantiene los derechos intelectuales del mismo.
Existen mltiples copias idnticas del producto.
Se utiliza sin sufrir ninguna modificacin por parte de la empresa adquiridora.
A continuacin se enumeran las ventajas e inconvenientes de utilizar componentes COTS
en lugar de componentes desarrollados en la propia empresa.
Ventajas
- Menor coste de desarrollo: Una de las ventajas ms claras es el factor econmico,
relacionado con el coste de desarrollo. Puede ser mucho ms barato comprar un
producto comercial, donde el coste de desarrollo ha sido amortizado por muchos
clientes, que intentar desarrollar una nueva pieza software.
- Mayor fiabilidad: El hecho de que un componente COTS haya sido probado y
validado por el proveedor y por otros usuarios del componente en el mercado, suele
hacer que sea aceptado como un producto mejor diseado y fiable que los
componentes construidos por uno mismo.
- Mejor integracin: Otra ventaja es que el uso de un producto comercial permite
integrar nuevas tecnologas y nuevos estndares ms fcilmente y rpidamente que
si se construye por la propia organizacin.
Desventajas
- Bajo control de especificaciones y riesgo: Los desarrolladores que han adquirido
un componente comercial no tienen posibilidad de acceso al cdigo fuente para
modificar la funcionalidad del componente. Esto significa que en las fases de
anlisis, diseo, implementacin y pruebas, el componente es tratado como un
componente de caja negra, y esto puede acarrear ciertos inconvenientes para el
desarrollador, como por ejemplo no saber cmo detectar y proceder en caso de
fallos; o que el sistema requiera un nivel de seguridad no disponible en el
componente.

- Continua actualizacin de los componentes: Los productos comerciales (COTS)
estn en continua evolucin. El fabricante incorpora nuevas mejoras al producto y se
lo ofrece a sus clientes (por contrato, licencia o libre distribucin). Sin embargo, de
cara al cliente desarrollador, reemplazar un componente por uno actualizado puede
ser una tarea laboriosa e intensiva: el componente y el sistema deben pasar de
nuevo unas pruebas (en el lado cliente).
- Falta de especificaciones claras: Otra gran desventaja es que, por regla general,
los componentes COTS se usan como partes ensamblables en la construccin de
sistemas, en lugar de considerarlos nicamente como programas finales de usuario.
Por este motivo los desarrolladores de componentes COTS se estn interesando en
disponer de especificaciones estandarizadas para sus productos ya que estos no
suelen tener asociados ninguna especificacin de sus interfaces, ni de
comportamiento, de los protocolos de interaccin con otros componentes, de los
atributos de calidad de servicio, y otras caractersticas que lo identifiquen. En
algunos casos, las especificaciones que ofrece el fabricante de componentes COTS
puede que no sean siempre correctas, o que sean incompletas, o que no sigan un
formato estndar. Otras veces, aunque el proveedor de componentes COTS
proporcione una descripcin funcional del componente, puede que no satisfaga las
necesidades del integrador quien quizs necesita conocer ms detalles del
comportamiento o de los requisitos del componente. Adems, la falta de informacin
de especificacin puede acarrear ciertos problemas al desarrollador que utiliza el
componente COTS, como por ejemplo la imposibilidad de estudiar la compatibilidad,
la interoperabilidad o la trazabilidad de los componentes durante el desarrollo del
sistema basado en componentes.
Otros conceptos clave para entender los procesos de la gestin de adquisiciones son:
Plan de gestin de adquisiciones
Describe cmo sern gestionados los procesos de adquisicin, desde el desarrollo de la
documentacin de adquisicin hasta el cierre del contrato.
Documentacin de la adquisicin
Los documentos de la adquisicin se usan para pedir propuestas a los potenciales
proveedores.
Los nombres ms comunes de los distintos tipos de documentos de la adquisicin son:
invitacin a licitacin, solicitud de propuesta, solicitud de presupuesto, aviso de oferta,
invitacin a la negociacin y respuesta inicial del contratista.
o Los trminos licitacin, oferta o presupuesto generalmente se usan cuando la
decisin de seleccin del proveedor se basa en el precio.
o El trmino propuesta se usa generalmente cuando son ms importantes otras
consideraciones como habilidades o enfoques tcnicos.

Propuesta
Documento preparado por el proveedor que describe su capacidad y disposicin para
suministrar los productos, servicios o resultados solicitados descritos en la documentacin
de la adquisicin.
Contrato
Es un acuerdo vinculante entre un adquiridor (comprador) y un proveedor (vendedor) en
virtud del cual el proveedor se obliga a proveer los productos, servicios o resultados
especificados, y el adquiridor se obliga a proporcionar dinero u otra contraprestacin vlida.
Un contrato es un vnculo legal sujeto a resolucin en los juzgados.
o Es responsabilidad del equipo de direccin del proyecto ayudar a adaptar el
contrato a las necesidades especficas del proyecto.
o La mayora de las organizaciones cuentan con polticas y procedimientos
documentados que definen especficamente quin puede firmar y administrar
dichos acuerdos en nombre de la organizacin
Declaracin del trabajo del contrato
Describe el producto o servicio a adquirir con suficiente detalle como para permitir que los
potenciales proveedores determinen si podrn suministrar el producto o servicio.
La informacin contenida en la declaracin del trabajo del contrato puede incluir: las
especificaciones, la cantidad deseada, los niveles de calidad, los datos de rendimiento, el
lugar de trabajo y otros requisitos.
Alcance del proyecto
Describe los lmites, requisitos, restricciones y suposiciones del proyecto relacionados con el
alcance del proyecto.
o Proporciona informacin importante sobre las necesidades y estrategias del
proyecto.
o Proporciona la lista de productos entregables y criterios de aceptacin para el
proyecto y sus productos, servicios y resultados.
Estructura de desglose del trabajo
Proporciona la relacin entre todos los componentes del proyecto y los productos
entregables del proyecto.
Plan de gestin del contrato
Para adquisiciones significativas, se prepara un plan para administrar el contrato basndose
en los temas especficos determinados por el adquiridor dentro del contrato.
1.2. MEJORES PRCTICAS
Todas las compaas, tanto grandes como PYMES, pueden desarrollar y llevar a cabo
mejores prcticas en la adquisicin para obtener ventaja competitiva. La clave es cmo

conseguir el mximo valor de la adquisicin en una industria y una posicin de mercado
especfica, definir un plan para alcanzarlo y ejecutar, de manera efectiva, el plan. La parte
de la ejecucin es, quiz, la ms difcil y dnde muchas compaas fallan por diversas
razones.
Desarrollar y llevar a cabo mejores prcticas en la adquisicin no siempre es fcil. Consume
mucho tiempo, supone romper barreras entre los grupos internos, demanda un nuevo
enfoque para los proveedores y requiere una inversin significativa reas como: personas,
formacin, anlisis, medicin, tecnologa o proveedores. Sin embargo, el retorno que tiene
esta inversin a largo plazo es normalmente muy elevado.
Una cosa que debemos tener en cuenta es que no hay dos compaas iguales, no hay un
enfoque nico acerca de las mejores prcticas de adquisicin. Por ejemplo, una compaa
que desarrolle un producto bsico puede seguir una estrategia de gestin de adquisiciones
que potencie el bajo coste, mientras que una compaa que realice productos de alta
tecnologa puede seguir una estrategia de adquisiciones que potencie el desarrollo de la
tecnologa y la rapidez de puesta en el mercado. En definitiva, cada compaa tiene unas
fortalezas y debilidades nicas y la direccin tiene que determinar cul es la mejor estrategia
de adquisicin, que determinar los objetivos para el desarrollo y utilizacin de mejores
prcticas.
A pesar de las diferencias que existen entre distintas compaas, hay algunos factores que
normalmente siempre estn presentes cuando una organizacin lleva a cabo con xito la
gestin de adquisiciones. Estos factores incluyen:
- Soporte activo desde la direccin: las compaas que llevan a cabo mejores
prcticas tienen ejecutivos que reconocen el valor que reside en la gestin de
adquisiciones y soportan de manera activa los esfuerzos que conlleva.
- Entendimiento de los costes: muchas compaas no son capaces de gestionar sus
costes y qu es lo que los provoca. Las compaas que realizan mejores prcticas
conocen en detalle la estructura de sus costes y toman acciones orientadas a la
reduccin de costes. De manera regular, recogen y analizan datos acerca de los
costes de los proveedores.
- Relaciones cooperativas con proveedores: las compaas reconocen que los
proveedores aportan un valor que no est presente en sus compaas. Estas
compaas integran a sus proveedores estratgicos en los programas que requieren
adquisiciones y tambin entienden que los proveedores deben obtener un margen de
beneficio para cumplir sus planes de negocio y poder invertir en nuevas tecnologas,
equipamiento y personas cualificadas.
- Cultura de mejora continua: las organizaciones que realizan buenas prcticas en la
gestin de adquisiciones no lo hacen en esta rea de forma aislada sino que, a todos
los niveles, buscan el aprendizaje y mejora continua en sus procesos y sus prcticas.
- Enfoque multi-funcin: para alcanzar un nivel ptimo, la gestin de adquisiciones
no debe incluir solamente al grupo de adquisiciones sino a otras funciones de la
organizacin que pueden aadir valor a travs de la interaccin con proveedores.

- Valoracin de tecnologas avanzadas de comunicacin: la tecnologa por si sola
no va a hacer nada por mejorar las operaciones de gestin de adquisiciones. Muchas
organizaciones creen que el uso de la tecnologa en las adquisiciones es, en s
mismo, una mejor prctica. Estas compaas no entienden que la tecnologa no
aporta valor si no forma parte de una estrategia de adquisiciones. La tecnologa es
una herramienta, no una estrategia. Cuando la tecnologa no se utiliza
adecuadamente, puede ser perjudicial para las operaciones de adquisiciones.
- Inversin en gestin de adquisiciones: la inversin en ciertos factores como
formacin, tecnologas y comunicaciones no conduce, de forma automtica, al
desarrollo de mejores prcticas en la gestin de adquisiciones. Sin embargo, entre
las organizaciones que tienen mejores prcticas de gestin de adquisiciones, es
difcil encontrar una compaa que no muestre alguno de estos rasgos.
Quiz el factor ms importante para maximizar el valor de la adquisicin es el soporte activo
desde la direccin. Este soporte no quiere decir necesariamente una implicacin de la
ejecutiva en las operaciones del da a da, sin embargo, es muy importante que la direccin:
- Entienda el valor de la adquisicin para el xito de la organizacin.
- Reclute y/o desarrolle el mejor talento disponible para la gestin de adquisiciones.
- Proporcione la financiacin necesaria para la gestin de adquisiciones.
- Muestre al personal que estn comprometidos con la excelencia en la gestin de
adquisiciones.
- Interacte con sus homlogos en las organizaciones de los proveedores clave de
manera peridica.
Sin soporte por parte de la direccin, una compaa no va a ser capaz de desarrollar y
ejecutar mejores prcticas. Con el soporte necesario y la consiguiente inversin en las
operaciones de gestin de adquisiciones, los otros elementos necesarios para el xito
vendrn como consecuencia de estos.
Otro factor importante para la realizacin de mejores prcticas es el desarrollo y uso de
metodologas y sistemas para medir el rendimiento de los proveedores, los sistemas y los
empleados. La medicin del rendimiento va de la mano de la mejora continua. Sin un
sistema de medicin formal y consistente, no se puede saber si se ha mejorado.
El enfoque tradicional con respecto a los proveedores estaba basado en precio, resultando
superficial y a corto plazo. Hoy, los gestores de adquisiciones ms innovadores se dan
cuenta de que, una vez que han seleccionado a los mejores proveedores, la cooperacin
mutua puede compensar tanto a cliente como a proveedor. El precio de compra slo es un
elemento ms del coste total y es crtico establecer programas de mejora continua con los
proveedores estratgicos.
Una clave en este proceso es seleccionar a los proveedores correctos. La importancia de la
seleccin de proveedores y las relaciones con los mismos es clave para el xito a largo
plazo.

La gestin y reduccin de costes es uno de los principales objetivos de las adquisiciones.
Muchas organizaciones confunden la reduccin de costes con la reduccin del precio de
compra, cuando hay una gran diferencia entre estos aspectos. El precio de compra es la
cantidad de dinero que se paga por un producto o servicio. El coste total es la suma de todo
el dinero gastado en realizar una accin especfica, incluye el precio de compra ms el coste
del resto de actividades necesarias para llevar a cabo esa accin.
Las compaas que realizan mejores prcticas en la reduccin de costes normalmente
trabajan conjuntamente con los proveedores para examinar todos los procesos involucrados
en ambas compaas e intentar reducir costes.
Para ayudar a los profesionales de la gestin de adquisiciones a comunicar sus ideas y
opiniones, el libro Strategic supply chain management: The five disciplines for top
performance propone responder a una serie de preguntas:
- Cules son los elementos clave en nuestra estrategia de negocio?
- Dada la estrategia de negocio, Cules son las principales implicaciones para la
gestin de adquisiciones?
- En qu necesitamos ser buenos? En qu necesitamos destacar?
- Cules son nuestras competencias principales?
- Nuestras prcticas estn alineadas con nuestra estrategia de gestin de
adquisiciones?
- Las mtricas que utilizamos contemplan el comportamiento que queremos tener?
- Los procesos de la gestin de adquisiciones son entendidos fcilmente por las
personas que los utilizan?
- Se han definido y documentado nuestras expectativas en relacin con los clientes y
con los proveedores?
- Tenemos tecnologas que soporten nuestra estrategia?
- El diseo de nuestra organizacin soporta la estrategia elegida por la empresa?

2. PROCESO DE GESTIN DE ADQUISICIONES
La gestin de adquisiciones en una empresa incluye una serie de procesos para la
adquisicin de productos o servicios, la gestin y administracin del contrato y la gestin de
de los cambios necesarios para administrar contratos u rdenes de compra. Tambin
comprende una buena seleccin y negociacin con los proveedores y un control de los
riesgos que puedan surgir durante el proceso de adquisicin. De todos estos puntos se
tratar en los siguientes apartados.
2.1. PLANIFICACIN DEL PROCESO DE ADQUISICIN
Durante el proceso de planificacin del proceso de adquisiciones se identificarn las
necesidades del proyecto que se puedan satisfacer de mejor forma comprando o
adquiriendo los productos, servicios o resultados fuera de la organizacin.
Uno de los puntos clave de esta fase del proceso ser considerar si es conveniente adquirir,
qu, cmo y cundo hacerlo. Para ello se deber definir la estrategia ms adecuada para la
eleccin de fuentes, se debern definir de forma clara los requisitos, se planificar el
proceso de la solicitud de oferta que se lanzar a los proveedores potenciales y se
desarrollarn una serie de criterios que ayudarn a evaluar a los proveedores de tal forma
que resulte ms fcil elegir al que ms convenga a la organizacin.
La siguiente tabla muestra las entradas y salidas a la fase de planificacin del proceso de
adquisicin y enumera algunas de las herramientas que se pueden utilizar para facilitar
llevar a cabo esta fase:
Tabla 1 Entradas, salidas y herramientas de la fase de planificacin
Entradas Salidas Herramientas y tcnicas
Factores ambientales de la
empresa.
Activos de los procesos de la
organizacin.
Enunciado del alcance del
proyecto.
Estructura de desglose del trabajo.
Plan de gestin del proyecto.
Registro de riesgos.
Acuerdos contractuales
relacionados con el riesgo.
Requisitos de recursos.
Cronograma del proyecto.
Estimacin de costes de las
actividades.
Lnea base de coste.
Plan de gestin de las
adquisiciones.
Enunciado del trabajo del
contrato.
Decisiones de fabricacin
directa o de compra.
Cambios solicitados.
Anlisis de
fabricacin directa o
compra.
J uicio de expertos.
Tipos de contrato.

2.1.1. Estrategia de seleccin de fuentes
Antes de planificar las adquisiciones habr que decidir qu enfoque seguir. Lo primero que
se debe hacer es tomar la decisin de desarrollar la solucin in-house o adquirir una
solucin proporcionada por un proveedor externo. Tras haber tomado esta decisin, ya se
entrara en el propio proceso de adquisicin.
Desarrollar una estrategia de seleccin de fuentes requiere tomar la decisin acerca de lo
que ms convenga para la empresa. Pocas compaas llevan a cabo evaluaciones para
decidirlo. Existen dos opciones, crear la solucin en la propia empresa, o comprar la
solucin a un proveedor externo. En ambas posturas hay pros y contras que deberan
investigarse y analizarse durante el proceso de seleccin de fuentes para ver cul es la que
ms conviene.
La estrategia de seleccin de fuentes comienza mediante la revisin de las funciones de
toda la organizacin para determinar cmo organizar las funciones que estn relacionadas
para conseguir el mximo beneficio. Esta revisin identifica aquellas tareas o funciones
de las que se puede obtener el mximo potencial pero que segn estn actualmente
llevadas a cabo no se consigue. El paso clave en el proceso de eleccin de fuentes es
definir de forma adecuada las funciones de la organizacin desde un principio para optimizar
el uso de herramientas y para mantener y mejorar el nivel de rendimiento o de servicios a un
coste reducido. Este proceso es continuo y puede tener distintos resultados dependiendo
de cmo se han definido las funciones.
Algunas observaciones a tener en cuenta son:
- Determinar el valor de negocio de las decisiones de seleccin de fuentes permite
implementar estrategias ms efectivas y aumentar la flexibilidad del negocio.
- Los directivos del negocio y los equipos de proyectos deberan formalizar un plan
que describa por qu y en qu debera basarse la seleccin de fuentes, incluso si la
respuesta fuera ninguna.
- Si no se contemplan los esfuerzos de cada aspecto del ciclo de vida del proceso de
outsourcing (desde el alineamiento con el negocio hasta la gestin de proveedores),
se tendr un gran riesgo de fallo.
- La competencia en la adquisicin de un producto es la mejor prctica para la
seleccin de proveedores.
- La firma del contrato es solo un punto en una larga lista de temas a tratar en las
negociaciones.
Algunas de las razones por las que seleccionar productos y servicios externos a la empresa
son:
- Falta de recursos o conocimientos internos: si no se tienen las capacidades
suficientes dentro de la compaa, se deben buscar en otro sitio.
- Acceso a habilidades y conocimientos especializados: se puede tener, por
ejemplo, una relacin con un proveedor de un servicio que necesitas.

- Innovacin: puede ser una oportunidad para buscar una nueva manera de hacer las
cosas.
- Acceso a tecnologa/inventos: la disponibilidad de las nuevas tecnologas puede
llevar a tomar la decisin de elegir outsourcing con el objetivo de estar a la cabeza
en el mercado.
- Ahorro en costes: previsibilidad. El outsourcing es a menudo un instrumento para
ahorrar dinero.
- Comparativa econmica: una compaa puede establecer criterios para establecer
cules de sus mejores prcticas deberan realizarse a travs de outsourcing.
- Expandir el negocio: la eficiencia de un buen proveedor puede permitir a un
negocio centrarse ms en sus propios productos o servicios, mejorando su calidad y
obteniendo ms ventaja competitiva.
- Transferencia de responsabilidad y de riesgo: apoyndose en proveedores
especializados en el servicio, el riesgo que acompaa al desarrollo dentro de la
propia empresa es transferido a un tercero que est mejor preparado para
gestionarlo.
- Beneficios de impuestos: transfiriendo un servicio a un proveedor, puede ser
posible la reduccin de tasas.
Existen distintos tipos de fuentes:
- Insourcing: se trata de utilizar los procesos de diferentes partes de la misma
organizacin.
- Co-sourcing: se trata de utilizar herramientas de terceras partes junto con recursos
de la propia compaa (personal de la empresa, sistemas, y capacidades de
servicio).
- Outsourcing: es el contrato temporal o a largo plazo con un proveedor externo.
- Reingeniera: es el rediseo de los procesos para mejorar la eficiencia y efectividad.
A lo largo de la gua se irn viendo los beneficios que reporta el adquirir un producto en vez
de desarrollarlo en la propia empresa. Una de las principales ventajas es la reduccin de
costes que supone, y esto es un factor importante, sobre todo si la compaa tiene
dificultades econmicas o presiones de presupuesto. La subcontratacin puede tambin ser
de utilidad para mejorar el servicio a los clientes y aumentar la eficiencia al poder
aprovechar las ventajas de las nuevas tecnologas.
Por otra parte, las transacciones con proveedores no deberan tomarse a la ligera ya que
conllevan establecer unos acuerdos comerciales muy complejos e invertir mucho tiempo y
esfuerzo para asegurar que los objetivos establecidos previamente se han conseguido.
Cuando una empresa elige seguir un enfoque basado en outsourcing, tras una evaluacin
de lo que ms le conviene en funcin de distintos factores, se debera plantear elegir entre
dos caminos: elegir un producto que ya est en el mercado listo para una distribucin
masiva o seleccionar un proveedor que desarrolle un producto o solucin a su medida.

2.1.2. Definicin de los requisitos
La calidad de los requisitos tiene un gran peso en el xito de los proyectos. Las actividades
de definicin de requisitos se plasmarn en un documento que ser la base funcional del
contrato y servir como gua para el diseo de una solucin.
Los beneficios de una definicin slida y detallada de los requisitos son:
- Obtener una mejor solucin
- Disminuir los costes
- Mejorar la implementacin y la adopcin de nuevos productos
Por otro lado, entre los inconvenientes de unos requisitos deficientes cabe sealar:
- Prdidas de tiempo
- Altos niveles de frustracin
- Una decisin para avanzar hacia la solucin incorrecta
- Otros fallos en el proyecto
En muchos casos, conseguir un alineamiento exacto con las especificaciones es imposible.
Con frecuencia se producir alguna desviacin en los requisitos, y la mejor salida posible
ser elegir lo que ms se ajuste o aproxime. En este caso el equipo de adquisicin
necesitar priorizar requisitos de tal forma que los criterios clave se cumplan.
En la siguiente tabla se dan algunas definiciones de los requisitos como parte del proceso
de adquisicin.
Tabla 2 Requisitos como parte del proceso de adquisicin
Requisitos en el proceso de adquisicin
La base para la solicitud de propuestas y de las respuestas
Un marco para guiar a la solucin apropiada
La base para asignar precios al proyecto
Un principio de negociacin del contrato
Un componente clave para comunicar los detalles de la solucin entre los involucrados en el negocio
Un componente de contrato o referencia crtica
La base del control de cambios
Los problemas que aparecen ms comnmente en relacin con los requisitos son:
- A menudo estn incompletos.
- La solucin puede presentarse desde el punto de vista de una persona en vez de
reflejar los requisitos reales.

- Hay una tendencia a apresurarse a dar una solucin y especificar respuestas a un
problema, en vez de describir primeramente la necesidad o el problema para ms
tarde buscar la solucin adecuada.
Durante el tiempo que duran una relacin o contrato con los proveedores, los requisitos
evolucionarn y las condiciones cambiarn. En la medida de lo posible, debera tenerse en
cuenta.
Aunque los requisitos deberan estar tan bien definidos para evitar interpretaciones errneas
en el diseo y elementos funcionales, tambin deberan permitir flexibilidad. Algunos
cambios son inevitables e imposibles de predecir con exactitud. Por ello se podran realizar
anlisis de tendencias y as identificar las reas que sean objeto de cambio como, por
ejemplo, procesos de negocio o entornos reguladores y tcnicos.
Requisitos estratgicos
El desarrollo de una solucin debera llevarse a cabo en funcin de:
Las expectativas que se tienen sobre el rendimiento.
El retorno de inversin.
Mejora de procesos.
Reduccin del coste.
Mitigacin de riesgos
Los requisitos exactos y completos son crticos en trminos de mitigacin de riesgos.
La necesidad de requisitos ms detallados aparece por el aumento de la sofisticacin de los
usuarios y clientes, por un aumento de las expectativas de productividad y flexibilidad y por
la implementacin de programas estratgicos. Estos requisitos detallados implican:
Gran entendimiento entre los involucrados en el negocio.
Habilidad para anticipar problemas culturales y tcnicos.
Comunicacin ms clara con los proveedores.
Reduccin del coste de la calidad y del re trabajo.
La direccin hacia la que apunte la estrategia de adquisicin de la compaa
probablemente influir sobre la prioridad de la funcionalidad, caractersticas, trminos y
condiciones. Por ejemplo, las compaas que persiguen una estrategia de adquisicin
agresiva valorarn el posicionamiento de la solucin en el mercado y su capacidad de
integracin, mientras que una compaa que tenga una determinada solucin
completamente integrada y adaptada valorar ms la potenciacin de las capacidades
existentes en cuanto a formacin, instalacin y soporte.
Los requisitos estratgicos clave estn a menudo expresados en los siguientes trminos:
- La solucin puede ser configurada para alinearse con los programas estratgicos?
- Se conseguir el objetivo del retorno de inversin (ROI)?

- La usabilidad y efectividad permitirn una adopcin fcil y minuciosa?
Las organizaciones deben utilizar mtodos efectivos para extraer y documentar los
requisitos. A continuacin se proponen algunos mtodos, que se pueden incluso combinar
para conseguirlo:
Tabla 3 Herramientas y tcnicas para establecer y validar requisitos
Herramientas y tcnicas para establecer y validar requisitos
Checklist de requisitos para asegurar que no se olvida ningn requisito.
Proceso de iniciacin robusto que incluya algn anlisis y aprobacin.
Cuestionarios. Estos son particularmente importantes para grupos de personas involucradas en el negocio que
estn ubicados en sitios geogrficamente alejados.
Entrevistas estructuradas y anlisis de usabilidad proporcionan un aumento en la granularidad de los
requisitos y en el entendimiento de los procesos.
Investigacin y comparativa para identificar mejores prcticas.
Plantillas, polticas y guas.
Prototipos para validar las suposiciones e interpretaciones de los requisitos.
2.1.3. Planificar el proceso de oferta
Una vez que la empresa tiene claro qu producto desea adquirir, podr comenzar a
planificar el proceso de oferta. Para obtener una buena respuesta a la oferta es importante
llevar a cabo unas actividades preliminares. Algunas buenas prcticas a seguir son:
Recoger tanta informacin como sea posible acerca de lo que se pretende obtener
como respuesta: los individuos involucrados, las necesidades del negocio y cualquier
presupuesto/coste/comparacin con el resto de respuestas anteriormente recibidas.
Investigar acerca de los proveedores potenciales en anuncios, publicaciones
peridicasincluso en ocasiones podra ser conveniente consultar a un experto en la
industria.
Estar cerca de los usuarios finales para identificar las necesidades de negocio que
estn intentando resolver y que constituyan el xito para ellos.
Para desarrollar la oferta del producto a adquirir, la empresa debera utilizar algn
documento que le sirviera como vehculo para llevar a cabo dicha oferta.
El objetivo de estos documentos es tratar de comunicar las necesidades de la empresa que
emite la oferta a los proveedores y el nivel de detalle de la solucin que espera recibir.
Pero, qu mtodo de solicitud es el adecuado? La respuesta depende del objetivo de la
empresa adquiridora. Hay distintos mtodos para obtener informacin de los proveedores.

- RFI (Request for information) Solicitud de informacin
- RFP (Request for proposal) Solicitud de propuesta
- RFQ (Request for quotation) Solicitud de presupuesto
- IFB (Invitation for Bid) - Solicitud para ofertar
Nota: Para evitar dar el nombre completo de cada uno de los documentos en algunas
ocasiones se utilizarn las siglas para hacer referencia a ellos.
A continuacin se va a describir brevemente en qu consiste cada uno de los mtodos. Para
ms informacin ir al Anexo I.
Solicitud de informacin (RFI)
La solicitud de informacin se utiliza para obtener informacin sobre productos, servicios o
proveedores. El RFI no vincula al adquiridor y al proveedor, ya que es un documento que
simplemente ayuda a recoger informacin antes de la toma de decisin de la empresa sobre
si desarrollar o adquirir la solucin. Normalmente a esta solicitud le siguen RFQ, RFP o IFB,
que realmente se utilizan durante el proceso de adquisicin del producto o solucin. El nivel
de formalidad de la solicitud RFI depende de la informacin que desea recibir la empresa
adquiridora (complejidad, cantidad, tipo de solucin.). En el Anexo I, donde se describe
ms en profundidad en qu consiste este tipo de solicitud, se hace referencia a los roles y el
formato que debera tener en el caso de que fuese una solicitud formal de informacin, pero
tambin hay que tener en cuenta que la empresa puede utilizar RFI para hacer una solicitud
informal de informacin.
Solicitud de propuesta (RFP)
Una vez que la empresa decide adquirir la solucin, debera investigar las distintas
soluciones que le ofrecen los distintos proveedores para tomar la decisin sobre qu
producto es el que ms le conviene. Es decir, RFP se utiliza cuando el adquiridor pide a los
proveedores que le recomienden soluciones a su problema. De esta forma el comprador
puede recoger informacin y negociar sin compromiso ninguno con el adquiridor para
finalmente adquirir su producto.
Al realizar este tipo de solicitud hay que tener en cuenta unas recomendaciones o pautas a
seguir para identificar al mejor proveedor, y por lo tanto, la mejor solucin. A continuacin se
proponen algunas:
- Igualdad en el trato a los proveedores: se debera proporcionar la misma informacin
a todos los proveedores, si se le permite a un proveedor modificar su propuesta
debera permitirse a todos los proveedores hacerlo
- La empresa adquiridora puede negociar con cualquier proveedor en cualquier punto
que no est claro de la propuesta
- La empresa adquiridora puede considerar pagar o compensar de alguna manera a
todos los proveedores que respondieran a la solicitud de propuesta por su tiempo e
ideas

En el Anexo I se pueden encontrar ms recomendaciones acerca de la propuesta de
solicitud.
Solicitud de presupuesto (RFQ)
RFQ o solicitud de presupuesto es utilizado para establecer compromisos con los
proveedores acerca de fijacin de precios, hitos de entrega, cantidad, servicios y calidad de
los productos. La respuesta al documento FRQ debe responder a los requisitos exigidos por
la empresa adquiridora, aunque por otra parte, este documento no obliga a que dicha
empresa adquiera ese producto. Es decir, el adquiridor es libre de negociar con los
proveedores que quiera pero el proveedor est atado por el presupuesto que establezca en
la solicitud. El uso de RFQ slo asegura que el adquiridor paga el precio ms bajo entre los
proveedores que responden a la solicitud de presupuesto, no asegura el precio ms bajo
posible.
Solicitud para ofertar (IFB)
Esta solicitud proporciona igualdad a todos los proveedores a la hora de realizar su mejor
oferta. IFB debera utilizarse slo si las especificaciones del producto estn perfectamente
definidas, el presupuesto a invertir para el desarrollo de la solucin es significativo y uno de
los mtodos anteriores no es adecuado. Este documento compromete tanto al adquiridor
como al proveedor ya que el proceso de oferta es muy formal y costoso para ambas partes,
por lo que IFB debera ser utilizado slo cuando ninguno de los otros mtodos pueda
proporcionar la informacin necesaria.
La siguiente tabla trata de comparar los distintos mtodos de solicitud descritos.

Tabla 4 Comparticin de los mtodos de solicitud
C
o
n
t
r
a
s

R
e
q
u
i
e
r
e

R
F
Q

o

I
F
B

S
i

l
a

s
o
l
i
c
i
t
u
d

n
o

e
s
t

b
i
e
n

p
r
e
p
a
r
a
d
a
,

l
a
s

o
f
e
r
t
a
s

n
o

p
u
e
d
e
n

s
e
r

c
o
m
p
a
r
a
d
a
s

S
i

s
e

p
e
r
m
i
t
e

a

u
n

p
r
o
v
e
e
d
o
r

r
e
v
i
s
a
r

u
n
a

p
r
o
p
u
e
s
t
a
,

d
e
b
e

p
e
r
m
i
t
r
s
e
l
o

a

t
o
d
o
s

P
r
e
f
e
r
i
b
l
e

u
t
i
l
i
z
a
r

o
t
r
o
s

m
t
o
d
o
s

q
u
e

p
e
r
m
i
t
a
n

m
s

f
l
e
x
i
b
i
l
i
d
a
d

a
l

c
o
m
p
r
a
d
o
r

P
r
o
s

F
c
i
l
,

r
p
i
d
o

(
e
n

f
u
n
c
i
n

d
e

l
o
s

d
e
s
e
o

d
e

l
a

e
m
p
r
e
s
a
)

E
l

c
o
m
p
r
a
d
o
s

p
u
e
d
e

n
e
g
o
c
i
a
r

t
o
d
o
s

l
o
s

a
s
p
e
c
t
o
s

m
i
e
n
t
r
a
s

q
u
e

e
l

p
r
o
v
e
e
d
o
r
e
s

e
s
t

a
t
a
d
o

a
l

p
r
e
s
u
p
u
e
s
t
o

E
l

c
o
m
p
r
a
d
o

p
u
e
d
e

n
e
g
o
c
i
a
r

c
o
n

u
n
o

o

t
o
d
o
s

l
o
s

p
r
o
v
e
e
d
o
r
e
s

e
n

c
u
a
l
q
u
i
e
r

p
u
n
t
o

d
e

l
a
s

p
r
o
p
u
e
s
t
a
s

P
r
o
c
e
s
o

f
o
r
m
a
l

q
u
e

p
e
r
m
i
t
e

c
o
m
p
a
r
a
r

e
n
t
r
e

o
f
e
r
t
a
s

y

d
o
c
u
m
e
n
t
a
c
i
n

d
e
l

p
r
o
c
e
s
o

R
e
s
u
l
t
a
d
o

C
a
t
l
o
g
o
s
,

p
r
e
c
i
o
s
,

l
i
s
t
a
s

y

f
o
l
l
e
t
o
s

O
f
e
r
t
a
s

e
s
p
e
c
i
f
i
c
a
s

q
u
e

p
u
e
d
e
n

s
e
r

c
o
m
p
a
r
a
d
a
s

e
n
t
r
e

p
r
o
v
e
e
d
o
r
e
s

U
n
a

v
a
r
i
e
d
a
d

d
e

s
o
l
u
c
i
o
n
e
s

p
o
t
e
n
c
i
a
l
e
s

d
e

e
n
t
r
e

l
a
s

q
u
e

e
l
e
g
i
r

M
e
j
o
r

o
f
e
r
t
a

f
i
n
a
l

F
l
e
x
i
b
i
l
i
d
a
d

N
o

v
i
n
c
u
l
a
n
t
e

F
o
r
m
a
l
,

d
i
r
i
g
i
d
o

a

r
e
q
u
i
s
i
t
o
s

e
s
p
e
c
f
i
c
o
s

P
e
r
m
i
t
e

n
e
g
o
c
i
a
r

y

r
e
c
o
g
e
r

i
n
f
o
r
m
a
c
i
n

s
i
n

c
o
m
p
r
o
m
e
t
e
r
s
e

a

l
a

c
o
m
p
r
a

h
a
s
t
a

q
u
e

s
e

h
a
y
a

i
d
e
n
t
i
f
i
c
a
d
o

l
a

m
e
j
o
r

f
u
e
n
t
e

V
i
n
c
u
l
a

t
a
n
t
o

a
l

p
r
o
v
e
e
d
o
r

c
o
m
o

a
l

c
o
m
p
r
a
d
o
r

C
u
a
n
d
o

u
s
a
r
l
o

A
n
t
e
s

d
e

l
a

e
s
p
e
c
i
f
i
c
a
c
i
n

d
e

r
e
q
u
i
s
i
t
o
s

C
u
a
n
d
o

l
o
s

e
l
e
m
e
n
t
o
s

o

s
e
r
v
i
c
i
o
s

d
e
s
e
a
d
o
s

s
o
n

c
o
n
o
c
i
d
o
s

C
u
a
n
d
o

e
l

c
o
m
p
r
a
d
o
r

n
o

e
s
t

s
e
g
u
r
o

d
e

p
r
o
c
e
s
o
s
,

c
a
l
i
d
a
d
,

s
e
r
v
i
c
i
o
s

P
a
r
a

e
l
e
m
e
n
t
o
s

c
o
n

u
n

p
r
e
c
i
o

e
l
e
v
a
d
o

o

c
u
a
n
d
o

h
a
y

p
r
u
e
b
a
s

d
e

p
r
e
c
i
o
s

m
e
n
o
r
e
s

P
r
o
p
s
i
t
o

O
b
t
e
n
e
r

i
n
f
o
r
m
a
c
i
n

d
e

l
o
s

p
r
o
d
u
c
t
o
s
,

s
e
r
v
i
c
i
o
s

y

p
r
o
v
e
e
d
o
r
e
s

O
b
t
e
n
e
r

c
o
m
p
r
o
m
i
s
o

d
e

p
r
o
v
e
e
d
o
r
e
s

s
o
b
r
e

e
l
e
m
e
n
t
o
s

o

s
e
r
v
i
c
i
o
s

e
s
p
e
c
f
i
c
o
s

O
b
t
e
n
e
r

s
u
g
e
r
e
n
c
i
a
s

d
e

l
o
s

p
r
o
v
e
e
d
o
r
e
s

p
a
r
a

c
o
n
s
e
g
u
i
r

l
a

m
e
j
o
r

s
o
l
u
c
i
n

p
a
r
a

u
n
o
s

d
e
t
e
r
m
i
n
a
d
o
s

r
e
q
u
i
s
i
t
o
s

P
r
o
p
o
r
c
i
o
n
a
r

u
n
a

o
p
o
r
t
u
n
i
d
a
d

i
g
u
a
l

a

t
o
d
o
s

l
o
s

p
r
o
v
e
e
d
o
r
e
s

d
e

h
a
c
e
r

s
u

m
e
j
o
r

o
f
e
r
t
a

T
i
p
o

d
e

s
o
l
i
c
i
t
u
d

R
I
F

R
F
Q

R
F
P

I
F
B


Buenas prcticas
A continuacin se describen algunas buenas prcticas para desarrollar los documentos de
solicitud:
- Desarrollar un estndar para utilizar en el futuro, de tal forma que las solicitudes
cumplan ese formato pre establecido.
- No sobrecargar las solicitudes con informacin superflua o con informacin que sea
relevante solamente para los proveedores que queden finalistas en la seleccin.
- No desanimar a las empresas poniendo el listn muy alto en la oferta, ni obligando a
que los proveedores tengan gran cantidad de trabajo de antemano.
- Incluir trminos y condiciones contractuales que sean estndares a la compaa en
un apndice, aunque no se debera pedir a los proveedores que respondan
directamente a estos trminos y condiciones en la primera ronda de la oferta. El
propsito de esta prctica simplemente es dar a conocer el lenguaje que se pretende
que se use durante la transaccin.
- Disponer de una persona en la compaa que revisase el documento de solicitud (el
que sea), y que sea ajena a la adquisicin que se quiere llevar a cabo. Si esa
persona puede identificar las afirmaciones con ms valor de la oferta, se estar
haciendo un buen trabajo.
- Entender que el proveedor sentir presin al responder a la oferta.
- Establecer unos hitos de entrega de respuestas a la oferta.
- Realizar estudios o encuestas para calcular cuntos proveedores respondern a la
oferta. De esta manera se tendr un indicador sobre si la oferta ha cumplido el rango
de participacin esperado o si ser necesario enviarlo a ms proveedores.
- Intentar ponerse en el lugar de los proveedores y preguntarse qu tipo de preguntas
e indicaciones seran necesarias para que los proveedores contestaran
correctamente.
- Tener claro que muchos proveedores posiblemente tengan un equipo de respuestas
de ofertas que estn acostumbrados a obtener documentos de oferta estndar y que
esperan recibir ese tipo de informacin.
2.1.4. Desarrollo de criterios de evaluacin
Las compaas a menudo tienen distintas opciones entre las cuales elegir la solucin que
mejor se ajuste a sus condiciones y que mejor satisfaga sus necesidades. Pero, cmo
decidirse entre ellas?, cules son los criterios de evaluacin clave? La empresa deber
establecer un marco de evaluacin previo a la eleccin de la solucin, para facilitar esta
tarea. La empresa adquiridora deber tener en cuenta aspectos tales como el ROI (retorno
de inversin), el coste de la solucin, el riesgo de la adquisicin, su longevidad.

El equipo del proyecto debera establecer un proceso de evaluacin para hacer una
eleccin efectiva de la mejor solucin. Un proceso de evaluacin robusto satisface varias
necesidades crticas como:
- Ayuda a definir el rango de opciones a considerar.
- Proporciona las bases para realizar la seleccin entre los distintos proveedores.
- Crea los cimientos para la toma de mtricas.
- Sirve como base para finalizar una relacin o evaluar el cambio de proveedor.
Los beneficios adicionales de un proceso de evaluacin efectivo son:
- Proporciona consenso sobre la salida de la evaluacin.
- Permite el alineamiento con los objetivos de la compaa.
- Minimiza los riesgos.
- Acelera el proceso de evaluacin.
El desarrollo de un modelo y proceso de evaluacin organizacional es clave a la hora
de asegurar consistencia y consenso en el resultado de la evaluacin. Este modelo
organizacional debera ser apoyado, aunque no dirigido, por altos ejecutivos. El modelo
debera vincular la estrategia de la unidad de negocio y de la empresa. Todo esto se podra
simplificar si la empresa tuviese una estrategia ya establecida o una metodologa de
mtricas de rendimiento. La experiencia ha probado que para que el modelo sea efectivo, el
proceso debera incluir una amplia representacin de las personas involucradas en el
negocio.
Un modelo de la empresa podra funcionar para adquisiciones estratgicas pero no tendra
suficiente granularidad para la mayora de las evaluaciones. El equipo del proyecto debe
pues desarrollar un conjunto de criterios adaptados a cada adquisicin del proyecto. El
equipo del proyecto servir como marco para el modelo de evaluacin especfico del
proyecto, definiendo los elementos de gua que aseguren el alineamiento con la misin y la
estrategia. A nivel de proyecto, los responsables del equipo debern facilitar el debate
acerca de los criterios especficos, incluyendo a todos los involucrados en el negocio en la
discusin.
La falta de un modelo tambin fomenta el riesgo de que distintos modelos especficos de los
proyectos reflejen diferentes perspectivas organizacionales, y por lo tanto, no permitan el
soporte de la estrategia. Una vez que el modelo se haya establecido, sera apropiado
comunicar los criterios a los candidatos de tal forma que puedan responder
directamente.
Retos
Seleccionar criterios de evaluacin no es una tarea sencilla. A menos que un proyecto
impacte slo sobre un pequeo grupo de personas involucradas en el negocio, el
desacuerdo sobre el criterio ser casi un hecho. Desarrollar un amplio rango de criterios es
algo esencial para llegar a un consenso. En algunos casos, diferentes grupos de personas

insistirn en utilizar criterios o palabras especficas, resultando as en dos versiones del
mismo criterio.
Una vez que se alcanza el acuerdo final acerca de los criterios, se llevar a cabo una nueva
ronda de discusiones para determinar qu criterios deberan tener mayor prioridad al evaluar
a los proveedores, ya que inevitablemente habr criterios en conflicto. En algunos casos,
esto reflejar las necesidades e intereses de los distintos grupos de personas involucradas
en el proyecto. Por ejemplo, puede aparecer el dilema de seguir con el estndar corporativo
o aprobar el del proveedor, intentando seguir siempre la mejor alternativa.
Priorizar las categoras de criterios de alto nivel permitir a los jefes de proyecto enfatizar los
elementos ms crticos. Priorizando las categoras de alto nivel de la forma adecuada,
proporcionar un factor apropiado y una amplia evidencia del foco estratgico.
Una regla comn en el desarrollo del software es que se pueden elegir dos de las siguientes
prioridades: velocidad, calidad, coste.
Un proveedor puede entregar un producto rpidamente y a bajo coste, sacrificando
caractersticas o calidad. Si el foco es la calidad, entonces los costes aumentarn
necesariamente, y as sucesivamente. La resolucin de estos conflictos se basa en la
construccin de un conjunto equilibrado de criterios de aceptacin.
Imaginemos la posibilidad de que no haya una solucin adecuada. Mientras que se hace
evidente, es importante que el equipo de trabajo se anticipe y desarrolle una solucin dentro
del marco de evaluacin. El criterio de evaluacin dirigir el rango de alternativas.
2.1.4.1. Criterios de evaluacin de producto
En las adquisiciones de producto, se tienen en cuenta ciertas dimensiones relacionadas con
lo que hace y lo que cuesta el producto. Las caractersticas son nicas para cada
adquisicin. Los criterios de evaluacin funcionales deberan estar orientados a los
requisitos. Los criterios funcionales abarcan elementos tcnicos, culturales y de negocio, y
los productos son evaluados en funcin del grado en el que se acercan a cada elemento.
Evaluando los productos es improbable que haya una combinacin perfecta.
Coste
En aquellos productos que requieran un esfuerzo importante en la planificacin e
implementacin, habra que considerar de forma prioritaria el tiempo y coste. El coste de la
compra inicial puede ser completado rpidamente con tasas en consultas, coste de
construccin, soporte de implementacin, tasas, prdida de productividad durante la
implementacin, y los costes de deshabilitar la anterior solucin.
Normalmente hay costes inesperados o enmascarados, como por ejemplo, interrupcin del
servicio, costes asociados al control de cambios, gestin de relaciones y comunicaciones
con las personas involucradas en el negocio.
Slo despus de anticiparse y calcular los costes de implementacin, ser posible llevar a
cabo una evaluacin financiera efectiva. Un producto que tenga un precio de compra bajo
puede de hecho ser ms caro que otras alternativas.

Coste total de propiedad
Una mtrica financiera utilizada comnmente en compras relacionadas con la tecnologa de
la informacin es el coste total de la propiedad (TOC), sobre la vida del activo. Para la
evaluacin, los costes son divididos en costes a corto, medio y largo plazo. Los costes a
corto plazo pueden incluir costes de licencia, de hardware, de consultoras, formacin,
recursos internos y gastos relacionados con equipos (hardware, herramientas especiales).
Los costes a medio plazo incluyen temas de administracin, el impacto potencial sobre otras
licencias y acuerdos, y el efecto sobre la plantilla de recursos humanos. Los costes a largo
plazo incluyen costes asociados a actualizaciones, el coste de la migracin y la retirada de
activos.
Permanencia del proveedor
Uno de los grandes miedos es si el proveedor permanecer en el negocio el tiempo
suficiente como para soportar el producto durante su vida til. Las compaas tecnolgicas
parecen ser las ms voltiles en este aspecto.
La duracin o permanencia del proveedor no implica necesariamente la duracin del
producto. Los proveedores a menudo tienen claras las estrategias del producto, y es
importante ser conscientes de esto. Ellos pueden planear realizar mejoras sobre un producto
que haya sido vendido recientemente, dar soporte a una versin o incluso retirar un producto
con el objetivo de conseguir lneas de producto ms exitosas.
Riesgo
El riesgo puede afectar a muchas categoras, incluyendo riesgo de estrategias tcnicas y
riesgos financieros. Los riesgos tcnicos pueden reflejar escalabilidad, seguridad, habilidad
de integrar el producto con tus procesos, y la habilidad de las fuentes internas o externas de
implementar y mantener el soporte del producto.
Fiabilidad
La fiabilidad puede tener un gran impacto en el retorno de inversin. Los costes asociados
con los productos que no son fiables son mayores que el coste de reparar y mantener, y el
simple coste de productividad perdida.
Los criterios de evaluacin de fiabilidad pueden incluir la disponibilidad de soluciones para
dirigir la fiabilidad, al igual que el rendimiento del propio producto. Algunos criterios de las
soluciones incluyen disponibilidad de la redundancia de los sistemas, capacidad de realizar
copias de seguridad y arquitectura bsica del sistema.
2.1.4.2. Criterios de evaluacin del servicio
Cuando hemos hablado de adquisicin, no slo hay que evaluar el producto que se va a
adquirir sino tambin los servicios relacionados. Muchos de los criterios de productos
pueden aplicarse en este caso, especialmente a elementos financieros. Sin embargo, hay
dimensiones adicionales a tener en cuenta.

Durante el proceso de negocio de outsourcing, hay temas complejos relacionados con
responsabilidades y con los acuerdos de nivel de servicio que no hay que olvidar. Incluso el
enfoque de negociacin debera considerarse como un importante criterio de evaluacin.
Responsabilidad
Las actividades que dan soporte a la entrega de servicios pueden incluir gestin de
proyectos, rendimiento de mtricas y otras formas de soporte como la formacin. Todos los
elementos son crticos para el xito de la entrega de servicios. Sin embargo, los
proveedores tendrn fortalezas y debilidades en estas reas que impactarn en los costes.
Los criterios de evaluacin incluirn el alcance de estos servicios de soporte, al igual que la
habilidad de los proveedores para realizar las tareas de forma efectiva. Asimismo, incluirn
el grado con el que los proveedores garantizan las tasas de adopcin, el retorno de
inversin, entrega a tiempo, integracin exitosa con otros sistemas.
Acuerdos de nivel de servicio
Mientras que las expectativas de nivel de servicio pueden especificarse en los requisitos, los
proveedores respondern con varios niveles de capacidad y coste. Los criterios de
evaluacin de nivel de servicio pueden incluir flexibilidad, volumen, disponibilidad, niveles de
habilidad y tiempos de respuesta.
Trminos y condiciones
Los criterios de evaluacin deberan incluir trminos y elementos del contrato como:
- Claridad y alcance de servicios y entregables.
- Procedimientos y responsabilidades de control de cambios.
- Procesos de entrega, inspeccin, aceptacin y rechazo.
- Calidad y enfoque para la gestin de proyectos.
- Provisiones de administracin del contrato.
- Hitos y trminos de pago.
- Previsiones para finalizacin del acuerdo y sus implicaciones.
2.1.4.3. Criterios intangibles
La evaluacin debera incluir tambin criterios intangibles, es decir, aquellos que son difciles
de medir y verificar y que tienen ms que ver con las relaciones que con los contratos
especficos. Estos incluyen:
- Confianza
- Recursos
- Flexibilidad
- Entendimiento
- Idoneidad

- Calidad de las referencias
Debido a que no hay estndares ni mtricas para estos criterios, el rendimiento en funcin
de los mismos es algo relativo.
2.2. SOLICITUD DE RESPUESTA A PROVEEDORES
Una vez realizada la planificacin del proceso de adquisiciones se procede a solicitar las
respuestas de los proveedores. Para ello es importante seguir unas buenas prcticas y
prepararse para la gestin de todo el proceso de ofertas, planificando la forma en la que se
van a gestionar las posibles preguntas que se reciban de los proveedores en potencia.
Tabla 5 Entradas, salidas y herramientas de la solicitud de respuesta a proveedores
organizacin.
adquisiciones.
Documentos de la adquisicin.
Lista de vendedores calificados.
Paquete de documentos de la
adquisicin.
Propuestas.
Conferencias de los
oferentes.
Publicidad.
Desarrollar lista de
vendedores calificados.
2.2.1. Buenas prcticas
Antes de enviar a los proveedores el documento de oferta, es decir, antes de solicitar la
respuesta de los proveedores, sera apropiado pararse a pensar en el proceso de
puntuacin que se va a seguir. De esta forma se podra solicitar en la oferta aquella
informacin que facilite la futura evaluacin y seleccin de proveedores.
La matriz de puntuacin puede desarrollarse despus de enviar el documento de oferta,
pero deberan tenerse las ideas claras acerca de los elementos que van aparecer en la
matriz, es decir, de los elementos que van a tenerse en cuenta a la hora de puntuar a los
proveedores. La matriz se utilizar para hacer distintas rondas de seleccin de proveedores,
hasta elegir al ltimo y definitivo proveedor. De la seleccin de proveedores se hablar en el
siguiente apartado.
Al realizar la gestin de documentos de oferta habra que separar claramente:
- Evaluacin de requisitos.
- Evaluacin de costes.
Respecto a la evaluacin de requisitos, sera necesario tener los requisitos priorizados para
facilitar la evaluacin. Tambin se debe tener en cuenta que no todos los requisitos deberan
ser crticos, ya que en este caso sera difcil diferenciar a los distintos proveedores.
En cuanto a la evaluacin de costes, es de gran ayuda invertir tiempo en desarrollar una
hoja de clculo de costes para conseguir la respuesta deseada de los proveedores y facilitar
la comparacin entre las distintas respuestas.

Es importante impedir que los proveedores proporcionen las respuestas de costes en el
formato que ellos crean adecuado, ya que complicar el proceso de evaluacin interno y la
comparacin de precios. Sin embargo, si un proveedor identifica una categora de costes
que no ha sido incluida en la matriz de costes, sera necesario investigar cmo han
contemplado estos costes el resto de proveedores.
Todos estos temas han de quedar claros y deben ser comunicados a los proveedores para
que la respuesta obtenida de los mismos sea la deseada. Adems, los proveedores
deberan tener conocimiento de cmo la empresa les va a valorar. Esto es algo beneficioso
tanto para los proveedores como para la empresa adquiridora, ya que las ofertas que se
reciban tendrn el enfoque y la informacin que se necesita para evaluarlos. Por otra parte,
los proveedores no deberan tener conocimiento de la puntuacin del resto de proveedores
para evitar problemas y quejas por parte de aquellos no seleccionados.
Otra buena prctica a seguir es no revelar informacin innecesaria o competitiva, as
como proteger a los miembros del equipo de preguntas comprometidas o de quejas de los
proveedores.
2.2.2. Gestionar el proceso de ofertas
En este apartado se ver la forma de gestionar el proceso de ofertas. Primero se va a definir
la estructura interna que la empresa adquiridora debera tener para favorecer la gestin del
proceso de ofertas. A continuacin se describir la manera de gestionar las posibles
preguntas que puedan surgirles a los proveedores responder a la solicitud de oferta.
Antes de entrar en estos temas, hay que destacar la labor del responsable de la gestin
de proveedores dentro de este proceso, quien tiene la responsabilidad de asegurar que los
objetivos de la gestin de proveedores se han cumplido. Entre sus tareas se incluyen las
siguientes:
Proporcionar ayuda en el desarrollo y revisin de acuerdos con proveedores, como
por ejemplo, acuerdos a nivel de servicio (SLAs), contratos, o cualquier otro tipo de
documento relacionado con los proveedores.
Asegurar que se ha obtenido la relacin calidad precio de los proveedores y
contratos.
Asegurar que todos los procesos de proveedores IT son consistentes y que las
estrategias corporativas de proveedores, procesos y trminos y condiciones
estndares estn relacionadas.
Mantener y revisar una base de datos de proveedores y contratos (SCD)
Revisar y realizar anlisis de riesgos de todos los proveedores y contratos de forma
regular.
Asegurar que cualquier contrato de soporte o acuerdos desarrollados estn
alineados con el negocio.

Asegurar que todos los servicios de soporte estn documentados y dentro del
alcance; y que las relaciones y dependencias entre proveedores, servicios de
soportes y procesos de soporte estn documentados y alineados.
Revisar los procesos de proveedores para garantizar que cualquier proveedor sub
contratado cumpla las obligaciones contractuales.
Realizar revisiones de contratos o SLAs, al menos anualmente, asegurando que
todos los contratos son consistentes con los requisitos de la organizacin y con las
condiciones y trminos estndar en la manera de lo posible.
Actualizar contratos o SLAs cuando sea necesario, asegurando que se siga el
proceso de gestin de cambios.
Gestionar un proceso para tratar disputas contractuales y asegurar que cualquier
disputa sea tratada de manera eficiente y efectiva.
Controlar, informar y realizar revisiones regularmente del rendimiento de los
proveedores, identificando acciones de mejora y asegurando que dichas acciones
van a llevarse a cabo.
Asegurar que los cambios son evaluados teniendo en cuenta su impacto sobre los
proveedores, servicios de soporte y contratos. Asistir a reuniones CAB (consejo de
evaluacin de cambios) cuando sea necesario.
Coordinar y dar soporte a todos los proveedores IT y a responsables de los
contratos, asegurando que cada contrato/proveedor tiene un propietario que ha sido
nombrado dentro de la organizacin proveedora de servicios.
2.2.2.1. Organizacin interna
Antes de gestionar las ofertas que se van a recibir de los proveedores, se debera definir
una estructura dentro de la organizacin de tal forma que todo el mundo tenga muy claro
cules son sus responsabilidades dentro de este proceso. Tambin debera recalcarse y
aclararse aspectos a tener en cuenta durante este proceso. Ver apartado anterior de buenas
prcticas.
a) Definicin del punto de contacto
Debera existir un solo punto de contacto (POC) que transmitiese la informacin tanto
interna como externamente, y por lo tanto, sea responsable de la recepcin y envo de los
documentos de oferta.
El POC debera gestionar dos procesos:
- Interacciones proveedor-empresa adquiridora.
- Comunicaciones externas de la compaa.
Uno de los objetivos del POC sera fomentar la competicin y tratar de conservar a los
buenos proveedores interesados en la oferta del negocio.
b) Crear el equipo interno

Hay que crear un equipo interno que defina los requisitos de la solicitud de ofertas y hojas
de costes y que responda a las ofertas de los proveedores. Es recomendable seleccionar
para esta tarea a personas con experiencia en el rea tcnica y de negocios, y que utilicen
un lenguaje preciso y eficiente. Otra opcin es seleccionar a los miembros del equipo y
darles formacin y ensearles buenas prcticas. Si el equipo interno ya tiene experiencia en
responder las ofertas de los proveedores, podra ser necesario reeducar al equipo para
quitarles viejos hbitos.
2.2.2.2. Gestin de preguntas y respuestas
Gestionar la interaccin con proveedores durante el proceso de adquisicin es uno de los
aspectos ms difciles de la gestin de adquisiciones. Hay que tener en cuenta algunas
consideraciones como las que se tratan a continuacin:
Es necesario permitir un perodo de preguntas y comentarios del proveedor tras la
difusin del documento de oferta.
Los proveedores enviarn preguntas sobre dicho documento de oferta, y en
ocasiones ser necesario realizar aclaraciones o volver a pensar en ciertos
temas que quizs no estaban muy claros.
Ser necesario definir un proceso para enviar la informacin revisada de vuelta a
los proveedores
Los proveedores algunas veces realizarn preguntas inapropiadas y el POC deber
tratar en algunas ocasiones con proveedores demasiado directos.
Solamente en el caso de que se haya cometido un error significativo en la solicitud,
debera corregirse y difundirse inmediatamente, explicando las razones por las que
se ha producido el cambio a todos los proveedores.
Asegurarse de que existe un procedimiento de preguntas/respuestas referenciado
en la propia solicitud de oferta con el objetivo de contestar a posibles preguntas de
los proveedores.
Habra que ser conscientes de que los proveedores intentarn extraer informacin de
la compaa, de los miembros del equipo o del POC para intentar conseguir ventaja
en la competicin con el resto de proveedores.
Sobre estos y otros aspectos se tratarn en los siguientes apartados:
2.2.2.2.1. Gestin de respuesta a proveedores
El hito de entrega puede verse modificado por distintas razones (presupuesto, prioridades,
recursos...) o por la necesidad de la empresa de reevaluar la solicitud de oferta debido, por
ejemplo, a las cuestiones realizadas por los proveedores.
Una fecha clave dentro del proceso de oferta es la establecida para que los proveedores
entreguen la respuesta a la oferta. Hay que asegurarse de que los proveedores tienen
suficiente tiempo para elaborar la respuesta a la solicitud de oferta.

Si se lleva a cabo algn cambio oficial sobre fechas de entrega, se deber enviar un
comunicado de forma inmediata a todos los proveedores y notificarlo tambin al equipo
interno. Lo ideal sera no modificar la fecha de entrega, pero en caso de hacerlo, no se debe
adelantar dicha fecha ya que puede provocar que los proveedores no tengan tiempo para
desarrollar la oferta. Las compaas tienden a sobreestimar el tiempo requerido para
responder a la solicitud de oferta.
El tiempo de respuesta, por parte de los proveedores, podra reducirse gracias a una buena
preparacin del documento de solicitud, especialmente las hojas de clculo para responder
a temas relacionados con los requisitos y los parmetros de coste.
Una de las formas para gestionar las respuestas de proveedores a solicitudes de oferta
complejas es pedir la exposicin de la propuesta de forma oral. Con ello se pretende:
Valorar si el proveedor entiende realmente los requisitos del producto que la empresa
necesita.
Ayudar a decidir si la empresa y el proveedor son compatibles en trminos de estilos
de trabajo, filosofas
Medir el nivel de compromiso del proveedor.
Llegar a comprender realmente el problema del negocio mediante la comparacin y
contraste de las propuestas de los proveedores de una manera interactiva.
2.2.2.2.2. Gestin de preguntas de los proveedores
Entre el momento de publicacin del RFP y la fecha de entrega de las respuestas a la oferta,
la compaa puede recibir llamadas de proveedores preguntando por distintos temas, por
ejemplo:
Aclaraciones sobre requisitos, especialmente sobre los requisitos identificados como
obligatorios. Por ello es importante tener claro por qu los requisitos que son
obligatorios lo son teniendo conocimiento de por qu son tan importantes antes de la
publicacin de la oferta.
Preguntas sobre las especificaciones tcnicas. Hay que asegurarse que se capture
cualquier pregunta sobre requisitos tanto de especificaciones de negocio como
tcnicas.
Si hay un presupuesto para el proyecto. Los proveedores tambin podran intentar
evaluar las suposiciones financieras (como el presupuesto) y pueden hacer
preguntas al respecto. El responsable de la gestin de preguntas debera intentar
contribuir a que este tipo de preguntas no se generasen.
Si ya se ha seleccionado internamente un ganador y la solicitud de oferta es
simplemente una formalidad.
Si el proveedor puede proponer su propia solucin, es decir, una solucin no
contemplada en la solicitud de oferta.

Como parte de la disciplina de gestin del proyecto, hay que capturar y registrar las
preguntas recibidas de los proveedores.
Se debera esperar durante un tiempo para enviar las respuestas, es decir, no responder
inmediatamente despus de recibirlas. Intentar esperar a que todos los proveedores tengan
la oportunidad de leer la solicitud de oferta y enviar sus preguntas a la compaa.
Otra prctica a seguir es la de mantener la confidencialidad de los proveedores que
realizan las preguntas. Es importante tratar las cuestiones de forma confidencial y no revelar
quin realiz las preguntas al responderlas. Un formato podra ser: una compaa realiz la
siguiente pregunta y la respuesta es..
Tambin sera aconsejable modificar las preguntas recibidas de tal forma que sean
genricas y as poder contestar a distintos proveedores al mismo tiempo.
2.3. SELECCIN DE PROVEEDORES
En los ltimos aos la gestin de proveedores ha proporcionado beneficios sustanciales
para las organizaciones en trminos de mejora de costes, mejora de la calidad, xito de las
entregas y una cadena de suministro ms responsable. Hay una serie de factores que
contribuyen a este xito. Uno de los ms significativos es el uso de una estrategia de
seleccin de proveedores. Normalmente se comienza por una evaluacin de los gastos,
proveedores, procesos, necesidades del cliente, mtricas, estrategias del negocio, y
rendimiento.
Tabla 6 Entradas, salidas y herramientas de la seleccin de proveedores
organizacin.
adquisiciones.
Criterios de evaluacin.
Paquete de documentos de la
adquisicin.
Propuestas.
Lista de vendedores
calificados.
Plan de gestin del proyecto.
Registro de riesgos.
Acuerdos contractuales
relacionados con el riesgo.
Vendedores seleccionados.
Contrato.
Plan de gestin del contrato.
Disponibilidad de recursos.
Plan de gestin de las adquisiciones
(actualizaciones).
Cambios solicitados.
Sistema de ponderacin.
Estimaciones independientes.
Sistema de seleccin.
Negociacin del contrato.
Sistema de calificacin de
vendedores.
J uicio de expertos.
Tcnicas de evaluacin de
propuestas.

2.3.1. Aplicar criterios de evaluacin
Los criterios de evaluacin que son desarrollados antes de comenzar con la solicitud de
propuesta son utilizados como marco para evaluar las respuestas de los proveedores a la
solicitud de oferta lanzada por la empresa adquiridora.
Al igual que al desarrollarlos, al aplicar criterios de evaluacin debera involucrarse
representantes de todos los grupos de personas relacionadas con el negocio.
Implementar el marco de evaluacin
Durante la seleccin de proveedores se asume que el equipo evaluador utilizar el marco de
evaluacin definido antes de lanzar la solicitud de oferta. En algunos casos, las respuestas
de los proveedores a dicha solicitud pueden destapar temas que no fueron tratados de la
forma adecuada en el marco original, en cuyo caso, el equipo necesitar decidir qu
cambios deben llevarse a cabo. Sin embargo, si las necesidades del negocio y los requisitos
estn encaminados no sera necesario realizar cambios en el marco de evaluacin. Si por el
contrario, son requeridos algunos cambios, todas las personas involucradas en el negocio
deberan tener conocimiento de ello lo antes posible, y todos los que trabajan directamente
en el marco original de evaluacin deben tenerlo en cuenta para la realizacin de
modificaciones.
El proceso de aplicar criterios de evaluacin comienza uniendo al equipo de evaluacin para
analizar las respuestas obtenidas por parte de los proveedores y, a continuacin, informar
de los resultados a los involucrados en el negocio.
Evaluacin de las respuestas de los proveedores
Evaluar las respuestas de los proveedores es normalmente lo que ms tiempo lleva de todo
el proceso. Esta fase de la evaluacin requiere planificacin, especialmente para asegurar:
- Que se tienen los recursos internos necesarios para evaluar las respuestas
- Que se han preparado unas hojas de clculo o el uso de otra herramienta similar
para facilitar la puntuacin de los proveedores e intentar minimizar la puntuacin
subjetiva.
Despus de recibir las respuestas de los proveedores, es necesario estudiarlas y evaluarlas
minuciosamente. Cualquier componente clave que falte (como, por ejemplo, una hoja de
clculo) debera ser reportado inmediatamente al proveedor correspondiente, el cual tendr
un tiempo lmite para enmendar el fallo.
Se necesitar programar al equipo para revisar las respuestas. Algunas compaas emplean
frmulas complejas de tal forma que los proveedores tengan la obligacin de tener un nivel
satisfactorio en ciertas categoras. Por ejemplo, una compaa puede haber enviado las
mejores respuestas de requisitos y tener los mejores costes, pero puede tener muy mala
reputacin y estar en bancarrota. En este caso, incluso si la puntuacin total es buena,
puede utilizarse una funcin compleja para eliminar a ese proveedor por recibir una
puntuacin demasiado baja en una categora de evaluacin importante.

Evaluar las habilidades de los proveedores
La evaluacin de las habilidades de los proveedores es clave para determinar el producto o
servicio ms competitivo y qu mejor satisfaga las necesidades de la empresa adquiridora.
Algunas de las habilidades genricas de los proveedores a tener en cuenta son:
- Rendimiento pasado: el rendimiento de un proveedor en trabajos similares en el
pasado y sus posibles resultados en contratos futuros.
- Capacidad: la capacidad del proveedor para absorber negocios adicionales.
- Habilidades: habilidades para gestionar el negocio especfico, que le interesa a la
empresa adquiridora.
- Integridad: la integridad del proveedor y la manera de saber llevar las relaciones
pasadas.
- Tiempo en el mercado: durante cunto tiempo la organizacin ha estado en esa
lnea de negocio y qu pruebas existen acerca de la sostenibilidad del negocio.
- Certificacin y licencias: puede ser necesario confirmar que el proveedor tiene las
certificaciones y licencias adecuadas, entre las que se podran encontrar derechos
de uso o propiedad intelectual.
- Factores financieros: debera solicitarse ciertos datos financieros a los proveedores
para evaluar su condicin financiera.
Durante la evaluacin de las habilidades de los proveedores puede incluirse visitas a los
proveedores, anlisis del rendimiento de la empresa, anlisis financiero, anlisis de la
calidad de los productos que desarrollan o de la gestin que llevan a cabo los proveedores.
Algunas de estas habilidades se describen en las siguientes tablas:

Tabla 7 Factores de evaluacin en la visita a la empresa proveedora
Habilidades Elementos a observar
Instalaciones del proveedor Condiciones y antigedad de los equipos, limpieza de
las instalaciones, volumen de produccin, actual nivel
de actividad de la empresa
Habilidades tcnicas Habilidades de desarrollo y de investigacin de los
proveedores, qu soporte dan al servicio de clientes,
qu habilidades de ingeniera tienen
Flujo de proceso Un proceso eficiente y la existencia de un flujo del
material son requeridos para asegurar haber
encontrado un proveedor competitivo.
Moral del empleado El estado de nimo de los empleados afecta en gran
medida a la calidad, adecuacin a los hitos
establecidos y a la eficiencia de cualquier operacin
que se desarrolle. (Cmo se sienten trabajando en la
empresa, cules son sus percepciones sobre la
gestin de la compaa, qu trato se les da)
Control del proceso Qu sistema es utilizado para planificar y controlar las
actividades del proceso, si se puede determinar de
manera rpida el estado y localizacin de los pedidos,
qu criterios son utilizados para establecer la prioridad
de los pedidos
Control de calidad Si los sistemas de control de procesos estn en su
sitio, quin los mantiene, si en la organizacin se
emplean herramientas estadsticas de control de
procesos de forma rutinaria y sobre todos los procesos
Compromiso de gestin Saber si la gestin de proveedores est realmente
interesada en el negocio de la empresa adquiridora,
cual es la involucracin de la gestin en las
operaciones, qu compromiso tiene gestin sobre la
calidad y servicios del cliente
Tecnologa Actualidad de la tecnologa utilizada por los
proveedores, cmo es utilizada la tecnologa de la
informacin, saber si el proveedor tiene habilidades
relacionadas con el comercio electrnico, saber qu
nivel de tecnologa es utilizado en el desarrollo y
diseo de productos y servicios, si el proveedor tiene
un plan tecnolgico

Tabla 8 Rendimiento de los proveedores
Habilidades Elementos a observar
Frecuencia y volumen de pedidos Cmo es de importante el negocio de la empresa
adquisidora para el proveedor?, si el negocio del
comprador ocupase una gran porcin del trabajo de
los proveedores, se conseguira una mayor prioridad,
y una dedicacin y trato favorable?
Tiempo para procesar los pedidos Cunto dura aproximadamente el proceso de
pedidos de los proveedores?, con pedidos grandes,
en qu medida se aumenta el tiempo en procesar el
resto de pedidos?
Entrega Las instalaciones y capacidades de los proveedores
son suficientes para llevar a cabo la entrega de
materiales o servicios en un periodo de tiempo
aceptable para el comprador?
Calidad Hay evidencias de una filosofa de gestin de calidad
total?, qu mecanismo utiliza el proveedor para
mantener la calidad?, qu opinan otros compradores
de la calidad de los productos desarrollados por ese
proveedor?
Retraso en los pedidos Hay muchos retrasos en los pedidos?, Se opera de
manera efectiva?
Programa de outsourcing de los proveedores Los elementos adquiridos son desarrollados
nicamente por los proveedores, o ellos a su vez
adquieren otros elementos ya desarrollados de una
tercera empresa?
Productividad Conocer la productividad de los proveedores
Flexibilidad Conocer la flexibilidad de los proveedores, es decir, la
capacidad de cambios frecuentes, repentinos y
constantes dentro de la organizacin. Esta habilidad
es importante en un proveedor ya que permite una
relacin de trabajo dinmica y responsable ante
cambios en el mercado.
Capacidades electrnicas La empresa proveedora tiene pgina web?, es
capaz de tratar con transacciones de comercio
electrnico? La inversin en capacidades electrnicas
facilitara las transacciones de negocio, reducira los
costes administrativos y mejorara la eficiencia.

Participantes en el proceso de seleccin de proveedores
El proceso de evaluacin puede no ser del todo imparcial, incluso la percepcin de
parcialidad puede reducir los esfuerzos por conseguir una solucin ampliamente aceptada.
Adems de la importancia de la imparcialidad, tambin es clave determinar el nmero ms
adecuado de participantes en el proceso de seleccin de proveedores. Mientras que una
masiva participacin con personal experto permitira una evaluacin ms exhaustiva de las
ofertas de los proveedores pudiendo conseguir un resultado muy acertado de la evaluacin,
conllevara muchos recursos tanto de tiempo como de personal. Si por el contrario se
decidiese utilizar un bajo nmero de participantes para las evaluaciones, se agilizara el
proceso y se ahorraran recursos. Por lo tanto hay que encontrar un equilibrio para
determinar el nmero idneo de participantes en la seleccin de proveedores en funcin de
los objetivos de la evaluacin, de la exhaustividad que se quiera aplicar y de las ofertas
recibidas.
Menos
evaluadores
Ms
evaluadores
Ms rpido Ms lento
Ms fcil Mayor reto
Menos
representacin
Mayor
representacin

Figura 1 Equilibrio de evaluadores del proceso de seleccin de proveedores
Reconciliar diferencias
Incluso despus de revisar cuidadosamente cada uno de los criterios y factores, habr
variaciones en las puntuaciones, y aunque generalmente las variaciones suelen ser
insignificantes, el modelo debera hacer la media de las puntuaciones para cada factor para
minimizar el efecto de las variaciones, excluyendo un valor cuando un miembro del equipo
se abstenga en vez de asignar un valor de forma arbitraria, por ejemplo.
Cuando hay grandes variaciones es importante revisar las puntuaciones que ha dado cada
miembro del equipo. Esto puede ser debido a malos entendimientos de trminos, criterios o
convencin de puntuaciones, o por la imparcialidad causada por diferentes visiones o
filosofas orientadas a la inversin.
Mientras que algunos equipos desechan las puntuaciones extremas para resolver
discrepancias, se debera discutir estas variaciones extremas. Diferentes puntuaciones
pueden indicar problemas ocultos que necesitan ser tratados. Algunas discusiones pueden
dirigirse a mejorar la solucin propuesta o a resolver diferencias del proceso de negocio o
culturales.

2.3.2. Relaciones con proveedores
Para muchas compaas, la gestin de proveedores es una parte compleja del proceso de
adquisiciones. La confianza con los proveedores puede ser un aspecto muy positivo y una
situacin ventajosa si la relacin que se establece con ellos es slida. Sin embargo, puede
ser arriesgado si los proveedores tienen falta de confianza en su habilidad para cumplir los
objetivos de la compaa.
El grupo de adquisicin a menudo se evala por su relacin con los proveedores. A pesar de
ello, muchas compaas no estn seguras de poder controlar ni de tener el conocimiento
suficiente para comparar el rendimiento de los proveedores ni realizar seguimiento de los
beneficios que se van obteniendo.
A menudo, las relaciones con los proveedores se definen por una falta de conocimiento y
visibilidad en cuanto al cumplimiento de los objetivos y metas establecidas por la compaa.
Este vaco de informacin es potencialmente peligroso hacia los beneficios cuando se
renuevan los contratos con los proveedores.
Para desarrollar buenas prcticas, las compaas deben examinar primero las polticas
actuales relacionadas con la seleccin de proveedores y las estrategias de negociacin. Se
podran considerar preguntas como las siguientes:
- Qu guas estn establecidas en cuanto a contratos con proveedores?
- Cmo se lleva a cabo el seguimiento del rendimiento de los proveedores?, o an
ms importante, se realiza algn tipo de seguimiento sobre los proveedores?
- Se anima a nuevos proveedores a que respondan a las ofertas realizadas por la
empresa adquiridora?
Las organizaciones que obtienen un mayor rendimiento estn completamente alineadas con
las mejores prcticas que han establecido, y reciben los beneficios por parte de los
proveedores de forma incremental. Estas compaas, a su vez, utilizan su tecnologa para
compartir todas estas mejores prcticas creando una situacin de colaboracin entre todas
las partes de tal forma que sea beneficioso para todo el mundo.
Seguimiento del rendimiento de los proveedores
Gracias a las nuevas tecnologas, el seguimiento de los proveedores se ha facilitado.
Actualmente, las compaas tienen la habilidad de mantener un registro de proveedores y
controlar su rendimiento, siendo toda esta informacin de gran utilidad para futuras
negociaciones con proveedores.
Mediante la implementacin de programas de cuadros de mando, las compaas pueden
cuantificar fcilmente datos intangibles relacionados con la calidad y con el nivel de servicio.
Adems, la informacin obtenida de los cuadros de mando puede ayudar a justificar la
eleccin de futuros proveedores para la empresa.
A menudo, una porcin sustancial de los costes indirectos de la compaa hacen referencia
a la creacin de relaciones y a la gestin de cuentas. La tecnologa puede eliminar estos
gastos mediante comunicacin de coste efectiva, herramientas de gestin de vendedor self-

service e implementacin de un programa de proveedores que autorice a los compradores a
elegir slo entre ciertos proveedores seleccionados. Estas tcticas permiten a los
proveedores ofrecer productos a un bajo coste y al mismo tiempo, recibir un alto margen de
beneficios.
Algunas mejores prcticas durante esta fase incluyen:
- Utilizar una seleccin de fuentes formal con un equipo de evaluacin multifuncional
experimentado y formado.
- Utilizar sistemas para priorizar el criterio de evaluacin utilizando un enfoque
disciplinado para seguir con el criterio de evaluacin establecido en la solicitud.
- Obtener estimaciones de coste que puedan servir de ayuda en las propuestas de
evaluacin de proveedores.
- Gestionar anlisis realistas de precios en cada propuesta de proveedor.
2.4. NEGOCIACIONES
La mayora de las compaas preferiran no negociar, aunque lo consideran algo inevitable.
Les gustara llevar el negocio a sus condiciones. De esta forma, el resultado puede que no
maximice el beneficio, pero reducira los costes y su percepcin de riesgo. Hay pocas
empresas que consideren la negociacin como una fuente de ventaja competitiva.
En muchas ocasiones, los representantes de la compaa utilizan estratagemas para simular
que estn negociando: andan con rodeos para que pase el tiempo, crean falsos puntos de
friccin para desviar la atencin de los problemas reales, etc.
Al prepararse para la negociacin, hay que tomar decisiones sobre el camino a seguir.
Distintos negociadores van a seleccionar distintos caminos. Necesitan observar las
circunstancias y evaluar el problema estratgica y tcticamente.
Las habilidades para resolver problemas son altamente valoradas en un entorno de negocio
tan complejo como el actual. La negociacin es un rea donde intervienen estas habilidades
de resolucin de problemas.

Tabla 9 Entradas, salidas y herramientas de la fase de negociacin
Contrato.
Vendedores seleccionados.
Informes de rendimiento.
Solicitudes de cambio
aprobadas.
Informacin sobre el
rendimiento del trabajo.
Documentacin del contrato.
Cambios solicitados
Acciones correctivas recomendadas.
organizacin (actualizaciones).
Plan de gestin del proyecto
(actualizaciones).
Plan de gestin de las adquisiciones.

Sistema de control de
cambios del contrato.
Revisin del rendimiento
realizada por el comprador.
Inspecciones y auditoras.
Informar el rendimiento.
Sistema de pago.
Administracin de
reclamaciones.
Sistemas de gestin de
registros.
Tecnologa de la informacin.
2.4.1. Debilidades en las negociaciones
El resultado de la negociacin viene determinado por un conjunto de factores internos que
incluyen:
Trabajo en equipo.
Definicin del proceso.
Sistema de mediciones y de gestin utilizado para conseguir un comportamiento
consistente y compartir informacin.
Las herramientas proporcionadas para permitir el aprendizaje y comparticin de
conocimiento.
La definicin y comprensin de los roles.
Alineamiento entre negocios.
Tambin hay aspectos externos de investigacin, informacin y despliegue, como:
Ejecucin de la estrategia de negociacin.
Comprensin del comportamiento y expectativas del cliente.
Su negociacin.
Habilidades analticas y creativas.
Veamos algunas de las debilidades tpicas en este proceso y sugerir soluciones al
respecto:
Falta de compromiso con la planificacin: el proceso de planificacin
recomendado por muchos gurs de la negociacin es poco realista en el entorno

corporativo, simplemente porque no hay tiempo. Se necesitan soluciones
pragmticas.
Roles poco claros: mucha gente afirma liderar la negociacin pero despus esta
gente se queja de falta de autoridad o de malas decisiones tomadas por otros. Esto
refleja una falta de autoridad real o control sobre la negociacin. Quin est al
cargo? En grandes empresas, la respuesta a esto a menudo es compleja y esto
conlleva que salga adelante el acuerdo menos malo o menos inaceptable.
Motivaciones en conflicto: esto tiene relacin directa con el problema de los roles y
a menudo como resultado se obtiene un acuerdo que cumple las aspiraciones
individuales o las necesidades del equipo pero no contempla lo que habra sido
mejor para el negocio. La utilizacin de sistemas de medicin y de gestin, objetivos
funcionales o Balanced Scorecards conducen estas motivaciones, que influencian el
comportamiento de todos los participantes: comprador, vendedor y terceras partes.
Control inadecuado: el control corporativo a veces desafa al anlisis lgico e
incluso puede conseguir el resultado contrario al deseado. Por ejemplo, una mala
disciplina interna puede provocar la revelacin de informacin fundamental que mine
la negociacin, personal poco cualificado puede llegar a un acuerdo sobre
compromisos irrealistas o provocar conflictos en documentos como una propuesta de
trabajo o un acuerdo de nivel de servicio, el equipo financiero puede requerir un caso
de negocio muy pesado, o el equipo legal puede restringir la negociacin de algunas
condiciones clave, hasta el punto de que la planificacin o estrategia real se vuelve
casi imposible y el equipo de negociacin pierde todo poder real.
Encontrar los sntomas
Estas debilidades significan que no estamos alcanzando los mejores resultados. A
continuacin, mostramos algunos sntomas que nos pueden ayudar a diagnosticar las
debilidades que afectan a la negociacin.
Ciclos de negociacin largos: qu es largo? cul debera ser nuestro objetivo?
Necesidad de reabrir problemas con frecuencia: qu provoca esto?
Cambios frecuentes en los requisitos o prioridades: qu provoca esto? (en ambos
casos, un factor principal es la falta de un proceso disciplinado, hay poco rigor en
establecer informacin y principios bsicos).
Sentimiento de frustracin entre los miembros del equipo: muchos malentendidos,
suposiciones que no se han probado adecuadamente.
Visin de la gestin ejecutiva de que, a menudo, podran alcanzarse mejores
acuerdos.

2.4.2. La negociacin como proceso de negocio
Las negociaciones ocurren diariamente y cada vez se han vuelto ms complejas y ms
crticas para el xito del negocio, cada vez son ms dinmicas, involucran a mayor nmero
de gente en la organizacin y normalmente durante largos periodos de tiempo.
Debido a la importancia de la negociacin, las organizaciones se estn dando cuenta de que
deben desarrollar la negociacin como una capacidad de la organizacin si quieren
conseguir resultados consistentes en ella. Deben asegurarse de que el personal cuenta con
los procesos, herramientas y habilidades necesarios para negociar de forma satisfactoria
acuerdos que maximicen el valor. Las compaas estn empezando a disear e implementar
la negociacin como un proceso de negocio, con fases definidas, roles y
responsabilidades, y mtodos y herramientas para gestionar, de forma consistente y
efectiva, cada actividad del proceso.
Para desarrollar la negociacin como un proceso de negocio, se podran considerar seis
fases:
1. Conseguir un alineamiento interno: sin l, los equipos de negociacin pueden
recibir mensajes contradictorios sobre qu deberan o no deberan hacer. Esto puede
ralentizar las negociaciones y disminuir la efectividad de los equipos de negociacin.
2. Proporcionar instrucciones: el equipo de negociacin necesita guas y mtricas
rigurosas para el xito de la negociacin: intereses clave que deben satisfacerse en
el acuerdo, criterios con los que los negociadores deben evaluar posibles soluciones,
ideas iniciales de posibles trminos de negociacin, objetivos de la relacin que debe
establecerse durante las negociaciones,
3. Preparacin: una buena preparacin va a incidir directamente en la calidad del
acuerdo final as como en la eficiencia de todo el proceso de negociacin. Muchas
veces, debido a la presin del tiempo, no se invierte el tiempo suficiente en la
preparacin y esto puede provocar que se pierda la visin de todos los elementos
que deben ser considerados.
4. Lanzar la negociacin: este proceso permite a las compaas determinar, junto con
las otras partes involucradas en la negociacin, cmo quieren negociar, qu reglas
van a seguir, cmo van a gestionar las dificultades, Este tiempo dedicado a
determinar entre las distintas partes cmo se va a negociar puede ahorrar mucho
tiempo en la posterior negociacin e incluso favorecer la relacin entre los
negociadores a la hora de resolver problemas.
5. Llevar a cabo la negociacin: para mejorar y sistematizar la capacidad de una
organizacin de negociar acuerdos ptimos, es importante apoyarse en herramientas
y mtodos bien definidos. Estas herramientas y mtodos pueden tomar muchas
formas posibles pero su principal propsito es ayudar al equipo de negociacin
proporcionndole un soporte basado en experiencias de negociaciones pasadas.
Algunos de los objetivos de estas herramientas deberan ser capturar y organizar

prcticas efectivas de negociacin para cada tipo de negociacin, permitir revisar el
estado de las negociaciones en progreso,
6. Revisar y recoger lecciones aprendidas: revisar de manera sistemtica las
negociaciones nos proporciona una oportunidad de extraer lecciones aprendidas con
respecto a lo que ha funcionado bien y lo que deberamos hacer de manera diferente
la prxima vez. Estas lecciones aprendidas deben ser compartidas de manera que
puedan ayudar a otros equipos a preparar sus negociaciones.
2.4.3. Negociacin inteligente
Muchas compaas forman a sus empleados de ventas en tcnicas de negociacin. Este
enfoque raras veces tiene un retorno de inversin y falla por dos razones principalmente:
No hay una estrategia de negociacin definida Hacia dnde queremos ir.
No hay un proceso para ejecutar la estrategia Cmo vamos a llegar all.
La estrategia de negociacin debera contener, al menos, lo siguiente:
Un proceso comn para preparar y ejecutar negociaciones.
Un enfoque en la creacin de valor, negociacin proactiva, en lugar de en la
divisin de valor, concesiones reactivas.
Reacciones predefinidas al comportamiento irracional de los competidores.
Resultados deseados en cuanto al precio de los productos y los servicios de soporte.
Para conseguir el cambio deseado en la organizacin, la nueva estrategia se debe construir
con todos los agentes involucrados en el proceso.
Cada negociacin es diferente: hay distintas personas involucradas, puede que distintas
culturas, distintas variables, consecuencias, problemas especficos del mercado, etc. que
ataen a cada negociacin. El proceso debe permitir la flexibilidad de poder personalizarse
para adaptarse a las necesidades nicas de cada negociacin y, al mismo tiempo, ofrecer
un lenguaje y un enfoque comn que definan la forma en que negocia la organizacin.
La institucionalizacin de la negociacin como proceso comienza con la definicin de
las fases de que va a constar y cules son las principales actividades dentro de cada fase. A
partir de ah, se deberan definir una serie de mtodos y herramientas que den soporte a la
ejecucin de estas actividades. Adems, para hacer este proceso realmente efectivo es
necesario tener en cuenta estos aspectos clave:
Mecanismos de formacin para poder desempear las habilidades necesarias.
Promover toda una filosofa de pensamiento que apoye al proceso.

Consistencia entre el proceso de negociacin y otros procesos de negocio,
definiciones de roles e incentivos.
Una infraestructura de TI que de soporte a los procesos y herramientas.
Una vez que se ha desarrollado la estrategia de negociacin, todos los agentes involucrados
necesitan aprender cmo utilizar el proceso para implementar la estrategia. Esto aumentar
la probabilidad de que realmente se produzca el cambio en el comportamiento. Algunos
pasos clave en el diseo y la ejecucin del proceso son:
La estrategia es consensuada por los agentes relevantes.
Los agentes relevantes han aprendido el proceso de implementacin.
El liderazgo interno da soporte a ambos.
Lo ms importante es la implementacin, de manera consistente, de la estrategia y del
proceso por parte de la direccin.
2.4.3.1. Estilos de negociacin
A continuacin, se expone cul puede ser el resultado de la negociacin cuando los
negociadores adoptan los siguientes estilos:

Tabla 10 Estilos de negociacin
Evitar Acomodar Competir Colaborar Comprometerse
Evitar Las partes
evitan la
persecucin
de objetivos,
no toman
acciones para
poner en
peligro la
relacin
El que se
acomoda
muestra
preocupacin
por el que
evita la
negociacin.
El que la evita
busca
minimizar la
interaccin
El competidor
dominar la
relacin o el
que la evita
escapar
El colaborador
muestra
preocupacin
por los
problemas y la
relacin,
puede desistir
El que se
compromete
muestra algo de
preocupacin
por los
problemas y por
la relacin. El
que evita puede
implicarse
Acomodar Las partes
evitan la
persecucin
de objetivos,
ceden
fcilmente.
Tratan de
dejar de lado
los problemas
de la relacin
El competidor
persigue sus
propios
objetivos. El
que se
acomoda
intenta
agradar y
puede cambiar
la base de la
discusin o
perder mucho
tiempo a no
ser que tenga
cuidado
Debera
resultar en
una relacin
fuerte, el
colaborador
puede
alcanzar
mejores
resultados
Una relacin que
mejorar con el
tiempo. El que
se acomoda
puede ser
atrado a
perseguir
algunos
problemas
Competir Ambas partes
persiguen sus
objetivos e
ignoran la
relacin.
Conflictos,
desconfianza y
hostilidad
El competidor
normalmente
gana, fuerza a
ambas partes
a ser
competitivas
El competidor
gana, puede
incitar al que se
compromete a
ser competitivo
Colaborar Ambas partes
persiguen
objetivos y
muestran
preocupacin
por el otro.
Confianza,
buena
relacin,
abierta
Resulta en un
buen
compromiso
Comprometerse Ambas partes
persiguen

objetivos,
protegen la
relacin pero no
extienden el
acuerdo
Fuente: A Complete Guide to Strategic Negotiation ", Think Before You Speak, 1996.
2.4.4. Mejores prcticas en la negociacin
Tanto si se acta como lder de la negociacin, con cierto grado de control sobre el
resultado, o como mero influyente, hay una serie de consejos y tcnicas que harn que
nuestra contribucin proporcione valor aadido y evite problemas en la negociacin, como
por ejemplo:
Es crtico ser honesto en la evaluacin del entorno del negocio en el que se va a
trabajar.
Si hay cosas que uno puede cambiar, habr que cambiarlas.
Si hay cosas que estn perjudicando los resultados pero estn fuera de nuestro
control, habr que buscar el cambio por parte de los que pueden llevarlo a cabo o
trabajar con la realidad de la situacin.
A continuacin se describen una serie de mejores prcticas que se pueden aplicar al rea
de la negociacin:
Mayor presin de la direccin para obtener resultados
o Mayor visibilidad de los resultados a travs de mejores sistemas para registro
y seguimiento de objetivos especficos. Las compaas que llevan a cabo
mejores prcticas esperan que documentos clave como propuestas de
trabajo o acuerdos de nivel de servicio se redacten y negocien por expertos
adecuados, equipados con las herramientas y sistemas adecuados.
o Creencia de los ejecutivos del lado del adquiridor de que podran conseguir
mejores acuerdos y por parte del proveedor de que deben controlar y
gestionar mejor los riesgos porque estn cediendo demasiado. Las
compaas que llevan a cabo mejores prcticas estn implementando
herramientas y sistemas de seguimiento ms sofisticados para asegurar la
auditora de la gestin actual de los resultados con respecto a las
expectativas, o de la demanda del mercado con respecto a las capacidades
actuales.
Aversin al riesgo y al coste
o A veces entran en conflicto las presiones que pueden venir del equipo
financiero o llegar con la direccin ejecutiva y con lo que puede suponer un

buen acuerdo. Los procesos de control pueden crear un nivel de rigidez que
reduzca los acuerdos alcanzados o que provoque que algunas soluciones,
debido a su coste o a su riesgo, no se exploren porque va a resultar muy
difcil realizar la compra a travs de la burocracia interna o externa. Las
compaas que llevan a cabo mejores prcticas implementan herramientas y
mtricas para alcanzar un equilibrio. Por ejemplo, realizan un seguimiento de
la rapidez y tiempo de respuesta de los agentes involucrados para identificar
cuellos de botella, introducen la capacidad de actualizar estrategias, procesos
y prcticas que reconozcan cambios en el mercado o en las condiciones del
negocio.
Aumento en la sofisticacin
o A medida que las organizaciones ven la negociacin como una competencia
clave, las tcnicas utilizadas se van volviendo ms sofisticadas. Por ejemplo,
la utilizacin de experiencias en anteriores negociaciones, la comparacin
con respecto a acuerdos similares realizados con los competidores, el mayor
entendimiento de las fortalezas, debilidades y capacidades del competidor,
todo esto se adquiere con ms rapidez, se comparte mejor y se incorpora en
las estrategias ganadoras en las compaas que llevan a cabo mejores
prcticas.
o Otro ejemplo de mejor prctica es el aumento en la utilizacin de la tecnologa
para simplificar los canales tradicionales de aprobacin o negociacin.
Mayor complejidad en las ofertas
o Este es un factor que hace la negociacin ms difcil, no solo la externa sino
tambin la interna, necesaria para llegar a un consenso y a un plan. Un
ejemplo de negociacin sofisticada es el outsourcing. En primer lugar, la
integracin aumenta el conjunto de partes interesadas en el acuerdo y, por
tanto, los involucrados en la toma de decisiones. La integracin no va a incidir
solo en la complejidad del producto o servicio sino tambin a nivel de la
organizacin. Por otro lado, el aumento en la contratacin de servicios
supone una mayor carga para el negociador. Los productos son tangibles,
pueden probarse, los fallos pueden identificarse y diagnosticarse y pueden
establecerse medidas contractuales para protegernos de estos fallos. Los
servicios son intangibles. El contrato, sin embargo, debe ser tangible por lo
que se hace necesario un lenguaje ms exhaustivo y una descripcin y
especificacin de los servicios mucho mayor. El nivel de incertidumbre y los
mecanismos necesarios para controlarlo suponen una carga significativa para
el equipo de negociacin. Las compaas que llevan a cabo mejores prcticas
tienen sistemas que se adaptan a estas situaciones y permiten una

evaluacin rpida de los riesgos y una asignacin de los recursos y
habilidades adecuados a las oportunidades.
Hay seis reas crticas donde la introduccin de mejores prcticas va a marcar la
diferencia:
La negociacin interna: enfoques, actitud, mtodos (comunicaciones, gestin de
riesgos).
Gestin de la informacin y del conocimiento: fuentes, adquisicin, difusin.
Tcnicas y mtodos: formularios, checklists, herramientas de anlisis,...
Pensamiento creativo y analtico: probar las suposiciones, explorar posibilidades,
Prepararse y adaptarse al cambio: realizar lneas base, revisar el progreso, evaluar
nuevas tendencias/condiciones.
Externalizar las mejores prcticas: qu fortalezas, debilidades, amenazas y
oportunidades puede crear esto?
Algunas consideraciones para negociaciones complejas
La complejidad de la negociacin est directamente relacionada con los niveles de riesgo y
recompensa percibidos, y con los intereses que se vean afectados por el desenlace. En
muchas organizaciones, hay una tendencia a centrarse ms en las consecuencias del fallo.
Esto restringe la agenda y la estrategia de negociacin.
En un acuerdo complejo, las partes deben entender que una relacin ptima implica dar y
recibir. El objetivo de la negociacin debera ser confirmar que la forma en que encajan las
partes resulta en una probabilidad de xito, y luego trabajar en las reas donde la manera
en que encajan las distintas partes est menos clara o necesita ser medida y controlada. La
planificacin y ejecucin de la negociacin debe canalizar los posibles cambios sobre los
trminos del acuerdo y establecer mecanismos para gestionar esos cambios, aadiendo o
eliminando servicios o resolviendo conflictos.
El primer paso a la hora de evaluar los riesgos y recompensas potenciales es que cada
parte determine de forma precisa por qu se considera la relacin. Normalmente, hay entre
tres y cinco objetivos prioritarios y para muchos clientes estos suponen el fundamento para
la negociacin. Sin embargo, muchos clientes no consideran el impacto de esos objetivos en
todos los aspectos de la negociacin.
La estrategia de negociacin tiene como pilares fundamentales: los objetivos de cada
parte, el alcance del acuerdo y la fortaleza y poder de negociacin de las partes.
La diferencia entre los objetivos de las distintas partes es lo que provoca la tensin en la
mayora de las negociaciones. Por ejemplo, un cliente puede pretender reducir costes, ganar
ventaja competitiva, aumentar los niveles de servicio o la flexibilidad. Los objetivos concretos
y sus combinaciones pueden variar segn el contrato y, por ello, es por lo que establecer

trminos y condiciones estandarizados es inadecuado. El proveedor est obviamente
interesado en cubrir los objetivos del cliente, pero siempre que maximice sus beneficios,
cuota de mercado e imagen. Una mejor prctica para asegurar este alineamiento es
enfocarse menos en los resultados a corto plazo y ms en el xito a largo plazo del acuerdo.
El alcance est determinado por los requisitos del cliente y determina la estructura del
acuerdo. Sin embargo, los requisitos a menudo son imperfectos, el proveedor puede estar
interesado en sugerir cambios para cumplir mejor sus objetivos o porque ha visto
oportunidades que el cliente haba pasado.
La posicin negociadora que ocupan las partes no es nica de acuerdos complejos, pero es
ms difcil cuando hay muchos factores implicados. La estrategia debe descomponer estas
situaciones complejas en secciones ms fcilmente gestionables. Esto se hace en parte
como simplificacin, pero tambin porque trabajar en muchas reas de manera secuencial
extendera demasiado el tiempo de negociacin. Estas negociaciones normalmente
involucran a varios grupos de expertos o equipos y esta es probablemente la forma ms
comn de segmentar un acuerdo, aunque no necesariamente la ms eficiente. Despus,
hay que asegurar que hay un sistema para integrar todas las partes y permitir llegar a un
acuerdo. Hay que tener en cuenta que no solo se est diseando un contrato, sino una
relacin que necesita control y procesos que lo hagan funcionar, y la negociacin tiene que
tener mecanismos para probar su consistencia y efectividad.
Normalmente las negociaciones complejas sern de duracin larga. Los cambios pueden
ser inevitables: pueden venir de la conciencia de que los requisitos son errneos o
incompletos, de nuevas oportunidades que vayan surgiendo, de variaciones en la estrategia
del negocio o del mercado, En estos casos, no sirve de nada quejarse, hay que
acomodarse a los cambios. Por supuesto, siempre que sea posible, se realizar una lnea
base del acuerdo en las primeras fases de la negociacin. La estrategia debe tener en
cuenta que los cambios pueden ocurrir y haber establecido las reglas bajo las cuales estos
cambios sern evaluados y gestionados
2.5. GESTIN DEL PROCESO DE ADQUISICIN
El proceso de compra no est completo una vez que se hace el pedido. El adquiridor tiene la
responsabilidad de asegurarse de que el producto o servicio es entregado cuando es
necesario y que cumple las especificaciones. Para llevar esto a cabo, el adquiridor debe
controlar y monitorizar todo el proceso desde que se hace el pedido del producto hasta
que dicho producto est entregado para evitar problemas.
Si por ejemplo la fecha de entrega va a variar por cualquier motivo o el proveedor va a ser el
responsable directo de un retraso en la entrega, el adquiridor deber tomar un papel activo
para minimizar las consecuencias de no cumplir las fechas de entrega deseadas.
En este apartado se examinarn las actividades relacionadas con la administracin de
contratos, y los procesos de seguimiento.

2.5.1. Gestin y administracin de contratos
Para gestionar de forma adecuada los contratos se deben seguir una serie de fases:
Negociacin y puesta en marcha.
Monitorizacin de resultados.
Gestin del proceso de control de cambios del contrato.
Estas fases se van a desarrollar en los apartados que aparecen a continuacin.
2.5.1.1. Negociacin y puesta en marcha
Durante la fase de la negociacin hay que centrarse en el entendimiento por ambas partes,
tanto de la empresa adquiridora como de los proveedores, de las obligaciones y el objetivo
de la negociacin, que es llevar a cabo de forma satisfactoria la adquisicin, y una vez
que esto est claro se discutirn las clusulas y se harn previsiones de riesgos.
Durante la reunin de negociacin del proyecto, deben tratarse y quedar claramente
entendidos como mnimo algunos puntos bsicos como:
Puntos clave del contrato.
Entregables.
Definicin de los hitos del proyecto.
Definicin del uso de los informes como medios de preaviso ante no conformidades o
amenazas.
Definicin de presupuestos y planes de pagos.
Cualquier aspecto poco claro de los requerimientos o de cualquier otro aspecto del
contrato.
Definicin de roles y responsabilidades durante las negociaciones.
Una vez que se han dejado claro estos puntos, se comenzar con la puesta en marcha, y
para ello es esencial haber ledo y entendido bien el contrato. Una buena prctica que puede
ayudar a saber si se ha entendido el contrato es desarrollar un pequeo resumen que
explique genricamente las clusulas, obligaciones y acciones del mismo.
Durante la fase inicial de la puesta en marcha se analizar el contrato realizando reuniones
que tambin ayudarn a asegurar el acuerdo ante los objetivos del contrato e identificar
posibles riesgos.
Uno de los puntos clave a analizar son los roles y responsabilidades que aparecen en el
contrato. Es importante identificar a la gente relacionada con el proyecto y hacerles tomar
parte activa del proceso. Algunas buenas prcticas relacionadas son:
Identificar el diagrama organizacional y responsabilidades de la empresa adquiridora.
Cerciorarse de la buena organizacin y divisin de responsabilidades por parte de la
empresa proveedora.

Una forma til de analizar el contrato es dividirlo en cuatro partes principales:
mbito de aplicacin. Sobre qu trata el acuerdo?
Roles y responsabilidades. Quin hace quin?
Mtricas, SLAs, hitos Cmo asegurar el funcionamiento?
Recursos, castigos Qu pasa si algo va mal?
Para conseguir entender y hacer un correcto seguimiento del contrato una buena idea es
pensar en trminos de clusulas activas y pasivas.
Las clusulas activas son aquellas que requieren de procesos y recursos para llevarse a
cabo. Deben cumplirse de forma obligatoria.
Por otro lado, las clusulas pasivas son aquellas que tpicamente surgen slo cuando
aparecen fallos o incidencias contrarias a los trminos acordados.
Proceso de comunicacin
El proceso de comunicacin es una de las piezas claves del xito del proyecto, es por ello,
que la comunicacin debe ser rigurosamente ejecutada y bien planificada. Para este
proceso, son tiles herramientas comunes de desarrollo as como cualquier otra herramienta
web.
El desarrollo del proyecto puede ponerse en peligro por una comunicacin pobre. Por ello,
hay que cerciorarse de realizar un ejercicio efectivo y constructivo de comunicacin.
No hay que confundir comunicacin e informacin. Comunicacin significa entender las
necesidades del receptor y enviarles mensajes simples y directos que expliquen qu es
necesario hacer y por qu. Siempre hay que tener claro que la informacin debe de ser
sencilla para el que la recibe.
Otro punto importante del que no hay que olvidarse es de la informacin que esperamos
recibir a lo largo del proyecto. Qu informes queremos? Cmo nos vamos a comunicar?
Para el buen funcionamiento de este proceso es necesario mantener un registro de la
informacin comunicada y las decisiones tomadas.
Asimismo todos los documentos relativos al proyecto, as como contratos, deben de estar
correctamente almacenados y ordenados pudiendo ser accesibles por cualquier miembro
del equipo.
Uso de software de gestin
El uso de software para la gestin del contracto sirve para simplificar las fases de puesta en
marcha y comunicacin. Puede ayudar por ejemplo a acceder a toda la documentacin del
contrato y a los cambios que se van realizando, hacer seguimientos del contrato as como
de los distintos aspectos a tratar que vayan surgiendo, incluso podra permitir monitorizar
procesos internos incluyendo el estado de cada requerimiento del contrato.

2.5.1.2. Monitorizacin de los resultados
Hay que tener en mente que durante el ciclo de vida del contrato va a haber cambios,
conflictos y reclamaciones as como nuevas oportunidades de desarrollo. El principal
objetivo tras la concesin de un contrato es el control del riesgo. Se debe mantener en todo
momento el control sobre el proyecto y asegurarse que se cumplen los requisitos de tiempo
y coste.
Es importante para ambas partes del contrato llevar un registro y monitorizar el cumplimiento
de los roles y responsabilidades asegurando que se encuentran dentro de las
especificaciones.
Otros aspectos que deberan ser monitorizados seran:
Fechas.
Equipos, o fechas de entrega del proveedor y adquiridor.
Advertencias, informes, formacin.
Facturas y pagos.
Para monitorizar el desarrollo tanto a nivel interno como externo de los requerimientos e
indicadores del proyecto una buena metodologa es el uso de los indicadores claves de
rendimiento (KPI, Key Performance Indicators). Los KPIs estn ya predefinidos y
proporcionan un clculo muy certero del estado del proyecto.
Una parte de la gestin es asegurarse de que las obligaciones contractuales se estn
cumpliendo, como por ejemplo:
Advertencias, informes, formacin.
Listado de informes, localizaciones, usuarios, interfaces
Condiciones operativas
No hay que olvidar que los informes de gestin son fundamentales para poder controlar y
tomar medidas preventivas anticipadas. Asimismo, hay que mantener registradas todas las
fechas e ir comunicando los resultados segn ocurran.
Resolucin de problemas
Un aspecto importante durante el desarrollo del proyecto es evitar disputas entre las
distintas partes (empresa adquiridora y proveedora) y acontecimientos inesperados. Es por
ello primordial que los problemas sean encontrados y tratados pronto, y se desarrolle una
lista de acciones correctivas.
Tiene que estar perfectamente definido qu debe ser supervisado y cmo, para asegurarnos
de que los objetivos se van cumpliendo, as como un plan activo en caso de desviaciones.
Debe existir un responsable encargado de supervisar la resolucin de los problemas y de
prever la posible desviacin del proyecto debida a los mismos, tal y como se establezca en
el contrato.

Seguimiento y aceptacin de entregables
Los entregables y su aceptacin son otro punto crtico en el desarrollo del proyecto. La
aceptacin es uno de los aspectos ms problemticos ya que las partes deben estar de
acuerdo en qu se requera exactamente y si el producto cumple sus requerimientos. Sin
embargo, puede que hayan ocurrido cambios a lo largo del desarrollo que el contratante
tiene que aceptar por estar recogidos en el contrato como cambios admisibles. Los criterios
de aceptacin deben estar bien definidos en el contrato, as como dnde y bajo qu
circunstancias operativas se llevar a cabo la aceptacin.
Gestin de pagos
Los pagos son algo muy relacionado con la aceptacin del proyecto o alguna de sus fases.
Es un factor crtico para ambas partes en trminos de tiempo, precisin, frecuencia y
cantidades. Es por ello que debe hacerse un buen seguimiento de las facturas, el proceso
de pago y los resultados. Nadie debe eludir sus responsabilidades en este aspecto.
El escenario bajo el cual debe ocurrir el pago, los procesos relacionados, los eventos tras
los cuales debe ejecutarse tambin se encuentran reflejados en el contrato.
La clave es, por tanto, saber exactamente qu trminos y procesos estn establecidos y
asegurarse de su correcto cumplimiento.
Gestin de costes
La gestin del coste del proyecto no se reduce simplemente al proceso de pago sino que
empieza antes de la firma del contrato, en las fases de negociacin de la oferta, y contina
durante todo el ciclo de vida del contrato.
Hay muchas actividades distintas que tienen una relacin directa con la gestin del coste del
proyecto:
- Suministrar las herramientas y recursos para un requisito especfico.
- El diseo de un sistema robusto para amoldarse a los cambios. Si los cambios no son
controlados el precio del proyecto se ver gravemente afectado.
La documentacin almacenada relacionada con este proceso debe de ser clara y fcilmente
accesible.
Revisiones
En cuanto a las revisiones durante el desarrollo, existe un gran nmero de formas de revisar
lo que se va sucediendo a lo largo del ciclo de vida del proyecto.
Hay que asegurarse de hacer revisiones internas de una forma regular. Asimismo, se deben
organizar revisiones peridicas con todas las partes participantes en el proyecto.
Estas sesiones deben estar estructuradas y todo el mundo debe de tener claro el role que
ocupa dentro de las mismas, pudindose tratar temas como:
- Situaciones que se alejan de lo planificado.
- Aspectos con riesgos y como resolverlos.

- Cambios y oportunidades.
2.5.1.3. Gestin del proceso de control de cambios del contrato
Efectos debido a los cambios
Los principales impactos debidos a cambios en el proyecto hacen referencia normalmente a:
- Coste
- Duracin estimada del proyecto
- Desarrollo del contrato
- Nivel de cumplimiento de requisitos
- Estado del proyecto
Un cambio puede afectar tambin a los trminos o procesos del contrato. Por ello, incluso
cuando un cambio no tenga efectos visibles sobre las estipulaciones del contrato, ser
necesario registrarlo ya que puede evolucionar e impactar en alguna clusula del contrato.
Peticiones del cambio
La necesidad de cambios puede venir tanto por la empresa adquiridora como por los
proveedores.
En cuanto al proceso de gestin de cambios, en el contrato debe definirse:
La forma en la que una solicitud de cambio debe de ser hecha
Dnde debe mandarse dicha solicitud
Procedimiento y personas autorizadas para revisar y aceptar o rechazar los cambios
Forma en que la decisin tomada respecto al cambio es comunicada
En el contrato adems debe quedar claramente identificado quien tiene autoridad
para iniciar y acceder a dichos cambios.
Procedimiento de control de cambios
Debe existir un procedimiento estndar de control de cambios que defina cmo manejar los
cambios que vayan surgiendo a lo largo del ciclo de vida del proyecto. Este procedimiento
debe ser consensuado y comunicado dentro de ambas partes de forma que todo el mundo
tenga conocimiento y entienda cmo funciona el mecanismo de control de cambios. Por
otro lado, hay que considerar las mtricas necesarias para monitorizar las posibles
necesidades de cambio.
Una herramienta de gestin del proyecto muy efectiva es un formulario estndar para
registrar las modificaciones del proyecto. En l deben aparecer los estados claves de
gestin de cambios como los que se muestran en la siguiente figura:

Fecha de la propuesta de
cambio
Nmero identificativo del
cambio
Origen de la propuesta de
cambio
Descripcin
reas afectadas
Implementacin del cambio
Evaluacin de los cambios
propuestos
Aprobacin o rechazo de
cambio
Identificacin de los cambios
propuestos
Costes previstos.
Implicaciones tcnicas,
operativas, contractuales
Decisiones y acciones
relacionadas con el cambio
Efectos de la ejecucin del
cambio en el contrato
original
Fecha y firma
Referencia a las reas
afectadas del proyecto
original
Figura 2 Pasos clave en la gestin de cambios
Algunos trucos tiles para conseguir controlar los cambios son:
- Uso de herramientas online
- Llevar a cabo el proceso de control de cambios sin demora
- Mantener en todo momento el registro de cambios y tenerlo accesible
- Comunicacin rpida y efectiva de las decisiones tomadas respecto a cambios
Modificaciones del contrato
El proceso de variacin de contrato es aquel en el que los cambios acordados son
incorporados de manera formal al contrato.
Uno de los problemas ms frecuentes que aparecen al incluir una modificacin en el
contrato es la existencia de contradicciones y conflictos con los trminos y clusulas del
contrato original que no haban sido tenidas en cuenta.
Hay que considerar, por tanto, el contrato completo y los efectos que sobre l puedan tener
las futuras variaciones antes de aceptar los cambios.

2.5.2. Control y monitorizacin de los riesgos
La calidad de la gestin de contratos tiene un efecto significante en el rendimiento del
negocio. Los contratos y el proceso de desarrollo de contratos tienen una gran contribucin
a la gestin de riesgos. Los responsables de la gestin de riesgos relacionados con la
negociacin deben entender los impactos de sus actividades, ser conscientes de la
disponibilidad de herramientas y tcnicas, y desarrollar habilidades y conocimientos
personales necesarios para obtener buenos resultados.
Las mejores prcticas que las compaas deberan seguir para conseguir una mayor
consistencia son:
Reducir variaciones de juicios y actitudes individuales.
Mejorar las definiciones de lo que tiene riesgo.
Aclarar las guas sobre lo que es riesgo.
Responsabilidades para conseguir soluciones, no listas de riesgos.
A continuacin se explican ms buenas prcticas que sera positivo seguir:
2.5.2.1. Entender los impactos
Hay que distinguir entre dos aspectos que pueden darse en malos contratos:
Que sean inapropiados para la situacin.
Construidos y redactados pobremente.
Ambos escenarios crean riesgos. Algunos son bastante obvios, por ejemplo, est claro que
hay que evitar la ambigedad. Pero otros tienen un impacto menos claro. Por ejemplo, el
encontrar unos trminos en el contrato que no son razonables puede provocar una reaccin
negativa que cause incluso el rechazo del acuerdo. O an sin llegar a tal extremo, esta
situacin provocar una gran distraccin y una inversin extra de tiempo. Esto se traduce en
no prestar suficiente atencin a otras reas del contrato que necesitan ser dirigidas.
Si se llega a este punto deberan plantearse cuestiones como:
Ser una estrategia de negociacin de la otra parte? Lo habrn hecho de forma
deliberada?
Realmente la otra parte entiende el negocio y los requisitos?
Es realmente un buen negocio o el contrato debera actuar como aviso de lo que
pasar en el futuro?
2.5.2.2. Ser conscientes de herramientas y tcnicas
El uso de herramientas, tcnicas y servicios de informacin aumenta la calidad de la gestin
de riesgos. Se deberan utilizar estas herramientas para reducir el tiempo en desempear
las tareas, generar nuevas ideas y evitar la repeticin de errores pasados. Por ejemplo, el

uso de amplios rangos de trminos mediante checklists, libros, artculos o pginas web que
proporcionen informacin sobre estndares, debatir sobre tcnicas o generar herramientas
propias para la empresa puede mejorar el enfoque y los resultados.
2.5.2.3. Posesin de la gestin de riesgos
Los riesgos en muchas compaas se dividen en reas. Los expertos ven su conocimiento
como una fuente de control y poder, en vez de utilizarlo para mejorar la organizacin con
innovacin y creatividad, no slo para evitar riesgos inoportunos.
Los expertos en contratos, tanto de parte de los proveedores como de los adquiridores,
normalmente se quejan de que se involucran demasiado tarde en el proceso de adquisicin
y de esta forma queda limitada su contribucin.
Los expertos tienen dos tendencias que deben evitarse:
Se transforman en cuellos de botella: ellos hacen pasar todas las situaciones por
ciclos de revisin y por lo tanto ralentizan los tiempos de cada ciclo y amenazan el
trabajo en equipo.
Llegan a obsesionarse con el anlisis: en su determinacin para compartir
experiencia y valor, ellos ven su role, errneamente, como si fuesen responsables de
identificar y listar todos y cada uno de los problemas que puedan prever. Ellos fallan
en cuantificar, calificar y priorizar los problemas. El resultado es que sobre sus
compaeros de trabajo, no tan expertos, recaer la decisin de qu hacer, cmo
manejar los problemas que les van llegando, incluso tendrn que decidir si ignorar
los riesgos que vayan apareciendo.
Proceso de gestin de riesgos
El grfico siguiente muestra una visin tpica del proceso de gestin de riesgos y puede
relacionarse de forma directa con el desarrollo y gestin de contratos. Estos elementos
deberan ser relevantes, en particular la necesidad de priorizar y la de medir y controlar ya
que normalmente son debilidades de la mayora de las organizaciones.
Explorar
incertidumbre
Analizar riesgos Priorizar riesgos Mitigar riesgos
Planes de
emergencia
Medicin y control
Figura 3 Proceso de gestin de riesgos
En el siguiente grfico se ven 3 cajas adicionales resultantes de un enfoque de mejores
prcticas:

Explorar
incertidumbre
Entender
oportunidades
Analizar riesgos Priorizar riesgos Mitigar riesgos
Planes de
emergencia
Modelar el negocio
Desarrollar el
contrato
Medicin y control
Figura 4 Mejora del proceso de gestin de riesgos
Las organizaciones deberan plantearse preguntas como:
Son correctas las suposiciones realizadas sobre las condiciones y trminos del
contrato?
Se est utilizando el acuerdo y modelo de relaciones correcto?
Las mtricas o trminos estndar utilizados son inapropiados?
Estamos analizando las races de las necesidades del negocio y requisitos?
Se estn utilizando herramientas de gestin para asegurar los mejores resultados
en la contratacin?
Uno de los elementos clave del papel del especialista en contratos es modelar el
negocio, asegurando que los requisitos u oportunidades se ajustan a los trminos de
negocio propuestos. Muy a menudo las organizaciones intentan modelar las oportunidades
para que encajen con los contratos y polticas disponibles pensando que es una forma de
reducir riesgos, pero en realidad no lo es. Esto puede contener riesgos ya que no se reduce
la probabilidad de que las cosas vayan mal. Lo que se debera hacer es:
Reducir el coste que supone un mala calidad de los contratos
Aumentar los ingresos, y para ello conseguir mejores acuerdos, negociaciones
exitosas, y realizar una buena gestin de contratos.
2.6. PROCEDIMIENTO DE CIERRE DEL CONTRATO
Como en todas las fases de gestin del contrato, es necesario definir un procedimiento de
cierre de contrato que aborde paso a paso los trminos y condiciones de los contratos y
todos los criterios de salida requeridos para el cierre del contrato.
El procedimiento de cierre de contrato incluye todas las actividades e interacciones
requeridas para establecer y cerrar todo acuerdo contractual establecido para el proyecto, y

tambin para definir aquellas actividades relacionadas que respaldan el cierre administrativo
formal del proyecto. Este procedimiento implica tanto la verificacin del producto (todo el
trabajo completado de forma correcta y satisfactoria) como el cierre administrativo
(actualizacin de registros de contrato para reflejar los resultados finales y archivo de esa
informacin para su uso futuro). Los trminos y condiciones del contrato tambin pueden
establecer especificaciones para el cierre del contrato, que deben ser parte de este
procedimiento. La finalizacin anticipada de un contrato es un caso especial de cierre del
contrato que podra suponer, por ejemplo, la incapacidad para entregar el producto, una
desviacin de presupuesto o la falta de los recursos requeridos.
Tiene que comprender todas las actividades y responsabilidades relacionadas de los
miembros del equipo del proyecto, de los clientes y de los dems interesados involucrados
en el proceso de cierre del contrato. Las acciones realizadas cierran formalmente todos los
contactos relacionados con el proyecto completado.
Algunas de las actividades que debe contemplar son:
- Verificar el cumplimiento del contrato (del alcance).
- Obtencin de informes, autorizaciones
- Confirmacin del cumplimiento de otras obligaciones contractuales.
- Resolucin de desacuerdos.
- Aseguramiento del cumplimiento de las obligaciones posteriores.
- Registro de toda la documentacin as como lecciones aprendidas.
Tabla 11 Entradas, salidas y herramientas del cierre del contrato
adquisiciones.
Documentacin del contrato.
Procedimiento de cierre del
contrato.
Contratos completados.
organizacin (actualizaciones).
Auditoras de adquisicin.
Sistemas de gestin de
registros.
2.6.1. Procedimiento de Cierre Administrativo
Este procedimiento forma parte del procedimiento de Cierre del Contrato, de forma que
describe en detalle todas las actividades, interacciones, roles y responsabilidades
relacionados con los miembros del equipo del proyecto y de los dems interesados
involucrados en la ejecucin del procedimiento de cierre administrativo del proyecto.
Realizar el proceso de cierre administrativo tambin incluye las actividades integradas
requeridas para recopilar los registros del proyecto, analizar el xito o el fracaso del

proyecto, reunir las lecciones aprendidas y archivar la informacin del proyecto, para su uso
futuro por parte de la organizacin
2.6.2.
2.6.3.
Verificacin del alcance
La verificacin del alcance es el proceso de obtener la aceptacin formal por parte de los
interesados del alcance del proyecto completado y los entregables relacionados. Verificar el
alcance del proyecto incluye revisar los entregables para asegurarse de que cada uno se
complete satisfactoriamente. Si el proyecto se termina antes de lo previsto, el proceso de
verificacin del alcance del proyecto debera establecer y documentar el nivel y alcance
completado.
La verificacin del alcance se diferencia del control de calidad en que la verificacin del
alcance se relaciona principalmente con la aceptacin de los entregables, mientras que el
control de calidad se relaciona principalmente con cumplir los requisitos de calidad
especificados de los entregables. Por lo general, el control de calidad se realiza antes de la
verificacin del alcance, pero estos dos procesos pueden realizarse de forma paralela.
Los criterios de aceptacin del producto y las acciones relativas a este proceso deben estar
claramente reflejados en el contrato.
La aceptacin puede ocurrir a diferentes niveles:
Aceptacin incondicional: significa que el producto o servicio cumple con los
requisitos contemplados en el contrato.
Aceptacin parcial: slo algunas partes son aceptadas.
Aceptacin completa con condiciones: el contratante tiene obligaciones sobre el
producto tras la entrega.
Rechazo total: el producto falla en alguno de los requisitos contractuales
fundamentales.
Obligaciones posteriores
Antes de la finalizacin de contrato, hay que revisar el mismo para encontrar aquellas reas
en las que alguna de las partes debe mantener unas responsabilidades posteriores. Algunas
de ellas pueden referirse a:
- Proteccin de la propiedad intelectual.
- Licencias.
- Servicios de mantenimiento y garanta.
- Actualizaciones de producto, nuevas versiones.
- Conservacin de la informacin y los registros.

2.6.4.
2.6.5.
Lecciones aprendidas
Una buena prctica, una vez que el contrato ha finalizado, consiste en realizar una
evaluacin para identificar las fortalezas y deficiencias encontradas en el proceso de gestin
durante todo el ciclo de vida.
Para recoger estas lecciones aprendidas se puede llevar a cabo una auditora de
adquisicin, es decir, una revisin estructurada del proceso completo de adquisicin. El
objetivo es identificar los xitos y fracasos que merecen ser reconocidos en la preparacin o
administracin de otros contratos de adquisicin en el proyecto, o en otros proyectos dentro
de la organizacin.
Algunas de las lecciones que pueden obtenerse se muestran a continuacin:
- Aspectos que han funcionado bien y deberan volver a usarse.
- Prcticas que no han funcionado y deberan ser evitadas.
- Cambios posibles a introducir en el desarrollo del prximo proyecto.
- Prioridad en la resolucin de los problemas e identificacin de aquellos que deben
evitarse.
- Conclusiones e informacin sobre el contratante, proveedor, procesos y recursos
usados para llevar a cabo el proyecto.
- Exactitud del estudio de mercado.
- Estrategia de negociacin elegida.
- Adecuacin de la documentacin.
- Formato del contrato.
Finalmente, otra buena prctica antes del cierre total del proyecto, es realizar una reunin
con todo el equipo que ha formado parte del mismo, para realizar una revisin del desarrollo
del proyecto.
Documentacin de cierre de proyecto
Uno de los puntos claves durante el proceso de cierre de proyecto es desarrollar una buena
documentacin. Conviene registrar aquellas acciones o hechos que permiten sacar
conclusiones tiles y lecciones aprendidas para futuros contratos, y mantener esta
documentacin disponible.
El cierre incluir el desarrollo del ndice y la ubicacin de la documentacin del proyecto:
- Documentacin de aceptacin formal. Se ha recibido la confirmacin formal por
parte del cliente o del patrocinador, estableciendo que se ha cumplido con los
requisitos y las especificaciones del cliente para el producto, servicio o resultado del
proyecto. Este documento indica formalmente que el cliente o patrocinador ha
aceptado oficialmente los entregables.

- Archivos del proyecto. Documentacin que resulta de las actividades del proyecto;
por ejemplo, el plan de gestin del proyecto, el alcance, el coste, el cronograma y las
lneas base de calidad, los calendarios del proyecto, los registros de riesgos, las
acciones de respuesta a riesgos que fueron planificadas y el impacto del riesgo.
- Documentos de cierre del proyecto. Los documentos de cierre del proyecto
constituyen la documentacin formal que indica la conclusin del proyecto y la
transferencia de los entregables del proyecto completados a un grupo de
operaciones, por ejemplo. Si el proyecto se da por finalizado antes de su conclusin,
la documentacin formal indica la razn por la cual se finaliz el proyecto, y formaliza
los procedimientos para la transferencia de los entregables finalizados.
- Informacin del histrico. La informacin del histrico y la informacin de las
lecciones aprendidas se transfieren a la base de conocimientos de lecciones
aprendidas para su uso en futuros proyectos.

3. ENFOQUE DE MODELOS
En este apartado se pretende definir el enfoque que distintos modelos orientados a la
gestin de adquisiciones como son CMMIpara adquisiciones (CMMI-ACQ) y un modelo
de madurez y capacidad desarrollado por la asociacin IACCM (International Association for
Contract and Commercial Management), dan a este tema.
3.1. CMMI-ACQ
Capability Maturity Model Integration (CMMI) es un modelo para la mejora de procesos que
proporciona a las organizaciones los elementos esenciales para desarrollar procesos
eficaces.
Los componentes de CMMIestn organizados en agrupaciones llamadas constelaciones,
cada una de ellas orientada a un rea de inters:
CMMIfor Development (CMMI-DEV).
CMMIfor Services (CMMI-SVC).
CMMIfor Acquisition (CMMI-ACQ).
CMMIDEV
Proporcionaguasparamedir,
controlarygestionarlos
procesosdedesarrollo
CMMISVC
Proporcionaguaspara
aquellosqueproveen
serviciosdentrodela
organizacinyaclientes
externos
CMMIACQ
Proporcionaunaguapara
habilitarunagestinen
adquisicionesinformaday
decisiva
16reas
de
proceso
usadasen
todos
Figura 5 Constelaciones de CMMI
Cada una de estas constelaciones se compone de los siguientes elementos:
Modelo.
Materiales de formacin.
Mtodo de evaluacin.

En esta gua, vamos a centrarnos en la constelacin de CMMI para la gestin de
adquisiciones.
Vamos a realizar una introduccin al modelo de mejora de procesos para la gestin de
adquisiciones CMMI-ACQ. Este modelo proporciona un conjunto de buenas prcticas para
la adquisicin de productos y servicios. Todas las prcticas de CMMI-ACQse centran en
las actividades del adquiridor. Estas actividades incluyen la seleccin de proveedores,
desarrollo y formalizacin de contratos con los proveedores y gestin de la adquisicin de
productos y servicios.
CMMI-ACQtiene 22 reas de proceso que vamos a describir a continuacin.
Las 22 reas de proceso de CMMI-ACQpodemos clasificarlas atendiendo al nivel de
madurez y a la categora a la que pertenecen. CMMI-ACQestablece cuatro categoras:
Gestin de proyecto, Gestin de procesos, Adquisicin y Soporte.
Tabla 12 Clasificacin de reas de proceso
Gestin de procesos Gestin de proyecto Adquisicin Soporte
Nivel
5
Innovacin y
Despliegue en la
Organizacin (OID)
Anlisis y Resolucin
de Causas (CAR)
Nivel
4
Rendimiento de los
Procesos de la
Organizacin (OPP)
Gestin Cuantitativa de
Proyectos (QPM)
Nivel
3
Enfoque en los
Procesos de la
Organizacin (OPF)
Definicin de los
Procesos de la
Organizacin (OPD)
Formacin
Organizativa (OT)
Gestin de Riesgos
(RSKM)
Gestin Integrada de
Proyecto (IPM)
Gestin Tcnica de
la Adquisicin (ATM)
Verificacin de la
Adquisicin (AVER)
Validacin de la
Adquisicin (AVAL)
Anlisis y Resolucin
de Decisiones (DAR)
Nivel
2
Planificacin de
Proyecto (PP)
Seguimiento y Control
de Proyecto (PMC)
Gestin de Requisitos
(REQM)
Solicitud y Desarrollo
de Acuerdos con
Proveedores (SSAD)
Desarrollo de
Requisitos de la
Adquisicin (ARD)
Gestin de Acuerdos
(AM)
Aseguramiento de la
Calidad (PPQA)
Medicin y Anlisis
(MA)
Gestin de
Configuracin (CM)

Vamos a centrarnos en la categora de adquisicin. A continuacin se describen las reas
que pertenecen a esta categora:
Tabla 13 Descripcin de reas de proceso de adquisicin
rea de proceso Propsito
Desarrollo de Requisitos de la
Adquisicin (ARD)
Desarrollar y analizar los requisitos del cliente y del contrato.
Gestin de Acuerdos (AM)
Asegurar que el proveedor y el adquiridor llevan a cabo sus actividades
de acuerdo al acuerdo/contrato establecido.
Gestin Tcnica de la
Adquisicin (ATM)
Evaluar la solucin tcnica del proveedor y gestionar las interfaces
seleccionadas de la solucin.
Solicitud y Desarrollo de
Acuerdos con Proveedores
(SSAD)
Preparar la solicitud, seleccionar uno o ms proveedores para
proporcionar el producto o servicio, y establecer y mantener el acuerdo
con los proveedores.
Verificacin de la Adquisicin
(AVER)
Asegurar que los productos seleccionados cumplen con sus requisitos
especificados.
Validacin de la Adquisicin
(AVAL)
Demostrar que un producto o servicio adquirido cumplen con su uso
previsto cuando se coloca en su entorno previsto.
Desarrollo de Requisitos de la Adquisicin (ARD): el propsito del desarrollo de
requisitos de la adquisicin es desarrollar y analizar los requisitos del cliente y del contrato.
Los objetivos y las prcticas relacionadas con esta rea son:
SG 1 Desarrollar los requisitos del cliente
SP 1.1 Recoger las necesidades de las personas involucradas en el negocio
SP 1.2 Desarrollar y priorizar los requisitos del cliente
SG 2 Desarrollar los requisitos del contrato
SP 2.1 Establecer los requisitos del contrato
SP 2.2 Asignar los requisitos del contrato
SG 3 Analizar y validar los requisitos
SP 3.1 Establecer los conceptos y escenarios operacionales
SP 3.2 Analizar los requisitos
SP 3.3 Analizar los requisitos para conseguir equilibrio
SP 3.4 Validar los requisitos
Gestin de acuerdos (AM): el propsito de la gestin de acuerdos es asegurar que el
proveedor y el adquiridor llevan a cabo sus actividades de acuerdo al acuerdo/contrato
establecido.

SG
1
1 Satisfacer los acuerdos con los proveedores:
SP 1.1 Realizar el acuerdo con los proveedores
SP 1.2 Monitorizar los procesos de proveedores
SP 1.3 Aceptar la entrega de productos adquiridos
SP 1.4 Gestionar facturas de los proveedores
Gestin tcnica de la adquisicin (ATM): el propsito de la gestin tcnica de la
adquisicin es evaluar las soluciones tcnicas del proveedor y gestionar las interfaces
seleccionadas de la solucin.
SG 1 Evaluar las soluciones tcnicas
SP 1.1 Seleccionar las soluciones tcnicas para el anlisis
SP 1.2 Analizar las soluciones tcnicas seleccionadas
SP 1. 3 Llevar a cabo revisiones tcnicas
SG 2 Realizar la gestin de interfaces
SP 2.1 Seleccionar las interfaces a gestionar
SP 2.2 Gestionar las interfaces seleccionadas
Solicitud y Desarrollo de Acuerdos con Proveedores (SSAD): el propsito de la solicitud
y desarrollo de acuerdos con proveedores es preparar la solicitud, seleccionar uno o ms
proveedores para proporcionar el producto o servicio, y establecer y mantener el acuerdo
con los proveedores.
SG 1 Preparar la solicitud y desarrollo de acuerdos con proveedores
SP 1.1 Identificar proveedores potenciales
SP 1.2 Establecer un paquete de solicitud
SP 1.3 Revisar el paquete de solicitud
SP 1.4 Distribuir y mantener el paquete de solicitud
SG 2 Seleccionar proveedores
SP 2.1 Evaluar las soluciones propuestas
SP 2.2 Establecer planes de negociacin
SP 2.3 Seleccionar proveedores

1
Specific Goal: Meta especfica a alcanzar en un rea de proceso, segn CMMI.

SG 3 Establecer acuerdos con proveedores
SP 3.1 Establecer un entendimiento del acuerdo
SP 3.2 Establecer el acuerdo con el proveedor
Verificacin de la adquisicin (AVER): el propsito de la verificacin de la adquisicin es
asegurar que los productos seleccionados cumplen con sus requisitos especificados.
SG 1 Preparar la verificacin
SP 1.1 Seleccionar los productos de trabajo para la verificacin
SP 1.2 Establecer el entorno de verificacin
SP 1.3 Establecer los procedimientos y criterios de verificacin
SG 2 Realizar revisiones entre pares
SP 2.1 Preparar las revisiones entre pares
SP 2.2 Realizar las revisiones entre pares
SP 2.3 Analizar los datos de las revisiones entre pares
SG 3 Verificar los productos de trabajo seleccionados
SP 3.1 Realizar la verificacin
SP 3.2 Analizar los resultados de la verificacin
Validacin de la adquisicin (AVAL): el propsito de la validacin de la adquisicin es
demostrar que un producto o servicio adquirido cumplen con su uso previsto cuando se
coloca en su entorno previsto.
SG 1 Preparar la validacin
SP 1.1 Seleccionar los productos a validar
SP 1.2 Establecer el entorno de validacin
SP 1.3 Establecer procedimientos y criterios de validacin
SG 2 Validar los productos y componentes de los productos seleccionados
SP 2.1 Realizar la validacin
SP 2.2 Analizar los resultados de la validacin
3.2. IACCM CAPABILITY MATURITY MODEL
IACCM (International Association for Contract and Commercial Management) es una
fundacin sin nimo de lucro reconocido como la autoridad internacional sobre contratacin
y gestin de compromisos. IACCM define un modelo de madurez y capacidad del que se va
a tratar en este apartado.

El modelo de IACCM proporciona la capacidad de evaluar el estado de las funciones de
contratos comerciales. Las organizaciones que usan este modelo son capaces de identificar
cmo se relacionan los estndares globales de forma rpida y de definir un programa de
cambio relevante para su negocio.
El modelo de madurez y de capacidad del IACMM fue desarrollado por un equipo
internacional formado por personal con experiencia perteneciente a distintas industrias, y
dirigido por Tim McCarthy miembro del IACCM, utilizando experiencia 6-Sigma y tcnicas en
diseo. El equipo desarroll una herramienta que permite la evaluacin rpida y exacta del
rendimiento tanto del comprador como del proveedor.
Aunque trata con nueve dimensiones de negocio, su foco est en la alineacin de las salidas
de negocio en el mercado o en la seleccin de proveedores, trminos y alineamiento de
ofertas y salidas. Una caracterstica nica de la herramienta online de IACCM es que los
resultados se comparan de forma inmediata con un portafolio de compaas y procesos
similares.
La metodologa y las herramientas asociadas han sido probadas y validadas por ms de 200
profesionales y responsables de la gestin de proyectos de ms de 15 pases, para
asegurar su facilidad de uso y generar resultados exactos. Estos usuarios iniciales tambin
proporcionaron el conjunto inicial de datos que permitirn a los usuarios futuros realizar
comparativas inmediatas.
Los usuarios iniciales han evaluado sus procedimientos de contratos, negociacin y gestin
de contratos. Para esta evaluacin, IACCM ha desarrollado un plan en 6 pasos rpidos y
exactos. El objetivo es dar soporte a la generacin de un plan de mejora de negocio
documentado y con un clculo del coste, en 30 das.
Paso 1. La comparacin de madurez y el anlisis de debilidades
IACCM establece un portal para permitir realizar la recoleccin de datos online.
1. Realizar autoevaluacin del rendimiento del proceso actual.
2. Realizar un anlisis para identificar las perspectivas de usuario de la madurez del
proceso (encuesta web).
3. Comparar las distintas visiones de los usuarios o participantes, para identificar las
debilidades clave de los procesos actuales y elementos para realizar una
investigacin ms detallada.
4. Usar IACCM proporciona datos de comparacin para identificar debilidades clave de
los procesos actuales.

Paso 2. Desarrollo de propuesta de valor de capacidad/solicitud de necesidad
Puede desarrollarse de forma paralela al paso 1.
Analizar las estrategias corporativas y metas en la solicitud de las salidas requeridas del
proceso (entregables y caractersticas):
- Necesidad
- Estado actual (debilidades/inhibidores)
- Habilidad para crearse
Paso 3. Establecer el marco de trabajo para los resultados medibles
Desarrollo de planes para mtricas en evolucin, que permitir mejoras y anlisis continuado
y darn soporte a evaluaciones iniciales del ROI y validacin de los resultados.
Paso 4. Definir proyectos y resultados potenciales
Las iniciativas requeridas para orientar las mejoras sern definidas como proyectos
discretos. Cada proyecto estar basado en salidas especficas y medibles que incluyan tanto
objetivos cuantitativos como cualitativos.
Paso 5. Priorizacin
Anlisis de la importancia relativa y costes de los programas de mejora: para cada iniciativa
potencial, trazar su relacin con los recursos necesarios (teniendo en cuenta las prioridades
establecidas en los pasos 1 y 2). Este anlisis permitir determinar el coste total del
programa de mejora y dar soporte a la priorizacin.
Paso 6. Creacin del plan de negocio
Consolidar los datos para definir recomendaciones y establecer un consenso interno.
Las secciones del plan deberan incluir:
- Por qu es importante contratar calidad?
- Qu est yendo mal?
- A qu ha sido debido?
- Qu mejoras pueden conseguirse?
- Los beneficios resultantes
- Anlisis de importancia vs Costes
- Acciones recomendadas
- Lo que conllevar conseguirlo: Tiempo, personas, coste, compromiso ejecutivo
(sponsors)

4. ANEXO I: MTODOS DE SOLICITUD DE INFORMACIN
A continuacin se describirn ms en detalle en qu consisten algunos mtodos de solicitud
de informacin.
4.1. DOCUMENTO RFI (REQUEST FOR INFORMATION)
Una solicitud de informacin o RFI es muy similar a una solicitud de propuesta o RFP
excepto porque RFI es utilizada con antelacin para tomar decisiones de
desarrollo/adquisicin, mientras que RFP se utiliza despus de haber tomado la decisin de
desarrollo o adquisicin.
Incluso si una compaa tiene la capacidad de desarrollar un producto/servicio, puede
querer tener conocimiento acerca de lo que costara que un proveedor externo se lo
proporcionase. En algunos casos la compaa puede no tener claro cmo desarrollar estos
productos/servicios, en cuyo caso se ver en la necesidad de utilizar una fuente externa que
los proporcione.
Por ejemplo, si una compaa fabrica coches y necesita que alguien desarrolle un software
para comparar las ventas con las de otras fabricas. En este caso puede que la empresa no
tenga a un experto que desarrolle dicho software y necesite que un proveedor proporcione
dicho producto.
Normalmente, RFI es utilizado para determinar si un proyecto sera beneficioso para la
compaa o no, y para ayudar a determinar la viabilidad de desarrollar un producto o servicio
internamente, obtenerlos de un proveedor externo o simplemente no hacer nada al respeto.
4.1.1. Comenzar la solicitud de informacin
La mejor forma de comenzar el proceso de RFI es dirigir unas sesiones de recogida de
requisitos (RGS). En estas sesiones, distintas personas de distintas reas (del rea
tcnica, funcional o de negocio) discuten acerca del propsito del proyecto/servicio.
Las personas de negocio desarrollan un caso de negocio para la propuesta del
proyecto/servicio basndose en sus necesidades. Las personas del rea funcional discuten
acerca de lo que necesitan y la gente tcnica traduce estas necesidades en trminos
tcnicos. Entonces las personas de negocio expresan los requisitos funcionales y tcnicos
en requisitos de negocio.
Estos requisitos son trasladados a un documento que formar parte de la propuesta de
informacin RFI. Desde ese momento se trabajar para desarrollar y distribuir un RFI
completo y exhaustivo a los distintos proveedores.
Se deber seleccionar un equipo que defina y escriba dicho documento. Es importante en
un primer momento identificar a las personas involucradas en el negocio y seleccionar a los
miembros del equipo que sean necesarios para proporcionar informacin y obtener la

aprobacin de los proyectos. El nivel de involucracin depender de las responsabilidades
de los distintos actores en el desarrollo del RFI.
Sern necesarios los siguientes roles:
- El sponsor ejecutivo: es un ejecutivo a alto nivel que tiene autoridad para recaudar
fondos y aprobar el proyecto y acepta la responsabilidad del documento RFI durante
todo el proceso, aunque no est involucrado en el da a da del proceso RFI.
- El jefe de proyecto: es una persona con habilidades en el uso de herramientas de
control de proyectos y de toma de mtricas durante la evolucin de los mismos.
Sirven como facilitadores para el RGS, controlan el proyecto RFI y ayudan en la
preparacin del documento RFI. Si por ejemplo es necesaria una propuesta de
trabajo como parte del RFI, el jefe de proyecto ser el encargado de escribirlo.
- Representantes tcnicos, incluyendo aquellos que provienen de TI, ingeniera,
calidad u otras disciplinas relevantes: juegan un papel fundamental proporcionando
informacin tcnica necesaria para crear el RFI. Ellos definen los estndares de
calidad a aplicar al proyecto y todos los parmetros de sistema y hardware. Como se
coment antes, tambin son responsables de transformar los requisitos funcionales
de un proyecto en lenguaje tcnico que pueda ser entendido y utilizado por
proveedores para completar sus respuestas para el RFI.
- Representantes legales: el departamento legal no est involucrado en el desarrollo
del RFI da a da, pero proporciona consejo y asesoramiento en cuanto a trminos,
lenguaje y condiciones legales que puedan ser requeridos en el RFI.
- Representantes de gestin de contrato: actan como punto de control central para
la creacin del documento RFI. Ellos proporcionan la lista de proveedores que
tienen la capacidad para participar en el proceso RFI. Si hubiese solicitudes de
proveedores que todava no han sido aprobados, y por lo tanto no forman parte de
la lista de proveedores, ellos sirven como punto para solicitar, recibir y distribuir
cualquier informacin de los nuevos proveedores potenciales.
- Otras personas que puedan proporcionar entradas al producto/solucin, como
recursos humanos, gestin de cambio o mtricas de rendimiento corporativas
4.1.2. Contenido del RFI
Cada documento RFI debera contener una serie de elementos bsicos como:
- Una carta de presentacin: Debera expresar la intencin de la compaa en
recoger informacin necesaria para tomar decisiones de negocio relativas a las
necesidades futuras de desarrollo/adquisicin de un producto o servicio particular.
Dejar claro que la compaa evaluar todas las respuestas de los distintos
proveedores en base a los requisitos tcnicos, funcionales y requisitos de negocio.
- Una visin general ejecutiva de RFI: Explicara, a un alto nivel, lo que se espera del
producto/servicio que se quiere adquirir. Explicar que si este proyecto se convierte en

una situacin de adquisicin los proveedores deben entender cmo se utilizar el
producto/servicio dentro del proceso de la compaa.
- Formato de respuesta: El documento RFI tambin debera incluir un formato de
respuesta recomendado u obligatorio. Debera incluir:
o Una carta de recomendacin que incluya nombre, direccin e informacin de
contacto de la persona que acta en representacin del proveedor.
o Explicaciones y alternativas conceptuales de cmo se cumplirn los
requisitos.
o Evaluacin de la viabilidad de cada alternativa propuesta
o Informacin adicional relativa al RFI: sugerencias
o Cualquier dato o material que no se haya requerido especficamente para la
evaluacin pero que el proveedor desea contemplar.
o Estimacin de costes y agenda
- Informacin requerida acerca de los proveedores: Informacin relevante sobre la
manera en la que los proveedores manejan su negocio: recursos disponibles y
aptitudes, estndares y metodologas utilizadas, trabajos similares realizados para
otras compaas, restricciones legales, informacin financiera, experiencia previa en
el tema, nmero de aos en el negocio....
- Requisitos tanto funcionales como tcnicos a un alto nivel.
- Requisitos de fijacin de presupuesto: Ya que este documento no se trata de una
solicitud de propuesta detallada, slo ser necesario recibir informacin a un alto
nivel del presupuesto para el proyecto (fijar precio de requisitos, lista de
honorarios,).
- Trminos y condiciones: En el documento RFI se deberan incluir trminos y
condiciones legales, que deberan ser aceptados por los proveedores como parte de
la evaluacin.
- Requisitos de seguridad: El departamento de seguridad definir todos los requisitos
de seguridad que se incluirn en el RFI. Se debera comunicar a los proveedores la
necesidad de que aadan todos los requisitos de seguridad.
4.1.3. Revisin, validacin y distribucin
Durante el desarrollo del RFI, pueden realizarse distintas reuniones de control con los
miembros del equipo para validar y aprobar lo que se ha escrito.
Cuando el RFI est completamente escrito y listo para distribuirlo a los proveedores, todos
los miembros del equipo deberan revisarlo. Una vez que el RFI se ha validado y aprobado,
la gestin del contrato liberar el RFI a los proveedores.
RFI es establecido nicamente con informacin y propsitos de planificacin. Las
respuestas de RFI no son ofertas y no son generalmente aceptadas para ser vinculantes a
contratos.

4.2. DOCUMENTO RFP (REQUEST FOR PROPOSAL)
Una vez tomada la decisin de adquirir un producto o servicio, se utiliza un RFP para
obtener la mejor solucin. Generalmente los RFPs son utilizados cuando la adquisicin es
muy compleja y ser necesario liberar gran cantidad de informacin a los futuros
proveedores.
La solicitud de propuesta, a la que se har referencia con las siglas RFP, debera incluir,
idealmente, todo lo que un proveedor potencial necesita para alcanzar y poner precio al
producto. Adems se deberan proporcionar instrucciones completas para responder al RFP.
La gestin de contratos deber seleccionar a un equipo que defina y escriba el documento
RFP. Es importante identificar a los miembros del equipo adecuados para proporcionar
informacin y obtener la aprobacin de los proyectos. El nivel de involucracin de cada uno
depender de las responsabilidades de los distintos actores en el desarrollo del RFP, al
igual que ocurra con el documento RFI.
Los representantes tcnicos de la empresa adquiridora debern incluir en el RFP aquellos
requisitos tcnicos y especificaciones de los productos /servicios. Si no se enva un conjunto
de requisitos completo a los proveedores, ser ms difcil llevar a cabo las negociaciones
con xito. La palabra clave de RFP es requisitos. Por ello ser necesario tener reuniones
con los representantes tcnicos para asegurar todos los requisitos tcnicos, las
funcionalidades y las especificaciones enviadas a los proveedores.
Es importante asegurar recursos para satisfacer los requisitos tcnicos. Para ello:
- Ser necesario que la empresa proveedora tenga un equipo de proyecto con
habilidades y experiencia necesaria para dar soporte al proyecto. (Identificar
individuos y sus habilidades)
- La empresa proveedora deber hacerse responsable de todas las actividades de
formacin en habilidades necesarias.
- Requerir que exista una comunicacin entre los proveedores y la compaa que
solicita la adquisicin mediante reuniones peridicas. (Establecer canales y procesos
de comunicacin robustos)
- Solicitar a los proveedores que complementen los entregables necesarios, iniciar
las revisiones e inspecciones utilizando una metodologa repetitiva.
Cuando el RFP est completamente escrito y listo para distribuirlo a los posibles
proveedores, ser revisado una ltima vez por los miembros del equipo del la empresa
adquiridora. Una vez que todos los miembros han validado y aprobado el RFP, la gestin de
contratos liberar el RFP a los proveedores. La gestin de contratos tiene control absoluto
de distribucin de cualquier comunicacin verbal y escrita en el proceso de RFP.
4.2.1. Roles y responsabilidades
Durante la creacin de RFP se vern involucrados unos roles similares a los del documento
RFI, incluso el formato del documento tambin ser tambin similar.

El departamento de la gestin de contrato, del que se ha hablado con anterioridad, a
menudo acta como punto de control central de la creacin del documento RFP. Desde all
se proporciona la lista de proveedores aprobados que han sido calificados para participar en
el proceso de RFP. Si hay solicitudes de proveedores que no pertenecen a la lista de
proveedores aprobados, las personas responsables del departamento de gestin de
contrato servirn de foco para solicitar, recibir y distribuir cualquier informacin de los
nuevos proveedores potenciales. Si es necesario celebrar alguna reunin con los
proveedores durante el proceso de RFP, el responsable de contratos coordinar la
agenda y el formato de la reunin tomando el papel de moderador.
Una vez que se toma la decisin de adquirir, se debera contactar con el departamento que
gestiona los contratos para poder comenzar a seleccionar un equipo para definir y escribir
el RFP. Es importante identificar a todos los miembros que puedan aportar informacin o
aprobacin a los proyectos.
Entre los miembros del equipo se debera incluir un sponsor ejecutivo y un jefe de proyecto,
al igual que representantes tecnolgicos, legales, de seguridad, de soporte y de gestin de
contrato.
4.2.2. Gestin de RFP
La gestin de RFP requiere gestionar un rango de procesos durante el periodo de seleccin
de proveedores. El proceso de gestin de RFP requiere un consumo de tiempo y un gran
compromiso de trabajo. Escribir el RFP es solo una pequea parte del proceso total que
comienza con la seleccin y formacin del equipo de personas que llevarn a cabo todo el
proceso de seleccin del proveedor, y finaliza con la seleccin y notificacin de un
proveedor que ser quien finalmente satisfaga las necesidades de la adquisicin.

5. GLOSARIO
- Acuerdo: convenio documentado entre dos o ms partes que pueden ser el
adquiridor y el proveedor (p.ej.: contrato, licencia, memoria de acuerdo, etc.)
- Acuerdo de nivel de servicio (SLA Service Level Agreement): acuerdo entre un
proveedor de servicio y un cliente. El SLA describe el servicio IT, documenta los
objetivos de nivel de servicio, y especifica las responsabilidades del proveedor de
servicios y del cliente.
- Adquiridor: agente que adquiere u obtiene productos o servicios de un proveedor.
- Adquisicin: proceso de obtener productos o servicios a travs de acuerdos con
proveedores.
- Auditora: inspeccin y verificacin formal para comprobar si se sigue un estndar o
un conjunto de guas, que los registros son precisos o que se estn cumpliendo los
objetivos de eficiencia y eficacia. Una auditora puede llevarse a cabo por grupos
internos o externos a la organizacin.
- Anlisis de riesgos: proceso de evaluar riesgos identificados para estimar su
impacto y probabilidad de ocurrencia.
- Balanced Scorecard: El balanced scorecard es un sistema de gestin (no slo un
sistema de medida) que permite a la organizacin clarificar su visin y estrategia y
traducirlo en acciones. Fue creado por los Dres. Robert Kaplan y David Norton.
- Buenas prcticas: mtodo superior o prctica innovadora que contribuye a la
mejora de rendimiento en una organizacin bajo un contexto dado, normalmente
reconocido como el mejor por otras organizaciones similares.
- Criterios de aceptacin: criterios de salida que un componente o sistema debe
satisfacer para ser aceptado por un usuario, un cliente, u otra entidad autorizada.
- Control de riesgos: proceso a travs del cual se toman decisiones y medidas de
proteccin para reducir o mantener los riesgos dentro de los niveles especificados.
- Calidad: grado con el que un componente o sistema satisface los requisitos
especificados y/o las necesidades y expectativas del usuario/cliente.
- Conflicto: situacin difcil, que conlleva un enfrentamiento de intereses y valores
considerados importantes.
- Contrato: acuerdo privado, oral o escrito, entre partes que se obligan sobre materia
o cosa determinada, y a cuyo cumplimiento pueden ser exigidas.
- Co-sourcing: prctica de negocio donde un servicio es ejecutado con personal
externo e interno a la organizacin.
- Coste total de la propiedad (TOC): mtodo de clculo usado para determinar los
costes directos e indirectos, as como los beneficios, relacionados con la compra de

equipos o programas informticos de forma que ofrece un resumen final que refleja
no slo el coste de la compra sino aspectos del uso y mantenimiento
- Coste: montante econmico que representa la fabricacin de cualquier componente
o producto, o la prestacin de cualquier servicio
- COTS: componente software diseado, elaborado y comercializado por terceras
partes, generalmente de bajo precio o de libre distribucin, utilizado por los
desarrolladores de software como partes preexistentes que puede incorporar en su
arquitectura sin crearlos.
- Cuello de botella: se produce cuando la capacidad de un recurso es igual o inferior
a la demanda.
- Eficiencia: capacidad del producto software para proporcionar el rendimiento
apropiado, relativo a la cantidad de recursos usados bajo las condiciones indicadas.
- Escalabilidad: capacidad del producto software de ser mejorado para contener
incrementos de carga.
- Especificacin: documento que especifica, de una forma completa, precisa y
verificable, los requisitos, diseo, comportamiento u otras caractersticas de un
componente o sistema, y con frecuencia, especifica tambin los procedimientos para
determinar si se ha cumplido lo que se ha propuesto.
- Estndar: es una especificacin que regula la realizacin de ciertos procesos o la
fabricacin de componentes para garantizar la interoperabilidad
- Estrategia de adquisicin: enfoque determinado para adquirir productos y servicios
que tiene en consideracin fuentes de proveedores, mtodos de adquisicin, tipos de
especificaciones de requisitos, tipos de acuerdos o contratos, y riesgos relacionados
con la adquisicin.
- Estrategia de negociacin: define la manera en que cada parte trata de conducir la
negociacin con el fin de alcanzar sus objetivos.
- Fiabilidad: capacidad del producto software para realizar las funciones requeridas
bajo las condiciones indicadas durante un periodo de tiempo especificado, o para un
nmero concreto de operaciones.
- Funcionalidad: capacidad del producto software de proporcionar funciones que
satisfagan las necesidades indicadas cuando el software se usa bajo las condiciones
especificadas.
- Hito: punto en el tiempo en un proyecto en el que entregables y resultados definidos
han de estar listos.
- Incidencia: cualquier evento que ocurra que requiera una investigacin.
- Indicador clave de rendimiento (KPI): mtrica de alto nivel de la efectividad y/o
eficiencia que se usa como gua y control progresivo del rendimiento.

- Insourcing: internalizacin de algn servicio y/o proceso con personal y recursos de
la compaa buscando una mejora de la eficiencia por la aplicacin de alguna ventaja
competitiva singular de la organizacin.
- Integracin: proceso de combinar componentes o sistemas en grandes montajes.
- Interoperabilidad: capacidad del producto software de interactuar con uno o ms
componentes o sistemas especificados.
- Jefe de proyecto: figura clave en la planificacin, ejecucin y control del proyecto,
con poder y autoridad para la toma de decisiones, se encarga de dirigir al equipo y
recursos para alcanzar los objetivos.
- Licencia software: contrato entre el titular del derecho de autor (propietario) y el
usuario del programa (usuario final), para utilizar ste en una forma determinada y de
conformidad con unas condiciones convenidas.
- Mantenibilidad: facilidad con la que un producto software puede ser modificado para
corregir defectos, para satisfacer nuevos requisitos, para hacer el mantenimiento
futuro ms sencillo, o adaptar a cambios de entorno.
- Mantenimiento: modificacin de un producto software una vez que se ha entregado
para corregir defectos, mejorar el rendimiento u otros atributos, o adaptar el
producto a un entorno modificado.
- Metodologa: estrategias de gestin, desarrollo y mantenimiento del software
orientadas a la calidad.
- Negociacin: proceso por el que las partes interesadas resuelven conflictos,
acuerdan lneas de conducta, buscan ventajas individuales o colectivas o procuran
obtener resultados que sirvan a sus intereses mutuos.
- Negocio: consecuencia de la correcta administracin de los recursos con un
resultado econmicamente positivo para las partes.
- No conformidad: no cumplimiento de un requisito especfico.
- Obtencin de requisitos: El proceso de identificar las necesidades y salvar las
disparidades entre los miembros involucrados en el negocio con el propsito de
definir y destilar los requisitos para cumplir con las restricciones definidas por dichos
miembros.
- Outsourcing (subcontratacin): se define como la contratacin de servicios
profesionales externos para satisfacer necesidades empresariales especficas.
- Planificacin: acciones llevadas a cabo para realizar planes y proyectos de diferente
ndole.
- Portabilidad: facilidad con la que un producto software puede ser trasladado de un
entorno software o hardware a otro.
- Prioridad: nivel de importancia asignada a un elemento, p.ej. un defecto.

- Priorizacin de requisitos: La priorizacin de requisitos es el proceso de asignar
prioridades a los requisitos, basndose en sus beneficios esperados y en la
importancia que tienen para la gente implicada en el proyecto, de tal forma que los
que tengan prioridades mayores puedan implementarse primero, como parte de un
ciclo de desarrollo incremental, iterativo
- Proceso: conjunto de actividades interrelacionadas, que transforman entradas en
salidas.
- Proveedor: entidad que proporciona productos o servicios que son adquiridos.
Entidad que tiene un acuerdo con un adquiridor para el diseo, desarrollo,
construccin, mantenimiento o provisin de los elementos que estn bajo los
trminos del contrato establecido.
- Proyecto: conjunto de actividades coordinadas y controladas con fecha de inicio y fin
asumido para conseguir un objetivo conforme a unos requisitos especficos,
incluyendo restricciones de tiempo, coste y recursos.
- Requisito: condicin o capacidad necesitada por un usuario para solucionar un
problema o conseguir un objetivo que debe ser satisfecho o posedo por un sistema
o un componente de un sistema para satisfacer un contrato, estndar, especificacin
u otro tipo de documento.
- Retorno de inversin (ROI): medicin del rendimiento de la inversin que sirve para
determinar la viabilidad de un proyecto.
- Reusabilidad: posibilidad de la reutilizacin del sistema o software en otro proyecto.
- Revisin: evaluacin del estado de un producto o proyecto para averiguar
discrepancias de los resultados planificados y recomendar mejoras. Como ejemplos
se incluyen revisin informal, revisiones tcnicas, inspecciones
- Riesgo: factor que puede resultar en una consecuencia negativa en el futuro;
normalmente expresado como impacto y probabilidad.
- Roles: distintos papeles que cumplen las personas dentro de una organizacin
- Sesin de recogida de requisitos (RGS): reuniones en las que diversas personas
de distintas reas (del rea tcnica, funcional o de negocio) discuten acerca del
propsito del proyecto/servicio.
- Sistema abierto: sistema construido acorde a unos estndares y tecnologas
abiertas y disponibles.
- Sistema: coleccin de componentes organizados para conseguir una funcin o un
grupo de funciones especficas.
- Solicitud de Informacin (RFI): documento que se utiliza para obtener informacin
detallada sobre productos, servicios o proveedores.
- Solicitud de presupuesto (RFQ): documento utilizado para establecer compromisos
con los proveedores acerca de fijacin de precios, hitos de entrega del producto,
cantidad, servicios y calidad de los productos.

- Solicitud de propuesta (RFP): documento oficial entregado a los potenciales
proveedores sobre los productos o servicios que requiere la organizacin.
- Solicitud para ofertar (IFB): Esta solicitud da a todos los proveedores una
oportunidad igual de hacer su mejor oferta. IFB debera utilizarse slo si las
especificaciones del producto estn perfectamente definidas, el presupuesto a
invertir para el desarrollo de la solucin es significante y uno de los mtodos
anteriores no es adecuado.
- Sponsor ejecutivo: ejecutivo a alto nivel que tiene autoridad para recaudar fondos y
aprobar el proyecto, y acepta la responsabilidad del documento RFI durante todo el
proceso, aunque no est involucrado en el da a da.

6. ACRNIMOS
AM (Agreement Management): Gestin de Acuerdos
ARD (Acquisition Requirements Development): Desarrollo de Requisitos de la
Adquisicin
ATM (Acquisition Technical Management): Gestin Tcnica de la Adquisicin
AVAL (Acquisition Validation): Validacin de la Adquisicin
AVER (Acquisition Verification): Verificacin de la Adquisicin
CAB (Change Advisory Board): Comit de cambios
CAR (Casual Analysis and Resolution): Anlisis y Resolucin de Causas
CM (Configuration Management): Gestin de Configuracin
CMMI-AQC Capability Maturity Model Integration for Acquisition
CMMI-DEV Capability Maturity Model Integration for Development
CMMI-SVC Capability Maturity Model Integration for Service
COTS (Commercial Off-The-Shelf)
DAR (Decision Analysis and Resolution): Anlisis y Resolucin de Decisiones
IACCM (International Association for Contract and Commercial Management):
Asociacin internacional de gestin de contratos y comercial.
IFB (Invitation for Bid) - Solicitud para ofertar
IPM (Integrated Project Management): Gestin Integrada de Proyecto
ISO(International Organization for Standarization): Organizacin internacional para la
estandarizacin.
KPI (Key Performance Indicator): Indicadores clave de rendimiento
MA (Measurement and Analysis): Medicin y Anlisis
OID (Organizational Innovation and Deployment): Innovacin y Despliegue en la
Organizacin
OPD (Organizational Process Definition): Definicin de los Procesos de la
Organizacin
OPF (Organizational Process Focus):Enfoque en los Procesos de la Organizacin
OPP (Organizational Process Performance): Rendimiento de los Procesos de la
Organizacin
OT (Organizational Training): Formacin Organizativa

PMC (Project Monitoring and Control): Seguimiento y Control de Proyecto
POC (Point of Contact): Punto de contacto
PP (Project Planning): Planificacin de Proyecto
PPQA (Process and Product Quality Assurance): Aseguramiento de la Calidad de
procesos y productos.
QPM (Quantitative Project Management): Gestin Cuantitativa de Proyectos
REQM (Requirements Management): Gestin de Requisitos
RGS (Requirement gathering session): Sesin de recogida de requisitos
ROI (Return of investment): Retorno de inversin
RSKM (Risk Management): Gestin de Riesgos
SCD (Supplier and Contract Database): Base de datos de proveedores y contratos
SLA (Service Level Agreement): Acuerdo de nivel de servicio
SSAD (Supplier Agreement Development): Solicitud y Desarrollo de Acuerdos con
Proveedores
TOC (Total Ownership Cost): Coste total de la propiedad
RFI (Request for information): Solicitud de informacin
RFP (Request for proposal): Solicitud de propuesta
RFQ (Request for quotation): Solicitud de presupuesto

7. REFERENCIAS
Cohen, S. Roussel, J . Strategic Supply Chain Management: The Five Disciplines for Top
Performance McGraw Hill, 2004.
Craig Meyers, B y Obernforf, P. Managing Software Acquisition, Addison-Wesley, 2001.
DeWaart. D, Cohen.S , Applying the Five Core Disciplines for Strategic Supply Chain
Management, 91st Annual International Supply Management Conference, mayo 2006
Dietmeyer. B, "Negotiating Intelligently: Strategic Marketplace Influence vs. Tactical
Reactions", Think! Inc., 2001.
Dr. Rene G. Rendon, C.P.M., CPCM, PMP, Best Practices in Contract Management, 92nd
Annual International Supply Management Conference, U.S. Naval Postgraduate School,
mayo 2007.
Kevin R. Fitzgerald, "Best Practices in Procurement", Ascet Volumen 4, 16 mayo, 2002.
Loretta Singletary. L, Ball. A, Rebori. M, Ten Principles of Effective Dispute Management,
Managing Natural Resource Disputes No.11, Fact Sheet 00-08
Nelson, Patricia E. Moody, J onathan Stegner, "The Purchasing Machine, How the Top Ten
Companies Use Best Practices to Manage Their Supply Chains", The Free Press, 2001.
Project Management Institute (PMI), Gua de los Fundamentos de la Direccin de Proyectos
(PMBOK) Tercera edicin, 2004.
R.Raedels, A, The Supply Management Process Volumen 1 NAPM, 2000.
Robert J . Engel, C.P.M., 10 Fundamental Strategies and Best Practices of Supply Chain
Organizations 92nd Annual International Supply Management Conference, mayo 2007
Supplier Management Best Practice Handbook The Art of Service, 2008.
ISM (Institute for Supply Management) - http://www.ism.ws/
SEI Software engineering institute - www.sei.cmu.edu/
IACCM (International Association for Contract & Commercial Management) -
http://www.iaccm.com/
Mdulos:
- Requirements definition.
- Sourcing Options
- Developing Evaluation Criteria
- Request For Information (RFI)
- Bid process and rules

- Applying Evaluation Criteria
- RFP Preparation and Content
- RFP Management
- Contract and Relationship Types
- Identifying and Managing Risk
- Knowledge Management Tools and Best Practices
- Supplier Relationship Management
- Contract Implementation & Communication
- Monitoring Performance, Tools & Techniques
- Control and Management
- Lessons Learned / Close-Out

Guia Avanzada de Gestion de Adquisiciones

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Guia Avanzada de Gestion de Adquisiciones

Uploaded by

Copyright:

Available Formats

GUA AVANZADA DE

You might also like