UNIVERSIDAD CATÓLICA BOLIVIANA “SAN PABLO”

UNIDAD ACADÉMICA REGIONAL COCHABAMBA

Departamento de Ciencias Exactas e Ingenierías
Carrera de Ingeniería de Sistemas

Desarrollo del rol de socio estratégico de tecnología,

en una empresa transnacional de consumo masivo
entre los años 2001 y 2017

Memoria Profesional

Harold Ruben Arando Quispe

Cochabamba – Bolivia
Diciembre de 2017
 TRIBUNAL EXAMINADOR

__________________________ __________________________
Dr. Gustavo Calderón Mejía Mgr. Tatiana Aparicio Yuja
Docente Evaluador Docente Evaluadora

__________________________ __________________________
Mgr. Yanina Galaburda Dr. Luis Alfonso Via Reque
Directora de Carrera a.i. Rector Regional
 Dedicatoria

A mi querida Esposa y a mis tres maravillosos hijos,

por su gran apoyo y paciencia.
 Agradecimientos

A Dios, que siempre me brindo las mejores oportunidades,

a mis padres y hermanos, que me guiaron en esta aventura llamada vida,
y un agradecimiento especial a la memoria del Mgr. Johnny Herrera, por su valioso
apoyo en mi formación académica.
 RESUMEN

El presente documento tiene por objetivo compartir las experiencias, vivencias y

aprendizajes de un profesional de sistemas, a lo largo de 16 años de trabajo en una empresa
transnacional de consumo masivo, desde diferentes cargos, procesos y países entre los
años 2001 y 2017.

Las diferentes situaciones y proyectos en los que participó el autor, son mostrados en un
orden cronológico y describen el crecimiento profesional del mismo, desde un perfil de
desarrollador y técnico, pasando por un proceso de crecimiento rodeado de importantes
desafíos, hasta convertirlo en un socio estratégico de tecnología, con importantes aportes
al negocio de Unilever Américas, a través de la implementación de proyectos de
tecnología en el área de Supply Chain.

La memoria profesional expone el uso de diferentes metodologías y herramientas de

tecnología de información que soportaron la exitosa implementación de varios proyectos
en diferentes países y procesos estratégicos en varias Plantas de Manufactura y Centros
de Distribución, con tamaños y realidades diferentes en un marco de gran diversidad que
solo Latinoamérica puede ofrecer.

Palabras clave: Unilever, Latinoamérica, SAP, OTM, Logística, Distribución, Socio

Estratégico.
 ABSTRACT

This document has the objective of sharing experiences and learnings of a systems
professional, over 16 years of work in a transnational company of massive consume, from
different positions, process and countries between the years 2001 and 2017.

The different situations and projects in which the author participates, are show in
chronological order and describes his own professional growth, from a developer and
technical profile, through a process of growth surrounded by important challenges, until
becoming a strategic partner of technology, with important contributions to the Unilever
Americas business, through the implementation of technology projects in the Supply
Chain area.

The professional memory exposes the use of different information technology tools and
methodologies that supported the successful implementation of several projects in
different countries and strategic processes of several manufacturing plants and distribution
centers, with different sizes and realities within a framework of great diversity that only
Latin America can offer.

Keywords: Unilever, Latin America, SAP, OTM, Logistics, Distribution, Strategic

Partner.
 ÍNDICE GENERAL

INTRODUCCIÓN.................................................................................................... 10

1. MARCO TEÓRICO REFERENCIAL ............................................................. 11

1.1. Unilever: caso de estudio ........................................................................... 11
1.2. Tecnología involucrada ............................................................................. 13

2. EL INICIO: ESTABILIZACIÓN, CREDIBILIDAD DE SISTEMAS E

INTEGRACIÓN ................................................................................................. 16
2.1. Ingeniería inversa de sistemas ................................................................... 17
2.2. Integrando Sistemas .................................................................................. 20

3. DE CASA A CONDOMINIO............................................................................. 23
3.1. Construyendo el Condominio.................................................................... 23
3.2. Viviendo en un Condominio ...................................................................... 27
3.2.1. Estructura Organizacional ............................................................... 28
3.2.2. SAP en el Condominio ..................................................................... 32
3.2.3. Cierre de un ciclo ............................................................................. 34

4. DESARROLLO DEL ROL DE SOCIO ESTRATÉGICO, EN LA

REGIÓN ............................................................................................................. 37
4.1. México: El desembarco.............................................................................. 38
4.2. Brasil, la operación más grande y diversa de Latinoamérica .................. 47
4.3. Desafío: South Cone .................................................................................. 51
4.4. Ultralogistik: la última frontera ................................................................ 56
4.4.1. Brasil, construyendo un Centro de distribución de clase mundial ... 57
4.4.2. Argentina, reordenamiento de la malla logística.............................. 58
4.4.3. Inbound Redesign: en busca de nuevos desafíos .............................. 61
CONCLUSIONES .................................................................................................... 65

RECOMENDACIONES .......................................................................................... 66

BIBLIOGRAFÍA ...................................................................................................... 67

ANEXOS
Anexo 1. Glosario de Términos Técnicos ......................................................................1
 ÍNDICE DE FIGURAS

Figura 1, Organigrama Unilever Andina Bolivia S.A............................................. 13

Figura 2, Malla de Sistemas ..................................................................................... 17
Figura 3, Proyecto Harmonía .................................................................................. 24
Figura 4, Proyecto Cordillera .................................................................................. 39
 INTRODUCCIÓN

A fines del año 2000, tras un proceso de selección tuve la oportunidad de realizar mis
primeras experiencias profesionales en el Instituto de Investigación en Informática
Aplicada de la Universidad Católica Boliviana, donde pude vivir de cerca el desarrollo
profesional de Software, en un marco internacional y con la aplicación de altos estándares
de calidad. Esta experiencia fue muy enriquecedora como desarrollador de software, pero
circunstancias laborales me llevaron a desarrollarme en otra área de tecnología.

En septiembre del 2001, fui contratado por una importante empresa transnacional de
consumo masivo llamada Unilever Andina Bolivia S.A., dicha empresa tiene como foco
de negocio: la fabricación y comercialización de productos de consumo masivo de
limpieza personal y del hogar, además de una división de alimentos, cuenta con un
importante portafolio de productos líderes en el mercado y con su producto estrella, el
detergente: “OMO”.

Unilever es una empresa anglosajona con sede central en Londres, con una fuerte
presencia global, donde cada día, dos mil millones de personas eligen un producto de
Unilever para verse bien, sentirse bien y sacarle más provecho a la vida [1]. En Bolivia la
oficina principal, el centro de distribución nacional y la planta de manufactura están
ubicadas en el departamento de Cochabamba, adicionalmente Unilever cuenta con una
oficina comercial y un centro de distribución en Santa Cruz y una oficina comercial en La
Paz, generando de manera directa e indirecta más de 700 fuentes laborales a nivel
nacional.

El año 2001, Unilever tras un importante y difícil proceso de renovación tecnológica la

empresa contaba con nuevos sistemas y se encontraba frente al gran desafío de estabilizar
los mismos. Es aquí donde comienza mi primera incursión en la compañía y le siguen 16
años de trayectoria profesional, en distintitos cargos y responsabilidades en el área de
sistemas, tanto a nivel nacional como internacional.

10
 1. MARCO TEÓRICO REFERENCIAL

A lo largo del presente trabajo, se describen sistemas, estructuras organizacionales,

procesos, estrategias de negocios y proyectos, que hacen parte del diario accionar de la
multinacional Unilever, por tanto, veo conveniente hacer una descripción de esta
compañía, así como del marco tecnológico que sustenta a la plataforma de sistemas que
es utilizada por esta empresa.

1.1. Unilever, caso de estudio

Unilever es compañía británica-holandesa, que cotiza en la bolsa de valores de Nueva

York con el código UN [1], que, en la fecha de elaboración del presente trabajo, el valor
unitario de cada acción es de 57.26 dólares americanos.

Unilever fue creada en 1930, como resultado de la fusión de Margarine Unie, compañía
holandesa de margarina y Lever Brothers, fabricante ingles de jabones. Durante la segunda
mitad del siglo XX la empresa diversificó su portafolio de productos en base al uso de
aceites y grasas, ampliando así sus operaciones a todo el mundo. Paralelamente, realizó
numerosas adquisiciones corporativas, entre las más importante están: Lipton (1971),
Brooke Bond (1984), Chesebrough-Ponds (1987), Best Foods (2000), Ben & Jerry's
(2000), Alberto-Culver (2010) y Dollar Shave Club (2016).

En 2015, el actual CEO Paul Polman, cambió gradualmente su enfoque hacia las marcas
de salud y belleza, dejando de lado las marcas de alimentos que mostraban un crecimiento
lento y que no iban en línea con la estrategia comercial establecida al interior de la
compañía.

Unilever cuenta con más de 400 marcas, a nivel global, el foco de la compañía se centra
en trece de ellas, donde cada una, factura anualmente más de mil millones de euros.

11
Las primeras 25 marcas de Unilever representan más del 70% de sus ventas. Las marcas
están organizadas en diferentes categorías: alimentos, cuidado del hogar, cuidado personal
y helados. Las marcas más conocidas a destacar son:

• Para el cuidado del hogar: Skip, Omo, Cif, Soft.

• Para el cuidado personal: TRESemmé, Axe, Rexona, Dove, Pond’s, Sedal.
• En alimentos: Maizena, Lipton, Knorr, Hellmann's, Ri-k.
• En la fabricación de helados: Kibon, Pingüino, Bresler, Tio Rico y Ben & Jerry's.

En lo referente a la estructura organizacional, Unilever tiene tres grupos de negocio a nivel

mundial, en los cuales se ejecutan diversas estrategias orientadas al tipo y tamaño del
mercado, y a los diferentes gustos de los consumidores.

• Grupo S1, Europa, una parte de Asia y la parte norte de África

• Grupo S2, Asia, Oceanía y la parte sur de África.
• Grupo S3, Norteamérica y Latinoamérica.

El grupo S3 está dividido en dos: Norteamérica que está compuesta por Canadá y Estados
Unidos y Latinoamérica que cubre toda la geografía que va desde México al norte hasta
Argentina en el Sud. Este grupo latinoamericano está liderado por Argentina a través de
su Presidente Miguel Kozuszok.

Bolivia, se encuentra dentro el grupo de negocios llamado Cono Sur y cuenta con una
estructura centralizada en Cochabamba, desde donde se atienden todos los procesos de
importación de materia prima y producto terminado, manufactura de bienes y
comercialización de productos locales e importados, además del proceso de tecnología de
información, que es expuesto en el presente trabajo. Figura 1.

Hoy en día Unilever en Bolivia, es líder del mercado de detergentes y tiene una importante
participación en el mercado de desodorantes y jabones.

12
 Figura 1
Organigrama Unilever Andina Bolivia S.A.

Gerente General

Gerente de Gerente de Gerente de

Gerente Comercial
Producción Logística Finanzas

Jefatura de
IT

Fuente: RRHH UNILEVER 2017

1.2. Tecnología involucrada

Dentro de un contexto global, Unilever tiene una infinidad de sistemas que envuelven
diferentes tecnologías de información, algunas actuales y otras más antiguas que están
consolidadas y aún vigentes.

En una empresa de la envergadura de Unilever, los sistemas de información son vitales a

la hora de la toma decisiones estratégicas de negocio. En este orden de ideas, la compañía
escogió un sistema robusto como SAP ERP [3], como la plataforma global a nivel
transaccional y operativo.

En lo referente a la tecnología usada a nivel de base de datos, aún está en vigencia las
bases de datos relacionales, ya que, si bien es una tecnología relativamente vieja, en

13
contrapartida es una solución bastante robusta, con mucho soporte y con una alta
confiabilidad.

Compañías grandes, como es el presente caso de estudio, trabajan con grandes socios de
tecnología que le ofrecen un alto grado de soporte y confiabilidad de soluciones. Es por
eso que Unilever globalmente utiliza soluciones provistas por Oracle [4], en lo que
respecta a la parte de implementación de proyectos, la consultora global Accenture es la
encargada de la ejecución de los proyectos en equipo con personas de IT y de negocio de
la compañía.

Para la parte de infraestructura de computadores, servidores y telecomunicaciones, la

misma lógica de grandes socios es utilizada, y es así que todos los equipos son de la línea
de IBM, Cisco, Lenovo y Alcatel.

Compañías de consumo masivo, donde el foco de negocio no es tecnología, los desarrollos

locales son muy reducidos y en caso de existir son tercerizados con empresas expertas en
el ramo. Sin embargo, si bien no se hace desarrollo interno, todos los conceptos teóricos
de Ingeniera de software [5], tienen que ser considerados a la hora de la negociación de
costos, tiempos y soporte de aplicaciones con los proveedores.

En este tipo de compañías, los conocimientos teóricos en sistemas de información y en

base de datos, de un profesional en sistemas, son ampliamente utilizados a momento de
ofrecer a los usuarios un soporte adecuado en los diferentes problemas y necesidades que
van surgiendo por la constante innovación y ajuste de las estrategias de negocio, que como
en cualquier proceso están sujetos a una constante evolución.

En los últimos años Unilever, al igual que el resto de las compañías del ramo ha priorizado
el uso de soluciones en la Nube, tanto para contratar servicios, como también sistemas, ya
que la necesidad de disponer de la información en cualquier lugar y a cualquier horario es
una tendencia que ya no tiene retorno, al igual que el uso de la tecnología móvil, donde

14
las tradicionales laptops y desktops pierden terreno a pasos agigantados y son candidatas
a desaparecer en un corto tiempo.

