Lectura PDF

309-S40
FEBRERO 25, 1998
DARRYL ROMANOW
MARK KEIL
F. WARREN MCARLAN
Timberjack Parts: Proyecto de Selección de

Software Empaquetado
La mañana del 15 de Diciembre de 1995, Jim Utting, el gerente general de partes de

Timberjack Corp en Atlanta, sopesaba la decisión que él y su equipo de proyecto estaban a punto de
tomar. Al equipo del proyecto, el cual incluía a tres miembros de Atlanta y a tres de una operación
similar de partes en Suecia, se le había dado la tarea de seleccionar el mismo tipo de software
empaquetado para ser usado en ambos lados del Atlántico. Mientras que ambas operaciones eran muy
similares en términos del volumen de ventas y el número de personal, Utting no podía hacer otra cosa
que reconocer las diferencias de opinión con respecto a los requerimientos de software. A pesar de
que Utting tenía la responsabilidad general del proceso de selección y estaba en la posición de tomar la
decisión final, él sentía que su equipo de proyecto debía llegar a un consenso.
Era claro que sólo se llegaría a un consenso haciendo concesiones y el grupo ya había
concedido bastante para llegar hasta este punto. A pesar de que el objetivo en el inicio había sido
seleccionar software usado por excelentes compañías de distribución o por los mayoristas, los
requerimientos de un fuerte soporte local en ambas partes del Atlántico, así como el de una
plataforma UNIX, forzaba a la lista a incluir principalmente compañías de software de planeación
de los recursos empresariales, las cuales se especializaban en software de manufacturación.
Sahlqvist, presidente de Timberjack Parts AB, preguntaba frecuentemente durante las demostraciones:
“¿Tenemos que empezar a fabricar para usar este sistema?”
Mientras Utting y Sahlqvist trataron difícilmente de formar un solo equipo, la geografía – y en un

grado menor, la cultura- había trabajado en su contra. Según lo explicara Utting: “Cuando el grupo
sueco vino aquí y fuimos juntos a las visitas de la locación, y pasamos tiempo juntos, al final de la
semana éramos un equipo. Pero luego de unas pocas semanas por nuestra cuenta, nos separamos
rápidamente.”
Antecedentes de la Industria
Timberjack era el fabricante líder en el mundo de equipo pesado para el maderero profesional, con
una participación total en el mercado de casi 25%. Su dueño era Rauma Oy, un conglomerado finlandés
________________________________________________________________________________________________________________
El caso de LACC número 309-S40 es la versión en español del caso de HBS número 9-398-085. Los casos de HBS se desarrollan únicamente para
su discusión en clase. No es el objetivo de los casos servir de avales, fuentes de datos primarios, o ejemplos de una administración buena o
deficiente.
Copyright 2009 President and Fellows of Harvard College. No se permitirá la reproducción, almacenaje, uso en planilla de cálculo o transmisión
en forma alguna: electrónica, mecánica, fotocopiado, grabación u otro procedimiento, sin permiso de Harvard Business School.
This document is authorized for use only in Peter Yamakawa's Gesti?n de proyectos 2 at ESAN - Graduate School of Business from Oct 2019 to Dec 2019.
309-S40 Timberjack Parts: Proyecto de Selección de Software Empaquetado
que se encontraba en las listas tanto de NYSE como de la bolsa de valores finlandesa. En 1995,
Timberjack tenía ventas por ó27 millones de dólares americanos, ganancias netas de 88 millones de
dólares americanos y casi 1,600 empleados. Timberjack y algunos otros competidores, tales como John
Deere, Blount, Caterpillar y Valmet, habían mantenido una participación dominante del mercado a largo
plazo. Muchas otras empresas pequeñas también participaban con equipo especializado que cubría
un nicho del mercado. El grupo Timberjack fue formado por medio de varias adquisiciones durante
las décadas de los 80 y 90, según se esboza en el Anexo 1.
La evolución del equipo para la industria maderera había cambiado dramáticamente la manera en
que se realizaba la extracción maderera en todo el mundo. A pesar de que todavía se practicaba la
tala de árboles con sierras eléctricas y el uso de animales para halar los troncos caídos, estos
métodos ya estaban desapareciendo. En Norteamérica, los árboles se talaban usando máquinas
llamadas cosechadoras forestales (feller buncher), luego eran arrastrados al borde del camino por
tractores de arrastre forestal (skidder), donde eran recortados por equipo desramador (delimber), y
luego levantados para colocarlos en camiones para troncos utilizando cargadores de troncos. En
Escandinavia, los árboles eran cortados y desramados por cosechadoras en el bosque, y luego un
tractor autocargable (forwarder) los cargaba hasta la carretera. Este método permitía que el maderero
pudiera cosechar selectivamente el bosque, en lugar de cortar todo en tajo abierto. El Anexo 2 ofrece
un panorama de la línea de productos de Timberjack.
La industria era extremadamente cíclica debido a que estaba directamente vinculada a los precios
de la pulpa de madera y los maderos, los cuales eran a su vez altamente dependientes de la fortaleza
general de la economía. Durante las caídas severas de los precios mayoristas de la pulpa de madera y
los maderos, las ventas anuales de las máquinas podían caer hasta en 75% con muy poca advertencia
anterior. Una recesión típica duraba uno o dos años, y con frecuencia muchos de los distribuidores,
contratistas y manufacturadores apalancados no eran capaces de soportar la tormenta. Esta era la
razón por la cual muchos proyectos de capital eran completados durante los años de prosperidad.
Operaciones de Timberjack Parts
Timberjack operaba dos operaciones de partes y servicios para dar servicio a su equipo a nivel
mundial; una en Marsta, Suecia, la cual estaba ubicada a las afueras de Estocolmo, y la otra en Atlanta,
Georgia. Ambas instalaciones fueron abiertas en 1994 e involucraron la reubicación de personal de otros
lugares. En 1995, cada instalación tenía aproximadamente 35 empleados y ventas por cerca de US $35
millones. La operación europea vendía la mayor parte de sus partes directamente a compañías
minoristas de propiedad de la compañía en Escandinavia; en Norteamérica, Timberjack vendía ex-
clusivamente a terceras partes, distribuidores de equipos pesados. En Escandinavia, la operación de
partes de Timberjack dependía de un sistema de software conocido como DAIM, el cual fue adquirido
en 1987 y funcionaba bajo una plataforma AS400. Timberjack de Atlanta estaba basada en el
software MM3000 de Hewlett-Packard, diseñado para correr en hardware HP3000. Este sistema,
originalmente adquirido en 1981, incluía un módulo de codificación personalizada para los
distribuidores desarrollado a inicios de la década de los años 90. El módulo de distribuidores le
permitía a los distribuidores marcar para conseguir acceso a la transmisión electrónica de órdenes
y para consultar sobre el precio y la disponibilidad de las partes utilizando una PC como un
terminal no inteligente. Casi el 80% de todas las órdenes de Timberjack de Norteamérica eran
colocadas en el sistema para los distribuidores.
Timberjack Parts: Proyecto de Selección de Software Empaquetado 309-S40
La Necesidad de Nuevo Software
A inicios de 1995, Sahlqvist y el grupo Masta se encontraban investigando activamente sobre la

adquisición de nuevo software de computación para administrar sus operaciones de partes. El impulso
mayor detrás de la decisión era la inestabilidad de sus sistemas existentes. Las frecuentes
modificaciones de su código fuente a lo largo de los años habían llevado a fallas frecuentes del
sistema. Como resultado de esto, los usuarios no siempre podían confiar en los datos que se les
presentaban. Por estas razones, Sahlqvist buscaba intensamente un nuevo sistema de computación con
la intención de instalar el sistema a inicios de 199ó como máximo.
Al mismo tiempo, en las oficinas principales de Timberjack de Norteamérica en Woodstock,

Ontario, Canadá, Coopers & Lybran se encontraba ayudando a la gerencia principal a delinear una
estrategia futura de sistemas de información. Este proyecto incluía la integración del proceso de
manufacturación y la red de distribuidores, así como la de partes y servicios. A pesar de que
Woodstock no estaba apurado en reemplazar todos sus sistemas, sí se enfrentaba al problema del
año 2000; lo que era más importante, Hewlett-Packard había notificado a sus clientes que ya no daría
apoyo a su software antiguo MM3000. Después de pasar varios meses en el local de Woodstock, Coopers
& Lybrand preparó un plan estratégico de sistemas de información. La estrategia concluía que
Timberjack se beneficiaría al seleccionar el mejor software posible para administrar las varias
unidades existentes dentro de las operaciones norteamericanas. En vez de depender de un solo
paquete para administrar el proceso de manufacturación, las partes y el servicio, se propuso que un
“paquete de compañía de distribución” sólido serviría mejor a las partes y un sistema separado de
manufacturación serviría mejor para la fábrica.
Las recomendaciones de Coopers & Lybrand para la oficina principal norteamericana fueron
luego presentadas a la junta de directores en Helsinki, Finlandia. Mikko Rysaa, presidente de
Timberjack Group, concluyó que una estrategia de software más global sería beneficiosa para
Timberjack. La sede principal en Helsinki luchaba continuamente en comparar los resultados
financieros de las diversas unidades con poco éxito. Un paquete financiero ayudaría a resolver este
problema. Los sistemas integrados implementados a nivel mundial también facilitarían el envío del
personal a otros países por algunos años, ya que no tendrían la necesidad de aprender un nuevo
software de computación. La selección global también agregaría apalancamiento a las negociaciones
con los distribuidores de software y hardware. Por estas razones, Rysaa sentía que Timberjack debería
embarcarse en una estrategia de software global.
Consiguientemente, se les dio a las organizaciones de partes de servicio la tarea de seleccionar un

solo sistema para administrar los negocios en Atlanta y en Marsta. Rysaa designó a Utting para
encabezar el proyecto e instruyó a Sahlqvist a paralizar el proceso de seleccionar un nuevo software en
forma independiente. Las instrucciones de Utting fueron bastante claras; él debía ganar el consenso por
un solo paquete en ambas locaciones y fue alertado de que “no hubiera desastres.” Si los dos
grupos fallaban en llegar a un consenso, entonces, la junta de directores de Timberjack lo decidiría.
Rysaa le había advertido a Utting en su usual poco humor: “El nivel de inteligencia no siempre sube
cuando la decisión la toma la junta de directores.”
Durante la siguiente semana, Utting y Sahlqvist decidieron los miembros del equipo del
proyecto y desarrollaron una programación preliminar. El 17 de Abril de 1995, el equipo del
proyecto conjunto tuvo su primera reunión en Woodstock, Ontario. Los miembros del equipo que
estuvieron presentes fueron Christine Smedjer, gerente de sistemas de información en Marsta; Jorma
Nikkinen, gerente de materiales en Marsta; Mark González, coordinador de servicios de información
para partes de servicio; Darryl Romanow, gerente de materiales en Atlanta; junto con Utting y
Sahlqvist. Los Anexos 3 y 4 muestran los organigramas de Timberjack para las operaciones de partes
de Atlanta y Marsta. Coopers & Lybrand designaron a Ilya Bahar para el proyecto, a pesar de que
Timberjack no había decidido sobre el grado de intervención de Coopers & Lybrand.
Ambas organizaciones se encontraban bajo una considerable transición al momento en que el

proyecto inició. En Abril de 1995, los miembros del equipo se encontraban en distintas etapas de
reubicación en las nuevas instalaciones de partes en Atlanta y en Marsta. Utting, Romanow y González
vivían cerca de la fábrica de Woodstock, Ontario. Utting se reubicaría en Atlanta en Mayo, Romanow se
mudaría a fines de Junio, pero González no había decidido todavía si se iba a mudar a Atlanta. La
nueva instalación de partes en Atlanta fue abierta en febrero de 1994 y comprendía el personal del
centro de distribución, un comprador y tres empleados del área de contabilidad, todos los cuales eran
nuevos en Timberjack. Marsta estaba en una situación similar, ya que Timberjack había cerrado sus
operaciones de partes en Tampere, Finlandia, y en Alfta, Suecia, para combinarlas en una sola en Marsta.
Mientras que Smedjer había sido recientemente contratado del área de Marsta, Nikkinen continuaba
viajando ida y vuelta los fines de semana desde Tampere (al centro de Finlandia) y Sahlqvist viajaba
desde Gotenborg, un viaje en carro de 3 horas desde Marsta.
En la primavera de 1995, la operación norteamericana tenía todavía al grupo principal de

compradores de partes, al personal de servicio al cliente y de contabilidad trabajando en Woodstock. A
pesar de que a la mayoría se le ofreció puestos de trabajo en Atlanta, muy pocos eran los que estaban
pensando en trasladarse. La mayoría de los miembros del grupo, se encontraba buscando activamente
nuevas posiciones en la operación de la fábrica. Utting sentía que tenía una estrecha ventana de
oportunidad para ganar información de este grupo de personas que promediaba como 20 años de
experiencia. La principal preocupación de Utting era que el compromiso con el proyecto sería
limitado, ya que muchas de las personas estarían dejando el departamento de partes.
Al final de la primera reunión, se decidió que se invitaría a Bahar para desarrollar una oferta
para el contrato de selección de software; la definición de requerimientos sería dada en Woodstock,
con el cierre en Marsta. Romanow y González trabajarían con Bahar durante Mayo y Junio en una
solicitud de propuesta que sería enviada a los distribuidores a fines de agosto de 1995. Para poder
liberar tiempo para que Romanow trabajara en el proyecto, Utting decidió que un supervisor
interino que reportara a Romanow, lo descargara en algún grado de las actividades diarias. Se le
dio la tarea a Jim McGregor, un empleado de 40 años de edad y un comprador principal del
departamento de partes. McGregor ya había decidido que no se mudaría a Atlanta y que sería probable
que se retirara al final del proyecto.
Proceso de Solicitud de Propuesta
A inicios de mayo, Utting recibió una cotización de Bahar, la cual incluía los servicios que
ofrecería y una programación de pagos. La oferta cubría la creación de la solicitud de propuesta, la
lista de distribuidores potenciales, visitas a los distribuidores y a las locaciones, consulta sobre la
decisión de la selección final, así como asesoría en la negociación del contrato. La mayor cantidad de
trabajo se daría durante la creación de la solicitud de propuesta debido a que varios especialistas de
Coopers & Lybrand estarían involucrados en el proceso. Bahar garantizaba que las tarifas,
incluyendo los costos de viaje no excedería los $100,000 CDN (US $75,000), los cuales serían luego
divididos entre Marsta y Atlanta. A pesar de que Utting y Sahlqvist pensaban que esta tarifa era alta,
ambos se daban cuenta de que el equipo podría usar el conocimiento práctico y los recursos
necesarios para elegir el software correcto. Utting firmó el contrato y el trabajo inició prontamente.
Bahar, Romanow y González organizaron un cronograma de fechas de reunión para completar la

mayoría del trabajo de la solicitud de propuesta antes de mediados de junio. Las sesiones se
programarían en medio día para la reunión inicial, medio día para revisar los procedimientos de la
primera sesión y para desarrollar una lista completa de los requerimientos, así como una serie de
reuniones de seguimiento para finalizar los requerimientos y ganar las aprobaciones. Se esperaba
que el borrador final de la solicitud de propuesta estuviera listo máximo a mediados de agosto, con
una programación para la revisión final fijada en la semana del 25 de agosto de 1995.
Durante la primera reunión, tres o cuatro representantes funcionales delinearían todos los
procesos de negocios usados en Timberjack dentro de su área. Un experto de Coopers & Lybrand sería el
facilitador y un persona alterna tomaría notas. González y Romanow, que asistirían a todas las sesiones,
trabajarían con el grupo para tratar de asegurar que se cubrieran todos los procesos con suficiente
detalle para que pudieran redactarse los requerimientos formales. Se prestó una especial atención a
los procesos más importantes de Timberjack, sin considerar si existía o no esa funcionalidad en un
software empaquetado estándar. También, se solicitó a cada grupo y a su gerente considerar cualquier
funcionalidad adicional de software que mejoraría la eficiencia de su área.
Después de cada sesión, Coopers & Lybrand prepararía las minutas para revisarlas en la
siguiente etapa. En la segunda reunión, cada proceso de negocio fue dividido en varias declaraciones
abreviadas de los requerimientos en forma de una pregunta, tal como “¿Su paquete soporta EDI?” o
“¿Su paquete calcula proyecciones automáticamente?”. Una vez que todos los requerimientos de
Timberjack fueran determinados, Coopers & Lybrand presentaría una lista exhaustiva de
requerimientos que ellos y otros clientes habían desarrollado a lo largo de los años. Esta lista fue
comparada con la lista existente en Timberjack, y se agregaron ocasionalmente nuevos rubros de la
lista de Coopers & Lybrand a la lista de requerimientos de Timberjack.
Se llevaron a cabo sesiones para contabilidad, finanzas, compras/planeamiento, servicio al cliente,