Es importante destacar que uno de los conceptos más utilizados del marco teórico de
sistemas de información, es la parte referida a la generación de información, que es llevada
a los sistemas, a través de la generación de reportes; este tal vez es el punto más importante
a considerar a la hora de la implementación de proyectos de tecnología de información,
ya que, hoy en día en general los sistemas transaccionales han quedado de lado y han dado
paso a los sistemas de reportes, que basados en conceptos de inteligencia artificial,
técnicas de minería de datos, inteligencia de negocios OLAP [6] y simulación de
escenarios futuros de negocio, ofrecen soluciones altamente competitivas y con una gran
demanda en el mercado empresarial, donde el acceso oportuno a la información marca la
diferencia entre negocios exitosos y fallidos.

15
 2. EL INICIO: ESTABILIZACIÓN, CREDIBILIDAD DE SISTEMAS E
INTEGRACIÓN

Unilever Bolivia en el 2001 era parte de un grupo de negocios denominado: “South

Andina”, donde junto con Perú, hacían un reporte conjunto de las operaciones a casa
matriz en Londres, sin embargo, en la parte de sistemas eran totalmente independientes,
cada país soportaba sus propios sistemas, y no contaban con ninguna estructura de soporte
centralizado.

Bolivia tenia implementados varios sistemas con alcance nacional, siendo los tres
siguientes, los más relevantes (Figura 2):

• MFG/pro, usado para el manejo de la facturación y el control de stock de producto

terminado en los almacenes. Era un producto estadounidense desarrollado en
California en PostgreSQL.

• Fourth Shift, usado para el manejo, planeación y control de la producción en la

planta de manufactura. Un producto estadounidense desarrollado en New York en
Visual C.

• Optimix, usado para el manejo de la contabilidad, tesorería, cuentas por pagar y

cobrar, costos, activos fijos y planillas. Un producto desarrollado localmente en
Form Designer y Report Designer bajo PL/SQL de Oracle.

El equipo local de sistemas, el cual era denominado IT (Information Technology), tenía a

su cargo el soporte de la infraestructura de comunicaciones y de servidores, el servicio de
Helpdesk, la implementación de proyectos y el soporte a todas las aplicaciones de negocio.

Mi primer rol en el equipo fue el de dar soporte al sistema financiero Optimix, el cual
tenía un porcentaje muy reducido de uso, dado sus constantes problemas.

16
 Figura 2

Malla de Sistemas

Fuente: IT UNILEVER 2002

2.1.Ingeniería inversa de sistemas

El inicio de mi trabajo, como soporte del sistema Optimix, no fue nada fácil,
aparentemente el proyecto de implementación del sistema que duró casi dos años no fue
adecuadamente manejado y las relaciones comerciales con la empresa que desarrolló la
solución no tuvo un buen término.

El impacto directo en el soporte de la deficiente implementación, fue que no existía una

adecuada documentación, no se tenía un diagrama entidad-relación de la base de datos

17
que estaba en Oracle, no se tenía códigos fuentes de los programas desarrollados, mucho
menos una adecuada documentación, no se tenía ningún manual de usuario, ni técnico del
sistema, además de que la mayoría de las personas que participaron en el proyecto ya no
estaban trabajando en la compañía.

En este punto, tuve que iniciar un largo proceso de ingeniería inversa del sistema, para
poder entender y comprender cómo realmente funcionaba y a partir de esto, poder corregir
los errores y hacer que los usuarios crean y usen nuevamente la aplicación.

El hecho de que nadie conocía realmente cómo funcionaba el sistema, propició que se
generaran varios errores de carácter contable que derivaron en que los usuarios dejaran de
usar Optimix y lo terminaron reemplazando con planillas y macros en Microsoft Excel,
debido a que los requerimientos de corrección y mejora del sistema nunca fueron
atendidos oportunamente.

Durante mis años de formación académica aprendí varios lenguajes de programación de

base de datos, sin embargo, el presente desafío requería que también conozca el proceso
financiero de la compañía y es ahí donde empecé. Participé y acompañé varios cierres
mensuales financieros y contables, para identificar las necesidades de los usuarios y los
verdaderos problemas que aquejaba el sistema.

El trabajo de ingeniería inversa que afronté empezó con la revisión de los reportes que el
sistema generaba, con el fin de saber su origen dentro de la base de datos y empezar a
construir un diagrama entidad-relación y en el camino corregir los problemas identificados
por los usuarios en cada uno de los reportes. En resumen, partí del resultado final para
entender cómo funcionaba el sistema.

Tras varias semanas de análisis y programación en Report Designer, finalmente pude

obtener un diagrama entidad-relación básico y corregir varios reportes críticos que el

18
usuario necesitaba con urgencia, dando paso a la siguiente etapa: la ingeniería inversa de
procesos.

En este parte tuve que trabajar muy de cerca con los usuarios ya que todas las pantallas de
ingreso de información y ejecución de procesos requerían un importante conocimiento del
proceso de contabilidad, cuentas por pagar y cobrar, tesorería, planillas de pago de salarios
y activos fijos.

Después de un par de meses, identifiqué los procesos más relevantes y su interrelación

con los programas y la base de datos, con este conocimiento conseguí determinar y
corregir los principales problemas a la hora de ejecutar los cierres contables mensuales.

Tuve un trabajo muy detallado y contra reloj para corregir las diferentes opciones del
sistema mediante el uso de Form Designer, ya que el cierre anual del 2001 estaba cerca y
no podíamos exponer a que la compañía no entregase el balance anual o que lo entregué
con errores.

El trabajo de ingeniera inversa no terminó con el balance anual, seguimos trabajando junto
a los usuarios para corregir los otros procesos, si bien los más críticos ya estaban
funcionando, los otros errores de sistema, hacían que los cierres mensuales duren
prácticamente una semana.

Tras 12 meses de muchos esfuerzos, pudimos devolver la credibilidad al sistema, los

usuarios dejaron de usar Microsoft Excel, documentamos adecuadamente las
correcciones, construimos un diagrama entidad-relación robusto, mejoramos el
performance de la aplicación y el impacto en tiempo de trabajo para el negocio fue muy
importante, además de que por primera vez los usuarios, contaban con manuales de uso
del sistema.

19
2.2. Integrando Sistemas

Posterior al éxito alcanzado en Optimix, fui involucrado en otros proyectos, con foco en
la integración eficiente de sistemas.

Ya en el 2003, Unilever Bolivia contaba con sistemas estabilizados, adecuadamente

documentados y con una incidencia baja de problemas que estaban bajo control, sin
embargo, si bien los sistemas por si solos atendían los requerimientos de la compañía, a
la hora de compartir información entre ellos, el tema no funcionaba como la compañía
requería, para el soporte en la rápida toma de decisiones estratégicas de negocio.

El principal desafío fue el de extraer información del sistema de manufactura: Fourth

Shift, para que este alimentase de forma automática, el módulo de costeo de la producción
del sistema contable Optimix. Fourth Shift era un sistema totalmente cerrado y sin soporte
oficial del proveedor, si bien generaba algunos archivos planos, la información era muy
compleja y desordenada para poder migrarla directamente a Optimix.

Solución: tras varias reuniones con los usuarios que usaban la aplicación logré determinar
que opciones del sistema, se podrían usar para generar la información necesaria para
ejecutar un adecuado costeo de la producción. Entonces se pasó a generar una cantidad
importante de archivos planos, donde en cada uno de ellos, se tenía parte de la información
requerida.

Los archivos planos eran de gran tamaño, debido a que la inclusión de filtros en el sistema
que los generaba no era nada fácil de implementar, por lo cual se determinó usar una
aplicación intermedia, que cargue correctamente los archivos planos, que ordene la
información, que la filtre eficientemente y que pueda generar archivos con un formato
“csv”.

20
Genere una aplicación en Microsoft Access, que con el uso de varias macros podía ejecutar
el proceso de carga, filtrado y generación de archivos planos de manera rápida y
automática. Dado que el sistema de manufactura era muy complejo, se tuvo que realizar
innumerables pruebas para garantizar que la información extractada fuera la correcta, de
hecho, durante algunos meses se usaron tablas en Microsoft Excel en paralelo para costear
manualmente la producción a fin de comparar los resultados con el nuevo proceso
automático que fue implementado, después de tres meses obtuvimos la credibilidad del
negocio y se eliminó el proceso paralelo.

El éxito de esta integración fue involucrar a los usuarios de la Planta, en los diferentes
ciclos de prueba, para que el equipo financiero compre el proyecto de automatización.

La integración con el sistema comercial y de almacén: MFG/pro, fue relativamente más

tranquila, toda la información que requería Optimix para la generación de los libros de
ventas y control de inventarios, MFG/pro lo generaba de forma ordenada. Un problema
con el que tropecé fue que el performance del servidor donde estaba alojado MFG/pro era
muy malo, y en los cierres mensuales, a la hora de generar las interfaces requeridas, el
servidor colapsaba y teníamos que reiniciar más de una vez los servicios.

Infelizmente una inversión en hardware para mejorar el servidor no fue aprobada por el
negocio, así que tuvimos que tomar mano de otras opciones:

Tunning del servidor, revisamos todos los parámetros de conexión de red, los parámetros
de la aplicación y los de la base de datos, encontrando varias oportunidades de mejora.
Esto requirió varias reuniones de análisis y pruebas con el equipo de infraestructura de IT.

Store Procedure, creamos varios programas en la base de datos para optimizar los tiempos
de respuesta durante la generación de las interfaces.

21
En este parte de mi desarrollo profesional, aprendí, que hacer más o menos es el
lineamento general de las grandes compañías, donde cada inversión es analizada
minuciosamente por el equipo financiero antes de aprobarla o rechazarla. Esta lección
aprendida fue vital en los roles futuros que tuve en la compañía.

22
 3. DE CASA A CONDOMINIO

A finales del 2003, Unilever Latinoamérica tuvo importantes cambios a nivel de negocio
que impactaron a todos los procesos de la compañía e IT fue uno de los más afectados.

Bolivia como negocio, dejó de reportar a Perú y comenzó a reportar a Colombia, un nuevo
grupo de negocios fue creado: “Greater Andina” que aglutinaba a Colombia, Venezuela,
Ecuador, Perú y Bolivia.

El común denominador de los sistemas de Unilever en Latinoamérica, era que cada país
tenía sus propios sistemas locales, por ende, también el soporte era local y pensar en tener
una estandarización de sistemas, era una necesidad que urgía, sobre todo dentro de una
economía global donde Unilever se posicionaba con mucha fuerza.

Fue en este momento crucial que la compañía acuño el término de “Condominio” y una
vez más IT, tenía que estar a la altura del desafío.

3.1. Construyendo el Condominio

En abril del año 2004 fui transferido, a Unilever Colombia para la implementación del
proyecto denominado “Harmonía” (Figura 3), cuyos objetivos principales eran cinco:

• Tener un ERP único, para toda Latinoamérica, la solución escogida fue: SAP R3,
al ser uno de los sistemas más robustos que ofrecía el mercado.

• Tener un único sistema de información gerencial de ventas y stock, la solución fue

Sinfonía de IBM Cognos, la cual contaba con una tecnología de cubos OLAP que
ofrecía un alto performance y disponibilidad a la hora de generar reportes
gerenciales.

23
• Tener una única infraestructura de servidores centralizada para toda
Latinoamérica, la solución fue crear un mega centro de cómputo en Trumbull,
Estados Unidos, para alojar el servidor de SAP, Sinfonía, Correo electrónico y los
servidores de dominio.

• Tener un soporte regional para las aplicaciones CORE de la compañía y solo dejar
con el soporte local las aplicaciones NO CORE, que, si bien no eran regionales,
eran muy importantes para las operaciones locales que las usaban.

• Tercerizar el soporte de Helpdesk, el servicio de impresión y de comunicaciones

tanto fijas como móviles.

Figura 3

PROYECTO HARMONÍA

Fuente: Portafolio de proyectos UNILEVER 2004

24
La compañía conformó un equipo de 160 profesionales de IT y de negocio en Bogotá,
Colombia para encarar el proyecto Harmonía, organizando los equipos en función a los
cinco objetivos que traía el proyecto.

En mi caso, dada mi experiencia en sistemas Financieros/Contables, integré el equipo de

implementación de SAP de los módulos financieros para todos los países que componían
“Greater Andina”.

SAP R3, tiene una cantidad importante de módulos para atender los diferentes procesos
de una compañía de la envergadura de Unilever, si bien muchos de ellos son
independientes, su correcta configuración requiere de una constante alineación entre los
diferentes equipos de implementación.

Los módulos específicos de Finanzas implementados fueron:

• FI-GL, Contabilidad general

• FI-LC, Consolidación de Sociedades (Países o negocios)
• FI-AR, Cuentas por Cobrar
• FI-AP, Cuentas por Pagar
• FI-AA, Gestión de Activos
• FI-SL, Libros contables
• CO-CCA: Contabilidad de Costos
• CO-OPA: Ordenes Internas

El proyecto comenzó con el levantamiento de las mallas de sistemas de los diferentes

países, como era de esperarse cada país tenía una innumerable cantidad de sistemas
locales, muchas veces era tan complejo de explicar la malla de sistemas de un país, que se
requería 2 o 3 personas de IT, sólo para este ejercicio.

25
El mapear qué sistemas serían reemplazados, con que módulos de SAP, fue una tarea muy
compleja, donde se tuvo que involucrar no sólo a IT, sino también el negocio y a una
empresa consultora contratada para atender el proyecto. La consultora era Accenture, un
importante socio estratégico de SAP, que tenía en su haber la implementación de
soluciones en varias compañías globales similares a Unilever.

Una vez que se definió la solución a implementar, que reemplazaba el 90% de los sistemas
locales para los cinco países, se inició la tarea de presentar y discutir con las personas del
negocio una a una las soluciones. Como era previsto, fue una de las etapas más difíciles
del proyecto, ya que ninguna operación y proceso quería perder el control de las tareas
que actualmente hacía. Después de casi dos meses la solución fue aprobada y comenzó la
configuración y los desarrollos en SAP.

En el caso particular de Bolivia, sólo dejamos en funcionamiento un módulo, de un

sistema local, esto fue una tremenda victoria para IT. Dejamos un único módulo de
Optimix, que, hacia la liquidación de las planillas de nómina y vacaciones, debido a que
no se implementó el módulo de gestión de planillas de SAP, por el elevado costo que
significaba comprar el módulo y adecuarlo al funcionamiento de la nómina de cada país.

Las dos siguientes etapas del proyecto requirió de mucha planificación y alineación con
los usuarios, estas etapas fueron la de Test y Entrenamiento. SAP era un sistema nuevo
para todos, entonces ningún usuario quería aprobar un Test, sin que estuviera 100% seguro
de que el sistema funcionaba correctamente, desde IT trabajamos muy fuerte en ajustar la
configuración de SAP y probar en varios ciclos de test unitarios, los desarrollos que fueron
contratados con la consultoría.

Inicialmente estaba planeado que los entrenamientos a usuarios finales fuera dada por la
consultora Accenture, pero dado que, hacia el final del proyecto, el presupuesto es lo
primero que se termina, el equipo de IT tuvo que tomar la responsabilidad de realizar los
entrenamientos. Al principio fue muy dura la preparación del material de entrenamiento y

26
la conciliación de agenda con los usuarios de los diferentes procesos y países, pero este
trabajo ayudó tremendamente al equipo de IT a entender y aprender mucho más del nuevo
sistema SAP, conocimiento que después fue importante en futuros proyectos y en la tarea
de estabilización del sistema.

El proyecto duró un año y tres meses, más de mil usuarios en cinco diferentes países,
pasaron de usar sistemas locales a usar un único sistema robusto como es SAP, la gente
de IT pasó de ser local a ser regional, fue un tremendo cambio cultural que tuvo que
superar el negocio, pero al final del día, ninguna operación dejó de facturar y pasamos a
vivir todos en un único “Condominio”.

3.2. Viviendo en un Condominio

Posterior a la implementación del proyecto de centralización, todas las personas que

fueron alocadas al proyecto retornaron a sus respectivos países, con la principal tarea de
estabilizar los sistemas implementados a través del nuevo modelo de soporte centralizado.

El primer cambio se refirió a la manera en que los usuarios accedían al soporte de IT, tanto
local como regional, una nueva metodología de soporte orientada a servicios fue
implementada bajo los lineamientos de ITIL [9], que es un marco de referencia que
describe un conjunto de mejores prácticas y recomendaciones para la administración de
los servicios de IT, con un enfoque en la administración de procesos. (WIKIPEDIA,1990)

Este nuevo modelo trajo consigo el concepto de apertura de tickets de servicio por parte
de los usuarios, para recibir soporte en los sistemas, en Helpdesk, en telecomunicaciones
e infraestructura. El número de ticket fue usado para hacer todo el acompañamiento y
priorización del requerimiento desde su apertura hasta su solución, previa aprobación del
usuario que abrió el ticket.

27
Todo el proceso de solución de un ticket fue adecuadamente documentado en una
herramienta CRM [11] del proveedor Siebel, en esta herramienta web se tenían creados
scripts que contenían todos los pasos a ser ejecutados para la solución de un incidente que
fue abierto a través de un ticket. Este sistema además de tener una importante base de
conocimiento sobre la solución de incidentes, permitía adicionar nuevos scripts e
interactuar con diferentes grupos de soporte, tanto local como regional, ya que los sistemas
CORE como SAP eran soportados desde Brasil a través de la consultora Accenture.

Este fue un cambio de paradigma muy fuerte para los usuarios, el hecho de no poder
acceder directamente al soporte de IT local como en el pasado, generó una fuerte
resistencia al cambio y una inconformidad creciente sobre el performance de los servicios
prestados por IT, no sólo en lo referido al soporte de sistemas, sino al conjunto de servicios
de tecnología que iba desde solucionar un problema en Microsoft Word, corregir un
problema de impresión, hasta una corrección/configuración/desarrollo de una nueva
transacción u opción en SAP. IT pasó a ser percibido como un equipo extremadamente
burocrático y que había perdió su noción de servicio.

A inicios del 2005 fui promovido al cargo de Jefe Nacional de Sistemas, con la principal
tarea de cambiar la percepción negativa de los usuarios sobre los servicios que prestaba
IT y en contrapartida debía ajustar la estructura organizacional del equipo y ejecutar todas
las oportunidades de tercerización que fueran encontradas, claramente estas tres tareas
entraban en conflicto en algún punto de su implementación.

3.2.1. Estructura Organizacional

El equipo local de Información Tecnológica, con el cual empecé mi nuevo rol de jefe de
departamento, contaba con 6 profesionales del área de sistemas, cuyas principales
responsabilidades eran:

28
• Un supervisor de proyectos, encargado de la implementación y estabilización de
sistemas o cambios generados mediante proyectos de tecnología y de negocio. Este
recurso tenía a su cargo la construcción del plan de trabajo del proyecto y era
responsable de su correcta y oportuna implementación en coordinación con el
negocio y el jefe de sistemas.

• Un supervisor de soporte de sistemas, encargado del soporte de sistemas que ya

estaban en producción. Este recurso se encargada de la asistencia directa a todos
los usuarios y coordinaba con el resto del equipo cuando necesitaba algún ajuste
en la infraestructura, alguna información sobre los proyectos o la necesidad de
escalar puntos con el negocio a través del jefe de sistemas.

• Un supervisor de infraestructura y telecomunicaciones, que era encargado del

mantenimiento y soporte de los servidores locales, equipos de comunicación como
Routers y Switches, telefónica interna, externa y móvil, además del soporte de los
enlaces de red internacionales y la coordinación del trabajo de los dos analistas de
Helpdesk.

• Dos analistas de soporte de Helpdesk, que trabajaban en turnos, encargados de

asistir a los usuarios en problemas de Microsoft Windows, correo electrónico,
Office, backups, antivirus, soporte en hardware y software de laptops y desktops.

• Finalmente, el rol que desempañaba como jefe de sistemas, en el cual coordinaba

las tareas del equipo y el relacionamiento con el negocio, era responsable del
presupuesto del departamento, coordinación de la implementación de nuevos
proyectos tecnológicos, manejo de los recursos humanos y de la infraestructura de
IT, soporte en auditorias de sistemas y miembro del comité ejecutivo de la
compañía donde presentaba los avances, estatus de proyectos y la estrategia de IT
mensual y anual.

29
Como parte de la nueva de estrategia regional de IT tuve que llevar adelante tres cambios
importantes en la estructura organizacional del equipo:

• El soporte de los sistemas CORE para toda Latinoamérica quedó en Brasil, por
tanto, me vi obligado a despedir al supervisor de soporte de sistemas y generar un
adecuado traspaso de conocimiento del soporte de sistemas locales al supervisor
de proyectos, quedando este último con la responsabilidad de implementación de
nuevos proyectos, soporte de sistemas locales y coordinación del soporte de
sistemas con el equipo regional de Brasil. Este fue un cambio bastante difícil de
manejar, porque implicaba retirar a una persona y hacer que otro recurso asuma
nuevas tareas sin ningún ascenso o incremento salarial, atado a estas nuevas
responsabilidades. El manejo de estas situaciones laborales, es algo que no te
enseñan en la formación académica, pero tienes que estar listo para ejecutarlas
cuando asumes posiciones de liderazgo.

• El equipo IT Latinoamérica, tomó la decisión de tercerizar todo el soporte de

infraestructura de servidores y comunicaciones. Para la parte de servidores, todo
el soporte quedó con la empresa Hewlett Packard, esto genero varios proyectos de
migración de servidores y servicios a centros de cómputo en Brasil y Estados
Unidos. Ejecutar estos proyectos de migración demandó mucho esfuerzo en la
parte de coordinación con la operación local, ya que de manera constante se
interrumpían varios servicios locales como el correo, el chat y acceso a SAP para
poder efectuar la correcta migración de servicios. El soporte del servicio de
telecomunicaciones también fue tercerizado, con una empresa inglesa a nivel
global llamada British Telecom, toda la parte de configuración y soporte a la
infraestructura de comunicaciones quedó en Brasil y Reino Unido. Pero tras una
larga gestión y negoción con el proveedor logré tener un recurso tercero local, que
coordine todos los trabajos de cableado de red, remote hand de equipos, soporte
en telefonía fija y móvil además del soporte a servicios de videoconferencia. En
contrapartida tuve que despedir al supervisor de infraestructura, además de planear

30
 y ejecutar un delicado proceso de traspaso de conocimiento a las dos nuevas
empresas de soporte HP y BT.

• Los dos analistas de soporte de Helpdesk, también tuvieron que ser tercerizados,
tras varias gestiones logré que HP contrate al menos uno de los dos recursos a fin
de que el todo el conocimiento de soporte a usuarios acumulado a lo largo del
tiempo no se perdiese y así lograr que los usuarios se sientan más seguros a la hora
de ser atendidos, infelizmente el segundo turno local de soporte desapareció y paso
a ser atendido desde Colombia, lo que significó que tuve que despedir a uno de los
analistas de soporte.

Entonces, en menos de dos años tuve que despedir a tres de mis funcionarios y pasar a
uno de ellos a ser un tercero local contratado por HP, con lo cual sólo quedamos dos
personas en el equipo de IT trabajando directamente para Unilever, más dos analistas
terceros uno de HP y otro de BT.

Como era de esperarse la moral del equipo bajó y se generó un ambiente de incertidumbre,
sobre futuras restructuraciones. Sin embargo, logré mantener esta misma estructura por 4
años más, hasta finales del 2010, a través de un fuerte de trabajo de mejora continua en
los servicios de IT, una mejora en la percepción de los usuarios y una adecuada interacción
con los equipos regionales de IT, dispersos por toda Latinoamérica y Reino Unido.

Después de 6 años en el cargo de jefe de sistemas, tras ejecutar una fuerte estrategia de
reorganización de la estructura organizacional de IT y varias estrategias de tercerización,
con mi salida del equipo local, logre reducir a una sola persona el staff de IT local y todos
los servicios técnicos fueron tercerizados con empresas locales e internacionales, pero sin
descuidar el nivel óptimo de servicio al negocio.

31
3.2.2. SAP en el Condominio

Uno de los mayores retos con los que me enfrenté en este nuevo modelo de soporte, fue
el de estabilizar e implementar mejoras en el sistema SAP.

Así como Bolivia tenia algunos errores de configuración y requerimientos de desarrollo

en SAP demandados por el negocio, todos los países en Latinoamérica también los tenían,
entonces se implementó una estrategia de “Releases Trimestrales”, donde sólo a inicios
de trimestre se podían subir cambios y mejoras al servidor único de SAP que estaba en
Estados Unidos, y esto, solo a la posterior ejecución de un proceso minucioso de
implementación, el cual iniciaba con la captura del requerimiento por parte del equipo de
IT y de negocio local.

Estos requerimientos que eran capturados, tras un filtro del equipo de soporte en Brasil,
podían ser resuelto por este mismo equipo, o ser reportados como un problema existente
en SAP que requeriría un cambio a nivel de configuración o desarrollo en Abap [10] que
es el lenguaje de programación sobre el cual fue desarrollado SAP, adicionalmente
también podía ser reportado como un nuevo requerimiento que necesariamente
involucraba un desarrollo.

Una vez pasado este primer filtro, se tenía una reunión donde por grupo de negocios se
decidía que requerimientos deberían ser implementados, con la limitante de que el costo
de implementación quede dentro del presupuesto asignado para cada grupo de negocios.

Cabe recordar que Bolivia estaba en el grupo de negocios: “Greater Andina”, esto
significaba que nuestros requerimientos deberían competir en importancia con los de
Colombia, Venezuela, Ecuador y Perú.

Si bien Unilever es una operación grande en Bolivia, al momento de competir con los
otros países del grupo, éramos la operación más pequeña, entonces lograr acomodar uno

32
de nuestros requerimientos era un desafío bastante grande, que cada tres meses tenía que
afrontar como líder de IT local.

En estas reuniones como es de suponerse todos queríamos salir victoriosos y así retornar
con nuestras operaciones con la bandera de victoria, indicando que lo que nos pidieron
hacer, se haría.

Sin embargo, el tema no terminaba en esta reunión, ya que, en varias oportunidades,

cuando para toda Latinoamérica había demasiados requerimientos que atender en un
mismo trimestre, una nueva reunión de filtro se llevaba a cabo, y esta vez había que
competir con grandes operaciones como Brasil, México y Argentina.

Esta nueva reunión, era mucho más desafiante, primero porque todas nuestras operaciones
eran más pequeñas que la de Brasil y la reunión era liderada por gente de IT que estaba en
Brasil y se llevaba a cabo en portugués. Un escenario totalmente adverso.

En las dos primeras reuniones de requerimientos con Brasil en las que participe, pese a
que me preparé con semanas de anticipación junto al negocio local, documentando
detalladamente, una buena presentación de los beneficios que traerían para la operación
el implementar nuestros requerimientos, todos fueron rechazados en favor de atender
requerimientos de Brasil y Argentina. Éramos un pez pequeño en un gran estanque.

Cabe señalar, que, a pesar de un inicio nada auspicioso, en los 6 años que estuve al frente
del equipo de IT en Unilever Bolivia, logré acomodar más de 25 requerimientos nuevos,
trabajando fuertemente en tres frentes:

• Hablar un portugués fluido.

• Conocer a detalle los pormenores de la operación, donde se tenía previsto obtener
los beneficios.

33
 • Y el más importante: dejar de pensar y presentar los requerimientos desde una
perspectiva solo técnica, sino más bien desde una perspectiva de negocio usando
términos de negocio y no solo de sistemas.

Si bien a largo de los 16 años que trabajé en Unilever, una de las cosas que más aprendí
fue negociación y persuasión, fue en estas reuniones de presentación de requerimientos
donde más desarrollé estas dos competencias.

3.2.3. Cierre de un ciclo

A inicios del 2010, entró en escena la planificación y ejecución del último proyecto
relevante que lidere en Bolivia.