fijación de precios, distribución y sistemas de información. Todas las reuniones se completaron
antes de mediados de junio y se enviaron las listas de requerimiento a Marsta para su revisión. Los
miembros del equipo sueco no estuvieron presentes durante las reuniones de solicitud de propuesta
en Woodstock. Marsta aprobó las listas de requerimiento rápidamente y agregó requerimientos
relacionados a la capacidad multilingüe, la transferencia electrónica de fondos para los pagos a los
proveedores y los reportes Intrastat, los cuales eran usados en Europa para hacer el seguimiento a los
movimientos de los productos.
También, se inició una revisión de beneficios en Woodstock. Este análisis de beneficios era un
intento de enlazar las mejoras potenciales en la funcionalidad del software con los ahorros en los costos
operativos o un servicio al cliente mejorado. En Woodstock, todos los gastos de capital requerían una
apropiación del capital y la aprobación estaba basada en el retorno sobre la inversión esperado. En las
operaciones europeas, los gastos de capital no estaban tan formalizados. Romanow explicó el
fundamento para el análisis de beneficios:
Reconocemos que desde el punto de vista de la aprobación del proyecto, el análisis

de beneficios no era necesario; habíamos sido requeridos por la oficina principal el
implementar el nuevo sistema. Estábamos haciendo el análisis de beneficios para sopesar
las mejoras de funcionalidad potenciales. Esto nos ayudaría a decidir qué software tendría el
mayor potencial para mejorar nuestras operaciones.
Para completar la solicitud de propuesta, Romanow y Nikkinen recopilaron estadística básica de

negocios, tal como las cantidades de partes, el número de las órdenes de ventas procesadas
diariamente y el número de clientes. González y Smedjer delinearon el número de usuarios y de los
sistemas preferidos de hardware y de sistemas operativos. González incluyó una descripción del
sistema de distribuidores norteamericano, el cual enlazaba directamente a los distribuidores con el
sistema heredado de Timberjack vía modem. A fin del mes de junio, la mayor parte del trabajo se había
realizado, pero las aprobaciones finales no fueron completadas hasta mediados de agosto. Las
vacaciones de verano, así como la reubicación de Romanow a Atlanta, retrasaron el proceso de
aprobación. El documento final tenía 200 páginas. Incluía más de mil requerimientos, copias de
informes estándar e instrucciones para los proveedores sobre el proceso de licitación. El Anexo 5
muestra un extracto de la solicitud de propuesta de Timberjack. Cada requerimiento, se clasificó como
crítico y no crítico, y había espacio disponible para que los proveedores indicaran si su software cumplía,
cumplía con una modificación menor, o requería una modificación mayor. Se definía una modificación
menor como aquella que tenía un costo estimado de US $2,500 o menos. Se reprodujo 50 copias y
también se copió la solicitud de propuesta en formato electrónico para permitir a los proveedores
responder tan rápidamente como fuera posible.
En esta etapa del proyecto era evidente que había perspectivas opuestas sobre el enfoque
tomado para la solicitud de propuesta. El equipo sueco estaba muy apurado en seleccionar e
instalar un nuevo sistema. Smedjer explicó:
Si la solicitud de propuesta se hiciera en Suecia tendría aproximadamente cinco

páginas. No sería tan específica, sólo mencionaría las funciones requeridas y no
mencionaría nada sobre cómo debería ser realizada o cómo debería lucir. Al final, el docu-
mento representa un montón de trabajo para los proveedores para poder responder a
estas preguntas en tal nivel de detalle.
El grupo norteamericano estaba comprometido a seguir la metodología de Coopers & Lybrand.

Utting defendió el proceso de solicitud de propuesta:
La fortaleza del proceso de solicitud de propuesta era de que termináramos con

una idea clara de lo que queríamos en detalle. El segundo beneficio era que
involucráramos a bastantes personas. Creamos cierto acuerdo de darle apoyo a la
propuesta, no perfecto pero cierto acuerdo de apoyo, debido a que involucró a las perso-
nas. Esto evitaba el problema de que las personas dijeran luego “Nadie me preguntó
sobre esto,” de tal forma que yo pienso que la solicitud de propuesta estableció una forma
de consenso.
Al final del proceso de solicitud de propuesta, el lado sueco estaba bastante frustrado con el
tiempo requerido para elaborar la solicitud de propuesta. A pesar de que Utting sentía que había un
valor en la solicitud de propuesta, reconocía que al final había creado una división entre los grupos
de Suecia y Atlanta. Sahlqvist comentó:
El proceso de solicitud de propuesta fue demasiado largo para nosotros, puesto que
teníamos mucho más presión que los otros. Teníamos un sistema que no funcionaba
apropiadamente, por lo que estábamos ansiosos por un proceso rápido. Y Atlanta estaba
bastante satisfecho con su sistema y tenía un mayor empuje en el proyecto para obtener un
sistema común. No realizaron concesiones para reducir el proceso; no pensaron en los
demás.
Lista de Proveedores
La lista de proveedores potenciales fue desarrollada por Coopers & Lybrand con la
información provista por Sahlqvist. Varias limitaciones afectaban a los proveedores potenciales.
Primero que nada, el sistema tenía que estar basado en UNIX, según lo había especificado un comité
interno de estándares dentro de Timberjack, llamado el grupo de Estándares de Información e
Integración (DSI). Este grupo consistía en los gerentes de varios departamentos de sistemas de
información de las instalaciones de Timberjack alrededor del mundo, incluyendo a González y
Smedjer. El requerimiento UNIX excluía a muchos otros paquetes excelentes en el mercado diseñados
para funcionar sobre otras plataformas.
Segundo, el grupo de Estándares de Información e Integración manifestó una preferencia por una
base de datos Oracle como un estándar corporativo y se aceptó a Progress como una segunda
alternativa. González comentó:
El estándar corporativo de Oracle tenía como intención que diera a Timberjack la

mayor flexibilidad para elegir otro software y permitir la máxima integración entre otras
locaciones de Timberjack. A pesar de que Progress podría ser un producto más fácil de
administrar, su participación en el mercado era una fracción de la participación de mercado
de Oracle. Una base de datos de Progress haría más difícil una futura integración con
Woodstock y sería difícil encontrar programadores calificados.
El paquete también tenía que tener presencia tanto en Europa como en Norteamérica.
Había paquetes de distribución sólidos usados en Suecia, pero no en Norteamérica, y viceversa. Al
especificar la presencia local en ambos mercados, la lista de proveedores se limitó a grandes paquetes
de planificación de los recursos empresariales (ERP), los cuales eran usados predominantemente por
grandes empresas de manufacturación.
Coopers & Lybrand recomendaron originalmente los mejores paquetes sólidos para las unidades
de negocios. A pesar de que las operaciones de partes de ambos lados indicaron que querían comprar
el mismo paquete con fortalezas en distribución, se requería de concesiones. La lista de proveedores se
redujo efectivamente a sistemas de manufacturación con fortalezas secundarias en distribución y
servicio.
En total, se envió las solicitudes de propuesta impresas y en discos magnéticos a 13 compañías.

Se enviaron el 15 de setiembre de 1995, tres semanas después de la programación originalmente
desarrollada en abril. Después de esto, pronto se llevó a cabo una reunión en Atlanta para responder
a cualquier pregunta que los proveedores tuvieran en relación a la solicitud de propuesta. La reunión de
proveedores tuvo muy buena asistencia con la participación de la mayoría de los proveedores
invitados. Muchos de los proveedores estuvieron interesados en el impacto del sistema de
distribuidores en el proyecto, y también hicieron varias preguntas en relación al presupuesto general.
El equipo de Timberjack no se sintió cómodo revelando la cifra del presupuesto en ese momento
debido a que podría haber influenciado el proceso de licitación.
Se les dio a los proveedores un mes para responder, y en la mayor parte de los casos, aquellos
con la intención de entrar a la licitación respondieron a tiempo. Otros requirieron alguna motivación
para que tomaran el tiempo para responder a la solicitud de propuesta. Los proveedores que no
respondieron inicialmente fueron SAP y QAD. La falla inicial de QAD en ofertar fue un desengaño
para el lado sueco y una sorpresa para Utting, ya que a QAD acababa de otorgársele el contrato para
proveer a las tiendas minoristas de Timberjack en Finlandia. Sahlqvist finalmente convenció a QAD
en Suecia que respondiera a la solicitud de propuestas. Al final hubo un total de seis ofertas; Lawson,
Oracle, Computer and Associates, QAD, Scala y American Software.
Cuando las respuestas ingresaron, el equipo evaluó las fortalezas y debilidades relativas de los
varios paquetes con respecto a la funcionalidad. Algunos paquetes eran muy sólidos en el área
financiera, mientras que otros eran sólidos en el área de compras/planeamiento. Ninguno de los
paquetes era capaz de hacer todo lo que se esperaba. Sahlqvist y Utting acordaron que la
funcionalidad más crítica estaba en las áreas de planeamiento y de servicio al cliente, seguidos de
almacenamiento, y luego finanzas. El Anexo ó muestra un resumen comparativo de las propuestas de
los cuatro proveedores principales en términos de funcionalidad.
Creando la lista corta Una vez que todas las ofertas fueron recibidas y los resultados tabulados, el
grupo pasó por un proceso rápido de eliminar varias de las ofertas. Scala ofrecía un paquete basado en
computadoras personales, pero a pesar de que sus costos eran bastante bajos, carecía de
funcionalidad. American Software mostraba una excelente promesa en el área de
compras/planeamiento, pero muy pocos de sus otros módulos estaban desarrollados para UNIX en ese
momento. Como resultado, se retiró los paquetes de Scala y American Software de la lista de
proveedores potenciales.
Con la rápida eliminación de dos proveedores oferentes, el equipo tuvo la oportunidad de

concentrarse en los cuatro proveedores restantes. Inicialmente, se llevaron a cabo reuniones
separadas con los proveedores en Estocolmo y Atlanta. La mayoría de las reuniones se llevaron a cabo
en el local del proveedor, y en algunos casos, otros miembros del equipo de administración de partes
también asistieron. Los participantes adicionales en Atlanta fueron Ron Kipp, gerente de servicio al
cliente y fijación de precios, así como Gene Torbush, gerente de distribución. Bert Westin, gerente de
servicio al cliente en Marsta, agregó profundidad a las reuniones en Suecia. Las reuniones duraban
generalmente la mayor parte del día y una parte era empleada en las presentaciones del proveedor,
así como en las preguntas de Timberjack relacionadas a las respuestas de la solicitud de propuestas,
o la cantidad de soporte local para el software. Según Romanow, a pesar de que la solicitud de
propuesta era muy detallada, todavía dejaba un gran espacio para la interpretación. Romanow
explicó: “Las visitas a los proveedores sirvieron para ganar un mejor entendimiento de los detalles
detrás de las respuestas de los proveedores. Esto se logró al pedir a cada proveedor demostrar
cómo es que su software realizaba varias tareas.”
Mientras que en Atlanta, el grupo esperaba un fuerte soporte local para los paquetes; en Suecia,
se empleó una cantidad considerable de tiempo investigando las capacidades de soporte local y el
conocimiento práctico de los consultores de implementación de los proveedores. Las preguntas allí se
enfocaban en el número de instalaciones en Suecia y el número de personal que tenía experiencia
previa instalando su software. El equipo sueco había experimentado problemas en el pasado para
encontrar un soporte competente de parte de los proveedores durante la implementación.
En Suecia había unas pocas instalaciones del paquete QAD MFG/Pro pero el software era
ampliamente usado en Europa. Origin, una división de Philips en los Países Bajos, era un socio
mundial de QAD para el soporte en la implementación. Origin tenía oficinas en los Estados Unidos y
Suecia. El equipo sueco favorecía a QAD en términos de soporte en la implementación.
Las presentaciones iniciales de Oracle en Europa no fueron bien recibidas. Smedjer comentó:
Asistimos a una presentación de ventas a la cual asistieron otras compañías. Para

nosotros, las presentaciones indicaban que el personal no estaba totalmente versado en la
funcionalidad del software. Hubo numerosos problemas técnicos durante las
presentaciones, lo cual nos dejó con una sensación de intranquilidad sobre el software.
El paquete de software de Computer and Associates (CA) que fue presentado fue MANMANX.
El grupo de Atlanta asistió a las sesiones con CA, pero el equipo sueco no lo hizo. La mayor
preocupación del grupo fue la estrategia que CA había tomado, la cual comprendía básicamente la
adquisición de software, más que un desarrollo continuo. El grupo Timberjack estaba interesado en el
soporte y el compromiso con el paquete a largo plazo.
En ese tiempo, el equipo del proyecto dependía fuertemente de los artículos de la industria para
entender mejor los atributos de la compañía, así como la funcionalidad del software. Timberjack en
Woodstock y Helsinki se suscribieron a las publicaciones del Gartner Group, las cuales cubrían
frecuentemente a los principales actores en el mercado de software ERP. Los artículos del Gartner
Group, según Utting: “eran como In formes del Consumidor para el software.” En ese tiempo, el Grupo
Gartner había colocado a SAP y a Oracle como los líderes en este mercado de acuerdo a sus atributos
técnicos y a su habilidad de implementación.
Reduciendo la lista a dos En noviembre de 1995, Sahlqvist, Smedjer y Nikkinen vinieron a Atlanta
para unirse al equipo de Atlanta para las reuniones con los cuatro proveedores restantes. El propósito
de la visita era ganar un mayor conocimiento de los paquetes y de los proveedores que le
brindaban soporte, y el de reducir las opciones a dos proveedores.
En la reunión con Lawson, los representantes de ventas pasaron una gran cantidad de tiempo
enfocando las competencias técnicas del software. Lawson enfatizó su habilidad para hacer interfase
fácilmente con otros de los mejores paquetes para poder llenar las brechas potenciales es su
funcionalidad. Nikkinen afirmó:
El paquete de Lawson también nos fue presentado en Suecia y estuvimos muy

impresionados con las capacidades de desglose (drill-down) del software; técnicamente
parecía muy sólido. A pesar de que al paquete le faltaba algo de la funcionalidad que
era importante para el equipo de Atlanta, estos rubros no eran tan críticos en Marsta.
Vimos un cierto potencial real en el software.
Se le solicitó al representante de Lawson proporcionar una cotización para un paquete de

pronóstico para redondear su oferta, ya que otros paquetes ofrecían sus propios módulos integrados
de pronóstico.
El representante de QAD, Rohit Lal, enfatizó que el tiempo requerido para implementar su
software MFG/Pro era usualmente de seis meses, lo cual era muy importante para el equipo de Suecia.
Sin embargo, González, sintió que el software no parecía estar basado en la misma flexibilidad que él
había percibido en su software heredado y en algunos de los otros proveedores que el equipo había
revisado. González comentó: “Estamos acostumbrados a un sistema muy flexible –un sistema que le
permita a uno entrar y hacer cambios sin afectar el código fuente. No parecía que MFG/ Pro
tuviera ese tipo de tecnología.” González sentía que por estas razones el sistema de distribuidores
de Timberjack requeriría modificaciones significativas en una plataforma MFG/Pro. A González
también le preocupaba que MFG/Pro estuviera escrito en Progress y que QAD tuviera dificultades
en migrarlo a una base de datos de Oracle.
Las presentaciones de Oracle en Atlanta involucraron a un representante financiero de Oracle,

un representante de distribución y al director del grupo de Consultoría de Implementación.
González comentó:
El paquete era claramente más complicado que los otros, con una gran cantidad de
banderas y botones para permitir al usuario la flexibilidad de cambiar el software sin
programar. Las pantallas de consulta estaban basadas en su tecnología Smart Client, la
cual permitía al usuario personalizar la presentación de las ventanas fácilmente. Esta
tecnología estaba basada en su uso creciente de programación orientada a objetos.
Durante la reunión, el equipo sueco empezó a presionar a los presentadores de Oracle sobre
sus implementaciones en Europa. Sahlqvist tomó la lista de clientes que el representante de Oracle
en Suecia le había proporcionado y narró las conversaciones que él había tenido con los clientes de
Oracle. Sahlqvist explicó sus preocupaciones:
Una de las instalaciones falló; el representante de sistemas de la compañía dijo que