Desde el negocio hubo un importante cambio de estrategia, Bolivia y Perú salieron del
grupo de negocios de “Greater Andina” y pasaron a formar parte del grupo de negocios
de “South Cone”, conformado por Argentina que era el líder, junto a Chile, Uruguay y
Paraguay.

Tras una dura batalla para lograr la aprobación en medio de un cambio de grupo de
negocios, fuimos autorizados a la implementación de WMS [12] de SAP en nuestro Centro
Nacional de Distribución ubicado en Cotapachi, Cochabamba.

WMS, es un módulo de SAP que te permite configurar tu almacén como si fuese una
matriz tridimensional, donde cada rack es una columna, la altura del rack una fila, y la
profundidad del rack una tercera dimensión, haciendo la intersección de estas tres
dimensiones una posición de stock. Mediante esta configuración se puede manejar
trazabilidad de productos, a fin de mejorar la gestión de tu stock, despachando los
productos oportunamente y evitar tener problemas de vencimientos y en caso de un
problema de calidad, se puede aislar rápidamente el producto dañado para evitar su

34
comercialización además de que los inventarios de productos, pasan a ser tareas simples
y rutinarias.

Cada vez que un pedido de venta es ingresado al almacén, WMS genera una orden de
trabajo de picking de productos, indicando la posición exacta de donde se encuentran
dichos productos y generando una ruta óptima de recolección de todos los productos de la
orden de venta dentro del almacén. Esta orden de trabajo es asignada a un funcionario del
almacén que ejecuta la ruta óptima que WMS generó, cada vez que un producto es
recolectado, el funcionario a través de una pistola de código de barras que está conectada
de forma inalámbrica con el servidor de SAP confirma la recolección y pasa a buscar el
siguiente producto, hasta terminar con todos los productos de la orden de venta a atender.

La mayoría de los proyectos en compañías del tamaño de Unilever son liderados por una
persona del negocio, experta en el área o proceso que impactará el proyecto, en caso de
WMS los procesos eran logística y distribución, sin embargo, la compañía tomó la
decisión de que mi persona liderase todo el proyecto desde IT y desde el negocio. Y en
realidad esto fue parte de la evolución del personal de IT que buscan las grandes
compañías de consumo masivo, donde el foco del negocio no es sistemas, y es así que
apuntan a tercerizar todos los servicios técnicos y buscan en el profesional de IT interno,
un socio estratégico de negocios, que sea experto en tecnología, pero que también sea un
experto en la operación, para así contar con un recurso valioso, que a la hora de
implementar un proyecto no sólo cuide los aspecto técnicos sino que haga una
implementación integral orientado a obtener los beneficios que el negocio espera.
La implementación del proyecto WMS fue muy exitosa, finalmente pudimos ordenar
efectivamente los almacenes y pude entregar al negocio una solución confiable para una
de las áreas más sensibles de la compañía. En términos personales, Unilever me dió un
reconocimiento por el trabajo realizado y esto me impulsó a buscar nuevos desafíos fuera
de casa.

35
Después de 11 años de trabajar en Unilever Bolivia y comenzar a desarrollar este rol de
socio estratégico de negocios, dejé la operación local y pasé a formar parte de un equipo
regional de proyectos de IT Supply Chain para Latinoamérica.

36
 4. DESARROLLO DEL ROL DE SOCIO ESTRATÉGICO, EN LA REGIÓN

Veo importante hacer una aclaración en este punto, entiéndase que cuando hablo de la
región, me refiero a todos los países de Latinoamérica, que están distribuidos en diferentes
grupos de negocio:

• Brasil, es la segunda operación más grande a nivel mundial que tiene Unilever,
esta solo detrás y muy cerca de Estados Unidos que es la primera. Con una
población de 207 millones, es un mercado gigantesco donde los volúmenes que
maneja Unilever salen de toda dimensión y genera una operación extremadamente
compleja y dinámica. El negocio es principalmente impulsado con la venta de
detergente en polvo y helados.

• South Cone, liderado por Argentina, en equipo con Chile, Uruguay, Paraguay,
Perú y Bolivia, es la segunda operación en importancia dentro de Latinoamérica,
siendo su principal desafío trabajar al unísono como una sola operación a largo de
los seis países que la conforman. El negocio es principalmente impulsado con la
venta de aerosoles y jabones de tocador.

• México y Caribe, liderado por México en equipo con Puerto Rico, República
Dominicana y Trinidad y Tobago. Es una operación muy diversa y las estrategias
de negocios requieren ser implementadas de manera quirúrgica. El negocio esta
principalmente impulsado por la división de alimentos.

• Midle Américas, liderado por Colombia en equipo con Venezuela, Ecuador,

Panamá, Costa Rica, Nicaragua, Honduras, Guatemala y el Salvador. La
operación de Venezuela es claramente muy atípica por la convulsión política, pero
el resto de las operaciones están exitosamente centralizadas en Colombia, lo que
permite manejar una estrategia unificada con muy buenos resultados. El negocio
es principalmente impulsado por la venta de aerosoles, detergente y helados.

37
Todas las operaciones antes mencionadas tienen muchas particularidades, cuentan con
varias plantas y centros de distribución estratégicamente localizadas, para soportar un
negocio tan dinámico, como lo es, el de Unilever.

A inicios del 2010, Unilever tomo la decisión de hacer una actualización de la versión de
SAP, implementar una nueva herramienta de ruteo llamada OTM [7] y unificar en una
única instancia de SAP a Norteamérica y Latinoamérica, este proyecto fue denominado
“Cordillera”. Este proyecto no sólo significó desafíos tecnológicos sino también involucró
una serie de cambios de estrategia de negocio para volver aún más eficiente la operación
y tener un Unilever Américas más competitiva.

Nuevamente fue utilizada una estrategia de “Releases”, donde el primer Release llamado
R1 fue la implementación de Estados Unidos y Canadá durante el 2010. En abril del 2011
inicio el Release 2 que fue México, es ahí donde inicio mi participación en el proyecto
Cordillera.

4.1. México: El desembarco

Junio 2011 São Paulo-Brasil, en una reunión multidisciplinaria con la participación de

todos los procesos y países de Latinoamérica, se dio inicio al proyecto Cordillera (Figura
4) para todos los países de habla hispana y Brasil.

Uno a uno los líderes de la organización, hicieron la presentación del proyecto, con un
enfoque orientado principalmente a los beneficios que la compañía tenía planificado
obtener tras la implementación, SAP ya era un viejo conocido por todos, pero un nuevo
sistema global de ruteo de transporte OTM (Oracle Transportation Management), entraba
en escena y venia como una solución a varios problemas de la compañía en el área de
Supply Chain, como el sobrecosto de fletes, la mala distribución de costos de transporte,
ociosidad en la flota de camiones y una deficiente planificación en la entrega a los clientes.

38
 Figura 4
PROYECTO CORDILLERA

Fuente: Portafolio de proyectos UNILEVER 2015

Durante un mes en un hotel de São Paulo, llevamos adelante una innumerable cantidad de
reuniones denominadas “Fit Confirmations” donde organizados por procesos y países, las
soluciones que traía la nueva versión de SAP ECC y OTM fueron presentadas.

Como era de esperar, esto generó una serie de discusiones sobre las soluciones
presentadas, ya que no todo lo presentado se adecuaba a la forma en que las operaciones
trabajaban en el día a día, si bien todos teníamos SAP R3 en los países después de la
implementación del proyecto Harmonía, cada país y proceso había generado sus propios
ajustes y modificaciones que hacían que no pudiéramos establecer un único punto de

39
partida. Estos cambios obedecían a un tema de ajustes legales y fiscales, como también
una adecuación de SAP al mercado local en cada una de las operaciones.

Por mi parte yo fui ubicado en el equipo de Logística y Distribución, donde los principales
desafíos eran estandarizar a través del uso del sistema, el variado funcionamiento que
existía en los diferentes centros de distribución de la región.

Otro de los puntos críticos a resolver, era determinar la forma más efectiva de conectar el
sistema de Unilever con los sistemas de los operadores logísticos, que en varios países no
eran operados por funcionarios de Unilever, sino más bien por empresas especializadas
en logística, almacenaje y distribución como lo es DHL.

Un punto relevante en el cual también se trabajó, fue el manejo de Pallets, el cual le

significaba a la compañía una importante pérdida de activos, ya que los mismos al no ser
manejados eficientemente y al tener una importante movilidad, el descontrol y la pérdida
era algo cotidiano, así que tener una integración con empresas como CHEP era muy
necesario.

Tras cerrar todas las reuniones de Fit Confirmations, se estableció una importante cantidad
de puntos a resolver donde la solución que traía el proyecto no era totalmente adherente a
lo que el negocio necesitaba y podía absorber. Estos puntos eran conocidos como “issues”
A lo largo de la implementación resolvimos todos estos issues a través del uso de una
metodología de IT que separaba en cuatro, las posibles soluciones a los puntos levantados:

a) Aclarar el detalle, claramente durante las reuniones maratónicas en São Paulo, no

se pudo ver a detalle todos los procesos, entonces muchos issues fueron registrados
para garantizar que los puntos levantados por el negocio fueran adecuadamente
mapeados y resueltos. Entonces, tras desembarcar en México, establecimos
reuniones con los responsables de los procesos y en muchos casos tras revisar el
detalle, se estableció que el issue levantado, realmente no era un problema y la

40
 solución pasaba por explicar más detalladamente la solución que traía el proyecto
y cerrar el issue. Una importante cantidad de issues fueron cerrados usando esta
primera alternativa que traía la metodología.

b) Change Management, tras revisar el issue a detalle con la operación, se establecía

que la operación debía adecuarse al sistema, lo que significaba un cambio en la
operación, un cambio de WoW. Esta solución significaba generar una fuerte
negociación con las personas de la operación para que aceptasen el cambio y
posterior a eso se tenía que trabajar en estrategias de comunicación eficiente del
cambio a todas las áreas impactadas y un robusto plan de entrenamiento para
garantizar que el cambio de proceso acordado se iba a materializar. En lo personal,
logré cerrar varios issues con esta alternativa, pero me significo llevar adelante
varias reuniones tensas de negociación con la operación y con la gente de IT local.

c) Configuración, si tras varias revisiones no se conseguía que la operación se

adecuase al sistema por temas de estrategia, recursos y particularidades del
mercado local, se generaba una serie de documentos técnicos para modificar la
configuración de SAP y OTM, obviamente esta solución es la que menos me
gustaba, porque el generar la documentación técnica junto al negocio y a la
consultora de SAP, significaba administrar procesos bastante engorrosos y
burocráticos, debido a que la documentación una vez terminada, debía ser
discutida con un equipo de Accenture de la India, para garantizar que los cambios
requeridos en la configuración estaban totalmente claros, por tanto el documento
generado debería tener un importante nivel de detalle. Posteriormente había que
establecer un detallado de plan de test de los cambios de configuración y un plan
adecuado de entrenamiento para los usuarios finales.

d) Desarrollo, esta cuarta opción, principalmente lo dejábamos para atender

requerimientos de orden legal y fiscal, donde SAP estándar no lo tenía y debía ser
desarrollado de manera obligatoria, para no exponer a la compañía a multas y

41
 sanciones por los entes legales e impositivos de cada país. También tuve varios
requerimientos, que, sin ser temas legales e impositivos, requirieron desarrollos en
SAP y OTM, sobre todo en la parte de conexión con sistemas de empresas terceras
de logística. Par este punto, también tuve que generar planes robustos de test y
entrenamientos para los usuarios finales.

La base de operaciones del proyecto se estableció en São Paulo, con viajes constantes a
México para llevar adelante la ejecución del plan de implementación.

En los primeros viajes a México, identifiqué una importante cantidad de desarrollos que
estaban hechos en paralelo y por fuera de SAP, no había un adecuado control de los nuevos
desarrollos, casi que prácticamente tenían un segundo SAP en paralelo, además de que
varios procesos eran hechos manualmente por fuera del sistema. Obviamente esto generó
un sinnúmero de problemas a la hora de la implementación, no sólo en un ámbito
estrictamente de sistemas, si no en un contexto de negocio, donde la gente estaba tan
acostumbrada a trabajar por fuera del sistema en Microsoft Excel y otras aplicaciones
pequeñas, que dejar de lado esta costumbre tan arraigada, significaba un cambio cultural
importante, y puedo afirmar con absoluta certeza y conocimiento de causa que convencer
a un mexicano, para adoptar nuevos sistemas, es una tarea por demás desafiante.

Una estrategia importante que nos ayudó en esta parte de la implementación y que de
hecho estaba en la metodología de implementación, era usar las lecciones aprendidas de
implementaciones pasadas, en este caso la del Release 1 (Estados Unidos y Canadá). Así
que generé varias reuniones con mis pares de IT de Norteamérica que participaron en el
proyecto. Para esto tuve que romper varias barreras que pasaron por lo cultural, por el
idioma y por las diferencias conceptuales de negocio, donde una solución que funcionó
brillantemente por allá, dada las connotaciones del mercado mexicano, nunca irían a
funcionar, entonces ahí solo quedaba que me invente una nueva solución desde cero, con
todo lo que esto significaba en términos de recursos, desarrollo, tiempo y presupuesto. Es

42
bueno también destacar que algunas soluciones creadas para Norteamérica si pude
implementarlas en México con pequeños y rápidos ajustes.

En lo referente a la integración con sistemas de terceros de logística, distribución y manejo

de Pallets, SAP ofrece una robusta solución, pero, así como es robusta, es compleja y
exigente.

SAP para lo que es integración de sistemas, tiene una herramienta llamada PI [8] que
garantiza un único punto de acceso, una monitorización centralizada, una definición de
condiciones de envió/recepción, una compatibilidad con distintos formatos de archivos y
protocolos de comunicación, además de poder establecer comunicaciones síncronas y
asíncronas para el intercambio de interfaces.