no pudieron hacer funcionar el software, a pesar de que Oracle afirmaba que era una
implementación exitosa. Ocho empresas más sólo habían implementado los módulos
financieros, no todo el conjunto para manufacturación. Ninguna compañía del tipo de
distribución había escogido el paquete en Suecia, y sólo dos o tres compañías estaban en
el proceso de instalar el paquete completo.
Los presentadores de Oracle estuvieron sorprendidos por las preguntas hostiles, afirmando que
ellos creían que de todas las compañías de software que Timberjack estaba considerando, Oracle
tenía la mayor presencia a profundidad en Europa. Ellos sentían fuertemente que la mayoría de las
empresas reconocían a Oracle como un actor global y esto era una de sus fortalezas. El representante de
Oracle, Mark Fine, prometió a Sahlqvist más información sobre las instalaciones europeas y reiteró
que tenía un personal de setenta y cinco personas en Estocolmo para dar soporte a varios cientos de
locaciones de clientes.
Después de la reunión con Oracle, el grupo se reunió brevemente para discutir los siguientes pasos
debido a que el grupo sueco tenía que tomar un avión. Se decidió que Smedjer y Nikinen continuarán
investigando a QAD y Lawson, mientras que Romanow y González se enfocarían en CA y Oracle. El
equipo sintió que la lista podía ser reducida a dos en el plazo de una semana. Las principales fuentes
de información en ese tiempo eran las tarifas de licencias de software, las comparaciones de
funcionalidad, los costos de consultoría para la implementación y los artículos del Gartner Group.
Al finalizar la semana, se convocó a una conferencia para determinar los dos paquetes finales. El
grupo sueco mostró preferencia por QAD, mientras que el grupo de Atlanta mostró una fuerte
preferencia por Oracle. Se tomó la decisión de continuar con Oracle y QAD, y ambos lados
investigarían las posibilidades de cada implementación.
Personalizaciones de Timberjack
A fines de noviembre de 1995, el equipo del proyecto tenía una buena idea sobre las
limitaciones de funcionalidad en el software de QAD y Oracle. El paquete de QAD requería
personalizaciones en el sistema para distribuidores, el tipo de orden y el stock de seguridad
automatizado, mientras que Oracle necesitaba trabajar en el módulo de procesamiento de órdenes para
10
equiparar la funcionalidad del sistema actual para distribuidores. La funcionalidad del tipo de órdenes,
le permitía a los distribuidores de Timberjack especificar el nivel de importancia que se daba a una orden
de ventas dada, mientras que el programa de stock de seguridad era usado para ajustar automáticamente
los niveles de inventario para optimizar el servicio con el distribuidor al costo más bajo. A pesar de
que existían otras deficiencias, el equipo de Timberjack no consideró que fueran críticas para el
funcionamiento del negocio.
Timberjack estaba interesado en obtener un contrato de precio fijo para el software y la

consultoría de implementación, además de modificaciones mayores. El equipo de Atlanta tenía tanto a
los representantes de personalización de Oracle como de QAD en el local para ver una demostración
del sistema de distribuidores. El equipo de Suecia se comprometió a la implementación en Marsta sin
ninguna personalización. En Atlanta, se proporcionó una documentación detallada sobre el sistema de
distribuidores y se hizo disponible el código fuente. Tanto a QAD como a Oracle, se les dio también la
oportunidad de enlazarse con el sistema de distribuidores vía MODEM para una mejor comprensión de
su funcionalidad.
Además de las modificaciones al sistema de distribuidores, se le proporcionó a QAD documentación

sobre el programa de stock de seguridad automatizado, así como los requerimientos de funcionalidad
de tipo de órdenes. Oracle era capaz de cubrir estas necesidades dentro del paquete base. Los costos
totales para las modificaciones de MFG/Pro fueron aproximadamente de US $200,000 y para Oracle
fueron de $30,000. A pesar de que Utting esperaba modificar el software y creía que las principales
modificaciones ya habían sido identificadas, se preguntaba qué otros costos de personalización serían
descubiertos durante la instalación.
Consultoría de Implementación
Los consultores de implementación de Oracle y de Origin, quien representaba a QAD, fueron

traídos a la locación para que pudieran investigar en mayor dimensión el entorno del usuario y para
presentar a Timberjack su metodología de implementación. Las metodologías de ambas firmas eran
bastante similares; sin embargo, el plan de Oracle incluía a más consultores durante más tiempo. Los
estimados iniciales de Oracle mostraban que los honorarios de consultoría para instalar el sistema
en ambas locaciones de Timberjack excederían los US $500,000. Mientras que Utting creía que el
sistema Oracle era más complicado, le era difícil comprender la inmensa diferencia de los costos
relativos a la consultoría de implementación.
A lo largo de las siguientes semanas, el equipo de Atlanta se reunió con el grupo de

consultoría de implementación de Oracle para discutir los requerimientos de la consultoría. Se
discutió cada una de las tareas dentro del proceso de implementación en términos de duración y
complejidad. A pesar de que los costos de la oferta de Origin no se revelaron, se comparó el número
de días para completar las tareas. Para cada una de las tareas, el grupo de Oracle pasaba de dos a
tres veces más tiempo en el recurso. Utting se preguntaba si el paquete era realmente mucho más
complicado o si la consultoría acostumbraba a generar un ingreso extra.
Debido a la cantidad de tiempo que Timberjack ya había invertido en la solicitud de

propuesta, Utting presionó a los grupos de consultoría para reducir el tiempo requerido para la
implementación. Esto se basó en el supuesto de que Timberjack no tendría que pasar tanto tiempo
delineando procesos de negocios y definiciones de requerimientos. Fine trabajó con el grupo de
Timberjack para apalancar el brazo consultor de Oracle con el fin de poder hacer concesiones en los
11
servicios de consultoría. Debido a la calidad de la solicitud de propuesta de Timberjack, él creía que

claramente había menos necesidad de definir los procesos al inicio de la implementación. La oferta de
consultoría de Oracle finalmente fue reducida en aproximadamente un 25%.
A pesar de que Utting estaba complacido en que el estimado de Oracle fuera reducido, se
preguntaba cuánto más trabajo recaería sobre su gente. Su organización no tenía un gran personal
de soporte, y la mayoría de su gente la pasaba en el teléfono con clientes y proveedores todo el día.
Sería difícil imaginar el pasar meses en salas de conferencia tratando de comprender el nuevo paquete.
Utting comentó, “Correcta o incorrectamente, el equipo sintió que en términos de complejidad de
implementación, QAD tomaría aproximadamente seis a siete meses para instalar, y con Oracle sería
por lo menos un programa de un año.”
Utting preguntó sobre las programaciones de implementación al consultor de implementación

de Oracle, quien respondió: “Todos los paquetes son difíciles de instalar, no hay vuelta que darles.
¿Es Oracle difícil de instalar? Absolutamente. Pero de ninguna manera es dos veces más difícil que
QAD. Todavía se necesita hacer toda la conversión de datos y comprender verdaderamente cómo es
que el software trabaja a través de los procesos claves.”
Utting le preguntó luego: “¿Por qué es que le toma dos veces más horas a sus consultores
hacer casi lo mismo?” El representante de Oracle respondió:
En todo se obtiene lo que uno paga. Si quiere que alguien venga y pase muy poco
tiempo comprendiendo su negocio, es su decisión. Básicamente, le dirán que
configuraciones usar y luego se van. A eso le llamamos consultoría de “cerebro en palo” y
nosotros simplemente no manejamos nuestro negocio de esa manera.
Sahlqvist y el equipo sueco estaban aún más preocupados sobre la instalación de Oracle. En un
esfuerzo para reducir estas preocupaciones, Mark Fine viajó a Suecia para encontrarse con el equipo de
Timberjack durante una de las sesiones de Oracle. Hasta este momento, el grupo sueco de Oracle
había tenido suficiente tiempo para ganar información más positiva sobre las instalaciones que había a
la fecha en Escandinavia. Durante las reuniones en Suecia, Fine extendió las garantías a nombre del
grupo de consultoría de Oracle en los Estados Unidos; él se comprometió a que si no había consultores
adecuados disponibles en Suecia, se proveería consultores de los Estados Unidos sin ningún costo
extra durante la duración de la instalación. Debido a la urgencia de la instalación en Suecia,
también se comprometió a que la implementación total sería completada dentro de la programación
de un año, sin que hubiera penalidades de incumplimiento aplicables a Oracle. Fine fue capaz de
ofrecer las garantías basándose en el hecho de que otras locaciones de Timberjack y Rauma,
particularmente en Woodstock, estarían seleccionando nuevo software en el futuro cercano.
Visitas a las Locaciones
Las garantías ofrecidas por Fine a Sahlqvist hicieron de Oracle una opción viable para el grupo
en Suecia. Romanow afirmó: “Hasta ese punto, sentíamos que estábamos tirándoles una soga para
poder hacer que ellos considerarán seriamente a Oracle como la solución.” Como el año ya iba a
concluir, el equipo sueco presionó por una decisión final. Sahlqvist le indicó a Utting que la semana
del 12 de diciembre era la última oportunidad para viajar antes de Navidad. Sahlqvist también le
indicó que las visitas a las locaciones de los clientes serían apropiadas si se pudieran hacer las
coordinaciones correspondientes. Varias personas claves de QAD, y particularmente de Oracle, ya
12
habían sido citadas para esa semana, pero las coordinaciones habían sido para reuniones.
Inicialmente, las visitas a las locaciones no habían sido coordinadas, ya que ninguno de los
proveedores tenía el tiempo adecuado para prepararse.
Cuando el equipo llegó a QAD, un representante de la compañía indicó que era posible visitar
a Matrix, el fabricante de champú para peluquerías localizado en Cleveland. Sahlqvist estaba muy
interesado en visitar la locación de una compañía de distribución que estuviera usando MFG/Pro,
pero no había ninguna disponible. Sin embargo, el equipo estuvo de acuerdo en que una visita al local
de Matrix daría un buen uso a su tiempo, así que reservaron vuelos para Cleveland. Romanow llamó a
Fine en Oracle y le indicó que el equipo iba a visitar una locación de QAD. Más tarde durante el
día, Fine le llamó a Romanow con la noticia de que True Temper, un fabricante de mangos de palos
de golf ubicado en Memphis, estaba disponible para ser la locación de visita para Oracle.
Utting comentó sobre las dos visitas a los locales:
El día en Matrix estuvo bien organizado y hubo varias personas de Matrix

disponibles para comentarios. Fue interesante notar que Matrix estaba funcionando con la
versión seis de MFG/Pro, la cual era bastante anterior. Matrix también había modificado
extensivamente, especialmente en el ingreso de órdenes y en las áreas de fijación de precios y
promociones. Nos preguntábamos si había una correlación entre las modificaciones y el
hecho de que Matrix todavía estuviera usando la versión seis, mientras que Timberjack
estaba estudiando la versión 8.4G.
El día con True Temper también fue muy informativo y su equipo de proyecto fue
muy dadivoso con su tiempo. True Temper había logrado su instalación en etapas,
iniciando la financiera primero, luego la de compras, y así sucesivamente. Una persona
de True Temper de cada área funcional pasó tiempo con el equipo de Timberjack para
comprender mejor el proceso de implementación. No podíamos evitar el notar el nú-
mero de personas que trabajaban en la instalación. Finanzas tenía un equipo de seis
personas, con varios de ellos pasando ó0% de sus días en el proyecto. El proyecto había
tardado más de un año en completarse, a pesar de que hubo recesos durante ese tiempo.
De regreso a casa desde True Temper, el grupo tuvo algo de tiempo en el aeropuerto de
Memphis y fueron a beber algo. Sahlqvist, Romanow y González discutieron sobre las visitas a las
locaciones y sintieron que la semana les había dado información nueva. González hizo un
comentario sobre el hecho de que Matrix todavía estuviera trabajando sobre una versión anterior de
MFG/Pro y especuló que los módulos fueran difíciles de modificar sin afectar el sistema básico.
Romanow agregó, “Yo creo que nuestra decisión es una de no tener un corto plazo a través de una
instalación de Oracle versus la ganancia de largo plazo de tener software más flexible. ¿Estamos dis-
puestos a pagar un premio por esa flexibilidad?” Sahlqvist replicó:
Ustedes muchachos no saben sobre lo que están hablando debido a que están tan convencidos de
que Oracle es por lo que tenemos que ir. ¿Por qué tendríamos que decidir por un sistema tan inmenso,
y por todos los dolores de cabeza, cuando el software cambia tan rápido que podríamos estar instalando
algo totalmente diferente en tres años? Somos más como el “taller de mecánica de Joe” que como
General Motors, por lo tanto, ¿por qué necesitamos Oracle? No apoyaremos el pagar un solo dólar
más a Oracle.
13
El Anexo 7 muestra un resumen de la evaluación del costo del proveedor. En el avión, Smedjer
y Nikkinen compararon notas con Romanow. Smedjer había escrito un artículo publicado en Suecia que
comparaba el correr las bases de datos en Progress versus las de Oracle. Smedjer parafraseó el artículo
que básicamente manifestaba que una base de datos Oracle requería 40% más de gastos generales,
lo cual se traducía en hardware más caro y más personal interno. Romanow comentó: “¿Por qué es
que nos dan esta información tan tarde en el proceso? Nosotros tratamos de enviarles por fax cada
artículo que teníamos cuando los recibíamos.” Smedjer respondió: “Es que se toma tanto tiempo en
convertir los artículos de sueco al inglés.”
Selección Final
El siguiente día, Utting y Sahlqvist decidieron que se excluirían de la reunión final de selección.
Si el resto del grupo no podía llegar a un consenso, entonces Utting y Sahlqvist tratarían de tomar
una decisión. Smedjer, Nikkinen, González, Romanow y Bahar se reunieron en la sala de
conferencias para tratar de hacer una recomendación para Utting.
Utting y Sahlqvist trabajaron juntos en la oficina de Utting para tratar de conciliar los últimos
costos financieros del software, hardware, consultoría y modificaciones. El equipo del proyecto había
recibido recientemente cotizaciones de QAD, Origin y Oracle, y Utting quería asegurarse de que todas
fueran comparables. La transferencia de moneda y las notas en sueco sobre los cambios hicieron
difícil la comparación.
Mientras tanto, el resto del equipo del proyecto se reunió con Bahar, quien actuaba como el
facilitador para la reunión, y quien comentó que él sinceramente comprendía que cada lado venía de
un lugar distinto y que los criterios eran diferentes. ¿Cómo es que se podía promediar la percepción
sueca –“no complique demasiado las cosas, queremos un sistema que trabaje en seis meses, y a
propósito, lo queremos barato”- con la otra percepción –“no estamos en gran apuro; queremos un
sistema bueno y si podemos tenerlo más o menos por un costo similar, ¿por qué no ir por la mejor
tecnología, el mejor sistema?”
Bahar trabajó con el grupo para tratar de decidir los factores que serían más importantes para
avanzar, adjudicarle un peso a cada uno y luego ganar consenso en el puntaje general. El Anexo 8
muestra los factores y pesos correspondientes que el equipo del proyecto utilizó para evaluar a los
dos paquetes.
Utting se alejó brevemente de su discusión con Sahlqvist y se preguntó cómo le estaría yendo al
equipo en la otra sala. Esperaba que tuvieran un mejor tiempo que el que él y Sahlqvist estaban
teniendo al tratar de ganar consenso sobre las últimas proyecciones de costos de Oracle y QAD. Dada
la tensión en el aire en el aeropuerto de Memphis, tanto Utting como Sahlqvist creían que su
participación podría endurecer la discusión libre entre los miembros del equipo. Además, era el
equipo de proyecto el que debía implementar la elección final. En ese punto Bahar pasó al interior de
la oficina y anunció “el grupo ha llegado a un consenso.”
14
-15-
309-S40
-16-
309-S40
309-S40 -17-
Anexo 3 Timberjack Parts:
JIM UTTING
GERENTE GENERAL
DE PARTES
Debbie Reimer Rick Cantu

Secretaria Comprador/planificador
Ron Kipp
Rick Cantu
Representante de Ventas de
Comprador/planificador
Partes
Dave Morris Mary Cole

Rick Cantu Jane Torbush
Gerente de Apoyo al Representante de Ventas
Comprador/planificador Gerente de Almacenamiento
Distribuidor Internacionales de Partes
John Yeoman Randy Aucker