Para la parte de integración con las empresas logísticas se estableció en conjunto con el
equipo de Norteamérica un set de interfaces estándar para garantizar una correcta y
controlada intercambio de información, las interfaces que implemente fueron:

• OMD.I.015-Maestro de Productos, esta interface era la encargada de enviar

cualquier actualización y creación de nuevos productos en SAP a los sistemas de
los terceros. Era una interface online que se disparaba automáticamente cada vez
que el maestro de productos en SAP era actualizado. El objetivo de esta interface
era garantizar que las empresas de logística, usen los mismos códigos de productos
que Unilever, y así evitar generar re-trabajos en tablas de-para de productos. Con
el fin de garantizar la seguridad de la información y el performance de la interface,
establecí varios filtros para garantizar que los diferentes proveedores logísticos
solo recibiesen las interfaces de productos que requerían y no todo el maestro de
productos de la compañía.

• OMD.I.016-Maestro de Clientes, esta interface era la encargada de enviar

cualquier actualización y creación de nuevos clientes en SAP a los sistemas de los

43
 terceros. Era una interface online que se disparaba automáticamente cada vez que
el maestro de clientes en SAP era actualizado. El objetivo de esta interface era
garantizar que las empresas de logística usen los mismos códigos de clientes que
Unilever, para evitar generar re-trabajo en tablas de-para de clientes. Con el fin de
garantizar la seguridad de la información y el performance de la interface, establecí
varios filtros para garantizar que los diferentes proveedores logísticos solo
recibiesen las interfaces de los clientes que requerían y no todo el maestro de
productos de la compañía. Para México en particular tuve que adicionar otros
filtros que ocultaban alguna información de los clientes, esto por temas legales que
el gobierno de México exigía.

• OMD.I.028-Maestro de Transportistas de fletes, esta interface era la encargada de

enviar cualquier actualización y creación de las nuevas empresas de transporte en
SAP a los sistemas de los terceros. Era una interface online que se disparaba
automáticamente cada vez que el maestro de transportistas en SAP era actualizado.
El objetivo de esta interface era garantizar que las empresas de logística usen los
mismos códigos de transportistas que Unilever, para evitar generar re-trabajo en
tablas de-para la hora del pago de los fletes. Con el fin de garantizar la seguridad
de la información y el performance de la interface, establecí varios filtros para
garantizar que los diferentes proveedores logísticos solo recibiesen las interfaces
de los transportistas que requerían y no todo el maestro de la compañía. Para
México en particular tuve que adicionar otros filtros que restringían él envió
selectivo de algunos transportistas, con el fin de no divulgar información sobre los
proveedores de transporte, ya que, en México, el mercado de transporte es muy
competitivo y cualquier brecha genera variaciones de precios y condiciones de
negociación de fletes, que puede repercutir negativamente en los costos y
encarecer de sobremanera la operación.

• OMD.I.210-Solicitud de Picking, toda vez que un nuevo pedido de venta era

ingresado, confirmado y aprobado en Unilever, esta interface era disparada para

44
 que el almacén administrado por el tercero efectué el proceso de picking y pueda
preparar el pedido, para que posteriormente sea cargado a un camión y pueda ser
entregado al cliente.

• OMD.I.220-Confirmacion de Picking, una vez que la preparación del producto en

el almacén administrado por el tercero era concluida, el tercero generaba esta
interface con el objetivo de confirmar a Unilever, cuanto del pedido fue preparado
y estaba listo para ser distribuido. Lo ideal era que el pedido sea preparado al 100%
pero muchas veces no se tenía todo el producto en el almacén o se encontraba que
el producto tenía algún golpe o estaba vencido y no podía salir en esas condiciones
del almacén, entonces era necesario tener una confirmación de lo que sería enviado
al cliente.

• OMD.I.255-Envio de transferencia, Unilever México contaba con varios Centros

de distribución repartidos por todo el país, algunos centros estaban más cerca de
las plantas y que además de acopiar de manera primaria la producción, también
eran encargados del envió de productos a los otros centros de distribución, tanto
dentro como fuera de México. El objetivo de esta interface era de enviar un pedido
de transferencia a otro Centro de distribución, que podía estar administrado o no
por Unilever. Con esta interface el centro receptor sabía exactamente lo que iba a
llegar en los siguientes camiones y podía efectuar la recepción oportuna en
términos de recursos y espacio en el almacén.

• OMD.I.180-Confirmación de transferencia, el centro receptor una vez que recibía

los camiones con los productos, tenía que confirmar si había alguna diferencia
provocada por algún robo, mal conteo en origen, siniestros o inversión de
productos. Esta interface era generada desde el almacén después del conteo y
cierre de la recepción.

45
 • OMD.I.170-Ajustes de inventario, esta interface era una de las más críticas y
controladas de la operación, ya que, con esta interface, después de un proceso de
conciliación documentado en un árbol de pérdidas, se establecían los
correspondientes ajustes de inventario que representaban los costos que deberían
ser asumidos por Unilever, la empresa tercera de logística o la flota de transporte.
En esta interface tuve que generar varios puntos de control y asociarlo a un flujo
de aprobación dentro de SAP para que antes de ser generada, cuente con todo el
proceso de manual de autorización de la compañía.

Estas interfaces fueron implementadas con cuatro operadores logísticos de México, donde
cada uno contaba con una diferente estructura de comunicaciones, un diferente equipo de
IT, unas políticas de conexión más exigentes que otras y un tamaño variable de negocio,
en fin, si bien las interfaces eran iguales, para la correcta implementación tuve que usar
diferentes estratégicas.

Un tercer punto que fue relevante en la implementación del proyecto Cordillera fue la
integración de SAP del proceso de manejo de pallets con la empresa CHEP, que es el
proveedor Américas de Unilever de la madera que va debajo de los productos dentro de
los camiones y los almacenes. Para esta administración se crearon dos interfaces:

• Inyección de pallets, los pallets eran solicitados a CHEP desde una central de
pallets que administraba la necesidad de los pallets para todas las plantas y centros
de distribución de México, pero la entrega de las maderas no era centralizada, los
pallets se entregaban en cada planta o centro de distribución. Entonces era en este
momento que se generaba una interface automática desde Unilever hacia CHEP
indicando la cantidad de pallets recibidos y el lugar donde fueron inyectados. Para
el desarrollo de esta interface tuve varios problemas de padronización de
interfaces, ya que CHEP al igual que Unilever tienen un sin número de controles
y restricciones sobre las interfaces, que van desde el formato, pasando por los tipos
de campos aceptados, hasta el protocolo de seguridad aceptado.

46
 • Uso de pallets, una vez que las plantas y lo centros de distribución tenían bajo su
control los pallets dos situaciones se presentaban para disparar esta interface.

1. Cuando los centros de distribución enviaban producto a los clientes en pallets,

la interface era enviada a CHEP para informarle que esos pallets ya no estaban
en Unilever y por tanto la compañía iba a dejar de pagar el alquiler sobre estos
pallets porque ya estaban con los clientes.

2. Cuando las plantas o centros de distribución, hacían una transferencia de

productos a otras plantas o centros de distribución, si bien el pago del alquiler
de pallets aún estaba con Unilever, era importante reportar a CHEP la nueva
ubicación del pallet por un tema de control de inventario.

En abril del 2012, tras 9 meses de implementación hicimos el Go-live de la operación de

México, e iniciamos el dificultoso y minucioso trabajo de estabilización de la
implementación y en paralelo también iniciamos el proyecto para Brasil.

En lo personal, la implementación fue muy enriquecedora en términos de experiencia del

manejo de un proyecto tan demandante y para una operación tan grande como lo es la
mexicana. Tuve que usar toda mi experiencia pasada, del proceso de IT Supply Chain para
poder cumplir con el plan de trabajo dentro de las fechas establecidas y con el alcance
esperado.

4.2. Brasil, la operación más grande y diversa de Latinoamérica.

Brasil tiene el mayor portafolio de productos de Unilever en la región, un mercado de 207

millones de consumidores potenciales, 12 de plantas y 20 centros de distribución,
distribuidos a lo largo y ancho de la enorme geografía brasileña, esta situación demandó
otro tipo de estrategia de implementación a la que usamos en México.

47
En la operación de Brasil, me encontré con un escenario más favorable en términos de IT,
ya que los sistemas que tenían, eran más estandarizados y no tenían muchos procesos por
fuera, como lo fue en México, los usuarios tenían una mayor cultura de manejo de
proyectos, entonces el verdadero desafío en el fondo, fue el tamaño y la diversidad de
procesos que se tenían en cada Estado, donde São Paulo, Rio de Janeiro, Pernambuco y
Rio grande do Sul concentran la mayor parte de las operaciones.

El escenario que más dificultó la implementación, fue el tema legal e impositivo, ya que
Brasil al ser un país Federal, cada estado es libre de crear leyes comerciales e impositivas
de acorde a sus necesidades, a fin de ofrecer un escenario más atractivo para los
inversionistas, y así garantizar un flujo constante de divisas por temas impositivos para el
estado, sobre todo de los productos que no son fabricados en su estado, pero que si son
comercializados, indistintamente si son de origen brasileño o extranjero.

Al igual que para México, comenzamos el proyecto con las reuniones de Fit
Confirmations, esta vez en menor escala y solo para Brasil, pero por el tamaño de la
operación igual tuvimos que acampar prácticamente un mes en un salón de un hotel en
São Paulo con todo el equipo de IT del proyecto y los principales Key Users del negocio.

Una vez consolidadas las listas de issues, empezó el peregrinaje a todos los estados y
ciudades donde Unilever Brasil tiene operaciones, si bien tienen procesos bastante
estandarizados y centralizados, el tema fiscal/legal hace que las operaciones tengan
importantes particularidades, que deben ser revisadas y atendidas desde la solución que
traía el proyecto, debido a que lo definido para las plantas y centros de São Paulo, no
necesariamente se puede usar al 100% en Recife u otros estados.

De los 20 centros de distribución que tiene Brasil, 17 son administrados a través de un

operador logístico externo, dando como resultado 10 empresas con las cuales se tenía que
hacer las interfaces de logística y distribución, ya que algunas empresas administraban
más de un centro de distribución, esto ayudo en alguna medida, sin embargo, el tema

48
legal/fiscal volvió a generar más de un proceso de control adicional por centro de
distribución y proveedor de servicios logísticos.

Como estas interfaces ya estaban funcionando para México, una estrategia de “Rollout”
controlado fue la que utilice, cuidando las particularidades de cada escenario, pero
tratando de mantener en la medida de lo posible un único estándar de las interfaces, con
el fin de facilitar el futuro proceso de estabilización y soporte centralizado.

Para la parte de manejo de pallets, fue un tanto más fácil ya que CHEP estaba presente en
todas las operaciones de Brasil, por tanto, la interface a implementar, fue prácticamente
la misma que usé en México, además de que el centro de excelencia de IT de la empresa
CHEP, está en Estados Unidos y cuida todas las operaciones de Latinoamérica, por tanto,
tampoco tuve la necesidad de trabajar con otros equipos nuevos de IT para la integración,
fueron los mismos con los que hice la integración en México.

En términos de interfaces, uno de los grandes problemas fue la infraestructura y el

performance, ya que, por el elevado número de operaciones, las interfaces llegaban a
colapsar la capa de integración PI de SAP.

Para poder resolver este punto, planifique y ejecute, una serie de test de performance,
generando masivamente un número importante de interfaces, hasta quebrar el servidor y
determinar el punto exacto, de hasta donde soportaba la infraestructura actual y así
determinar la solución más adecuada, que pasaba por la ampliación de los enlaces de
comunicación, ampliación de disco y memoria de los servidores, hasta procesos de
virtualización de servicios.

Otros puntos relevantes con los que me enfrente fueron las etapas de test y entrenamiento.
La etapa de test, demando coordinar un gran número de recursos para poder realizar un
test integrado y así garantizar que el sistema funcione como el usuario lo requería. Fue
una etapa dura, donde las correcciones y ajustes, levantados en las pruebas, tenían que ser

49
coordinados y enviados a la fábrica de software que está en Filipinas-Manila, era bastante
complicada esta gestión en términos de huso horario e idioma.

Para la parte de entrenamiento usamos la metodología de “Train The Trainers”, donde por
la limitación de no poder tener a todos los usuarios en una única sala para entrenarlos
juntos, pasamos a entrenar a una persona por centro y proceso, para que después esta
persona sea una replicadora de conocimiento con sus colegas en su centro y proceso
respectivo. Si bien esto facilitó el tema, igual la coordinación del entrenamiento a estas
personas no fue nada fácil por temas de agenda y recursos, ya que para algunas plantas y
centros pequeños compartíamos recursos de negocio con los otros equipos de
implementación.

En agosto del 2013, tras mover previamente un par de veces la fecha del Go-live, por la
complejidad de la operación, hicimos el lanzamiento del proyecto con una estrategia de
“Big Bang” en todas las operaciones de Brasil de manera conjunta, para lo cual todo el
equipo del proyecto nos dividimos y fuimos a dar soporte a las operaciones más
importantes. En mi caso fui asignado a Recife donde teníamos 2 plantas y 2 centros de
distribución con operaciones de detergentes y helados.

Durante los dos meses que estuve en Recife, teníamos dos reuniones por día, para reportar
el avance de la estabilización de los sistemas y los problemas identificados por la
operación. En esta reunión también la consultora de implementación, presentaba un
estatus de la solución a los problemas reportados en días pasados. En términos generales
las operaciones de detergentes, fueron las que más rápidamente pudieron estabilizarse, sin
embargo, las de helados, fue una historia muy diferente, principalmente por el hecho de
las particularidades que tienen en la distribución y comercialización de sus productos,
donde Unilever no solo llega a clientes sino también a los consumidores finales de manera
directa.

50
En diciembre del 2013, cerramos oficialmente el proyecto para Brasil, no sin antes haber
superado un duro proceso de estabilización, y una gestión desgastante con la fábrica de
software en Manila. A pesar de las dificultades enfrentadas y superadas, pudimos realizar
el cierre anual de Brasil sin mayores inconvincentes, la prueba de fuego había sido
superada e íbamos por más.

4.3. Desafío: South Cone

En enero del 2014, fui transferido a Buenos Aires, para liderar la implementación del
proyecto Cordillera para el proceso de Distribución en los seis países que componen el
grupo de negocio de South Cone. Esta fue mi primera oportunidad como líder de
implementación de un proceso, en un proyecto regional, tenía mi propio equipo, mi propio
presupuesto, y muchos desafíos personales.

Tras la implementación del proyecto en México y Brasil, muchos temas en términos de

sistemas, recursos y logísticos estaban resueltos, sin embargo, era la primera vez que
implementábamos el proyecto en un grupo de negocios compuesto por varios países,
donde las diferencias de tamaño de negocio, diferencias culturales y legales/fiscales,
representaban el principal desafío.

South Cone, es una operación muy diversa, que cuenta con 10 plantas y 10 centros de
distribución repartidos en los seis países que lo componen:

• Argentina, tiene cinco plantas de producción de productos de cuidado personal

como jabón de tocador, aerosoles, shampoo, detergentes, alimentos y jugos. Tres
centros de distribución que concentran todo el volumen de lo producido
localmente y lo importado. A su vez tiene 21 pequeños almacenes conocidos como
TP (Transit Point), donde desconsolidan la carga de grandes camiones a pequeñas
camionetas y así poder llegar a todos clientes ubicados en zona alejadas de la

51
 capital y mercados con una alta concentración de personas que hace inviable hacer
la entrega con grandes vehículos.

• Chile, tiene tres plantas de cuidado personal, detergentes y helados. Dos centros
de distribución desde donde atienden a todos los clientes de manera directa.
Adicionalmente cuentan con 10 oficinas para la distribución de helados en casi
todas las ciudades importantes de Chile.

• Uruguay, no tiene plantas, pero tiene un centro de distribución desde el cual recibe
todas las importaciones y realiza la distribución a todo el territorio uruguayo de
forma directa.

• Paraguay, no tiene plantas, pero cuenta un con centro de distribución para el

manejo de importaciones y venta directa a los clientes.

• Perú, tiene una planta de Shampoo y un único centro de distribución.

• Bolivia, una planta de detergentes y shampoo además de dos centros de

distribución, uno para atender la para occidental del país y el otro para atender la
parte del centro y la del oriente.

La primera etapa de implementación de Cordillera para este grupo de negocio, fue el de

visitar cada uno de los países, a fin de presentar la solución tecnológica que traía el
proyecto, presentar a la estructura organizacional del proyecto y la identificación de issues
potenciales que podrían generar algún impacto directo en el proyecto y las operaciones.

El primer destino fue Bolivia, durante una semana en Cochabamba presentamos,

discutimos y aprobamos las soluciones a implementar, tanto desde la perspectiva del
negocio como de IT. En general Bolivia estaba bastante alineada en términos de procesos
y sistemas, una cantidad reducida de issues fue levantada y la mayoría estaban orientados

52
al manejo de condiciones comerciales, particularidades de la factura y algunos procesos
en la parte de manufactura que eran manuales y deberían ser automáticos.

El principal problema para Bolivia, era que, al ser una operación pequeña, el tema de
definir los recursos locales que deberían participar en el proyecto, se tornó bastante
complicada, varios equipos de implementación tuvimos que compartir los recursos, lo que
dificultaba la generación de entregables y reuniones con el equipo local.

Para Perú y Paraguay, nos encontramos con un escenario similar al de Bolivia, procesos
y sistemas bastante alineados, pero sin la disponibilidad de recursos locales, para trabajar
en el proyecto.

Para estos tres países, muchas de las tareas que en anteriores implementaciones quedaban
bajo la responsabilidad del equipo local, tuvieron que pasar a mi equipo central del
proyecto por la falta de recursos de negocio, es importante mencionar que tuvimos un
importante apoyo de los equipos locales de IT, en esta parte ayudo mucho el hecho de
que, en un pasado no muy lejano, yo era parte del equipo de IT de South Cone.

Uruguay tenía una operación muy importante a nivel de facturación y distribución con un
centro de distribución tercerizado con un operador logístico que llevaba varios años en la
operación, pero a diferencia de los otros operadores logísticos de la región, este proveedor
usaba directamente el sistema SAP de Unilever, lo cual facilito tremendamente la
implementación y no se tuvo que hacer una integración de sistemas. Sin embargo, para
Perú y Argentina, los centros de distribución que eran administrados por operadores
logísticos, tenían sus propios sistemas y la integración con los mismos era totalmente
necesaria.

Chile, venia de un proceso fuerte de cambios estructurales de personas y procesos, con lo

cual aún teníamos una operación en proceso de estabilización, que no permitía tener una
clara visión de cómo tendría que quedar operando el negocio, después de la

53
implementación del proyecto, muchas dudas quedaban en el aire. Entonces el proyecto
Cordillera para Chile no solo represento una innovación tecnológica, sino también una
oportunidad de ajuste de procesos y estructuras.

Al tratarse de la primera implementación multi - países, fue inevitable el desarrollo de

nuevas opciones y transacciones dentro de SAP, ya que, las que desarrollamos para
México y Brasil, estaban orientadas a otros tipos de mercado y no todo nos servía.

Generamos una importante cantidad de especificaciones funcionales donde

documentábamos técnicamente el requerimiento del negocio y la manera en que deberían
ser atendidos, a través del desarrollo de nuevas transacciones, creación de nuevas tablas,
configuraciones y nuevas pantallas para el ingreso de datos, lo cual también derivaba en
que tuve que generar nuevas transacciones de reportes para la operación y conciliación de
resultados.

Otro punto relevante de esta implementación, fue que, al ser líder de un proceso, de
manera constante participaba en reuniones de ajuste de estrategia de implementación y de
presentación del estatus del avance del proyecto, esta tarea administrativa era bastante
demandante ya que los lideres querían saber en todo momento el avance real del proyecto
y conocer de cerca los mayores inconvenientes que íbamos encontrando durante la
implementación. Un punto con el que tuvimos que lidiar en más de una ocasión, fue la
deserción de recursos, tanto internos como externos, la presión era bastante fuerte y no
todos conseguían ir a ese ritmo. En lo que respecta a mi equipo, solo un miembro del
equipo de IT, abandono el proyecto, infelizmente yo mismo tuve que asumir sus funciones
ya que estábamos en la etapa final del proyecto y el presupuesto ya no daba para contratar
otro recurso.

La etapa de test fue bastante peculiar, ya que al unísono teníamos que organizar las
pruebas para diferentes escenarios de negocio, muchas veces la transacción de SAP era la
misma, pero por las particularidades de cada país hacia que los resultados a evaluar fuesen

54
muy diferentes. Obviamente muchos usuarios estaban envueltos en estas pruebas y
coordinar agendas, personas, países y procesos fue un desafío importante en términos
administrativos.

La etapa de entrenamiento no fue muy diferente a la de Test, por la cantidad de recursos

envueltos desde el negocio y el equipo central de proyecto. Nuevamente recurrimos a la
metodología de “Train The Trainers”, para lograr cubrir el entrenamiento del 100% de los
usuarios.

En enero del 2015, tras doce meses de un demandante proceso de implementación,

hicimos el Go-live en los 6 países, distribuí mi equipo a todos los países para soportar el
proceso de estabilización de la implementación y yo me quedé como soporte en Argentina,
ya que, al tratarse de la operación más grande, era la que más demandaba un soporte
senior.

De manera general el proceso de estabilización fue controlado, sin embargo, en la parte

de ventas es donde más tuvimos problemas, ya que por diversos problemas del sistema y
del proceso, los pedidos de ventas y descuentos no corrían correctamente dentro de SAP
y OTM, lo que provoco que en algunas operaciones dejemos de facturar por algunos días,
esto nos obligó a que todos los equipos de implementación dejemos el proceso que
implementamos y nos concentremos en solucionar los problemas de la parte comercial.
Tras unas semanas, resolvimos los principales problemas del módulo de ventas y la
tensión generada en el Go-live, bajo rápidamente. Fue una implementación bastante
desafiadora, donde nos unimos más como equipo y le mostramos una vez más al negocio
que el staff de IT estaba a la altura de este y de otros nuevos desafíos.

La próxima unidad de negocios a implementar era Midle Américas y Caribe, con base en
Bogotá, sin embargo, por una decisión estratégica de IT, yo no participe en esta
implementación y fui alocado a un nuevo proyecto regional, que en ese momento era más

55
relevante y estaba tropezando con algunos problemas de organización y falta de ejecución,
donde el plan de trabajo definido estaba muy lejos de cumplirse.

4.4. Ultralogistik: la última frontera

En abril del 2015, fui transferido por 4 meses nuevamente a São Paulo para hacer parte
del equipo del proyecto Ultralogistik, que tenía como meta principal hacer que los
procesos de logística y distribución en Latinoamérica trabajasen de la misma manera, con
los mismos controles, mismos indicadores, mismos proveedores y una estructura
orientada al servicio.

Esta nueva visión regional fue plasmada en la formación de dos centros de excelencia de
Supply Chain, que eran conocidos como Torres de servicios logísticos que concentrarían
todas las operaciones de logística bajo un mismo lineamiento.

• Torre de Panamá, el alcance de esta torre era para los países de México, Caribe y
Midle Américas. Mi participación en la formación de esta torre fue desde una
posición de consultor de IT, ya que como había participado en la implementación
de Cordillera en México, conocía los pormenores del funcionamiento del área
logística y sabía exactamente como habían quedado los procesos en términos de
sistemas.

• Torre de Brasil, el alcance de esta torre era para las operaciones de Brasil y South
Cone. Como yo había sido parte del equipo que implemento Cordillera tanto en
Brasil como en South Cone, me asignaron la implementación de herramientas
tecnológicas para una nueva área creada bajo el nombre de LSP (Logistic Strategic
Planning) con un equipo repartido entre São Paulo y Buenos aires.

El principal foco de esta nueva área de LSP, era encarar proyectos de gran impacto en la
estructura organizacional y de procesos de la compañía, en ese orden de ideas los dos

56
primeros desafíos de este equipo, fueron la definición de la estrategia de la apertura de un
nuevo centro de distribución que debería atender al 70% de la operación de Brasil y el
segundo era el de reordenar la ubicación, cierre y apertura de los TPs para Argentina.

4.4.1. Brasil, construyendo un Centro de distribución de clase mundial

Para definir una adecuada estrategia para la apertura de un nuevo centro de distribución
con el tamaño y la envergadura que se requería, lo primero que debíamos definir es la
ubicación física del mismo, ya que Brasil al ser un país tan grande en términos de
geografía, la ubicación correcta de este CD era primordial.

Con la premisa de no bajar el nivel de servicio de entrega de productos a nuestros clientes

en todo Brasil, necesitábamos determinar cuáles CDs deberían ser cerrados para ser
reemplazados por este nuevo CD.

Tras un proceso exhaustivo de búsqueda de una solución tecnológica en el mercado,

optamos por usar una solución denominada: Supply Chain Gurú, que era desarrollada y
comercializada por una empresa estadounidense llamada Llamasoft.

Supply Chain Gurú, es una solución especializada en la simulación de mallas y proceso

logísticos a partir de datos reales y la simulación de escenarios futuros óptimos,
semiautomáticos y manuales.
Iniciamos el proyecto con la carga de información a Supply Chain Gurú de las ubicaciones
georreferenciadas de nuestros centros de distribución y clientes. También cargamos la
información de que CD atendía a que cliente, y los costos asociados a esta distribución en
términos financieros, de tiempo y recursos involucrados.

Una vez se tenía esta información en el sistema de simulación, corrimos una y otra vez el
modelo que era denominado “Zero” hasta poder reproducir dentro del sistema el
funcionamiento actual del proceso de distribución que tenía Brasil, esto es términos de

57
tiempo invertido en la recolección de información que era requerido para la simulación
del escenario actual, fue mucho más complejo de lo que parece.

Una vez que el modelo Zero estaba funcionando correctamente, se inicia el proceso de
simulación de escenarios futuros, en una primera instancia dejamos que el mismo sistema,
nos sugiera la ubicación optima del nuevo CD, mostrándonos cuales CDs podrían ser
cerrados, la variación de costos de distribución y el nivel de servicio ofrecido a todos los
clientes.

En mucho de los casos los costos y nivel de servicio no tenían una gran diferencia respecto
al actual, sin embargo, para otros clientes, los costos de distribución eran muy elevados y
los tiempos de atención extremadamente largos, entonces ahí comenzamos un proceso de
ajuste manual del modelo donde simulábamos quitar solo algunos CDs y ubicar el nuevo
CD en varios posibles lugares. Una y otra vez el modelo era corrido, cada vez con un
escenario diferente.

Tras varios procesos de simulación, análisis y alineamiento con el negocio se estableció

la ubicación y el tamaño idóneo de este nuevo CD, el mismo fue ubicado en el estado de
Minas Gerais en la ciudad de Pouso Alegre. Esta decisión derivo en el cierre de ocho
centros de distribución en Brasil.

4.4.2. Argentina, reordenamiento de la malla logística

Debido a la geografía de Argentina, Unilever concentra los Centros de distribución y

Plantas en la provincia de Buenos Aires y Capital Federal, pero al ser un país tan largo en
términos geográficos y logísticos, necesita tener puntos de desconsolidación de camiones
grandes en otros más pequeños para facilitar la distribución optima de los productos a los
clientes fuera de la provincia de Buenos Aires.

58
La solución logística para esta necesidad de Argentina es el uso de 21 TPs, ubicados
estratégicamente en varias provincias que tienen la mayor concentración de clientes.

El requerimiento para el área de LSP, era el de identificar si estos 21 TPs, estaban

correctamente ubicados en términos logísticos, en términos de costos de distribución y de
nivel de servicio a los clientes.