Phil Eckhardt 14 PERSONAS
Grente de Apoyo al Representante e Ventas
Producto Internacionales de Partes
Chuck Bartram John Eckstein

Ed Garner
Especialista de Apoyo al Representante de Ventas
Producto Internacionales de Partes
Jeff McMillian
Lamar Sanders
Representante de Ventas
Internacionales de Partes
Louie Wilson
David Jared
Representante de Ventas
Comprador
Internacionales de Partes
309-S40 -18-
Anexo 4 Organigrama de Timberjack Parts en Marsta
Presidente
Pert Sahlqvist
Sistemas de Información (S)

Christine Smedjer Compras
Sanna Blomberg
Despacho Hans Anderson
Asistente de Postventa Lars Älvag
Dieter Reinisch Jaana Ruuska
Johan Eriksson
Proyectos Asistente de Postventa Operaciones de Inventario

Jelena Rochina Jaana Ruuska Hans Larsson
Bo Hansson
Leif Jansson
Börje Söderlind
Servicio al Cliente
Bert Westin – Gerente
Almacenamiento
Ake Airjocensuu
Jens Lindberg: Nórdico, Europa Central
Göran Hedberg
Kent Rapp: Ultramar, Báltico
Li Jansson
Björn Juvas
Lars Säfström: Europa Latina, Rusia
Kent Landin
Pontus Lung
Anders Borg: África
K-A Matthiasson
Catarina Sjöberg
Eric Wiklund: Soporte Técnico de Partes
Micahel Wrede
309-S40 -19-
Anexo 5 Extractos de la solicitud de propuesta de Timberjack
Planeamiento de requerimientos
Las siguientes funciones serán requeridas:

Requerimientos Debe Cumple Mejora Personaliza N/A
5.2.1. Habilidad para dar soporte al planeamiento de requerimientos *
5.2.2. Habilidad para dar soporte al planeamiento de requerimientos basado en pronósticos de demanda con fases de tiempo *
5.2.3. Habilidad para dar soporte al planeamiento de requerimientos basado en los balances del inventario disponible *
5.2.4. Habilidad para dar soporte al planeamiento de requerimientos basado en las políticas de órdenes *
5.2.5. Habilidad para dar soporte al planeamiento de requerimientos basado en las políticas del stock de sguridad *
5.2.6. Habilidad para dar soporte al planeamiento de requerimientos basado en las órdenes planificadas confirmadas *
5.2.7. Habilidad para dar soporte al planeamiento de requerimientos basado en recibos programados *
5.2.8. Habilidad de permitir la creación de órdenes y recibos planificados por el planeamiento de requerimientos *
5.2.9. Habilidad para permitir al comprador/planificador cambiar las órdenes planificadas *
5.2.10. Habilidad para permitir al comprador/planificador cambiar las órdenes confirmadas *
5.2.11. Habilidad para dar soporte a als regulaciones de redondeo de cantidad en las órdenes definidas por el usuario *
5.2.12. Habilidad para asignar el stock automáticamente basado en las prioridades definidas por el usuario *
5.2.13. Habilidad para dar soporte a los centros de distribución múltiple *
5.2.14. Habilidad para dar soporte a una definición de red de almacenes *
5.2.15. Habilidad para dar soporte a la gestión de cadena de suministro *
5.2.16. Habilidad para dar soporte al reporte de excepción definido por el usuario *
5.2.17. Habilidad para dar soporte a las simulaciones del planeamiento de requerimientos *
5.2.18. Habilidad para dar prioridad a demanda/embarque *
5.2.19. Habilidad para dar prioridad al stock limitado y a las órdenes pendientes *
5.2.20 Habilidaid para usar un calendario de planeameinto de requerimientos *
5.2.21. Habilidad para tener plazos de tiempo entre los almacenes *
5.2.22. Habiliad para calcular la rotación de inventarios proyectada *
5.2.23. Habilidad para dar soporte al cálculo flexible de rotación de inventario *
5.2.24. Habilidad para consultar sobre el satus del stock en todas las locaciones *
5.2.25. Habilidad para calcular el inventario proyectado basado en fases de tiempo *
*Combinación de Planeamiento MRO/Planeamiento Estadístico del Inventario *
309-S40 -20-
Anexo 5 (continuación)
Compras
Las siguientes funciones serán requeridas:

Requerimientos Debe Cumple Mejora Personaliza N/A
5.3.1. Capaz de administrar órdenes siguiendo los métodos de "las mejores prácticas" de colocación, control y aplicación *
5.3.2. Capaz de administrar/controlar compras en bloque a través de planillas de órdenes con propuesta discreta *
5.3.3. Capaz de establecer la programación de los proveedores *
5.3.4. Capaz de alternar proveedores con historia para las mismas partes con el fin de asistir en la decisión de compra *
5.3.5. Capaz de dar soporte a la categorización de los proveedores para determinar a los buenos o malos proveedores y el costo *
verdadero de la compra
5.3.6. Capaz de administrar órdenes de compra únicas con múltiples números de rubro de línea *
5.3.7. Capaz de administrar órdenes con múltiples fechas de vencimiento para un número de rubro *
5.3.8. Capaz de dar soporte a notas de órdenes de formato libre, las cuales se imprimen automáticamente para todas las *
órdenes
5.3.9. Capaz de dar soporte a notas de órdenes de formato libre, las cuales se imprimen automáticamente para proveedores *
específicos
5.3.10. Capaz de integrar el módulo de planeamiento de requerimientos vía solicitud de compra *
5.3.11. Capaz de convertir las solicitudes de compra a órdenes de compra automáticamente *
5.3.12. Capaz de calcular la varianza de precio de compra al recibo/pago *
5.3.13. Capaz de administrar órdenes de compra en moneda extranjera múltiple *
5.3.14. Capaz de hacer seguimiento a la fecha de necesidad *
5.3.15. Capaz de hacer seguimiento a la fecha prometida *
5.3.16. Capaz de hacer seguimiento a la fecha de vencimiento *
5.3.17. Capaz de hacer seguimiento a la fecha real *
5.3.18. Capaz de crear órdenes de compra para rubros que no son para inventario *
5.3.19. Capaz de hacer seguimiento a la precisión de precio del proveedor *
5.3.20. Capaz de importar los incrementos de precio del proveedor electrónicamente *
5.3.21. Capaz de hacer seguimiento/informar sobre los tiempos de embarque del proveedor - fecha real vs. Fecha de vencimiento *
5.3.22. Capaz de hacer seguimiento/informar sobre los tiempos de embarque del proveedor - tiempo real vs. Plazo de tiempo *
5.3.23. Capaz de hacer seguimiento/informar el cumplimiento del proveedor con los requerimientos SOS *
5.3.24. Capaz de dar soporte a recibos parciales *
5.3.25. Capaz de enviar un fax automáticamente a ciertos proveedores *
5.3.26. Capaz de usar EDI con ciertos proveedores *
5.3.27. Capaz de cambiar/cancelar la orden de compra por rubro de línea *
5.3.28. Capaz de anular todas las fechas *
309-S40 -21-
Anexo 6 Comparación de funcionalidad de la propuesta de los cuatro proveedores principales
Lawson CA Oracle QAD

General Total Cumple % Cumpli. Cumple % Cumpli. Cumple % Cumpli. Cumple
1.1. Hardware 9 9 100 7 78 9 100 7
1.2. Software 37 36 97 36 97 36 97 33
1.3. Seguridad 17 17 100 15 88 17 100 17
1.4. Informe de usuario final 27 27 100 24 89 27 100 23
1.5. Impresiona 15 15 100 12 80 15 100 12
1.6. Documentación 8 8 100 8 100 8 100 8
Total General 113 112 99 102 90 112 99 100
Procesamiento de Orden de Ventas Total Cumple % Cumpli. Cumple % Cumpli. Cumple % Cumpli. Cumple
2.1. Ingreso de orden de ventas 91 73 80 65 71 82 90 77