Para atender la implementación de este requerimiento fui transferido durante cinco meses
a Unilever Argentina, con el fin de estar más cerca de las operaciones y acompañar este
nuevo proceso de simulación logística. Para este proyecto nuevamente tome mano de
Supply Chain Gurú y lo implemente, esta vez para el equipo de LSP que estaba en
Argentina.

Los TPs, manejan diferentes costos, en función a la cartera de clientes que atienden y a un
portafolio especifico que está ligado a la geografía donde se ubican. Entonces conseguir
los datos para la construcción del modelo Zero fue bastante más demorado. Mucha de la
información requerida no estaba en SAP, se encontraba en planillas en Excel, donde cada
TP manejaba un formato diferente. Otro factor que dificulto la recolección de información
fue el hecho de que, de manera constante se iban cambiando las empresas que hacían los
transportes y fletes a los diferentes TPs, esto debido a que las inclemencias climatológicas
en Argentina son muy fuertes y no todas las empresas de transporte están preparadas para
atender un TP en medio de un calor abrazante en la pampa Argentina o en un frio extremo
en la Patagonia.

Durante casi dos meses me dedique junto al negocio a este proceso de recolección de
información. Tras superar esta fase, finalmente pudimos construir el modelo Zero en
Supply Chain Gurú y después de varias iteraciones logramos reproducir la malla actual de
TPs de Argentina, con los mismos costos y nivel de servicio hacia los clientes.

59
La principal diferencia con Brasil fue que allá se necesitaba abrir un único CD, aquí se
estaba evaluando 21 posibles aperturas de TPs, cambio de algún TP o cierre de los 21 TPs,
entonces las variables para la simulación de escenarios futuros eran bastante más
complejas y teníamos muchas condiciones más que atender y evaluar.

Para la simulación tuve que integrar al equipo algunos otros funcionarios de otros
procesos, como ser al equipo de compras, servicio al cliente, pago de fletes y conciliación
de facturas. La herramienta de simulación que estábamos usando era bastante versátil y
tenía varias opciones de variación de escenarios, pero la enorme cantidad de información
que estábamos manejando, hacía que cada corrida demore entre 2 y 3 horas, entonces cada
cambio de variable para una nueva corrida tenía que ser bien pensada, antes de simular el
nuevo modelo, ya que fácilmente podíamos perder 3 horas de reproceso, sin generar
ningún resultado útil.

Las ultimas simulaciones, nos arrojaron información bastante reveladora sobre los
cambios en la malla de TPs para Argentina, entonces tras una presentación al negocio y
una discusión sobre los resultados, se generó un plan de implementación con la siguiente
definición:

Reubicamos doce TPs, debido a que las nuevas ubicaciones generaban ahorros en costos
de fletes y mantenían el nivel de atención al cliente.

Abrimos dos nuevos TPs, que, por su ubicación estratégica, nos generaban un buen retorno
en términos de costos.

Lamentablemente tuvimos que cerrar nueve TPs, que tenían costos muy elevados y un
bajo nivel de atención al cliente. Digo lamentablemente, porque con estas definiciones
estratégicas, varias personas quedaron desempleadas o fueron reubicadas en otras oficinas.

60
Los dos proyectos donde se utilizó esta herramienta de simulación, tuvieron una muy
buena aceptación en términos de servicios y Supply Chain Gurú se transformó en el
software oficial, no solo para la torre de Brasil, sino también para la Torre de Panamá,
esto fue una motivación muy importante para mi equipo de IT, con el cual hicimos las
implementaciones.

Tras terminar el proyecto en el área de LSP, nuevamente fui transferido a Brasil para
iniciar otro nuevo proyecto, esta vez para las plantas de manufactura.

4.4.3. Inbound Redesign: en busca de nuevos desafíos

En enero del 2016, encaré el último proyecto que realicé en Unilever, dicho proyecto
llevaba el nombre de “Inbound Redesign”, cuyo principal objetivo era el de usar el sistema
de ruteo de cargas a nuestros clientes llamado OTM, para las operaciones en las plantas.

OTM, a partir de un proceso de facturación a clientes, hacia un armado óptimo de la carga

en los camiones, reduciendo así la ociosidad de los mismos, además de que generaba una
ruta óptima de entrega a los clientes, con el fin de bajar los costos de fletes.

Brasil después de varios procesos de optimización en las plantas, quedó con diez de ellas
distribuidas de la siguiente forma: Vinhedo, Indaiatuba, Valinhos, Aguai, Garanhuns,
Goiana, Iguarassu, Joboatão, Pouso Alegre y Suape.

Las plantas de Brasil manejan un volumen gigantesco de compra de materias primas, para
la elaboración de productos terminados, tanto de fabricación extrajera que llegan vía
importación, como de fabricación local. Adicionalmente a este flujo, también reciben y
envían productos del proceso de elaboración de ofertas y promociones a empresas
terceras, que reciben un producto de línea de Unilever y lo transforman en una oferta,
adicionándole algún regalo o juntando dos o más productos para generar un tercer
producto, que debe ser enviado nuevamente a Unilever para su comercialización.

61
Las plantas también tienen un importante flujo de transferencias de materia prima entre
plantas para optimizar el uso de las materias primas. Adicionalmente, todos los productos
que son fabricados, tienen que ser enviados a los centros de distribución para su
almacenaje.

Todos estos flujos mencionados, generan un importante costo de fletes de transporte, el

cual estaba siendo manejado de manera muy ineficiente, generando un sobrecosto
monstruoso dentro de la operación en Brasil, a raíz de esto surgió la necesidad urgente de
tener un sistema para el ruteo de camiones, para la optimización de rutas y el control de
ociosidad de la flota de camiones para las Plantas.

El concepto de tener una torre de servicios de transporte, es un tema global de Unilever,

entonces lo primero que se hice, fue intentar reutilizar el manejo de OTM para las plantas
que se estaba haciendo en la torre de Norteamérica.

Una parte del equipo del proyecto nos trasladamos a la torre de transporte de Connecticut,
la cual atiende a todo Estados Unidos y Canadá. Pudimos rescatar algunas buenas
practicas, pero en general las operaciones de Norteamérica son muy distintas a las de
Brasil, allá el 80% de la operación es con Wal-Mart y el otro 20% con empresas de gran
envergadura, donde no se maneja un picking por caja, ni por pallet, si no por camión
completo, es una realidad muy diferente a la nuestra y que difícilmente tendremos en
Latinoamérica y sobre todo en Brasil.
Durante los meses de marzo y abril construimos una solución en OTM más acorde a la
realidad de las plantas de Brasil, esta solución involucraba una amplia configuración de
nuevas opciones en OTM y el desarrollo de algunas funcionalidades que OTM estándar
no tenía implementadas.

El resultado de la etapa de análisis, fue altamente discutido con el negocio, ya que debido
a las particulares que tenían algunas plantas de Brasil no se podía implementar un único
modelo, que es lo que buscaba la organización, pero si se generaba una fuerte optimización

62
de los costos de fletes. Tras varias reuniones con el negocio, la solución fue aceptada e
iniciamos la etapa de Diseño.

Para llevar adelante el diseño y estar totalmente seguros de que la solución que se presentó
en la etapa de análisis, sea funcional, hicimos un recorrido de las diez fábricas, donde en
cada una, fuimos presentando la solución y levantando los principales issues por planta.

Con todo este relevamiento construimos una solución robusta, que atendiese
satisfactoriamente a la mayoría de las plantas, en algunos casos específicos tuvimos que
generar un proceso de Change Management para adecuar los procesos de algunas plantas
a la solución diseñada.

Al final de la etapa de diseño presentamos la solución final al negocio y con su aprobación

enviamos las especificaciones técnicas a la fábrica de software de Manila para su
desarrollo y configuración.

OTM era una herramienta bastante conocida en Unilever para las operaciones de ventas,
sin embargo, para las plantas todo era nuevo, esto repercutió en que la etapa de test, se
volviese enorme, en términos de tiempo y escenarios que el negocio quería revisar, para
garantizar que la solución estaba de acorde a lo que había sido definido. Realmente en
términos de sistema, los desarrollos y configuraciones pedidos a la fábrica de software
quedaron bastante bien y dentro del cronograma, pero desde el negocio tuvimos una lenta
evolución en esta etapa de Test.

En noviembre del 2016, tras superar la etapa de test, encaramos la etapa de entrenamiento,
con el fin de facilitar la implementación del proyecto, dividimos la implementación en 4
fases, donde en la primera fase con Go-live en enero 2017 solo estaban las fábricas de
Vinhedo e Indaiatuba.

63
El Go-live de estas dos primeras fabricas fue bastante demandante en términos de soporte,
todo era nuevo para los usuarios y la curva de aprendizaje y el proceso de estabilización
fue más lento de lo acostumbrado. Sin embargo, a inicios de abril, ya la operación tomo
el total control del sistema y se empezaron a evidenciar los beneficios en términos de
ahorro en costos de fletes.

A partir de esta exitosa evolución, comencé a ejecutar los siguientes lanzamientos de las
otras fábricas, quedando el plan de implementación de la siguiente manera:

• Junio 2017, Suape, Igarassu, Valinhos PC y Aguai

• Agosto 2017, Jaboatão y Valinhos IC
• Octubre 2017, Goiâna, Pouso y Garanhuns

Para cada nuevo lanzamiento tuvimos un foco muy fuerte en las etapas de Test y
Entrenamiento, ya que teníamos una total confianza en que el sistema OTM funcionaba
correctamente y solo restaba que el usuario tenga confianza y empiece a utilizarlo.

El Go-live de junio y agosto fueron exitosos, los usuarios compraron la idea a partir de la
exitosa implementación de las dos primeras plantas, este hecho generó una importante
confianza en el proyecto. No logré participar en el Go-live de octubre, ya que la búsqueda
de nuevos desafíos me impulso a dejar Unilever y afrontar nuevos retos, dejé de vender
detergente y pasé a vender la bebida no alcohólica más popular del planeta.

64
 CONCLUSIONES

Después de haber trabajado por 16 años en una compañía del tamaño de Unilever, hago
una retrospectiva sobre todos los momentos que viví en ella, sobre todas las personas y
procesos de negocio que conocí y los países en donde tuve la suerte de trabajar.

Es entonces que puedo concluir que fue una experiencia por demás enriquecedora en todo
sentido, afronté momentos muy difíciles, tuve que superar una infinidad de retos técnicos
y de proyectos, choques culturales, diferentes idiosincrasias y sobre todo el sobrellevar el
demandante ritmo que significa tener una posición regional en un proceso tan estratégico
como lo es el de IT para Logística y Distribución.

Las empresas globales de consumo masivo, tienen una filosofía de alto rendimiento, donde
todo está orientado a resultados claros y concretos, que generan un ambiente
extremadamente competitivo, y que, para conseguir moverte en este torrente de procesos
y estrategias, tienes que dar lo mejor de ti, en todos los desafíos que te toque vivir.

Unilever, da la opción de crecer, pero, así como da todas las herramientas tecnológicas y
de procesos para afrontar los retos, también es muy exigente a la hora de cobrar los
resultados. En estos 16 años, tuve la suerte de medirme con profesionales del área de IT
de todos los países de Latinoamérica y la verdad es que nunca me sentí menos que nadie,
realmente la formación que recibí en la UCB me permitió participar, competir y destacar
en este entorno competitivo, donde el sentido común fue mi principal aliado a la hora de
generar valor para la compañía, desde las diferentes posiciones de IT que tuve la
oportunidad de vivir.

El poder de abstracción que tenemos los profesionales en sistemas, es una importante

ventaja que nos permite tener una visión amplia de los procesos y conceptos de negocio,
el entenderlos y aplicarlos nos convierten en un socio estratégico de tecnología altamente
competitivo y demandado por las grandes organizaciones.

65
 RECOMENDACIONES

Al empezar la vida profesional, cada uno trae bajo el brazo un importante bagaje de
conocimiento, que nos fue impartido a lo largo de nuestra formación académica en la
Universidad, es claro que este conocimiento es un conjunto de información teórica que
puede diferir de la práctica en menor o mayor grado en función del entorno donde uno se
desenvuelva.

Tras haber vivido una larga experiencia laboral, siento que un profesional de sistemas
formado en la UCB, tiene un importante nivel de conocimiento técnico, que le permite
destacar en un exigente entorno laboral, pero veo que en el campo de conocimientos
administrativos es donde tenemos la oportunidad de mejorar, sobre todo si el profesional
se desenvuelve en una empresa que no tiene como foco de negocio el desarrollo de
software, sino más bien el de producción y comercialización de bienes y servicios, en este
orden de ideas puedo compartir con una total convicción, que una de las competencias
que te llevan a tener una carrera exitosa, es la capacidad de reinventarte en todo
momento, en todo lugar y en frente de cada nuevo desafío que te toca superar, el nunca
sentirte menos o más que tus colegas y el de siempre tener la predisposición de trabajar
en equipo harán que las situaciones difíciles que se generan día a día en el trabajo sean
más fáciles de sobrellevar, el secreto está en ser flexible y acomodarte al entorno, que hoy
en día es que todos los sistemas tienen que estar en la nube y que tengan una aplicación
móvil para interactuar con la información generada, quizá estos dos últimos puntos abren
un sinnúmero de oportunidades para los sistemas tradicionales que aún están presentes en
las grandes corporaciones.

Mi recomendación para todos los profesionales en sistemas que buscan un espacio en una
empresa transnacional de consumo masivo, es que, desde el primer día laboral, trabajen
en entender y comprender todos los procesos críticos que mueven la compañía, y así
empezar a construir el rol de socio estratégico que les llevara a desarrollar y explotar todo
su potencial dentro de la organización.

66
 BIBLIOGRAFÍA

1. UNILEVER, “Acerca de Unilever”. En <https://www.unilever.bo/about/who-we-

are/introduction-to-unilever/> (fecha de consulta: 25/09/2017)
2. UNILEVER, “UN”. En <https://www.nyse.com/quote/XXXX:UN> (fecha de
consulta: 12/12/2017)
3. SAP, “ERP”. En <https://www.sap.com/index.html> (fecha de consulta:
12/12/2017)
4. ORACLE, “BASE DE DATOS”. En <https://go.oracle.com> (fecha de consulta:
01/09/2017)
5. INGENIERÍA DE SOFTWARE, “DEFINICIÓN”. En
<https://definicion.de/ingenieria-de-software/> (fecha de consulta: 12/12/2017)
6. INGENIERÍA DE NEGOCIOS, “OLAP”. En
<https://es.wikipedia.org/wiki/OLAP> (fecha de consulta: 12/11/2017)
7. ORACLE, “OTM”. En <https://go.oracle.com> (fecha de consulta: 01/09/2017)
8. SAP, “SAP PI”. En <https://es.slideshare.net/OrekaIT/que-
essappiprocessintegrator> (fecha de consulta: 10/11/2017)
9. TECNOLOGÍAS DE INFORMACIÓN, “ITIL”. En
<https://seguinfo.wordpress.com/2008/12/03/%C2%BFque-es-itil-2/> (fecha de
consulta: 23/10/2017)
10. DESARROLLO, “ABAP”. En <http://inforsap.com/que-es-sap-abap/> (fecha de
consulta: 10/09/2017)
11. HERRAMIENTA, “CRM”. En <https://www.sumacrm.com/soporte/customer-
relationship-management> (fecha de consulta: 05/11/2017)
12. WAREHOUSE, “WMS”. En <https://alekseigil.wordpress.com/2011/09/19/que-
es-wms/> (fecha de consulta: 15/11/2017)

67
ANEXOS
Anexo 1. Glosario de Términos Técnicos

Abap: Advanced Business Application Programming, es un lenguaje de cuarta

generación, propiedad de SAP, que se utiliza para programar la mayoría de sus productos,
utiliza sentencias Open SQL, para conectarse con prácticamente cualquier base de datos.

Accenture: Es una compañía global líder en servicios profesionales de estrategia,

consultoría, digital, tecnología y servicios.

Backups: Es una copia de seguridad, respaldo, copia de respaldo, copia de reserva en

ciencias de la información e informática, es una copia de los datos originales fuera de la
infraestructura que se realiza con el fin de disponer de un medio para recuperarlos en caso
de pérdida.

Big Bang: Es una estrategia de lanzamientos de proyectos, donde al mismo tiempo se

lanzan todas las operaciones, procesos o países sin ningún escalonamiento.

BT: British Telecommunications, es una empresa de servicios de telecomunicaciones más

grandes del mundo y opera en más de 170 países. A través de su división BT Global
Services es un proveedor de servicios de telecomunicaciones a clientes corporativos y
gubernamentales en todo el mundo.

CD: Es una abreviatura de Centro de distribución, que es una infraestructura de almacenes

donde se guardan productos de forma masiva.

Condominio: Es un término usado en tecnología, para identificar que varias operaciones

o países conviven y comparten un mismo ambiente centralizado de sistemas.

1
Cordillera: Es un proyecto propietario de Unilever, que involucra la actualización de la
versión de SAP R3 a SAP ECC para Norteamérica y Latinoamérica, uniéndolas en una
sola instancia de SAP.

CORE: Aplicaciones de carácter crítico y estratégico de las empresas. Normalmente están

en un ambiente centralizado, así como también su soporte.

CRM: Customer Relationship Management, es un modelo de gestión de toda una

organización, basada en la satisfacción del cliente.

CSV: Son archivos planos, en formato sencillo para representar datos en forma de tabla,
en las que las columnas se separan por comas o puntos y comas.

Change Management: Es parte de una metodología de implementación de proyectos,

donde en lugar de realizar ajustes y desarrollos de sistemas, se realiza un cambio en el
proceso de negocio, para lo cual se tiene que manejar el cambio correctamente en las áreas
impactadas.

CHEP: Es una empresa norteamericana, con sede en Orlando Florida, que provee el
servicio de alquiler de Pallets, utilizados principalmente en grandes centros de distribución
y plantas de manufactura.

DHL: Empresa líder global del sector logístico. Experto en manejo de operaciones
logísticas en grandes centros de distribución.

Diagrama de Entidad-relación: Es una herramienta para el modelado de datos que

permite representar las entidades relevantes de un sistema de información, así como sus
interrelaciones y propiedades.

2
Flete: Es un término usado para el pago del costo del transporte, que puede ser por peso,
volumen o distancia.

Fit Confirmations: Son reuniones de proyecto, donde se revisa a detalle las soluciones y
los impactos en el negocio.

Form Designer: Es una herramienta propietaria de Oracle, que permite el desarrollo de

aplicaciones que interactúan con base de datos relaciones a través del uso del lenguaje
PL/SQL.

Fourth Shift: Es un sistema norteamericano, desarrollado para administración de los

procesos de manufactura y control de inventario.

Go-live: Es un término técnico usado en la implementación de proyectos que representa

la fecha en el cual entrara en operación, un determinado sistema, configuración o proceso.

Greater Andina: Grupo de negocios propietario de Unilever, que es liderado por

Colombia y compuesto por Ecuador, Venezuela, Perú y Bolivia.

Harmonía: Es un proyecto propietario de Unilever, el cual tuvo por objetivo la migración

de los sistemas locales a SAP R3, para toda Latinoamérica.

Helpdesk: También conocido como mesa de ayuda o mesa de servicio, es un conjunto de

recursos tecnológicos y humanos, que prestan servicios con la posibilidad de gestionar y
solucionar todas las posibles incidencias de manera integral, junto con la atención de
requerimientos relacionados a las tecnologías de información y comunicación.

HP: Hewlett-Packard, es una empresa estadounidense, de las mayores empresas de

tecnologías de información del mundo. Fabrica y comercializa hardware y software,
además de brindar servicios de asistencia relacionados con la informática.

3
IBM Cognos: Es una división de IBM que produce software de inteligencia de negocios
y administración del desempeño.
IC: Ice Cream, es una división de Unilever que se dedica a la fabricación y
comercialización de helados en algunos países de la región.

Inbound Redesign: Es un proyecto propietario de Unilever, el cual tiene como objetivo

usar OTM para las operaciones en las plantas de manufactura en Brasil.

Issue: En computación, el termino issue se atribuye a la unidad de trabajo para realizar

una mejora en un sistema informático. Un issue puede ser el arreglo del fallo, una
característica pedida, una tarea, un pedido de documentación especifico y todo tipo de
solicitud al equipo de desarrollo.

IT: Information Technology, son las tecnologías de información y comunicación (TIC),

agrupan los elementos y las técnicas utilizadas en el tratamiento y la transmisión de las
informaciones, principalmente de informática, internet y telecomunicaciones. Es también
el nombre con el que se conoce comúnmente a los equipos de sistemas en las empresas.

ITIL: Es un conjunto de conceptos y buenas practicas usadas para la gestión de servicios

de tecnologías de la información, el desarrollo de las tecnologías de información y las
operaciones relacionadas con la misma en general.

Key Users: Se refiere a la persona que es el nexo entre el usuario final y los miembros de
un proyecto. Es un usuario experto en un área o proceso de una compañía.

LSP: Logistics Strategic Planning, es un equipo regional de Unilever Américas,

encargado de la planeación de proyectos estratégicos de gran impacto para el negocio.

4
MFG/pro: Es un sistema de origen estadounidense, cuyo principal uso, es para el proceso
de facturación y control de almacén de producto terminado. Esta desarrollado en un
lenguaje de base de datos llamado: PostgreSQL.

Midle Américas: Es un grupo de negocios de Unilever Américas, liderado por Colombia

en equipo con: Venezuela, Ecuador, Panamá, Costa Rica, Nicaragua, Honduras,
Guatemala y el Salvador.

NO CORE: Aplicaciones que no son categorizadas como críticas dentro de un conjunto

de sistemas, normalmente el soporte y el alcance de este tipo de aplicaciones es local.

OLAP: Online Analytical Processing, es una solución utilizada en el campo de la llamada

inteligencia de negocios, cuyo objetivo es agilizar la consulta de grandes cantidades de
datos. Para ello utiliza estructuras de datos diversas, normalmente multidimensionales o
cubos OLAP, que contienen datos resumidos de grandes Base de datos o Sistemas
transaccionales.

OMO: Es un detergente propiedad de Unilever, que se comercializa en formatos de polvo,

líquido y capsulas. Es uno de los productos estrella dentro del portafolio comercializado
en Latinoamérica.

Optimix: Es un sistema boliviano, desarrollado en herramientas de Oracle: Form

Designer y Report Designer bajo el lenguaje de programación de base de datos: PL/SQL.

Oracle: Es una compañía especializada en el desarrollo de soluciones de nube y locales,

ocupa el primer lugar en la categoría de base de datos a nivel global.

OTM: Oracle Transportation Management, proporciona una plataforma con la que las
empresas pueden administrar la actividad de transporte en todas sus cadenas de
aprovisionamiento. OTM es la solución especifica en el ámbito de la logística de Oracle.

5
Pallets: Es un armazón de madera, plástico u otro material empleado en el movimiento
de carga, ya que facilita el levantamiento y manejo con pequeñas grúas hidráulicas.

PC: Personal Care, es una división de negocios de Unilever, que comercializa artículos
de cuidado personal, como cremas y desodorantes.

PI: Process Integration, es la herramienta de SAP para centralizar el intercambio de

información entre sistemas SAP o sistemas no-SAP, estableciendo un único punto de
acceso y monitorización centralizada.

Picking: En el campo de logística, picking o preparación de pedidos es el proceso de

recogida de material extrayendo unidades o conjuntos empaquetados en un almacén.

PL/SQL: Es un lenguaje de programación incrustado en Oracle, que soporta todas las

consultas a una base de datos, la sintaxis es la mima que SQL con características
adicionales.

PostgreSQL: Es un sistema de gestión de base de datos relacional orientado a objetos, el

cual permite el desarrollo de aplicaciones a través del uso de sentencias SQL.

Release: Es un término usado en la jerga de implementación de proyectos, que representa

un lanzamiento de un determinado proceso, operación o país. Es usado para dividir en
etapas una implementación.

Remote Hand: Terminado usado para identificar un soporte remoto que requiere una
interacción física.

Report Designer: Es una herramienta propietaria de Oracle, que es usada para generar
reportes a través del acceso a base de datos relacionales usando sentencias PL/SQL.

6
Rollout: Es un término usado en la jerga de implementación de proyectos, donde a partir
de un lanzamiento previo se hacen nuevos lanzamientos con las mismas características del
primero y solo se tiene cambios o ajustes menores.
Routers: También conocido como enrutador, es un dispositivo que proporciona
conectividad a nivel de red o nivel tres en el modelo OSI.

SAP ECC: ECC es una versión de SAP que es un ERP de origen alemán. Es un sistema
de cómputo integrado de gestión, que permite controlar todos los procesos que se llevan
a cabo en una empresa, a través de módulos.

SAP R3: R3 es una versión de SAP que es un ERP de origen alemán. Es un sistema de
cómputo integrado de gestión, que permite controlar todos los procesos que se llevan a
cabo en una empresa, a través de módulos.

Siebel: Es una compañía dedicada principalmente al diseño, desarrollo, comercialización

y soporte de software de gestión de relaciones con clientes.

Sinfonía: Nombre de un proyecto de Unilever Américas, para la centralización de

información de ventas, a través del uso de cubos OLAP.

South Andina: Grupo de negocios de Unilever, compuesto por Perú y Bolivia.

South Cone: Grupo de negocios de Unilever, compuesto por Argentina, Chile, Uruguay,
Paraguay, Perú y Bolivia.

Store Procedure: Es un programa almacenado físicamente en un base de datos. Su

implementación varía en función del gestor de base de datos, pero el objetivo principal es
de conseguir un mejor performance de ejecución.

7
Supply Chain Gurú: Es una herramienta, desarrollada y comercializada por Llamasoft,
su principal característica es la simulación de procesos logísticos para la toma de
decisiones.

Supply Chain: Es la cadena de abastecimiento usada en un proceso industrial, que va

desde la fabricación del bien, el transporte, almacenado y su distribución.

Switches: También conocido como conmutador, es un dispositivo digital lógico de

interconexión de equipos que opera en la capa de enlace de datos del modelo OSI.

Test: Es una etapa del ciclo de vida, en la implementación de proyectos, en esta etapa se
realizan las pruebas del sistema para garantizar un correcto funcionamiento de las nuevas
configuraciones o desarrollos.

Ticket: Es una solicitud de servicio, generado por un usuario que requiere soporte, en un
área específica de tecnología de información.

TP: Transit Point, es un pequeño almacén donde se realiza la desconsolidación de

camiones grandes en camiones más pequeños, para facilitar la distribución de bienes.

Train The Trainers: Estrategia de entrenamiento, en donde, en lugar de entrenar a todos

los usuarios, se entrena a uno en específico, el cual posteriormente replicara el
conocimiento con los demás usuarios finales.

Tunning: Proceso de ajuste de un equipo o proceso, con el fin de conseguir el máximo

provecho a través del uso de una configuración eficiente.

Ultralogistik: Proyecto propietario de Unilever, que gestiona la creación de torres de

servicio logístico para Latinoamérica.

8
Unilever: Es una empresa anglosajona, con presencia global en el rubro del consumo
masivo de productos de cuidado personal, cuidado del hogar, alimentos y helados.

Visual C: Es un entorno de desarrollo integrado para lenguajes de programación C y C++.

WMS: Es un sistema de gestión de almacenes, es un módulo de software de SAP que da
soporte a las operaciones diarias de un almacén, que permite la gestión centralizada de
tareas, como el seguimiento de los niveles de inventario y la ubicación de existencias.

WoW: Ways of Working, es la forma o manera en que es realizada una determinada tarea
o gestión de procesos dentro de una unidad de negocio.