2.2. Fijación de precios 36 27 75 30 83 34 94 26
2.3. Verificación de inventario 10 7 70 9 90 10 100 10
2.4. Verificación de crédito 8 8 100 9 113 8 100 6
2.5. Reformas y créditos 13 8 62 13 100 13 100 6
2.6. Aduana 4 1 25 0 0 1 25 1
2.7. RSPL 9 1 11 3 33 9 100 7
2.8. Informes 3 3 100 3 100 2 67 3
2.9. Integración 7 3 43 5 71 7 100 5
Total órdenes de ventas 181 131 72 137 76 165 92 141
Sistema de Distribuidores Total Cumple % Cumpli. Cumple % Cumpli. Cumple % Cumpli. Cumple
3.1. 13 11 85 7 54 13 100 11
Análisis de ventas Total Cumple % Cumpli. Cumple % Cumpli. Cumple % Cumpli. Cumple
4.1. 25 15 60 14 56 25 100 23
Gestión de inventario Total Cumple % Cumpli. Cumple % Cumpli. Cumple % Cumpli. Cumple
5.1. Pronóstico/planeamiento 49 22 45 46 94 46 94 34
5.2. MRP 25 21 84 22 88 25 102 25
5.3. Compras 28 27 96 23 82 27 96 27
5.4. Kitting 14 3 21 14 100 14 100 14
(procesamieinto de orden de rubros separados pero relacionados y atendidos como una unidad
309-S40 -22-
Anexo 6 (continuación)
Lawson CA Oracle QAD

Almacenamiento Total Cumple % Cumpli. Cumple % Cumpli. Cumple % Cumpli. Cumple % Cumpli.
6.1. Recepción/separación 30 21 70 22 73 24 80 28 87
6.2. Selección/empaque 47 19 40 34 72 33 72 37 79
6.3. Facturación 15 15 100 14 93 12 80 14 93
6.4. Control de inventario 22 22 100 21 95 22 100 22 100
6.5 Informes 9 7 78 5 56 9 100 9 100
6.6. Integración 10 4 40 3 30 10 100 9 90
Total Almacenamiento 133 88 86 99 74 110 83 117 88
Contabilidad Total Cumple % Cumpli. Cumple % Cumpli. Cumple % Cumpli. Cumple % Cumpli.
7.1. AR 51 49 96 47 92 47 92 48 90
7.2. AP 52 49 94 47 90 51 98 48 92
7.3. GL 84 82 98 85 100 84 100 80 95
7.4. Costeo 27 8 30 22 82 25 93 24 89
7.5. Informes 54 43 80 53 98 54 100 50 93
7.6. Integración 6 6 100 4 67 6 100 6 100
Total Contabilidad 274 237 87 258 94 267 97 254 93
Datos del Archivo Maestro Total Cumple % Cumpli. Cumple % Cumpli. Cumple % Cumpli. Cumple % Cumpli.
8.1. Información sobre las partes 88 60 68 69 78 85 97 80 91

8.2. Información sobre los clientes 27 24 89 20 74 26 96 25 93
Información de los
8.3. proveedores 24 20 83 17 71 24 100 23 96
Total del Archivo Maestro 139 104 75 106 76 135 97 128 93
Nota: Este anexo es una comparación de las respuestas positivas al cuestionario de solicitud de propuesta de Timberjack. Se le preguntó a cada proveedor si
su software cubría los requerimientos de funcionalidad requeridos sin una personalización. Por ejemplo, Lawson podía satisfacer 78% de los requerimientos
sin ninguna modificación.
Este documento fue preparado con el apoyo de Coopers & Lybrand.
Anexo 7 Resumen de evaluación de costos de proveedores
Marsta USD Atlanta USD Total
QAD
Servidor 85,757 73,245 159,002
Software de aplicación 175,000 150,000 325,000
Personalización 0 200,000 200,000
Consultoría de Implementación 175,000 120,000 295,000
Honorarios de Soporte cinco años – HW y SW 185,000 150,000 335,000
Total QAD 1,314,002
Oracle
Servidor 139,051 135,751 274,802
Aplicación de software 275,000 250,000 525,000
Personalización 0 30,000 30,000
Consultoría de Implementación 275,000 240,000 515,000
Honorarios de Soporte cinco años – HW y SW 260,000 275,000 535,000
Total Oracle 1,879,802
Nota: Para mantener la confidencialidad sobre las cotizaciones de los proveedores, se han cambiado
todos los números. Las relaciones entre las ofertas se han mantenido a través del uso de una
escala proporcional.
Anexo 8 Criterios de evaluación y pesos
Factor peso Weight QAD Oracle
Soporte 20
Funcionalidad 30
Interfase de usuario 10
Flexibilidad 20
Prospectos futuros 10
Confiabilidad 20
Integración 30
Plataforma 20
Total 160
23

Lectura PDF

Cargado por

Información del documentohacer clic para expandir la información del documento

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Lectura PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Lectura PDF

Cargado por

Copyright:

Formatos disponibles

309-S40

FEBRERO 25, 1998

Timberjack Parts: Proyecto de Selección de

La mañana del 15 de Diciembre de 1995, Jim Utting, el gerente general de partes de

Mientras Utting y Sahlqvist trataron difícilmente de formar un solo equipo, la geografía – y en un

Operaciones de Timberjack Parts

La Necesidad de Nuevo Software

A inicios de 1995, Sahlqvist y el grupo Masta se encontraban investigando activamente sobre la

Al mismo tiempo, en las oficinas principales de Timberjack de Norteamérica en Woodstock,

Consiguientemente, se les dio a las organizaciones de partes de servicio la tarea de seleccionar un

Ambas organizaciones se encontraban bajo una considerable transición al momento en que el

En la primavera de 1995, la operación norteamericana tenía todavía al grupo principal de

Proceso de Solicitud de Propuesta

Bahar, Romanow y González organizaron un cronograma de fechas de reunión para completar la

Se llevaron a cabo sesiones para contabilidad, finanzas, compras/planeamiento, servicio al cliente,

Reconocemos que desde el punto de vista de la aprobación del proyecto, el análisis

Para completar la solicitud de propuesta, Romanow y Nikkinen recopilaron estadística básica de

Si la solicitud de propuesta se hiciera en Suecia tendría aproximadamente cinco

El grupo norteamericano estaba comprometido a seguir la metodología de Coopers & Lybrand.

La fortaleza del proceso de solicitud de propuesta era de que termináramos con

El estándar corporativo de Oracle tenía como intención que diera a Timberjack la

En total, se envió las solicitudes de propuesta impresas y en discos magnéticos a 13 compañías.

Con la rápida eliminación de dos proveedores oferentes, el equipo tuvo la oportunidad de

Asistimos a una presentación de ventas a la cual asistieron otras compañías. Para

El paquete de Lawson también nos fue presentado en Suecia y estuvimos muy

Se le solicitó al representante de Lawson proporcionar una cotización para un paquete de

Las presentaciones de Oracle en Atlanta involucraron a un representante financiero de Oracle,

Una de las instalaciones falló; el representante de sistemas de la compañía dijo que

Timberjack estaba interesado en obtener un contrato de precio fijo para el software y la

Además de las modificaciones al sistema de distribuidores, se le proporcionó a QAD documentación

Los consultores de implementación de Oracle y de Origin, quien representaba a QAD, fueron

A lo largo de las siguientes semanas, el equipo de Atlanta se reunió con el grupo de

Debido a la cantidad de tiempo que Timberjack ya había invertido en la solicitud de

servicios de consultoría. Debido a la calidad de la solicitud de propuesta de Timberjack, él creía que

Utting preguntó sobre las programaciones de implementación al consultor de implementación

Visitas a las Locaciones

Utting comentó sobre las dos visitas a los locales:

El día en Matrix estuvo bien organizado y hubo varias personas de Matrix

Anexo 3 Timberjack Parts:

Debbie Reimer Rick Cantu

Dave Morris Mary Cole

John Yeoman Randy Aucker

Chuck Bartram John Eckstein

Anexo 4 Organigrama de Timberjack Parts en Marsta

Sistemas de Información (S)

Proyectos Asistente de Postventa Operaciones de Inventario

Anexo 5 Extractos de la solicitud de propuesta de Timberjack

Las siguientes funciones serán requeridas:

Las siguientes funciones serán requeridas:

Anexo 6 Comparación de funcionalidad de la propuesta de los cuatro proveedores principales

Lawson CA Oracle QAD

2.1. Ingreso de orden de ventas 91 73 80 65 71 82 90 77

Lawson CA Oracle QAD

8.1. Información sobre las partes 88 60 68 69 78 85 97 80 91

Anexo 7 Resumen de evaluación de costos de proveedores

Marsta USD Atlanta USD Total

Anexo 8 Criterios de evaluación y pesos