soporte erp e implementaciÓn erp-sap ... - tesis ipn
TRANSCRIPT
INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERIA Y CIENCIAS SOCIALES
Y ADMINISTRATIVAS
“SOPORTE ERP E IMPLEMENTACIÓN ERP-SAP EN ÁMBITOS INTERNACIONALES”
M E M O R I A D E E X P E R I E N C I A P R O F E S I O N A L
Q U E P A R A O B T E N E R E L T Í T U L O D E L I C E N C I A D O E N C I E N C I A S D E L A I N F O R M Á T I C A P R E S E N T A L U I S F E R N A N D O G A R C Í A G U T I É R R E Z
CIUDAD DE MÉXICO 2019 No. DE REGISTRO C3.447
Resumen .................................................................................................................................................... i
Introducción ............................................................................................................................................ iii
Capítulo I. Contexto general de los proyectos ................................................................................... 1
1.1 Generalidades de Jafra ..................................................................................................................... 1 1.2 Mi experiencia profesional antes de hacer carrera en Jafra ................................................... 4
Capítulo II. Soporte al sistema comercial – ERP Jafra ..................................................................... 7
2.1 Problemática ....................................................................................................................................... 7 2.2 Sistema Comercial ERP .................................................................................................................... 9 2.3 ERP en JAFRA, Hardware y Software ........................................................................................... 9 2.4 Portafolio de Aplicaciones............................................................................................................. 15 2.5 Soporte de ERPs globales y su complejidad ............................................................................ 17 2.8 Fortalezas y debilidades del equipo de trabajo ....................................................................... 21 2.9 Conocer a tus clientes directos e indirectos ............................................................................ 24 2.10 Victorias a corto plazo “Quick Wins” ....................................................................................... 26 2.11 Necesitamos recursos calificados ............................................................................................ 27 2.12 Escenario de soporte multi cultural. ......................................................................................... 29 2.13 Como ganar proyectos ................................................................................................................. 31 2.14 Project Management (Administración de Proyectos) ........................................................... 33 2.15 Convivencia Generacional en Armonía .................................................................................... 36 2.16 Manejo de Proveedores ................................................................................................................ 38
Capítulo III. Implementación SAP ....................................................................................................... 43
3.1 ¿Qué es SAP? ................................................................................................................................... 43 3.2 ¿Porque SAP? ................................................................................................................................... 45 3.3 Problemática ..................................................................................................................................... 46 3.4 ¿Implementación Completa “Big Bang” o Parcial? ................................................................ 47 3.5 Estructura Organizacional para la implementación ................................................................ 48 3.6 Viajes al extranjero y situaciones familiares ............................................................................ 49 3.7 Retos en la comunicación ............................................................................................................. 51 3.8 Retos Multiculturales ...................................................................................................................... 53 3.9 TI en funciones de área usuaria ................................................................................................... 54 3.10 Toma de Requerimientos en base a múltiples modelos de negocio ................................ 57 3.11 Manejo de Consultores SAP ....................................................................................................... 59 3.12 Blue Print de SAP .......................................................................................................................... 61 3.13 Indispensable involucramiento con los usuarios ................................................................. 64 3.14 Requerimientos que cambian durante la implementación ................................................. 67 3.15 Seguriad en SAP ............................................................................................................................ 69 3.16 Simulación de carga de trabajo productiva del nuevo ERP ............................................... 71 3.17 Entrenamiento a Usuarios del nuevo ERP SAP ..................................................................... 73 3.18 Cutover – Plan de transición ....................................................................................................... 77 3.19 Go Live – Puesta en producción del nuevo ERP SAP .......................................................... 79 3.20 Soporte a producción y estabilización ..................................................................................... 80
Conclusiones ......................................................................................................................................... 82
Referencias ............................................................................................................................................. 84
Anexos..................................................................................................................................................... 85
i
Resumen
El informe de memorias “Soporte ERP e Implementación ERP-SAP en ámbitos internacionales”
está estructurado en los siguientes tres capítulos:
Capítulo I: Contexto General de los Proyectos
Aquí les comparto generalidades de la empresa, que incluye información muy importante sobre la
misma, tal como información general sobre la marca, localidades donde tiene presencia, una muy
interesante reseña histórica, los detalles del giro comercial y algunos detalles para identificar su
tamaño.
Adicionalmente, les comparto una breve reseña de mi experiencia profesional antes de iniciar en
JAFRA; me parece muy importante sentar un marco de referencia profesional, ya que previo a mi
larga trayectoria en JAFRA y a quien debo gran parte de mi experiencia profesional y mi crecimiento
personal, también tuve oportunidad de desarrollar diversas habilidades y conocimientos técnicos,
muchos de ellos con bases interesantes a nivel de programación y materias específicas que me
regaló UPIICSA.
Capítulo II: Soporte al sistema comercial – ERP JAFRA
Dentro de este capítulo encontrarán información muy valiosa alrededor de un ERP, en este caso
desarrollado en casa, implementado y soportado a nivel mundial, lo cual me da la oportunidad de
compartirles algunos conceptos, recomendaciones y estrategias aplicables a este escenario que por
naturaleza tiene fundamentos multiculturales.
Se iniciará con un planteamiento de la problemática que puede presentarse no sólo en compañías
con el mismo giro; hablaré de conceptos básicos de un ERP; les compartiré algunos aspectos
básicos acerca del software y hardware utilizados con la intención de sentar un marco técnico sobre
el cual se desarrollaron infinidad de proyectos; les hablaré de forma general sobre el portafolio de
aplicaciones para establecer el tipo de las mismas, con enfoque de uso interno y externo.
Incluiré conceptos muy interesantes sobre el soporte a ERPs globales y su complejidad lo cual
incluirá no sólo actividades puramente de soporte sino también para nuevos desarrollos como áreas
de oportunidad y crecimiento. En el ámbito de equipos de trabajo, hablaré de sus fortalezas y
debilidades con aspectos dedicas al soporte fuera de México que por si mismo es un reto importante.
Les hablaré de la importancia de conocer a los clientes directos e indirectos ya que es común
encontrar puntos ciegos y es vital ubicar y centrar esfuerzos para ambos grupos.
Les comparto también algunas estrategias que seguí para la consolidación de un equipo de trabajo,
como las victorias a corto plazo, lo cual se combina con la necesidad de tener recursos calificados,
teniendo en mente que se compite con otros recursos a nivel mundial, y en donde en México no sólo
se nos tiene que ver como mano de obra barata, y sumado planteo el escenario de soporte
multicultural que incluye desde aspectos de horarios múltiples hasta el tratamiento de diferentes tipos
de usuarios con diferentes culturas.
ii
En temas de administración de proyectos, les compartiré estrategias que seguí para ganar proyectos
derivados inicialmente del soporte mismo, pero que con entregas de calidad se transformó en un
área de oportunidad clave para el crecimiento del equipo de trabajo; les hablaré en lo particular sobre
la administración de proyectos incluyendo conceptos y algunas metodologías interesantes para su
gestión.
Desarrollé también un tema muy enriquecedor acerca de la convivencia en armonía de múltiples
generaciones, lo cual bien llevado permite establecer una estrategia que permite un ambiente de
trabajo cordial pero sobre todo muy productivo.
Finalmente les hablaré sobre la administración de proveedores, lo cual como muchos otros temas
no es trivial y requiere de atención precisa para una correcta administración y resultados exitosos.
Capítulo III: Implementación SAP
Gran parte de mi carrera tiene una formación y extensas experiencias en tecnologías de información
(TI), sin embargo, en este capítulo encontrarán información muy valiosa sobre la contra parte usuaria,
que es en realidad a quien cualquier área de TI debería de tener en todo momento presente y nunca
obviarla, ya que es en realidad a quien nos debemos como gente de TI.
El capítulo está dedicado a una implementación SAP, considerado actualmente como el standard
más representativo y mayormente implementado a nivel mundial en soluciones de ERP. Aquí podrán
encontrar desde conceptos básicos hasta temas muy profundos incluyendo del porque una
implementación de esta magnitud, pasando por el planteamiento de la problemática que lleva a la
decisión, y tocando temas muy interesante sobre el alcance que puede ser parcial o completa.
Les compartiré temas de carácter personal con todos los retos familiares inmersos en la participación
de una implementación SAP ya que hay muchas semanas fuera de casa.
Al ser una implementación con alcance global, plantearé diferentes retos asociados a la
comunicación y a las diferentes culturas que participan.
Dentro de todas estas funciones como usuario, compartiré la importancia y fortuna de tener
formación TI, ya que al estar en ambos lados de la moneda se genera una empatía muy interesante
entre ambos lados de la ecuación en sistemas: TI y usuarios.
Hablaré de aspectos particulares a SAP durante el ciclo completo de la implementación tales como
el manejo de consultores, metodologías de implementación incluyendo algunos conceptos como
plano azul (Blue Print), definición de requerimientos, seguridad, entrenamiento, planes de transición,
puesta en producción y soporte a producción y estabilización.
iii
Introducción
El presente informe está basado en mi experiencia profesional adquirida a lo largo de más de
diecisiete años de carrera en la empresa JAFRA, dedicada principalmente a la venta directa de
cosméticos a través de una red de consultoras JAFRA, dentro de la cual tuve la oportunidad de
desarrollar y consolidarme en diferentes posiciones en el área de tecnologías de información,
principalmente enfocada en áreas de desarrollo y gestión de aplicaciones ERP a nivel internacional,
así como en una posición de líder de negocio en el área de Ventas y Distribución (SD Sales &
Distribution) clave para la implementación de un nuevo ERP utilizando soluciones SAP para México
y USA.
Es muy importante para mi mencionar que todas las experiencias aquí compartidas fueron
acumuladas como una gran oportunidad de vida personal y profesional basados en diversos
proyectos implementados en diferentes países alrededor del mundo, lo cual me parece muy
enriquecedor al haber tenido la gran satisfacción de haber aprendido y trabajado mano a mano con
diferentes culturas alrededor del mundo.
Será muy interesante identificar y desarrollar los retos multi culturales, y así mismo identificar que
tenemos como mexicanos muchas cualidades que con una administración adecuada nos pueda dar
resultados extraordinarios y de competencia a cualquier nivel en cualquier ámbito internacional.
Mientras que el Capítulo I cubre los conceptos e información básica de JAFRA, los Capítulos II y III
cubren dos grandes áreas de mi experiencia profesional que considero las más relevantes en mi
carrera, mismas que considero complementarias ya que el Capítulo II cubrirá una serie de
experiencias desde un enfoque principalmente de tecnologías de información (TI), mientras que el
Capítulo III expandirá experiencias basadas en el área usuaria de negocios, brindándome la
oportunidad de compartir una dualidad de conocimientos que en el mundo real de cualquier giro de
empresa tienen que funcionar en una armoniosa simbiosis ya que uno no puede existir sin el otro.
El capítulo II, tiene su base en un sistema ERP desarrollado en casa durante décadas, mismo que
abrió las puertas de ser implementado en diferentes países del mundo, resultando por su naturaleza
en una serie de retos desde su desarrollo hasta el soporte al mismo en esquemas multiculturales y
en un mundo que inevitablemente a evolucionado y que generó diferentes necesidades para
mantenerlo a la vanguardia sobre la tecnología disponible.
En este capítulo encontrarán información muy valiosa más allá de conceptos técnicos de un ERP,
enfocada a equipos de trabajo en escenarios globales y multiculturales, tales como victorias a corto
plazo, la necesidad de personal calificado, como ganar proyectos, incluyendo temas fundamentales
en la administración de proyectos y el manejo y gestión de diferentes generaciones (por ejemplo:
Milenials, Baby Boomers, etc) entregando resultados muy productivos a nivel mundial.
Entrando al capítulo III, considero que no es muy común que alguien con formación TI, tenga la
oportunidad de estar con funciones de usuario. Les adelanto que es algo sumamente retador e
interesante y que definitivamente me lleva a gestionar TI con un enfoque, sino nuevo, si considerando
todas las aristas y principalmente desarrollando una mayor empatía con el área usuaria y una gestión
ajustada de todos y cada uno de los proyectos que a partir de esta oportunidad tendré en lo futuro.
Se vive irremediablemente ése sentimiento que critica a la gente de sistemas, por una aparente
iv
incomprensión hacia el área usuaria, por lo que bien enfocados los esfuerzos será mucho más
natural sumar y perseguir los resultados exitosos en cada proyecto.
Si bien el informe está basado en JAFRA, prácticamente todos los conceptos son trasladables a
otros giros de empresa en mayor o menor magnitud. Considero que les comparto muchos conceptos
y experiencias de carácter universal que pueden ser utilizados como una guía. Considero que hay
muchas formas de llegar al mismo resultado, desafortunadamente algunas de ellas son muy
dolorosas y costosas, por lo que siempre será de ayuda saber que hay más allá de una formación
académica; que dicho sea de paso es imprescindible, ya que las bases de la personalidad profesional
y ganas de ser exitoso en la vida se combinan con nuestra personalidad y formación en casa.
El presente informe tiene un enfoque principalmente con fines académicos por lo que no pretende
asentar conocimientos formales sobre SAP o bien divulgar información confidencial de la empresa,
sino más bien plantear escenarios y compartir el conocimiento desarrollado y adquirido de
situaciones en un mundo real que estoy convencido sumarán conocimiento para futuras
generaciones y que para mi representa un gran orgullo como mexicano y como estudiante de mi
amada UPIICSA, ya que es una realidad para mi que fue aquí donde complementando la parte
personal como ser humano se me brindaron a través de todos y cada uno de los profesores todas
las herramientas para sentar las bases de conocimiento desde mi primer lenguaje de programación
hasta temas más complejos en ámbitos de administración y gestión de proyectos.
Es mi mayor deseo que disfruten tanto como yo al escribirlo, de la lectura de este informe cuya mayor
pretensión será la de compartir mis experiencias profesionales y conocimiento.
Muchas Gracias.
1
Capítulo I. Contexto general de los proyectos
1.1 Generalidades de Jafra
Nombre y/o Razón Social
JAFRA Cosmetics International, Inc.
Acerca de la marca JAFRA
JAFRA Cosmetics International, Inc., es uno de los líderes mundiales en fabricación de productos de belleza, ofreciendo una gama completa de cuidado del cutis, fragancias, maquillaje, baño y cuerpo, con operaciones en 18 países alrededor del mundo. Es una compañía privada que tiene más de 550,000 consultoras independientes (Se le conoce con consultoras a todas aquellas personas que ofertan los productos) e ingresos anuales arriba de medio billón de dólares americanos. Desde 2004, JAFRA ha sido parte del Grupo Vorwerk, una empresa de familia establecida en 1883 con oficinas centrales en Alemania.
Oficinas Centrales 2451 Townsgate Road, Westalake Village, CA 91361
2
Reseña histórica de JAFRA
El año es 1956. Elvis Presley hace su primera aparición en la escena musical; Grace Kelly se casa
con el Príncipe Rainiero de Mónaco. Sartenes antiadherentes se introducen al mercado. Y nace
JAFRA.
El lugar es Malibu, California, una hermosa comunidad frente al mar en la costa del Pacífico. Los
cofundadores de JAFRA, Jan y Frank Day, son una pareja joven con una visión y un sueño. El
singular nombre de JAFRA se derivó de la combinación de los primeros nombres de sus
cofundadores (JA + FRA)
Jan y Frank estudiaron los secretos de belleza de los antiguos egipcios, y así fue como nació la
legendaria Royal Jelly Milk Balm. Royal Jelly se convirtió en un éxito de la noche a la mañana, y
hasta el día de hoy continúa siendo el producto de firma de JAFRA. La compañía se expandió para
poder incluir colecciones de productos para el cuidado de la piel, fragancias, maquillaje y artículos
de tocador.
La dedicación de la pareja Day al empoderamiento de las mujeres fue más allá de sólo ayudarlas a
verse y sentirse mejor. JAFRA también les ofreció la oportunidad de vender sus productos como
consultoras independientes.
Hoy en día, el patrimonio de los Day sigue vivo en la misión y valores de JAFRA. JAFRA Cosmetics
International crea productos de belleza y oportunidades de negocio para atender las necesidades de
las mujeres, oportunidades que les permiten explorar, descubrir, reinventar y revelar su verdadero
potencial. Con el lema de “la libertad de ser tú”, JAFRA celebra el espíritu único que existe dentro de
cada mujer, y todas las cosas que las hacen ser imperfectamente perfectas e individualmente
hermosas.
¡El compromiso de JAFRA es el de lograr su misión de transformar las vidas de millones de mujeres
alrededor del mundo!
Giro
JAFRA oferta una oportunidad de venta directa, dando el poder a las mujeres de transformar sus
vidas a través del trabajo en equipo, opciones y éxito.
JAFRA inicio con un modelo de mercadeo con “Fiestas en Casa”. A través de las décadas, el
mercadeo ha cambiado dramáticamente. JAFRA actualmente da soporta una variedad de flexibles
e innovadores sistemas de ventas para sus Consultoras, incluyendo ventas de uno a uno, o en
ambientes de grupos pequeños así como de mercadeo a través de sitios web, blogs y a través de
redes sociales.
3
Tamaño
JAFRA es una compañía de nivel mundial. Tiene presencia en América del Norte a través de sus
oficinas en USA y México; en América del Sur con oficinas en Brasil; en Europa cuenta con oficinas
en Alemania, Austria, Países Bajos, Suiza, Italia y Rusia; en Asia con oficinas en Indonesia. Y cuenta
con Distribuidores en República Checa, Hungría, Eslovenia, Polonia y Eslovaquia, como se describe
gráficamente en la Figura 1.1 Mercados y Distribuidores de JAFRA en el mundo.
Figura 1.1 Mercados y Distribuidores de JAFRA en el mundo
(https://www.jafra.com/about-jafra/choose-country 6 Diciembre 2018)
La información contenida en este capítulo fue extraída, sintetizada y traducida de los siguientes link:
www.jafra.com
http://dyt7354sr16hm.cloudfront.net/global/media/document/jafra_cosmetics_intl_presskit_2016.pdf
6 Diciembre 2018
4
1.2 Mi experiencia profesional antes de hacer carrera en Jafra
Me parece importante dar un marco de referencia en mi experiencia profesional antes de iniciar
laboralmente en JAFRA.
Durante la década de los 90, muchas soluciones empresariales estaban basadas en arquitecturas
Cliente Servidor. Principalmente con el uso de lenguajes visuales, como Visual Basic, que estaba en
una etapa interesante de esplendor en México, pero que funcionaba adecuadamente para empresas
pequeñas que utilizaban como servidor de base de datos Microsoft Access y SQL Server.
Históricamente, en las aplicaciones empresariales, había una necesidad de una interface de usuario
más amigable. Parece que fuera un tema trivial ya que hoy en día casi todo es muy visual, intuitivo
e interactivo, salvo defectuosas excepciones.
La necesidad visual se cubría a través de lenguajes visuales como Visual Basic, dejando un poco
atrás la tendencia de pantallas monocromáticas y uso limitado de la interface de usuario, al incluso
no permitir el uso de un mouse como en lenguajes básicos como Cobol, Pascal y C Para poder lograr
el uso de interfaces más amigables con menús, mouse, etc se requería de un desarrollo significativo
en las aplicaciones y un uso de recursos y tiempos de compilaciones elevados si, por ejemplo, se
utilizaban las librerías gráficas de un Turbo Pascal 7.0
En UPIICSA, durante los primeros semestres de la carrera tuve la oportunidad de conocer lenguajes
de programación básicos como Pascal, Basic, C, Cobol. Fue durante los primeros semestres que se
me permitió ir más allá de lo enseñado en las aulas, y el profesor Jose Luis López Goytia me permitió
desarrollar el auto aprendizaje a través del desarrollo y entrega de proyectos especiales basados en
Turbo Pascal 7.0 y Visual Basic, un hasta entonces excelente lenguaje orientado a eventos. Aun no
llegaba el momento de la Programación orientado a objetos.
Estoy convencido, dados mis años de experiencia, que el conocimiento de las aulas se limita
únicamente por el alumno; si bien las universidades como UPIICSA tienen un programa básico de
desarrollo, es indispensable para cualquier estudiante que desee alcanzar mejores oportunidades
profesionales auto desarrollarse, buscar información actualizada, precipitar oportunidades de
conocimiento y no tener ninguna apatía al respecto, esperando que el profesor lo de todo “en bandeja
de plata”. Esto abre puertas y oportunidades de iniciar la investigación sobre cualquier tema
utilizando otro lenguaje como el inglés, que si bien puede ser limitativo para algunos, también es una
oportunidad paralela. Dicho sea de paso, todos los libros técnicos afortunadamente no están escritos
como novelas literarias con palabras y vocabulario rebuscado. Es muy fácil seguir con un inglés
básico los conocimientos y emprender la práctica correspondiente.
Lo anterior me permitió desarrollar habilidades de programación que se fueron combinando con otras
materias como estructura de datos, programación orientada a objetos, bases de datos y SQL que
precisamente me permitieron incorporarme a la escena laboral en una etapa temprana durante el 4º
y 5º semestre con una ventaja competitiva que en el momento tenía una demanda laboral muy
grande y donde pocas personas realmente en México teníamos el conocimiento.
La experiencia anterior, en temas actuales durante 2018, puede carecer de un valor sustancial. Aquí
el punto a compartir más importante es que lenguajes de programación y herramientas de bases de
datos van, vienen y han evolucionado de una forma exponencial prácticamente dejando a un lado
cualquier límite de una necesidad de usuario, por lo que lo más importante es extrapolar que lo que
5
hoy en día y en cualquier punto en el futuro se utiliza, y que no necesariamente lo encontrarán en un
aula universitaria. Se requiere de una inversión intelectual que puede formar la base sólida de un
inicio de carrera profesional.
No hay que olvidar que en el ámbito profesional no todo son los lenguajes de programación y bases
de datos, porque estas son sólo herramientas que se tienen que combinar con una visión de negocio
para cubrir requerimientos comerciales en cualquier industria y de la vida real, cotidiana, donde se
de una solución de una forma gráfica amigable, pero sobre todo intuitiva, para que la pueda usar
incluso un pequeño de 4-5 años que utiliza una Tablet o un teléfono inteligente.
La gente orientada a tecnologías de información, tendemos de forma natural -al menos en las etapas
iniciales- a esa cuadratura que nos hace creer que nuestros desarrollos son entendibles por cualquier
usuario, cuando la realidad nos dicta que todos los días tenemos algo nuevo por aprender, y que
todos los días hay mejoras a procesos humanos que van dictando en el día a día la evolución de
cualquier aplicación o sistema comercial.
Así, durante mis etapas tempranas profesionales pude hacer uso de los conocimientos antes
mencionados y tuve la oportunidad de liderar un equipo de desarrollo en la parte de front-end en
Visual Basic para una solución ERP (Enterprise Resource Planning) en Fuller de México. Dicho ERP
estaba basado en una arquitectura cliente servidor, utilizaba Visual Basic en el front-end y en el back-
end IBM AS-400. Más adelante daré información muy interesante acerca de este tipo de servidores.
Cuando se tienen aún pocos años de experiencia, es muy fácil identificar que el trabajo realizado es
muy poco remunerado, con el pretexto, en mi caso, de que fui parte de un programa de becarios en
una fuerte empresa tegnológica. Yo lo he llamado durante muchos años “El mal del becario”, mismo
que si, es verdad, me permitió entrar al proyecto de Fuller, pero que en la realidad de mi economía
no estaba reflejado ni en una proporción 1/10 con respecto a lo que dicha empresa tegnológica
cobraba por mí a Fuller México, con un modelo de negocio basado en ventas multi nivel.
Es muy importante entender que así funciona el modelo laboral de forma inicial y quizás perdure
durante algunos años, pero que también es un privilegio personal decidir en dónde pararlo para
entonces buscar nuevos horizontes profesionales con la experiencia ya adquirida. En mi caso me
llevó a buscar mi primer oportunidad como Analista de Sistemas, en una compañía que -pudiera
parecer coincidencia- se dedicaba a desarrollar software para compañías multinivel.
Durante esta etapa profesional, pude darle un excelente uso a mis clases de SQL en UPIICSA, ya
que una parte fundamental era el análisis de datos, e incluso programación y análisis de stored
procedures, mismos que me permitían hablar el lenguaje de los desarrolladores de dicha compañía
de software.
Y aquí una de mis primeras reglas de oro profesionales, ya que como analista de sistemas, tenía
también la responsabilidad de hacer especificaciones que algún programador debía seguir. Fue
entonces indispensable ser un buen desarrollador, porque eso me permitía trasladar en un lenguaje
más entendible para el desarrollador dichas especificaciones.
La regla de oro es entonces, que es deseable, conocer el detalle de lo que uno tiene que especificar,
coordinar, administrar en todas las escalas y posiciones en el área de desarrollo de las tecnologías
de información, ya que aún en mi etapa de directivo me permitía hacer muy buenas aproximaciones
6
sobre tiempos de desarrollo, análisis, etc; Porque, ¿quien no ha escuchado casos donde el técnico
más técnico siempre “infla” sus tiempos para entregar X o Y tarea?
Posteriormente tuve otra experiencia profesional igualmente como analista de sistemas para una
oficina gubernamental, de cuyo nombre prefiero no acordarme y gracias a la cual me prometí en la
medida de lo posible evitar cualquier contacto con el gobierno. Esto podría ser por si sólo un tema
de tesis que con toda seguridad alguien ya cubrió y puede estar al alcance en nuestra amada
biblioteca en la UPIICSA.
Finalmente previo a JAFRA, tuve la oportunidad ser parte del ejército de personal que formó parte
de uno de los fraudes documentados y del cual podemos encontrar información pública más grandes
que ha dado la unión americana, ENRON. Fui seleccionado por un equipo de reclutamiento de IBM.
Aquí un paréntesis con el idioma inglés. Y quizá sea mi recomendación profesional nivel 0, para
todas aquellas personas que lean este informe y que tengan deseos de desarrollarse fuera de
México.
Hoy en día se dice, o se nos dice que el lenguaje del futuro es el Chino. Quizá lo sea. Sin embargo,
el lenguaje universal que nos permite una comunicación adecuada, es en mi experiencia hasta el día
de hoy el lenguaje Inglés. Es cierto, a algunos nos cuesta más trabajo que a otros, hay seres
privilegiados que pueden dominar más de 2, 3 o 4 idiomas. La realidad laboral, es que el hablar o
escribir inglés, abre un sin número de oportunidades, y es un factor diferenciador que se suma a
cualquier cualidad personal y profesional que se tengan. Sin él, ¿cómo comunicarnos fuera de
México, en donde no se hable español? Más adelante hablaré sobre muchas experiencias asociadas
a temas multiculturales, que es una combinación con el idioma Inglés si, pero recuerden que por si
sólo es una de las mejores herramientas que les puede regalar la vida.
¿Como aprenderlo?. Hay muchas formas, algunas que pudieran parecer tontas: ver películas,
escuchar canciones, hasta leer libros, tomar clases, ir a estudiarlo al extranjero, etc. Aquí al igual
que la parte autodidacta que mencioné anteriormente en temas técnicos, se requiere de lo mismo
para el idioma, y en todo momento, y en la más mínima oportunidad practicarlo, practicarlo…
practicarlo, practicarlo. Les van a ayudar mucho cualquier certificación en el idioma. No por el papel,
sino, porque habrá un esfuerzo tras esa certificación que ayudará en el mundo real. Porque, ¿alguna
vez se han puesto a pensar, que aún hablando el mismo idioma no nos entendemos? El factor idioma
es una variante profesional muy interesante que más adelante igualmente trataré en este informe.
Cerramos paréntesis y continuamos. Durante dicho proceso de reclutamiento de IBM para Enron, fui
seleccionado precisamente porque a demás de cubrir la parte técnica, hablar y escribir inglés con
relativa soltura, me regaló la primera oportunidad de representar a México en el extranjero, en
Houston, USA, al haber formado parte del proyecto de Enron durante aproximadamente 6 meses,
con una promesa de contrato en IBM, hasta que la realidad financiera de Enron los alcanzó.
Y es a partir de mi regreso frustrado de Enron, que me incorporo a las filas laborales en JAFRA como
Líder de Proyectos WEB, gracias al “boom” del internet a finales de la década de los 90’s / principios
del 2000.
7
Capítulo II. Soporte al sistema comercial – ERP Jafra
2.1 Problemática
Siempre tendremos áreas de oportunidad ante cualquier problemática o reto profesional; Hay
oportunidades de desarrollo que se precipitan por estar en el momento adecuado durante la
problemática desafortunada.
Un área de soporte y desarrollo global, enfrenta retos muy importantes por si misma: En la mayoría
de los casos es complicado señalar o apuntar a personas o situaciones en específico, ya que en la
gran mayoría de los casos, hay escenarios económicos entre países, presupuestos, direcciones
ejecutivas y tantos otros elementos que pueden desarrollar escenarios adversos y de los cuales no
se tienen todos los elementos e inclusive resultaría poco ético y relativamente ocioso profundizar.
Por eso la problemática planteada para este capítulo se enfocará objetivamente en las principales
áreas de oportunidad que identifiqué cuando recibí la responsabilidad del área de soporte/desarrollo
global:
Comunicación verbal y escrita limitada por el uso del lenguaje en inglés: Desde mi punto de
vista, se trata de la esencia misma en el soporte, ya que si no me puedo comunicar
adecuadamente con mis clientes (en este caso se habla de mercados-países), resulta muy
complicado poder entender los requerimientos y resulta aún más complicado poder entregar
resultados de calidad.
Falta de SLAs (Service level agreements – Acuerdos de los niveles de servicio): Es un
principio básico en el soporte de cualquier área de soporte. Este punto se revisará con
mayor detalle durante el desarrollo del subtema asociado a los retos en el soporte de este
informe. Para abrir de forma inicial el contexto les comparto que los SLA´s son acuerdos
formales del soporte entre la unidad de soporte y el cliente o clientes cuando se presente
algún incidente en el ERP. Por ejemplo la caída modular de una página web para captura
de pedidos, no puedo recibir pagos por internet, el sistema no responde, etc ; los SLAs
establecen los tipos de tickets (1, 2, 3 o alguna clasificación similar que indica la prioridad)
asociados a tiempos de respuestas máximos en su resolución. Un SLA es para mi la
formalidad para establecer en blanco y negro las responsabilidades y condiciones entre la
unidad de soporte y sus clientes. También, es una ayuda para el área de soporte al
establecer un marco de referencia y comunicación con los clientes para tener claras las
condiciones de cómo se va a solucionar la problemática de un incidente.
Habilidades del equipo de soporte limitadas: Dentro de Este informe se desarrollarán las
estrategias que seguí para el desarrollo y crecimiento del equipo de soporte. Aquí entran
diversas habilidades dentro de las que destacan:
o Comunicación: ya sea en español o en inglés, para primeramente entender los
incidentes y requerimientos.
o Calidad en las pruebas unitarias: es imperativo evitar los re-trabajos extensos
o Habilidades técnicas para cubrir el espectro completo de necesidades, y así evitar
segregación de recursos; el objetivo es que cualquier recurso pueda resolver
cualquier tipo de incidente tanto para aplicaciones back-end, como front-end. Se
detallará este tema con mayor profundidad durante los temas de “pantalla verde” y
“Web” en los subtemas subsecuentes.
o Actitud de servicio orientada a clientes finales: establecer preguntas básicas tales
como ¿a quien le afecta si me equivoco? ¿Que puedo hacer para mejorar la calidad
8
en mi trabajo? ¿Estoy haciendo todo lo posible para hacer intuitivas mis soluciones?
Etc.
o Necesitamos un área de Administración de Proyectos (Project Management Office
– PMO); en la actualidad es desde mi punto de vista indispensable un área de
administración de proyectos interno, se necesitan segregar funciones y establecer
claras estrategias para manejos de nuevos requerimientos, o bien estrategias para
desarrollar y precipitar la generación de nuevos requerimientos.
Desarrollar la confianza de nuestros clientes externos e internos: Más adelante en este
informe detallaré la importancia de conocer a nuestros clientes internos y externos. El
objetivo principal en esta área de oportunidad es el desarrollar una estrategia para obtener
la confianza de todos y cada uno de los entregables ya sean incidentes o nuevos
requerimientos y ser el proveedor número 1 de nuestros clientes internos y externos para
así evitar la búsqueda de soluciones a través de proveedores terceros hasta donde la
dinámica de la unidad de soporte lo permita.
Generar nuevos proyectos: Más adelante encontraremos un subtema de cómo ganar
proyectos, que en esencia consolida diversas área de oportunidad ya planteadas.
Manejo de proveedores: Es indispensable desarrollar a los proveedores del área de soporte
como socios de negocio para lograr mayores eficiencias en diferentes aspectos, desde el
principal, el recurso humano, hasta el costo y estrategias de desarrollo de habilidades
técnicas.
También encontré otras áreas de oportunidad por ejemplo en manejo de presupuesto, en
administración de áreas de trabajo, y otros temas de menor impacto que por cuestiones de espacio
en este informe no podré cubrir.
Estoy convencido que cada área de soporte en el mundo real podría coincidir o no con las áreas de
oportunidad antes mencionadas, por lo que no es mi intención en este informe de asentar un marco
de soporte rígido, sino por el contrario, necesitamos dar soluciones flexibles y que se puedan adaptar
a la dinámica de las compañías en el mundo real recordando que en todo momento hay cambios,
que en muchas compañías la única constante es el cambio, por lo que es necesario desarrollar toda
la flexibilidad emocional, de estrategias en procesos, en manejo de proyectos, de recursos y otros
aspectos que considero básicos y que detallaré en este informe.
9
2.2 Sistema Comercial ERP
Contexto General de un ERP
ERP, Enterprise Resource Planning, por sus siglas en inglés, está definido como la habilidad de
entregar un conjunto de aplicaciones de negocio. Las herramientas ERP comparten un proceso en
común y un modelo de datos, cubriendo amplia y profundamente procesos de principio a fin (end-to-
end), tales como los que se encuentran en Finanzas, Recursos Humanos, Distribución, Manufactura,
Servicio y Cadenas de Suministro.
Aplicaciones ERP automatizan y dan soporte a una amplia gama de procesos de negocio operativos
y administrativos a lo largo de diferentes tipos de industrias, incluyendo líneas de negocio, contacto
al cliente, administrativas, y la administración de activos de una empresa.
Las implementaciones de ERP tienden a representar un alto costo, y los beneficios del negocio son
comúnmente difíciles de justificar y entender.
Se busca por beneficios de negocios en cuatro áreas:
Ahorros en costos de Tecnologías de Información (IT)
Eficiencia en procesos de negocio
Estandarización de la plataforma de procesos de negocio
Catalizador de innovación en el negocio
La mayoría de las empresas se enfocan en las dos primeras áreas, ya que son las más fáciles de
cuantificar; sin embargo, las últimas dos áreas comúnmente tienen el mayor impacto en el negocio.
2.3 ERP en JAFRA, Hardware y Software
El sistema comercial en JAFRA -objetivo de este capítulo- se desarrolló en casa para el mercado
mexicano. Estuvo basado inicialmente en una arquitectura de hardware de servidores IBM AS-400,
a través de sesiones de emulación tipo Client Access, en donde los usuarios podían hacer uso de
las aplicaciones con una interfaz de usuario tipo “Pantallas Verdes”.
Dicho sistema fue desarrollado a lo largo de aproximadamente 30 años.
Este sistema comercial en sus etapas tempranas proporcionaba todo el soporte necesario para todas
las áreas del negocio internas y abarcaba a todo el ciclo comercial, desde el registro y mantenimiento
de las consultoras, la captura de pedidos, facturación, crédito y cobranza, y procesos de comisiones,
hasta el envío del producto a las casas de las consultoras.
Desde el punto de vista de TI, fue un traje completamente hecho a la medida y necesidades que
fueron evolucionando a la par del modelo de negocio que se desarrolló en México desde los inicios
de JAFRA en México. De ahí su periodo de antigüedad y mejoras continuas durante más de 30 años.
Durante la década de los 90’s, JAFRA México tuvo la primer oportunidad de establecer un modelo
de soporte de TI Global. Gracias a esto y a la apertura de nuevos mercados en Europa, se logró la
10
implementación de una versión especial con ambiciones globales. El sistema se pudo implementar
satisfactoriamente durante esa década en JAFRA Alemania, desde donde se daba soporte al
mercado Europeo para JAFRA.
El sistema comercial de JAFRA México y el de Alemania siguieron caminos diferentes; JAFRA USA
tenía su propio sistema comercial basado en una solución local. Esta realidad me da la oportunidad
de hacer mención de uno de los retos más grandes que se tienen durante el desarrollo de cualquier
aplicación de alcance global, mismo que detallaré en una sección especial de este informe. Tener
más de una versión de la misma aplicación representa por sí misma dolores de cabeza en todos los
ámbitos del soporte que se puedan considerar.
En el año 2007 por cuestiones presupuestales y ahorros significativos, se hace una nueva
implementación para USA, basado en el sistema comercial de México, retirando el sistema comercial
basado en JD Edwards, mientras que la versión de Alemania no pudo ser actualizada desde su
implementación en la década de los 90’s.
A la implementación de USA, le siguieron implementaciones en Suiza, Rusia y Brazil.
Y es así, como en el año 2013 recibo la oportunidad y gran responsabilidad con funciones de
dirección para dar el soporte a un sistema comercial global, con diferentes versiones implementadas
en las diferentes localidades antes mencionadas.
Cabe aclarar que el soporte al sistema mexicano ha sido realizado por un equipo completamente
dedicado a ello, por lo que no entró dentro de mi ámbito de soporte y por consiguiente no forma parte
dentro de este informe.
El soporte se realizó inicialmente con un equipo de trabajo que recibí de aproximadamente 7-8
personas, incluyéndome, pero que gracias al gran trabajo mexicano se pudo expandir a lo largo de
3 años creciendo a un equipo de 40-45 personas, entre desarrolladores, analistas de sistemas y
líderes de proyecto, Project Managers y soporte a proyecto.
11
Hardware
La arquitectura como antes se ha mencionado estaba basada inicialmente en equipos IBM AS-400,
mismos que han seguido evolucionando hasta lo que hoy se conoce como equipos IBM iSeries.
Formalidades del AS/400 y equipos iSeries
En 1988, IBM introduce en Junio al mercado el IBM Application System /400, una nueva familia de
computadoras easy-to-use (“fácil de usar”) diseñada para empresas de tamaño pequeñas e
intermedias. Como parte de la introducción, IBM e IBM Socios de Negocios global anunciaron más
de 1,000 paquetes de software en el más grande anuncio de aplicaciones liberadas simultáneamente
en la historia de la computación.
El AS/400 número 400,000 fue presentado en Octubre 9 de 1996 en Rochester, Minesota a Greg
Lemond, 3 veces ganador del tour de France, un emprendedor de pequeños negocios. Rápidamente
se convirtió en uno de los sistemas más populares a nivel mundial en sistemas computacionales de
negocios.
La familia AS/400 fue reemplazada en el año 2000 por el IBM eServer iSeries – Alto rendimiento,
servidores de negocio integrados para compañías de tamaño mediano.
El contenido de este subtema se extrajo y sintetizó del link:
https://www.ibm.com/ibm/history/documents/pdf/as400.pdf 6 Diciembre 2018.
En el mundo real
La plataforma IBM AS-400 ha sido la más estable que he conocido durante mi carrera profesional;
puedo dar fe que su poder de procesamiento es extremadamente confiable y muy superior a muchos
otros esquemas de hardware durante su época de apogeo. Aún hoy en día continía siendo uno de
los pilares principales en la capacidad de procesamiento de pedidos y tareas del día a día del
mercado mexicano en JAFRA.
La arquitectura de este servidor inicialmente era utilizado para procesamientos en bloque o batch;
su capacidad fue extraordinaria en comparación que muchas soluciones en el mercado paralelas.
Su esquema de seguridad, sistema operativo y sistema de base de datos han sido de los más
robustos que con el que he tenido experiencia y oportunidad de trabajar; su confiabilidad y soporte
por parte de IBM era extremadamente buena.
El AS/400 en etapas muy tempranas tuvo una gran aceptación a nivel mundial. Durante la década
de los 90’s ver y trabajar con pantallas de emulación “Verdes”, era lo más avanzado que existía en
su época. Esa simplicidad en la interface de usuario ayudaba extraordinariamente en el consumo
mínimo de recursos mismos que eran realmente utilizados en explotar su gran fortaleza para el
procesamiento de millones de registros en segundos.
Desafortunadamente vivimos en un mundo de percepciones; en ocasiones una percepción lo puede
ser todo, y puede influir gravemente en una toma de decisión ejecutiva. Con el paso de los años, las
pantallas “Verdes” podían envejecer no tan sanamente, mientras a la par había sistemas comerciales
gráficos de la competencia, con uso de mouse, ventanas, interactivos, que si bien daban la
12
percepción de ser un sistema “moderno”, se quedaban muy cortos en cuanto a capacidades de
procesamiento en bloque-batch. Aquí uno de los grandes debates de todos los tiempos en el mundo
de empresas usando AS/400s: pantallas “verdes” eficientes con un alto poder de procesamiento vs
pantallas gráficas “bonitas” y procesamiento limitado.
La batalla por sí misma fue muy difícil de justificar para las pantallas “Verdes” en JAFRA.
Con el paso de los años, y con el cambio de milenio el boom del internet en México era ya inminente,
por lo cual IBM ya tenía avances importantes en cuanto a una vista gráfica para hacerla más
amigable a la vista del usuario y combatir el tema de las percepciones de modernidad.
Este punto dio paso a una oportunidad de negocio para el desarrollo de aplicaciones WEB basadas
en el sistema AS/400, en donde el sistema mismo fungía además de ser un servidor de aplicaciones
y de base de datos como, un servidor WEB, en donde se podían desarrollar aplicaciones con acceso
directo a la base de datos. Este último punto se tratará en sección posterior sobre el Software.
En un AS/400, así como en cualquier hardware que se utiliza para un sistema comercial, siempre
está la batalla principalmente por los recursos de memoria, procesamiento y almacenamiento. Esto
a nivel de hardware representaba un reto en la configuración y monitoreo del equipo mismo.
Dependiendo de la dinámica de los negocios en dónde se utilizaban AS/400, existían retos como en
JAFRA, en donde el pico de ventas y uso de recursos (memoria, procesamiento y almacenamiento)
era altísimo durante los cierres de mes comerciales. Una vez implementada la WEB para captura de
pedidos en JAFRA, esto agregó una variable que incluso hasta hoy en día requiere de una
planeación detallada de los recursos.
Durante la etapa de implementaciones del sistema comercial en USA, Suiza, Rusia, Alemania, Italia,
Brasil se contaban ya con equipos IBM iSeries, mismos que permitían el manejo de particiones en
un solo equipo muy grande, en donde se podían asignar recursos por cada partición. Para el equipo
de soporte, y desarrolladores, era prácticamente un “equipo virtual” dedicado por mercado-país.
Las telecomunicaciones en México, por su naturaleza, condiciones geográficas y diversos factores
externos, siempre han representado un reto. Los equipos de forma inicial se encontraban sirviendo
desde México en las instalaciones más modernas posibles.
Hay una frase muy conocida en TI, “los fierros” no tienen palabra. Y aún cuando en muchos casos
esta frase es una realidad, durante casi 16 años que tuve contacto más directo con el soporte,
incluida esta etapa de soporte internacional, las fallas por hardware en realidad fueron mínimas. Las
áreas de oportunidad más comunes se encontraban con mayor frecuencia en las telecomunicaciones
y en alguna compilación o liberación de objetos productivos.
Aun cuando mi responsabilidad directa no era el hardware como tal, compartía 100% la
responsabilidad del mismo, ya que cuando una consultora no podía hacer un pago o capturar un
pedido, así como sucedería con cualquier cliente en cualquier empresa, no importaba realmente si
el problema es hardware, software o los dos, el problema simplemente se tiene que solucionar a la
brevedad posible.
13
Software
Antes de entrar en materia, es muy importante mencionar fortalezas importantes derivadas del
hardware y arquitectura del sistema AS/400- iSeries que formaran parte del tema de software:
Sistema Operativo: OS-400
Sistema de base de datos: DB2-400
Compiladores varios: C, RPG
Lenguajes/Scripts de programación gráficos: Java Script, XML
Seguridad: inmersa en OS-400
Como lenguaje de programación base se utilizó el RPG, Report Program Generator por sus siglas
en inglés, mismo que tuvo diversas evoluciones como RPG II, RPG III, RPG IV hasta la última versión
que conocí RPGLE o RPG ILE.
RPG es un lenguaje de programación muy antiguo, creado desde el año 1959, y utilizado sistemas
IBM de la época incluidos los sistemas de tarjetas perforadas, pasando por sistemas 3, 32, 34, 36,
38, AS/400, iSeries. En todas y cada una de sus etapas ha ido evolucionando significativamente.
Desde un punto de vista didáctico, RPG en su base es un lenguaje de programación más que como
todo lenguaje utiliza definiciones de arreglos, apertura de archivos, y ciclos condicionados,
condiciones básicas y todo lo que se puede ver desde lenguajes como Basic y C -Por lo que las
bases expuestas por los profesores de la UPIICSA formaron una base indispensable para un
entendimiento y uso sano del mismo, claro, todo lenguaje tendrá siempre sus peculiaridades y trucos
que se aprenden como parte de la práctica y comunidades de desarrolladores alrededor del mundo.
Una fuerte recomendación aprovechando este tema, es jamás limitarse en el aprendizaje. Si bien mi
función cuando me uní a JAFRA jamás me dictó ser un desarrollador de RPG, mi naturaleza curiosa,
y el programador que siempre llevo en el corazón, me condujeron a ponerme como reto -y superarlo-
aprender a desarrollar aplicativos inicialmente para pantallas “verdes”, y posteriormente abrir puertas
y desarrollar los primeros prototipos de interfaces gráficas WEB utilizando RPG y una gama de
librerías (CGI – Common Gateway interface) que permitían su exposición al gran mundo de internet.
Los desarrollos WEB hacían amplio uso de otros lenguajes-scripts tales como Java Script, XML, y
herramientas adicionales gráficas para desarrollo de hojas de estilo, botones gráficos, etc.
Recordando que mis funciones iniciales en JAFRA fueron las de liderar proyectos WEB, yo me
autoasignaba tareas de programación a la par de mi equipo de desarrollo como líder de proyecto
para continuar aprendiendo, y además tener una ventaja competitiva dentro de mis pares líderes de
proyecto de otras áreas, ya que además de coordinar los proyectos tenía el conocimiento de cómo
hacerlo. Eso facilitó enormemente la medición de tiempos de desarrollo más exactos, para esto
proyectarlo en expectativas de entregables para los usuarios y todos los beneficios derivados de ello.
Con funciones gerenciales y de dirección futuras, como lo es el motivo de este informe, dichas bases
fueron igualmente fundamentales, porque facilitaban grandemente mis funciones y en otros niveles,
me daban el poder sano del conocimiento que me permitió permear y coordinar el conocimiento a
nuevas generaciones y poder entregar soluciones a nivel mundial durante las etapas de desarrollo.
Adicional a RPG, también tuve oportunidad de implementar los conocimientos adquiridos en
UPIICSA del lenguaje de programación C; Durante la implementación del sistema comercial para
14
USA, se dio la necesidad de implementar la solución para el cálculo de impuestos, que dicho sea de
paso es muy complejo, ya que requiere la combinación de Código Postal, Condado, Ciudad para que
de una forma muy exacta se determine el % de impuesto a cargar. Pues bien, uno de los retos de
integración más fuerte fue con el software de impuestos, aun cuando corría en plataforma AS/400,
su integración con programas RPG para pantallas verdes y WEB no era natural. Demandó el
desarrollo de un programa en lenguaje C para poder hacer la interface dentro de un programa RPG.
Este desarrollo orgullosamente fue mío, ya en etapas gerenciales dentro de mis funciones en JAFRA,
nunca pudimos encontrar un desarrollador C para AS/400 dada la urgencia y necesidad del negocio.
No fue una tarea trivial y dediqué un numero importante de horas a la investigación y puesta a punto
de la solución ya que de ello dependía el visto bueno de una parte medular del sistema comercial.
Los conceptos teóricos de RPG en este subtema fueron sintetizados del link:
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/rzahg/rzahgrpgcode.htm
6 Diciembre 2018.
15
2.4 Portafolio de Aplicaciones
Dentro del portafolio de aplicaciones, se tenían básicamente 2 clasificaciones importantes, las de
uso interno y la gama de opciones para la WEB y el uso de las consultoras JAFRA.
Aplicaciones de uso Interno
Aquí destacaban las siguiente aplicaciones de forma general:
Consultas sobre datos de Consultoras JAFRA: Todos los datos generales de consultoras
Registro de nuevas Consultoras: La creación de un nuevo registro que se incorpora al
programa JAFRA, incluyendo esquemas promocionales iniciales, asignación de
patrocinadora, animadora, ambos conceptos clave para el proceso de comisiones.
Estado de Cuenta: Todo el historial de transacciones de una consultora en particular, donde
se podían ver el saldo, detalle de pagos, pedidos, promociones, y prácticamente ligas a cada
una de las funciones de una consultora dentro del ciclo de negocio.
Captura de Pedidos: Captura de pedidos indicando clave de producto, cantidad, indicando
promociones alcanzadas, incluyendo ajuste de precios
Historial de Pedidos: Aún cuando el estado de cuenta daba esta información, el aplicativo
estaba dedicado a un historial específico de pedidos de una forma más amigable.
Servicio a Cliente: Registro y atención de necesidades del cliente, incluyendo devoluciones,
cambios y toda la gama de necesidades para la atención adecuada de las consultoras
durante sus visitas a las oficinas o bien en llamadas telefónicas.
Cálculo de Comisiones: Parte medular del programa JAFRA. Todo el esquema de
comisiones se definía, parametrizaba y calculaba en esta aplicación.
Promociones de Producto: Configuración de promociones asociadas al producto. Por
ejemplo, en la compra de A, te regalo B, o en la compra de C te hago un descuento de X%,
y muchas variables derivadas de estrategias de Marketing.
Promociones de Programa: Configuración de promociones asociadas al programa JAFRA,
por ejemplo, por X número de nuevos ingresos en el mes, tienes un % de comisión adicional,
y n variantes específicas en el programa JAFRA por mercado-país.
Facturación: Configuración y ejecución para facturación de pedidos, de acuerdo a las
necesidades de distribución por mercado-país. Por ejemplo, por zona geográfica, etc.
Pagos: Todo lo asociado a la recepción de pagos, interfaces con Bancos, Tarjetas de
Crédito, etc.
Crédito y Cobranza: De acuerdo a cada mercado-país, se definía si había un esquema de
crédito y las reglas de negocio asociadas. En su caso se gestionaba la cobranza igualmente
siguiendo reglas del negocio específicas.
Distribución: Generalmente un módulo de interfaces para software terceros de aplicaciones
en almacén.
Reportes varios: Una gama extensa de reportes en su mayoría desarrollados a la medida
de acuerdo a las necesidades de cada área usuaria interna, o bien de regulación
gubernamental, etc.
16
Aplicaciones WEB
El gran reto de esta gama de aplicaciones era brindar soluciones a la medida con un enfoque intuitivo,
buscando llegar a la facilidad en el uso de cualquier generación y status social y educativo de
nuestras consultoras.
Así bien, esta gama de aplicaciones estaba enfocada a facilitar y dar seguimiento del negocio de
cada una de las consultoras:
Nuevos Ingresos al programa JAFRA: El objetivo era permitir el ingreso de nuevas
consultoras a través de una interfaz WEB. En algunos mercados-países, se configuró la
captura del primer pedido, con el objetivo es que la nueva consultora pudiera a partir de ese
momento capturar pedidos.
Captura de Pedidos WEB: Una de las aplicaciones con mayor demanda, principalmente en
etapas promocionales y con un gran pico durante el cierre de mes comercial.
Seguimiento-Consulta de Pedidos WEB: Todo el seguimiento de los pedidos, status,
información de rastreo de la caja, etc.
Pagos WEB: Toda el seguimiento de los pagos realizados, así como de acuerdo al mercado-
país captura de pagos con tarjeta de crédito.
Reportes sobre el programa JAFRA: Una amplia gama de reportes con el objetivo de permitir
el sano seguimiento de cada consultora, así como de sus grupos directos e indirectos. Estos
reportes son clave durante etapas promocionales y principalmente cercano al cierre de mes,
para poder cubrir con las bases promocionales.
17
2.5 Soporte de ERPs globales y su complejidad
Los ERP globales requieren de características específicas desde su arquitectura y la base en el
diseño, no así como parches o mejoras a las mismas.
Algunas características básicas e indispensables:
Alto grado de Procesos de Negocio estandarizados
Multi País
Multi Compañía
Multi Moneda
Multi Lenguaje
Multi horario
Modular y configurable en procesos críticos
Arquitectura de Hardware, Telecomunicaciones y capacidad de procesamiento robusta
Base de datos robusta
Los costos de mantenimiento, de hardware y de operación, entre otros, así como los tiempos de
implementación son muy altos cuando no se ha diseñado una aplicación considerando al menos
todos estos puntos.
Hay algunas compañías transnacionales que durante la década de los 80’s, 90’s apostaron por el
diseño y construcción de aplicaciones globales in-house, dedicando equipos internos de IT para
desarrollo de aplicaciones e infraestructura. En la mayoría de los casos derivado de la falta en el
mercado de una solución que cubriera las necesidades de negocio. El sueño de cualquier compañía
transnacional es tener un ERP que le permita la apertura de nuevos mercados a corto plazo, con el
menor costo de hardware y software posible y la menor inversión posible.
Algunas compañías de software identificaron esta necesidad y fue entonces que el desarrollo de
grandes ERPs surgieron con el pasar del tiempo. Por ejemplo SAP, JD Edwards, IBM por citar
algunos.
En este ramo de compañías que utilizan esquemas de comisiones de venta, de 2, 3 o N niveles, hay
algunos procesos clave, tales como los esquemas promocionales, ya sea de producto o de programa
(incentivos) y cálculo de pago de comisiones, que por si mismos representan una complejidad muy
alta en sus procesos, y que al ser el corazón del negocio pueden dictar entonces la estrategia de
hacer un desarrollo in-house para poder cubrir con dichas necesidades. Hoy por hoy, en este
segmento comercial por ejemplo no hay ningún software ERP, Módulo, o similar, que cubra con las
necesidades, incluyendo volúmenes de procesamiento, para el cálculo de comisiones en JAFRA.
Como en el ejemplo anterior, en diversos sectores comerciales hay procesos que hacen único al
negocio y que siempre representarán los retos más importantes durante una implementación de ERP
externo, ya que en la mayoría de los casos requerirá de un desarrollo nuevo en una plataforma
nueva, con todas las complejidades y retos que representa.
18
2.6 Alto grado de procesos estandarizados
Desde mi punto de vista y experiencia profesional es el más importante de todas las características
antes citadas.
Es muy común que las compañías vean a sus áreas de TI como las todólogas y solucionadoras de
todos sus problemas, bajo la percepción de que el sistema DEBE de arreglar los problemas de
negocio. Cuando en realidad, desde mi punto de vista, DEBERIA de ser el negocio quien dicte los
requerimientos idealmente a través de un área interna de transformación del negocio para que
entonces con ayuda de herramientas en TI, se puedan materializar dichas necesidades.
Un ERP global, implica por si mismo una necesidad fundamental de hacer negocios en diferentes
países, culturas de trabajo, usos horarios diferentes, etc.
Aquí se abre una puerta muy interesante de modelos de negocio, y citaré como ejemplo el sector
comercial de ventas multinivel.
Mi modelo de negocio de ventas no funcionará igual en un país desarrollado (USA, Alemania, Suiza,
Italia, etc.) que en un país emergente-en vías de desarrollo (México, Brasil, Indonesia, etc.), ya que
hay un principio fundamental en el negocio: ¿qué lo mueve?.
Mientras que en un país emergente, la necesidad de un trabajo, ya sea fijo o alternativo, por horas
en el día, a uno existente es indispensable, porque de ello dependen necesidades básicas como
comida, casa, escuela, etc., en un país desarrollado, en realidad están cubriendo en su gran mayoría
necesidades secundarias, por ejemplo, terminar de pagar un auto, terminar de pagar una segunda
casa, etc.
Y de esto se derivan modificaciones particulares por ejemplo en todos los procesos de promociones
y pagos de comisiones. Por la naturaleza del mercado no se puede estandarizar el proceso
asumiendo que desde un punto de vista de economía todos los países pueden ser tratados
igualmente.
En contraparte, hay otros procesos que requerirán de un menor grado de “configuración”, y muchos
otros que podrían considerarse estándar.
En un mundo ideal cualquier ERP Global debería de tener cuando menos el 80% de procesos de
negocio estandarizados y cuando más un 20% de procesos a la medida.
Por las razones antes expuestas, en algunos sectores comerciales es imposible administrarlas como
franquicias. Y aún en las franquicias, siempre habrá, aunque mínimo, algún ajuste para apegarse a
reglas gubernamentales, como el cálculo de impuestos.
19
2.7 Complejidad en el soporte
La complejidad del soporte en sistemas globales, reside y será proporcional en la medida en que
todas las características indispensables de un ERP global se hayan cumplido o no.
Citaré algunos ejemplos prácticos:
Si por alguna razón algún aspecto de multi país, multi moneda, multi compañía, multi
lenguaje no fue considerado o parcialmente considerado, habrá un número importantes de
cambios a nivel de base de datos, re-compilación de programas, pruebas, puesta a punto,
ventanas de actualizaciones, etc.
Aún dentro de los procesos modulares críticos, dependiendo de la complejidad del cambio,
será necesario revisar que los cambios a las necesidades de negocio del país A no le afecten
al B, C, D, E, ……Idealmente se tendrían que coordinar y revisar los cambios, hacer planes
de trabajo extensos, idealmente dedicar un Project Manager a las tareas de coordinación
para definición de requerimientos, pruebas, puesta a punto, y ventanas de actualización.
En cuanto al hardware, y capacidades de procesamiento robustas, es crítico el monitoreo
constante de:
o Los niveles y uso de espacio en disco. Por cuestiones de crecimiento del negocio,
hacer planificación de respaldos de información, coordinar la cantidad de tiempo que
es necesario tener registros en línea.
o Los niveles y uso de procesamiento. Es muy común que haya algunos usuarios
haciendo actividades, o ejecutando una consulta complicada con un alto número de
registros que consuma el procesador en zonas del tiempo donde hay una alta
demanda de otros procesos críticos. Es indispensable contar con esquemas de
entrenamiento para nuevos usuarios o recordatorios amigables a usuarios expertos
para evitar el uso de procesamiento no deseado, o que quizá pueda ser ejecutado
en horarios no pico o incluso durante la noche. Es posible también que haya algún
error en algún programa que haya encontrado algún ciclo sin fin, que igualmente
requiera de una atención pronta para evitar el consumo desmesurado de
procesamiento.
o Telecomunicaciones. Quedan en completo control de los proveedores de dicho
servicio. En algunos casos suceden siniestros inesperados como terremotos,
inundaciones, etc. que puede dañar parcialmente los servicios; dependiendo de la
complejidad del problema y donde se encuentre el hardware y la conectividad a
dichos servicios se tendrá que actuar en consecuencia.
Adicionalmente a los puntos antes mencionados asociados a las características de un ERP global,
dentro de la complejidad en el soporte tenemos también otros factores y puntos a considerar muy
importantes:
Definición de SLAs (por sus siglas en inglés Service Level Agreement). Los SLA´s son
acuerdos formales del soporte entre la unidad de soporte y el cliente o clientes cuando se
presente algún incidente en el ERP. Por ejemplo la caída modular de una página web para
captura de pedidos, no puedo recibir pagos por internet, el sistema no responde, etc. Los
SLAs establecen los tipos de tickets (1, 2, 3 o alguna clasificación similar que indica la
prioridad) asociados a tiempos de respuestas máximos en su resolución. En el caso de
unidades de soporte externa, pueden incluso ligarse a temas contractuales y generar un
20
costo a la unidad de soporte por incumplimiento, etc. Los SLA´s típicamente incluyen
periodos de mantenimiento de las aplicaciones, temas legales gubernamentales, y diferentes
factores que es indispensable poner en blanco y negro para un constante cumplimiento de
los mismos.
Usos horarios: Es quizá el factor más importante de administrar desde el punto de vista del
recurso humano. Al considerar un soporte, por ejemplo, desde México a Europa, América
del Sur, Asia, Rusia, será necesario coordinar unidades de soporte con la disponibilidad
inmediata en los diferentes usos horarios para atender un incidente de categoría 1 y 2, ya
que por acuerdos en el SLA se tendrán que solucionar durante un periodo de tiempo mínimo,
habrá categorías 3 y 4, que podrán ser resueltos durante horarios de trabajo “normales”. En
algunas ocasiones dependiendo de la criticidad del incidente, será necesario hacer
movimientos de horarios completos, e incluso definir unidades de soporte nocturna para el
soporte de aplicaciones. Los equipos de infraestructura deberán de forma indispensable
tener un soporte formal 7 x 24.
El lenguaje. El idioma comúnmente utilizado es el lenguaje inglés por ser el de mayor uso
entre diferentes unidades de negocios de distintos países. Si tenemos, por ejemplo, el
soporte desde México a N localidades en el mundo, será INDISPENSABLE, que al menos
los dos primeros niveles de soporte sean bilingües: La persona que atiende la llamada o
recibe el email, la persona que analiza el problema y necesitará contactar el usuario para
recibir mayor información, dar seguimiento con el experto, y finalmente, comunicar
resultados idealmente positivos a los usuarios como respuesta.
Manejo de conflictos y estrés. Ambos puntos son características INDISPENSABLES, de al
menos los dos primeros niveles de soporte (mencionados en el punto anterior). Hay
situaciones muy críticas, que pueden llegar a representar la pérdida de millones de dólares
por cada minuto que una caída de sistema no pueda solucionarse, por lo que estos dos
puntos tienen que manejarse y ser parte de la personalidad del equipo de soporte.
21
2.8 Fortalezas y debilidades del equipo de trabajo
Cuando se recibe un equipo de soporte global, la primera tarea es conocer a todos y cada uno de
los miembros, sin importar las funciones. Esto puede incluir a personal aparentemente no
relacionado con el trabajo, como las asistentes de área.
A continuación listaré las preguntas más relevantes que utilicé en un caso práctico al recibir el área
de soporte global que utilicé como base para conocer el perfil del equipo:
A los analistas-desarrolladores:
o ¿Qué tarea o tareas estás realizando y para qué mercado-país?
o ¿Tienes claros los requerimientos? ¿Tienes alguna especificación a la mano?
o ¿Cómo realizas las pruebas unitarias de tu desarrollo?
o ¿Qué lenguajes de programación conoces?
o ¿Qué bases de datos conoces?
o ¿Cómo te sientes en la plataforma AS/400?
o ¿Cuáles son tus horarios de soporte fuera del horario “Oficial”?
o ¿Tienes alguna pregunta?
o ¿Cuentas con el equipo PC/laptop/software adecuado para desarrollar tus tareas?
o ¿Tienes alguna necesidad de capacitación?
A los líderes de proyecto:
o ¿Qué mercado-país estás soportando?
o ¿Cuántos incidentes tenemos abiertos?
o ¿Cuántos proyectos nuevos tenemos en ejecución y cuántos pendientes/abiertos?
o Regálame copia de tu reporte de KOIs (Key Operational Indicators) mensual de los
últimos 3 años?
o ¿Quién es tu contacto directo en el mercado-país? ¿Cómo es tu relación laboral y
personal con él/ella?
o ¿Qué metodología siguen para recabar requerimientos y como son documentados
para los analistas-desarrolladores?
o Platícame de tu experiencia en la plataforma AS/400.
o Platícame de tu experiencia dentro del sector de ventas multinivel.
o ¿Qué idiomas conoces?
o ¿Podemos tener una charla en inglés?
o ¿Cómo coordinas los horarios para el soporte de tu mercado-país?
o ¿Cuentas con las herramientas PC/Laptop y Software para desarrollar tus tareas?
o ¿Utilizamos alguna herramienta para el registro de incidentes? ¿Como funciona?
o ¿Tenemos SLAs (Service Level Agreements) para tu Mercado-país?
o ¿Tienes alguna necesidad de capacitación?
o ¿Tienes alguna pregunta?
Al personal de soporte técnico local:
o Platícame de las características de los equipos PC/Laptops que tienen asignado el
personal del área: versiones de sistemas operativos, memoria, procesador, etc.
o ¿Tenemos equipos de contingencia en caso de que alguna PC/laptop deje de
funcionar?
22
o Regálame un reporte básico del inventario PC/laptos, proyectores, en donde pueda
ver la antigüedad de los mismos y características. ¿Cual es la política de
actualización de equipos?
o ¿Todo el personal tiene asignado un lugar adecuado de trabajo?
Al personal de infraestructura del área:
o Regálame copia de la bitácora de respaldos de los equipos AS/400 por mercado-
país
o Regálame copia de tu calendario de mantenimientos por mercado-país.
o Regálame copia de tus SLA por mercado-país (Service Level agreement)
o ¿Quienes son los operadores o personal que atienden las llamadas para atender
incidentes de infraestructura? ¿Hablan inglés?
o ¿Cual es el procedimiento para la liberación de objetos-aplicaciones a producción?
Al asistente del área:
o Regálame un reporte con todos los proveedores corrientes.
o Regálame copias de los contratos de nuestros proveedores.
o ¿Hablas inglés? Podemos tener una conversación en inglés?
o Regálame un status de los pagos relacionados al edificio donde laboramos, agua,
luz, etc.
o ¿Tenemos algún contrato pendiente con algún proveedor?
o ¿Cómo está organizado el servicio de cafetería del área?
o ¿Cómo están tus relaciones profesional y laborales con las áreas de finanzas que
reciben nuestras facturas de proveedores?
En el mundo real, generalmente la mitad de estas preguntas serán contestadas y muchas otras
quedarán con respuestas parciales; algunas otras no tendrán respuestas, y todas y cada una de
ellas formará criterios y acciones a tomar dependiendo de la gravedad a corto, mediano o largo plazo.
Algunas de estas preguntas, estarán asociadas directamente al presupuesto del área. Por ejemplo
temas de capacitación, actualización de equipos y software, mismos que representan un reto que
seguramente no podrá ser subsanado a corto plazo.
Las primeras tareas una vez realizadas las entrevistas, estribarán en determinar que las personas
estén ubicadas en el lugar correcto, para la tarea correcta, y en caso contrario iniciar planes de
mediano a largo plazo para realizar algunos ajustes.
Durante las entrevistas también podríamos recibir retroalimentación sobre intereses personales y
profesionales que igualmente podrían derivar en áreas de oportunidades o reasignaciones de tareas.
Dentro de un esquema de soporte global, se tiene que definir al menos un líder de proyecto
responsable por mercado-país, asegurar que las herramientas para reportes de incidentes existan y
que el proceso alrededor de ellas sea lo más eficiente, tomando en cuenta que el esquema que
puede funcionar para X mercado-país, podría no funcionar para otros mercados; idealmente tendrá
que ser un proceso estándar, pero siempre hay que estar preparados para las excepciones; Se
tendrá que tener muy bien estudiados los proyectos corrientes y nuevos en cuanto a mejoras o
necesidades de negocio nuevas. Cada líder de proyecto deberá tener asignado el número necesario
de analistas-desarrolladores de acuerdo a las cargas de trabajo. En la gran mayoría de los casos,
es común que el equipo de soporte de X mercado-país no tenga los recursos humanos necesarios
23
lo cual obligue a jornadas de trabajo extensas, mismas que a corto plazo será complicado remediar,
y que dependerá en gran medida de las cargas de trabajo de otros mercados-país, o quizás puntos
en el tiempo con “tiempos muertos” que permitan el reacomodo de recursos para balancear las
cargas de trabajo.
Podría ser sorprendente, pero aún dentro de áreas de soporte global, no todo el personal que tiene
contacto directo con los clientes hablan inglés, siendo este uno de los puntos más importantes a
corregir tan pronto como sea posible. En la gran mayoría de los casos se tratará de personal experto
que tiene un alto conocimiento de las aplicaciones, de los procesos, pero que sin tener la herramienta
indispensable de la comunicación en inglés, estarían limitados y no podrían desarrollarse en todas
sus capacidades. Siendo un tema presupuestal, será indispensable que sea defendido a capa y
espada en la definición del nuevo presupuesto. En ocasiones habrá retos para lograr permear la
necesidad en quien aprueba el presupuesto, y de ser necesario deberá de ser escalado para su
aprobación. Aunque parezca increíble, muchos ejecutivos no ven como una necesidad esencial que
la comunicación sea lo más clara posible.
Será esencial también identificar proyectos nuevos. Siempre habrá proyectos clave de negocio que
abrirán puertas a nuevas posiciones, como Project Managers, Soporte a Proyectos, y establecer una
base para una oficina de proyectos (PMO – Project Management Office). Aún cuando la compañía
cuente formalmente con un área de PMO generalmente global, siempre hay necesidades
particulares que son mejormente resueltas con un área de PMO local que puede idealmente estar
en sincronía con PMO global.
Concluiré estableciendo que las debilidades deberán de ser siempre vistas como áreas de
oportunidad que tienen que ser valoradas y trabajadas de acuerdo a prioridades y presupuesto
asignado. En cuanto a las fortalezas, siempre se deberán de seguir desarrollando y llegar al siguiente
paso en cualquier ámbito; es necesario no caer en alguna zona de confort o presunción.
24
2.9 Conocer a tus clientes directos e indirectos
Podemos tener al mejor equipo técnico, las mejores herramientas de software, el mejor ERP del
mercado, pero sin conocer a nuestros clientes directos e indirectos nos puede llevar a caer en puntos
ciegos, situaciones de apatía o percepciones equivocadas de un requerimiento que pareciera no ser
importante. Todas nuestras labores cotidianas idealmente deberán de tener una razón de ser, un
porqué, más allá del sueldo. Conocer a tus clientes te llevará en general a darle un mejor sentido y
orientación a los esfuerzos y a hacer la diferencia con una actitud orientada al servicio.
Como clientes directos, siendo un área de soporte de global, estarían como primera instancia los
usuarios de determinado país-mercado: todos aquellos que identifiquen un problema en alguna
aplicación.
En un mundo globalizado, y en escenarios de soporte global remoto, es muy común que la
comunicación se de a través de la frialdad de un email o una llamada telefónica, sumándole cualquier
reto individual en el idioma. Hay situaciones y escenarios que no pueden ser trabajados a la
distancia, en especial para proyectos nuevos con requerimientos complejos, en donde siempre será
recomendado precipitar una visita y realizar sesiones de trabajo en conjunto; esto no solo ayudará
en el buen resultado del proyecto sino en una mejora sustancial en la moral de los involucrados.
Independientemente de tener proyectos nuevos o no, es también ideal ponerle una cara y entorno a
nuestros clientes con una visita física. Se pueden aprovechar revisiones de incidentes actuales,
alguna junta global, etc. Las visitas son temas de costos en algunos casos muy elevados, que
igualmente tendrían que soportarse y escalarse de ser necesario para que puedan ser defendidos
durante el presupuesto.
Parecería intrascendente mencionar que, sin importar el lugar en el mundo las personas como aquí
en México ríen, lloran, conviven, aman, y se desarrollan de una forma muy similar a nosotros. Claro,
tomando en cuenta las proporciones del caso, pero son al fin y al cabo seres humanos. Y en mi
experiencia, los mejores resultados de soporte y proyectos se han dado gracias a la “complicidad”
profesional entre equipos de trabajo multiculturales. Es en sí mismo una oportunidad de conocerse
como mexicano en el extranjero, donde aunque pareciera que no, en su gran mayoría nos reconocen
como gente muy trabajadora y responsable.
En cuanto a clientes indirectos, dependiendo del esquema organizacional de la compañía, el entorno,
etc, podemos estar hablando de consumidores finales. Es muy fácil perder el foco de para quien en
realidad estamos trabajando más allá de una cuestión monetaria.
Aprovecho aquí para compartir una experiencia real que viví en JAFRA. Como parte de la bienvenida
a la vida laboral en JAFRA, recursos humanos comparte experiencias de vida reales y casos de
éxito, señoras, por ejemplo. En México, con condiciones de vida que nos harían vibrar, casos de
violencia doméstica, machismos, y condiciones contra corriente de vida que gracias a una
oportunidad de negocio puede dar un giro de 180 grados. No sólo se trata de una oportunidad
económica de negocio sino de una oportunidad de crecimiento, ya que en algunos casos el nivel
educativo de las consultoras JAFRA no es el ideal, pero que gracias a sesiones de capacitación
exhaustivas, el seguimiento cercano, se logran transformar vidas, y los casos de éxito a través de
los años dan giros extraordinarios y muy positivos.
Lo anterior nos lleva sólo como un ejemplo, a pensar más allá de lo que una línea de código puede
implicar: Saber que si se nos cae el sistema y una consultora no puede colocar un pedido,
25
independientemente del beneficio económico para la compañía, se estaría afectando un entorno
familiar, así como en la falla de cualquier otro punto durante el ciclo comercial que impidiera la llegada
del producto o el pago de una comisión por las ventas. Esto con el paso del tiempo nos lleva a un
concepto de servicio donde en realidad nos importa y preocupa las consecuencias de cualquier
actividad en el negocio.
Y es así con este ejemplo como concluyo de la importancia de conocer a tu cliente, ya sea directo o
indirecto, que también formará parte de tus logros profesionales en mayor o menor medida.
26
2.10 Victorias a corto plazo “Quick Wins”
Existen escenarios de soporte donde puede parecer todo caótico y tener un panorama muy adverso.
Podríamos tener un escenario donde tengamos todo en contra y nada a favor, principalmente cuando
se reciben áreas de soporte que han quedado sin cabeza durante un tiempo significativo, o bien
donde las prácticas anteriores han llevado a una falta total en la confianza por parte de los clientes
derivada de una serie de malos resultados.
A estos escenarios adversos, generalmente también se sumarán la falta de recursos humanos, usos
horarios, etc, haciendo lo que se conoce como una “tormenta perfecta”. Bajo este escenario mi
recomendación será siempre identificar aquellas victorias / quick wins de corto o inmediato plazo.
En ocasiones hay puntos ciegos, pero en una revisión detallada de incidentes abiertos, o proyectos
pendientes, siempre habrá ciertas actividades o puntos que pueden marcar la diferencia en el
soporte, así como calmar los ánimos de los clientes, y permitirnos entrar a un punto de negociaciones
sanas, donde podemos poco a poco retomar la confianza perdida de nuestros clientes.
Algunos de estos puntos será tan fáciles de corregir en minutos o en pocas horas, y en cambio
pueden marcar la diferencia y cambiar la percepción del escenario adverso.
Por increíble que parezca, estos puntos con frecuencia se esconden dentro de un grupo de
actividades, en donde por “alguna razón” no se le dio la prioridad adecuada. Claro, no hay solución
mágica, así que se deberá de hacer el uso de la experiencia y de un equipo técnico experto que nos
permita rápidamente valorar los esfuerzos involucrados en la solución para poder entonces planearlo
y aplicarlo a la brevedad posible.
27
2.11 Necesitamos recursos calificados
En un área de soporte global, es indispensable contar con el recurso humano calificado para poder
resolver lo más eficientemente posible; No sólo se trata de hacerlo bien, sino de mejorar y reducir
los tiempos de espera asociados, por ejemplo los documentados en SLAs (Service Level
agreements).
En un caso práctico, al recibir el área de soporte global en JAFRA, identifiqué dos segmentos clave
de necesidad de recursos humanos. Los dos segmentos correspondían a capacidades técnicas para
resolver incidentes de las aplicaciones:
Aplicaciones “Verdes”
Aplicaciones “WEB”
Anteriormente mencioné que una aplicación verde dentro del AS-400 se trata exclusivamente de un
proceso o aplicación donde un usuario interactúa a través de una interfaz simple, generalmente
carente de ventanas, mouse, etc., mientras que una aplicación WEB, por si misma implica
interactividad, control de flujo, eventos, interfaz gráfica, soluciones intuitivas, etc.
Recordemos que en la plataforma de AS/400, ambas aplicaciones utilizan en su parte medular el
lenguaje de programación RPG ILE (mencionado anteriormente en el capítulo de “Software” de este
informe). Sin embargo, las aplicaciones WEB se tienen que combinar con otros lenguajes como Java
Script, uso de XML, habilidades gráficas, etc., formando así un perfil mucho más completo. En puntos
claros, un desarrollador WEB podía cumplir ambas funciones, soporte tanto a aplicaciones “Verdes”,
como a las “WEB”.
Cada área formalmente requiere de un perfil de programador diferente. Tradicionalmente el
desarrollo de aplicaciones “Verdes”, lleva muchos años en el mercado, y generalmente es soportado
a través de generaciones de programadores “Baby Boomer” vs las aplicaciones WEB que son por
excelencia dominada por generaciones X, pero principalmente por Milenials. Y a partir de aquí la
complejidad del caso.
Como resultado del análisis de fortalezas y debilidades cubiertas en un capítulo correspondiente,
identifiqué que un 70% de los analistas-programadores, eran verde, y un 30% WEB, lo cual nos
posicionaba como equipo de trabajo en un desbalance de entrada numérico, que combinado con el
grueso de requerimientos y su naturaleza se encontraban prácticamente invertidos, ya que tenia un
70% de requerimientos WEB y un 30% de requerimientos “Verdes”.
Por cuestiones de presupuesto y balanceo de cargas de trabajo, era imposible tener el nivel de
soporte adecuado para la cantidad de requerimientos en puerta.
El esquema de contratación de analistas-desarrolladores, por políticas de la compañía, dictaban que
tenían que ser personal externo a través de lo que se conocen como “Casas de Software”; Así que
mi primer tarea fue plantear el reto a las casas de software. Dada la naturaleza y tiempo de vida de
la plataforma AS-400, los recursos en si que desarrollan en RPG son muy escasos, así que no fue
posible encontrar más recursos, y en mucho menor medida estaban disponibles recursos AS-400
WEB, ya que son muy pocas las compañías que utilizan la metodología de desarrollo utilizada.
28
De aquí, partí con una estrategia, de ganar-ganar con las casas de software, y puse a concurso un
esquema de capacitación interna, ofreciendo la oportunidad a los programadores actuales de
desarrollar nuevas habilidades de programación WEB, y a la vez, formar una escuela de
desarrolladores WEB para las nuevas generaciones. Se negoció con los analistas-desarrolladores
para que dieran horas extras dedicadas a dicha capacitación, al igual que un pago adicional por parte
de la casa de software del recurso capacitador. El presupuesto corriente por analista-programador
nos dio un margen para poder implementar esta estrategia.
Cabe mencionar que los requerimientos corrientes y nuevos proyectos no se congelaron. Por el
contrario, los resultados del equipo de trabajo comenzaron a dar frutos, y la confianza de los clientes
aumentaba conforme los meses caminaban. Así que la necesidad incluía una proyección de recursos
importantes durante el ciclo presupuestal siguiente.
El resultado fue muy interesante y muy satisfactorio. En la mayoría de los casos se logró elevar el
nivel de conocimiento rompiendo el paradigma de algunos “Baby Boomer” donde su forma de trabajo
y de resolver un problema en particular, y de enseñarles programación orientada a eventos, fue todo
un reto con muy buenos resultados. En su contraparte, con la generación X y Milenials, se utilizó un
esquema tomando como sus fortalezas experiencias de desarrollo en WEB de cualquier otra
plataforma, y se les enseñó simplemente un lenguaje de programación nuevo: RPG ILE.
A través de esta estrategia, se logró consolidar y crecer un equipo de trabajo que nos diera la
dualidad de los dos segmentos. Nos dio mayor versatilidad, y los tiempos de desarrollo y ejecución
de proyectos se redujeron considerablemente.
Saliendo del caso práctico, hay muchas estrategias y movimientos presupuestales que con una
intención específica nos puede dar el resultado deseado para lograr tanto como nos sea posible
tener el personal calificado para la tarea en cuestión. Siempre es un incentivo humano incluir
esquemas de capacitación; y siempre es un deseo continuar desarrollando conocimientos,
especialmente de personal con perfil de TI. No hay límite en las generaciones, los Baby Boomer, X
y Milenials, pueden aprender y trabajar en perfecta armonía con la estrategia adecuada.
29
2.12 Escenario de soporte multi cultural.
El soporte multi cultural es uno de mis temas favoritos ya que es un aspecto que me hizo reflexionar
sobre el factor humano que trasciende fronteras y sobre muchos aspectos en el ámbito profesional
que culturas, y que es real y posible la convivencia en armonía de las mismas para lograr grandes
proyectos con excelentes resultados.
Antes de compartirles aspectos relevantes de algunos equipo de trabajo de otros países con quien
he tenido el privilegio de haber trabajado, considero muy importante primero hablar sobre nuestra
cultura mexicana en el ámbito personal y profesional; no es sorpresa para muchos que tenemos
algunas áreas de oportunidad pero también muchas fortalezas.
Sobre nuestras áreas de oportunidad identifico:
Se rompen más reglas de las que se debería: Desafortunadamente aún existe alguna
tendencia en buscar caminos cortos, rápidos, con poco análisis, que si bien pueden dar una
salida rápida, pudiera no ser la mejor de mediano a largo plazo, generando re-trabajos y
tomando a la larga mucho más tiempo del necesario.
En 5 minutos/en un ratito lo resuelvo: Los 5 minutos mexicanos son frecuentemente los más
largos que he encontrado en la resolución de una tarea, creo que tenemos que desarrollar
una mejor cultura de asertividad, en muchas situaciones se reconoce y aprecia una
respuesta honesta y atinada de lo que una tarea nos podría llevar.
Impuntualidad: Es desafortunado, pero una realidad que con mayor frecuencia que nos
gustaría, participantes de México llegan de tarde a muy tarde a citas de reuniones o llamadas
de trabajo; siempre habrá una excusa, y en ocasiones nuestro entorno en las grandes
ciudades nos expone a imponderables.
No nos movemos sin la autorización del “Jefe”: tenemos rasgos culturales, donde tenemos
plasmado en la genética temas ancestrales de “El gran jefe penacho emplumado”; hay
situaciones donde esta situación genera una burocracia impresionante ya que es difícil que
alguien tome la responsabilidad de tomar una decisión, ya que siempre se tiene que
consultar con “el jefe”; es importante reconocer las limitaciones que esto genera; SI, hay que
seguir las reglas, las políticas, pero también nos haría mejor como sociedad desarrollar un
mayor número de líderes que tengan el empoderamiento de tomas de decisión.
Dentro de nuestras fortalezas:
Compromiso y dedicación: Esta es una de las características más reconocidas a nivel
mundial. Si, hay que creerlo, cuando nos dedicamos realmente a una tarea, son increíbles
los resultados que podemos lograr; a veces nosotros mismos no sabemos de nuestra
capacidad real.
Trabajo bajo presión: Por cuestiones culturales, tenemos desarrollados factores que facilitan
el poder entregar resultados aún bajo presión y condiciones adversas.
Actitud de Servicio: Somos latinos, tenemos el trato amable y amigable en la sangre; en la
mayoría de los casos, somos muy cálidos, y le ponemos sentimiento a muchas situaciones
que nos ayudan a tener una mejor actitud de servicio
Es un orgullo compartirles, que un alto porcentaje de Mexicanos con los que he tenido oportunidad
de trabajar en el extranjero, están consientes de nuestras áreas de oportunidad, y hay esfuerzos
muy importantes para mitigarlos; es curioso, pero es como si una fuerza interna nos obligara a
30
demostrar que NO todos los Mexicanos tenemos dichos comportamientos y que podemos trabajar
de tu a tu con cualquier cultura y personalidad que nos encontremos.
Retomando el tema sobre aspectos relevantes en el ámbito profesional de equipos de trabajo de
otros países, les compartiré algunas de las características más relevantes que me ha dejado la
experiencia del trabajo con USA y Alemania;
USA:
Aún cuando formalmente hay un “Jefe”, no hay ninguna regla que impida a cualquier
subordinado de cualquier nivel, establecer un diálogo o cuestionar a cualquier gerente,
directos o inclusive altos ejecutivos de una empresa. Hay un diálogo abierto respetuoso y
muy profesional. Esto ayuda mucho, y abre muchas puertas a la colaboración entre todos
los niveles.
Hay una tendencia muy fuerte a trabajar y resolver un problema siguiendo los procedimientos
o metodologías establecidos, es muy difícil que se busquen caminos cortos. Esto lo percibo
como una fortaleza muy relevante que los lleva a tener resultados muy positivos.
Diálogo abierto y profesional para la discusión y resolución de un problema. Su nivel de
asertividad en la comunicación lo he percibido muy alto.
Grupos de trabajo muy sólidos.
Alemania:
Hay una cuadratura muy elevada en el seguimiento de sus procedimientos y metodologías
aún mayor a la vivida con equipos de USA, mientras un equipo en USA, pudiera
excepcionalmente buscar un camino corto, un equipo Alemán no lo hará.
No es nada sencillo ganarse la confianza de un equipo Alemán, sin embargo, dan
oportunidades, y si se demuestra la calidad del trabajo, el compromiso, habrá un grado de
confianza muy importante y una apertura de trabajo de igual a igual lo que lleva a resultados
extraordinarios.
Hay un reconocimiento del “Jefe”, pero también hay un empoderamiento y diálogo muy
abierto y directo para resolver un conflicto.
En ámbitos de trabajo, frecuentemente escucharán gritos, tonos fuertes y adjetivos muy
fríos sobre un resultado o situación; es muy importante saber que todo esto es estrictamente
profesional para ellos. Jamás van a mezclarlo con temas o situaciones personales, o
dirigidos a la persona en cuestión.
Equipos de trabajo altamente eficientes.
Todo acuerdo deberá de estar formalizado en blanco y negro.
He tenido la fortuna de haber trabajado también con Suiza, Italia, Rusia, Brasil, Indonesia, y sin entrar
a más detalles en lo particular con dichos países, lo más importante para mi aquí es compartirles
que al final del camino todos somos unos excelentes seres humanos, es muy importante que
entendamos que en todos los países hay seres humanos que ríen, gritan, lloran, se divierten, van a
fiestas, celebran tanto o más que nosotros; en realidad en el aspecto profesional que nos pueden
diferencias son las características que culturalmente marcan las diferencias, y que en su mayoría
sumadas y con la combinación de personalidades adecuadas, pueden dar resultados extraordinarios
en cualquier tipo de proyectos que se presenten.
El respeto a las culturas y formas de trabajo serán siempre esenciales para cualquier tarea o proyecto
en puerta, incluido por su puesto, el soporte de aplicaciones global.
31
2.13 Como ganar proyectos
Como ganar proyectos está dedicada a esa gran área de oportunidad en todo equipo de soporte,
donde se busca que los clientes directos vean como primer frente de solución de requerimientos
nuevos a un área que por su naturaleza debería de ser la de mayor experiencia y la que nos ayudaría
a implementarlos en un menor tiempo y costo.
El contexto de esta sección está situado en un caso práctico donde se recibe un equipo de soporte
con una dinámica de confianza muy limitada, donde básicamente se hacen los proyectos mínimos
indispensables y donde la confianza de los mercados es notoriamente baja.
El caso práctico planteado sobre el soporte global está rodeado así de muchas áreas de oportunidad
mencionadas con anterioridad, y que a partir de este punto serán identificadas como “pain points”
(puntos de dolor):
Incidentes varios sin una prioridad identificada;
Herramientas para seguimiento de incidentes inexistente
Falta de SLAs (Service Level Agreements)
Habilidades de recursos en dos o más grupos limitando la capacidad de resolución de
incidentes.
Comunicación con los mercados-países limitada a nula
Proyectos prácticamente inexistentes, sólo se solicitan tareas puramente de mantenimiento.
Durante diversas asignaturas de la carrera de informática en UPIICSA, se nos plantean casos y
problemas prácticos a solucionar, y aún cuando podría parecer muy trillada la solución planteada
académicamente, es toda una realidad en el mundo laboral que todo inicia con un análisis profundo
de la situación; es necesario hacer una pequeña pausa para saber en donde estamos, hacia dónde
queremos ir, con que herramientas contamos y que pasos tenemos que seguir para llegar a ese
punto.
Con este contexto, lo más importante hacia como ganar proyectos, está claramente enfocado a
primeramente estabilizar los “pain points” (puntos de dolor) de nuestra área de soporte. No se puede
pensar en tener y ganar más proyectos a través de la confianza de los clientes, si los objetivos
básicos del área que es tener un ERP estable y funcional no están cubiertos al 100%.
En mi experiencia la solución inicial y medular para ganar proyectos estriba en el desarrollo de la
confianza de los clientes, para lo cual no hay una fórmula mágica, pero que puede claramente iniciar
por sencillamente hacer las cosas bien y con la mayor calidad posible en tiempo y forma; es muy
importante aclarar que no puede haber soluciones unilaterales, entre proveedor de servicios, en este
caso de soporte y cliente, se tiene que también a la par desarrollar una complicidad, invitar a subirse
al barco de soporte a los clientes, para así tener un compromiso compartido durante todas y cada
una de las etapas iniciando por una correcta definición de la problemática, ayudar a identificar casos
de falla, colaborar en las pruebas de usuario previo a las pruebas unitarias, establecer las mejores
ventanas de tiempo de implementación y finalmente las pruebas en producción para certificar la
calidad del trabajo entregado.
Cuando yo tengo un área de soporte estable, implicará por definición que mis clientes saben que
tengo un alto grado de compromiso, que la calidad de todos los incidentes que se entregan es muy
alta, que la calidad de las pruebas y mecanismos de implementación fueron los adecuados, que
32
logré hacerlo sin interrumpir el ciclo de negocio o que lo hice al mínimo. Todos y cada uno de estos
puntos de forma natural harán que mi cliente me busque para realizar cualquier otro requerimiento
nuevo en lugar de buscar soluciones de terceros, por que hay ya un precedente de que se pueden
hacer las tareas correctamente en casa y de que será un esfuerzo con un menor costo y tiempo en
beneficio para la compañía.
33
2.14 Project Management (Administración de Proyectos)
Contexto General
Conceptos Generales
Mucho tiempo atrás antes de que fuera formalmente un instituto de Administración de Proyectos
(Institute for Project Management, también conocido como PMI), actualización de conocimiento de
libros o guías de cómo manejar proyectos, o incluso antes de la existencia de Gráficas de Gantt, la
historia nos ofrece de diversos ejemplos de proyectos colosales satisfactoriamente completados. Las
pirámides de Giza, La gran muralla de China, el Coliseo son buenos ejemplos de tales proyectos.
La administración de proyectos en sus cimientos más fundamentales, se preocupa de crear un
ambiente donde la gente puede trabajar en conjunto para alcanzar objetivos en común para así
entregar proyectos exitosos en tiempo y presupuesto.
A través de la historia de la humanidad, los seres humanos han estado trabajando en mejorar y
refinar las practicas de Administración de Proyectos.
La administración de proyectos se ha practicado desde que la humanidad ha poblado la tierra. Hay
muchos ejemplos en la historia de proyectos retadores que fueron satisfactoriamente completadas,
a pesar de las complejidades e incertidumbres que pudieron haber traído a la falla de dichos
proyectos. Muchos de estos proyectos necesitaron de una tremenda fuerza de trabajo, un alcance
largo, muchos años de trabajo, planeación avanzada y ejecución precisa. Lamentablemente, a pesar
de estos monumentales logros, existe muy poca documentación de los métodos y técnicas utilizadas.
No es hasta los años 1950s, que organizaciones iniciaron a aplicar sistemáticamente herramientas
y técnicas para proyectos complejos. Durante los años 1960s proyectos muy ambiciones como la
llegada del hombre a la luna ayuda a la formación y utilización de herramientas para manejar el
alcance de grandes proyectos. En los años 1970s el avance tecnológico hizo posible la creación de
software para la administración de proyectos, a través de compañías como Oracle. En los años
1980s las PC (Computadoras personales) fueron asequibles, consecuentemente compañías más
pequeñas iniciaron con el uso de computadoras para la administración de proyectos. En los años
1990s iniciaron notables herramientas para la administración de proyectos tales como PRINCE2 y
CCPM. A principios del nuevo milenio, iniciaron los esfuerzos académicos ofreciendo certificaciones
en administración de proyectos; más aún, teorías de administración de proyectos, herramientas, y
técnicas son ahora de las principales corrientes en muchas organizaciones e industrias.
No es claro el futuro que le depara a la administración de proyectos, sin embargo con los retos
actuales de globalización, reducción de recursos y el incremento de la población, no hay otro mejor
vehículo para la administración de tales problemas que no sea la Administración de Proyectos.
PRINCE2
PRINCE2 (acrónimo por sus siglas en inglés PRojects IN Controlled Environments), es un método
basado en proceso para una efectiva Administración de Proyectos. Utilizado ampliamente por el
gobierno Británico, PRINCE2 es ampliamente reconocido y utilizado en el sector privado, tanto en el
Reino Unido como internacionalmente. El método de PRINCE2 es del dominio público, y ofrece guías
de mejores prácticas, no propietarias, acerca de la Administración de Proyectos.
34
Características Principales de PRINCE2:
Enfocado en la justificación del negocio.
Organización estructurada definida para el equipo de Administración de Proyectos.
Enfoque de Planeación basada en productos.
Enfatiza en dividir el proyecto en fases manejables y controlables.
Flexibilidad que puede ser aplicada al nivel adecuado del proyecto.
PRINCE se estableció en 1989 por CCTA (the Central Computer and Telecomunicactions Agency),
desde entonces se renombró por OGC (the Office of Covernment Commerce). En Junio 2010, las
funciones de Office of Covernment Commerce Best Practice Management se movieron dentro la
oficina del gabinete.
PRINCE fue originalmente basado en PROMPT, un método para administración de proyectos creado
por Simpact Systems Ltd en 1975, y adoptado por CCTA en 1979 como el estándar a ser utilizado
en todos los proyectos de sistemas de información del gobierno.
Cuando PRINCE fue lanzado en 1989, efectivamente superó a PROMPT en los proyectos del
gobierno. PRINCE se mantiene del dominio público y los derechos de copyright los tiene la corona
del Reino Unido. PRINCE2 fue publicado en 1996, habiendo recibido contribuciones de un gripo de
150 organizaciones europeas.
El contenido de este subtema fue sintetizado de los links:
https://www.prince2.com/eur/what-is-prince2#prince2-history
https://www.prince2.com/eur/what-is-prince2#prince2-definition
6 Diciembre 2018.
En el mundo real
Profesionalmente es junto con la programación, la Administración de Proyectos (Project
Management) es una de mis dos grandes pasiones profesionales en Tecnologías de Información.
La administración de proyectos en realidad no es exclusiva de TI, por lo que la podemos encontrar
en grandes proyectos de muchos sectores profesionales en la actualidad y formalmente desde hace
ya varias décadas.
Dentro de las asignaturas formales en UPIICSA, no tuve oportunidad de tener una asignatura como
tal para la administración de proyectos, sin embargo, es sumamente interesante compartirles que la
formación de UPIICSA en realidad tiene todas las bases para un muy buen uso de las mejores
prácticas de administración de proyectos, dentro de las cuales destacan en mi punto de vista el
análisis y la estructuración de cualquier problema planteado que permite precisamente segregar un
problema en diferentes tareas, priorizarlas, secuenciarlas y ejecutarlas; de ahí que muchos Project
manager exitosos en la actualidad tienen su formación en un perfil orientado a Tecnologías de
Información; claro que también hay otras características clave que se pueden ir desarrollando con la
experiencia e implementación de proyectos siendo para mi punto de visto los más relevantes:
liderazgo, manejo de conflictos, comunicación, manejo de presupuesto, etc.
35
La administración de proyectos es muy extensa, dentro de mi carrera he tenido la fortuna de haber
implementado proyectos importantes para JAFRA siguiendo la metodología de PRINCE2, sobre la
cual algunos empleados clave tuvimos la fortuna de obtener una certificación.
Desde mi punto de vista PRINCE2, utiliza muchos principios básicos de PMI (Project Management
Institute), detallando una serie de principios mejor conocidos como mejores prácticas que ayudan y
facilitan la administración de proyectos con muy buenos resultados.
Cabe hacer notar, que dentro de toda las corrientes-metodologías para la Administración de
Proyectos, hay mucha teoría, hay muchas certificaciones, incluyendo aquellas como las de PMI que
requieren un esquema de puntuación variado que se tiene que renovar con cierta periodicidad, que
si bien dan todo el contexto general necesario, ya en la vida práctica de un proyecto es imposible ser
o pretender ser un purista de la metodología, ya que siempre habrá características y dinámicas de
las compañías que no permitirán su uso al 100%.
En base a la experiencia, en el caso de PRINCE2, estimo que en la mayoría de los proyectos se
puede implementar de un 70% a un 80% la metodología. Es altamente recomendado NO forzar la
metodología ya que esto puede llevar a un rechazo de la misma, una falta de credibilidad y por
consiguiente una pobre ejecución y resultados de un proyecto. Incluso el porcentaje puede variar de
proyecto a proyecto dentro de la misma compañía. El punto medular en su uso, desde mi punto de
vista, estriba sobre todas aquellas características que tiene mi proyecto en cuestión vs las mejores
prácticas recomendadas que le acomodan y se tienen los elementos para su correcto uso; adicional
a esto, es INDISPENSABLE tener el patrocinio de la compañía, desde un punto de vista de
credibilidad, y por consiguiente del reconocimiento de posiciones clave en la estructura
organizacional del proyecto, que no necesariamente sigue una estructura organizacional formal en
su organigrama.
Al final del camino, las metodologías para la Administración de Proyectos forman en si el uso de
mejores prácticas que tienen que ser aplicadas con un balance organizacional, y de las cuales la
compañía necesita estar convencida de los resultados, y tiene que haber un empuje desde los
niveles más altos en cualquier organización, de lo contrario se convierte en un intento más para
mejor la ejecución de los proyectos buscando la mejora de la ejecución en tiempo y presupuesto.
Se necesita una madurez organizacional para lo cual se recomienda un programa de entrenamiento
focalizado a posiciones claves que potencialmente podrían formar parte de la estructura
organizacional de cualquier proyecto futuro aunado a toda la base teórica principalmente de los
beneficios del uso de X o Y metodología.
El uso de una metodología en un mundo práctico dentro de cualquier organización, más aún, en
compañías transnacionales, es un reto muy complejo que puede estar tildado de perdida de tiempo,
de apatía, de falta de credibilidad, pero que en realidad tiene todo el potencial de convertirse en uno
de los pilares organizacionales que de forma incremental y real reducirían costos y aumentarían
eficiencias en la implementación de proyectos tanto en el sector público como privado.
36
2.15 Convivencia Generacional en Armonía
Contexto General
Existe una realidad documentada a partir de generaciones sociales a lo largo de las últimas décadas.
Si bien la intención de la documentación es indicar factores específicos de cada generación, es
importante considerar que en algunos casos la clasificación generacional podrá ser una mezcla
originada por diversos factores y escenarios familiares y profesionales.
Cabe hacer notar, que dentro de varias fuentes de información, se encuentran variaciones de 2-3
años en cuanto a los rangos de años en los que cada generación aplica.
Baby Boomers (Nacidos entre 1945 y 1964)
Nacidos post Segunda Guerra Mundial. El nombre de esta generación refiere al “Baby boom”,
identificado como un repunte en la tasa de natalidad de esos años.
El trabajo como modo de ser y de existir: estable, a largo plazo, adictivo, no necesariamente de lo
que aman hacer. No le dedican mucho tiempo al ocio y a la actividad recreativa.
Las mujeres de esta generación aún se están incorporando al mercado laboral. Si bien persiste el
ideal de familia tradicional, se empiezan a romper estructuras.
Generación X (nacidos entre 1965 y 1981)
Según un estudio de la Universidad de Michigan, los hombres y mujeres X trabajan mucho, pero
logran un equilibrio, son felices con sus propias vidas.
Son los que vieron el nacimiento del Internet y de los avances tecnológicos. Están marcados por
grandes cambios sociales.
Como son una generación en transición, se les llamó Generación Perdida e incluso Generación Peter
Pan – pueden hacer convivir equilibradamente la relación entre tecnología y vida social activa
“presencial”: tienen participación dentro de los eventos de su comunidad.
Son más propensos a estar empleados (aceptan las órdenes de jerarquía institucional) y equilibran
la energía entre el trabajo, los hijos y el tiempo de ocio.
Son los padres de los Millennials, hacen esfuerzos adaptativos a la vertiginosidad de la generación
que sigue.
Generación Y o Millennials (nacidos entre 1982 y 1994)
Muy adaptados a la tecnología. La vida virtual es una extensión de la vida real. Aunque conservan
algunos códigos de privacidad en relación a lo que exponen o no en Internet (a diferencia de los
Centennials, que comparten todo). Son Multitasking.
No dejan la vida en el trabajo, no son “workholic” (quizá observaron que sus padres sí lo fueron, y lo
hacen distinto).
Son emprendedores y creativos, intentan vivir de lo que aman hacer. Son idealistas.
Aficionados a la tecnología del entretenimiento: usuarios de las salas de chat de los 90s y ahora de
redes de citas. Pasaron por todo: SMS, Reproductor de CD, MP3, MP4, DVD.
Aman viajar, conocer el mundo, ¿y subir las fotos a las redes!
Según estudios, duran en sus trabajos un promedio de dos años, a diferencia de la generación X, y
los “baby boomers” (más estables). Es por eso que las empresas enloquecen armando políticas de
“fidelización”.
37
Generación Z o Centennials (nacidos a partir de 1995 y hasta el presente)
Son verdaderamente “nativos digitales” (desde su niñez usan internet)
Autodidactas (aprenden por tutoriales), creativos (incorporan rápido nuevos conocimientos y
relacionan bien) y sobreinformados (alta propensión al consumo de información y entretenimiento).
Visitan redes que sus padres no: un ejemplo es Snapchat. Comparten contenido de su vida privada,
aspiran a ser YouTubers. Su vida social pasa en un alto porcentaje por las redes.
Nada de la tecnología les es ajeno. Pasan mucho de su tiempo “frente a pantallas”. Estudios
recientes aseguran que están expuestos un promedio de cuatro veces más tiempo del recomendado
en dispositivos.
Su éxito se mide en “compartidos” y “likes”.
Según un estudio realizado por The Futures Company, son más pragmáticos que los Millenials,
buscan innovar con “lo que hay”.
No accedieron a la vida laboral todavía, pero se observa que les preocupa encontrar una vocación
acorde a sus gustos, conocerse a sí mismos y aceptar las diferencias, en un mundo cada vez más
globalizado.
La armonía
Les pido considerar el contexto general previo como un marco de referencia más allá de considerarlo
como un dato duro.
Como lo mencioné anteriormente hay diferentes factores que pueden jugar individualmente para
hacer una clasificación más precisa, y sobre esto les compartiré mi caso práctico.
Si bien mi ámbito familiar fue de padres “Baby Boomers”, mi ámbito profesional desde muy temprana
edad profesional fue repleta de “Baby Boomers”, por lo que de forma natural y sin el conocimiento
que hoy tenemos sobre las generaciones, yo adopté características laborales clave de dicha
generación y las adapté para hacerlas mías: tradicionalista, estructurado, aunque desarrolle una
mezcla me parece interesante entre rigidez y flexibilidad en conjunto con los rasgos más
trascendentales mi generación X.
Saliendo del caso práctico, podemos teorizar en abundancia sobre este tema tan interesante, sin
embargo, canalizaré mi experiencia profesional en compartirles que la armonía es completa y
totalmente posible; ha existido en diferentes ámbitos profesionales e industrias con resultados muy
exitosos. Considero que la clave del éxito estriba en mantener un balance en el análisis y
reconocimiento de competencias y estilos laborales individualmente, para potenciarlas y lograr la
combinación más adecuada para el trabajo o proyecto en cuestión, que puede variar entre
departamentos de área y aún de proyecto a proyecto.
Más allá de dictar una fórmula mágica entre las generaciones para tener la armonía, un aspecto
fundamental en el liderazgo es el reconocer que NO hay generaciones buenas o malas, o unas más
eficientes que las otras; es precisamente en la diversidad de generaciones que se encuentra la
riqueza más amplia en la ejecución de proyectos al retroalimentarse los miembros del equipo de
trabajo entre si con la ayuda del líder del equipo de trabajo fomentando el respeto mutuo y el
entendimiento a los diversos estilos laborales, ya que al tener muy claro todos estos aspectos de
forma individual resulta mucho más natural para la dinámica del equipo de trabajo caminar hacia
delante.
38
2.16 Manejo de Proveedores
El manejo de proveedores, es un tema fundamental en áreas de soporte, principalmente en todas
aquellas compañías donde haya políticas específicas para las áreas de TI que dicten que cierto perfil
de recursos humanos sea subcontratados por así convenir a los intereses de las compañías, para
principalmente evitar acumulación de antigüedad, manejar esquemas de beneficios laborales
diferentes, entre otros.
Hoy en día, inclusive, hay una tendencia muy interesante a donde grandes compañías se están
moviendo a esquemas en donde incluso áreas casi completas de TI incluyendo hardware, desarrollo
y soporte de aplicaciones están siendo subcontratadas a través de grandes contratos con compañías
de servicios varios de TI. En todos estos esquemas hay pros y contras, y generalmente se apuesta
por una estandarización de servicios a bajo costo (o en teoría así debería de ser) y una serie de
beneficios intangibles que abren la puerta a grandes proyectos de transición y transformación.
Este subtema, se tratará entonces, primeramente desde un punto de vista de proveedores como
áreas de soporte en TI, para posteriormente tocar detalles durante la etapa de transición a un
esquema completamente subcontratado.
Desde un punto de vista de soporte de TI
Dentro de esta sección voy a tocar temas de soporte tanto de hardware como de software en donde
posiciones de atención a cliente directo, monitoreo de sistemas de información, monitoreo de
hardware, analistas-programadores e incluso algunas posiciones como soporte a proyecto y
gerentes de proyecto son subcontratados.
En la gran mayoría de los casos, al recibir como responsabilidad un área de soporte, se recibirá una
plantilla de proveedores existentes, que en gran mayoría pueden tener años a servicio de la
compañía y en donde pueden existir algunos “compromisos” no escritos o documentados en
contratos que pueden generar cierta dependencia y vicios que generalmente o se pulen o se
eliminan.
El tema de manejo de proveedores implica por si mismo el manejo de intereses con compañías
terceras que pueden representar temas económicos muy importantes, y en donde tienen que persistir
principios y valores humanos fundamentales como la honestidad, equidad, imparcialidad entre otros
muy importantes. Son escenarios que DEBEN ser regulados a través de la madurez de políticas de
las compañías que pueden servir como guías e incluso, como una excusa o salida política a intentos
de las compañías terceras por hacer intentos de favoritismo en la celebración de un contrato,
permanencia etc. Tengo que compartirles que estos temas son universales, no se trata hacer un
cliché a escenarios Mexicanos, también existen en cualquier parte del mundo de ahí que los
principios y valores humanos igualmente deben de prevalecer universalmente y deberán ser
cuidados en todo momento. Las áreas de recursos humanos constantemente se encuentran
realizando campañas de información, de “certificación en aspectos de ética profesional” sobre todos
estos temas que facilitan su entendimiento y razón de ser en beneficio de todos los participantes y
de la compañía misma principalmente.
Así al recibir un área de soporte, listaré una serie de pasos recomendados en secuencia para el
tratamiento de proveedores:
39
1. Revisar todos los contratos actuales con proveedores así como los SLAs (Service Level
Agreements) para primeramente entender contractualmente cuales son las
responsabilidades y obligaciones de ambas partes. Hay que revisar las vigencias de los
contratos, la vigencia de fianzas.
2. Contactar al área legal de la compañía para tener el soporte correspondiente en
terminologías de carácter legal, ya que generalmente los contratos están escritos bajo
términos legales que causan confusión.
3. Contactar al área financiera para revisar todos los temas de fianzas asociadas a dichos
contratos.
4. Reunirse con todos y cada uno de los proveedores; es muy importante conocer con quien
estamos tratando, cuales son los niveles de compromiso, se tendrán que incluir cualquier
incidencia pasada, planes de mitigación de las mismas, estrategias de crecimiento, planes
de capacitación de los recursos, proceso de selección, entre otros temas importantes.
Durante esta reunión será indispensable precipitar alianzas, recordemos que el factor
humano es clave en todas las áreas de la organización, y desarrollar un “partner” de negocio
es estratégico, principalmente durante etapas álgidas y de tensión que son comunes con
cualquier proveedor de servicio. Se tiene que sugerir, de no existir, la programación de visitas
constantes de los proveedores con sus empleados directos.
5. Como base en los puntos anteriores, será indispensable revisar las cuotas de los perfiles de
los recursos humanos que forman parte del equipo; es muy común que haya una diferencia
en las cuotas de los recursos del mismo perfil-posición entre diferentes proveedores.
Excepcionalmente se encuentran razones que justifiquen la diferencia, generalmente
derivado de servicios o garantías adicionales de cada proveedor. La recomendación es
homogeneizar tanto como sea posible las cuotas para mantener un esquema de equidad lo
más sano posible, aun cuando hay temas de confidencialidad entre proveedores, siempre
puede presentarse el caso de alguna inconformidad.
6. Se tiene que revisar el presupuesto corriente y coordinar el tiempo de revisión de contratos
con los proveedores para estar preparados en la revisión de incrementos de cuotas;
generalmente esto tiene periodos de revisión anuales; es muy importante entender que los
recursos humanos recibirán o deberán de recibir una parte proporcional de dichos ajustes a
las cuotas.
7. Al tratar con factor humano, una recomendación será acercarse con los miembros del equipo
y sondear si hay alguna inquietud o inconformidad con su proveedor contratante; hay casos
particulares, donde el recurso en cuestión pueda no tener una compensación económica
sana que dispare sin ser un tema directo, la inquietud de una búsqueda laboral nueva y que
pueda poner en riesgo la estabilidad y dinámica del equipo de trabajo si se trata de un
recurso clave. En la mayoría de los casos, y a través del desarrollo de un “partner” de
negocio, estos temas se pueden tratar sin intervenir a fondo con los representantes de
proveedores y se pueden precipitar beneficios ganar-ganar para todos. Recordemos que
como en la mayoría de los casos, detrás de cada recurso y salario hay una familia que
alimentar.
8. Se tiene que revisar el proceso de pago de facturas a proveedores, estar seguros que todas
las partes entienden su responsabilidad y consecuencias en el proceso de autorización de
facturas. Aun cuando generalmente los proveedores deberían de tener una solvencia
económica y sostener un retraso en su pago, algunos de ellos trasladan directamente
cualquier retraso en el pago de facturas a los salarios de los recursos en cuestión; son temas
delicados, pero que tienen que ser tratados con la mayor asertividad posible. Se debe
entonces tener un proceso de entrega y pago de facturas completamente transparente y lo
más eficiente posible; en la mayoría de los casos habrá áreas de oportunidad e
40
imponderables que se tendrán que resolver a la brevedad posible, recordando que las
relaciones comerciales deben de ser ganar-ganar, y que igualmente es trasladado al recurso
humano en cuestión en la misma proporción.
9. En virtud de los temas de ética y de las políticas sobre las que se tiene que basar el trato a
proveedores, hay que constantemente cuidar que no haya ninguna desviación, aún aquellas
situaciones que pudieran no tener transcendencia, se tiene que evitar cualquier mal
interpretación; hay que recordar que ciertas situaciones pueden generar ciertas
percepciones, en ocasiones una percepción puede precipitar un juicio sin fundamentos, por
lo que no está demás la humana recomendación de prevenir antes que lamentar.
Me es grato compartir que durante mi estancia en UPIICSA se complementaron muchos principios
fundamentales con mi entorno familiar, que me han dado una fortaleza moral para describir los
puntos anterior, por lo que igualmente invito a cualquier alumno que lea este informe a un acto de
introspección honesta y de porque no, desarrollar cualquier área de oportunidad que se identifique.
Transición a un esquema subcontratado completo, hardware y software
Como mencioné anteriormente en este subtema muchas compañías grandes, estratégicamente se
están moviendo a un esquema subcontratado de TI muy cercano al 100%, que incluye generalmente
hardware, telecomunicaciones y soporte y desarrollo de aplicaciones.
Hay temas muy debatibles en cuanto a la justificación de un cambio tan importante
organizacionalmente hablando, que implica generalmente un alto costo que en teoría deberá de tener
un retorno de inversión a mediano plazo.
Un cambio de esta magnitud deberá contar con un análisis muy complejo revisando todas las aristas
del esquema de soporte.
Al tratarse de un cambio organizacional, se deben de incluir a todas las áreas de la compañía en
cuestión, ya que se experimenta un cambio en la cultura organizacional, que tiene que ser llevada
con el mayor cuidado posible para que la resistencia al cambio sea mínima y los resultados no sea
devastadores y desgastantes a lo largo del proceso de transición.
Estos cambios representan proyectos que pueden tomar años de su implementación que
generalmente representan un desgaste en todos los aspectos para la compañía; son temas muy
complejos que requiere la inclusión dedicada personal calificado interno y externo.
Durante el periodo de transición es inevitable la eliminación de posiciones de TI, aun posiciones
clave, para dar paso al esquema subcontratado, en algunos casos excepcionales la compañía
proveedora de servicios puede llegar a re contratar con ellos ciertas posiciones que requieran de un
conocimiento especializado y en donde sea más conveniente retomarlo con un esquema de
contratación nuevo. Todas las áreas de TI son impactadas, tanto de hardware como de desarrollo.
Dentro de este subtema desarrollaré las características más relevantes, sin profundizar con tanto
detalle, acerca de las transiciones de hardware y software, incluido el soporte y desarrollo de
aplicaciones. Hay otras transiciones en programas de esta magnitud, como lo son Help Desk que
por cuestiones de espacio en el informe no podré cubrir.
41
Es muy importante mencionar, un aspecto al que comúnmente no se le da la importancia necesaria,
y que debe de acompañar en todo momento todas y cada una de las transiciones incluidas en un
programa de esta magnitud: OCM (Organizational Change Management – Administración-Gestión
del cambio organizacional). OCM es uno de los factores y necesidades claves para el éxito de un
programa; igualmente por cuestiones de espacio en la sección de este subtema no será cubierto.
Hardware
El esquema de transición de hardware es complejo por si mismo; incluye temas de
telecomunicaciones y todos los equipos hardware como Servidores de aplicaciones ERP, PCs,
Laptops, Impresoras, equipos de redes, routers, wifi, telefonía, sistemas IVR (Interactive voice
response), etc, etc etc. Tiene una relación simbiótica con el software en su gran mayoría.
Los puntos que recomiendo tomar en cuenta para la transición de hardware son los siguientes:
Se tiene que establecer una estructura organizacional para la Administración del Proyecto o
Programa (que se diferencia de un proyecto por la magnitud y complejidad de sus
componentes); tiene que quedar muy clara la metodología a seguir, así como los
participantes y el empoderamiento necesario contando con el patrocinio de las altas esferas
ejecutivas de la compañía.
Se tienen que analizar y dividir todas y cada una de las áreas en el alcance; se deberá de
establecer un líder responsable que funja tanto como coordinador de tareas por área como
el punto de comunicación dentro de la estructura del proyecto.
La estrategia de comunicación de todos los participantes tiene que estar muy clara; la falta
de comunicación es uno de los puntos flacos de cualquier proyecto.
En los aspectos técnicos, se tendrá que hacer un inventario de todo el hardware incluyendo
todas las características de memoria, almacenamiento, procesador(es), sistemas operativos,
telecomunicaciones asociadas, etc; se necesita tener a la mano toda la información
relacionada a políticas de actualización del hardware, revisar contratos de mantenimiento,
telecomunicaciones, etc.; aún cuando esta sección está dedicada a Hardware, será
indispensable hacer un mapeo de aplicaciones de Hardware vs Software.
En cuanto a servidores, dependiendo de la naturaleza del ERP actual, se deberá de analizar
temas de mantenimiento, como calendarios, ventanas de tiempo, etc;
Será indispensable conocer las proyecciones de crecimiento de bases de datos,
transacciones I/O.
Se necesita ubicar el personal experto interno, para poder contar en todo momento con la
mejor calidad de información a utilizarse en toma de decisiones clave.
Es indispensable tener una lista completa y estrategia clara en blanco y negro sobre el
tratamiento de todas las IP (internas y externas), dominios de sitios WEB, certificados de
seguridad (SSL, etc).
Definir una estrategia clara en blanco y negro sobre la estrategia de DRP (Disaster Recovery
Plan – Plan de recuperación de desastres) actual y la proyectada una vez terminada la
transición.
42
Software
En cuanto a software se incluirán todas y cada una de esas aplicaciones que le dan vida y
funcionamiento aplicativamente hablando a una compañía. Es una realidad, que muchas compañías
no tienen documentadas todas sus aplicaciones, al grado que muchos usuarios en su vida laboral
diaria desconocen exactamente que aplicación o aplicaciones combinadas le dan el resultado, por
lo que será indispensable incluir en todo momento personal del área de TI para que ayude a la
identificación correspondiente. Han existido casos desafortunados en estos programas, donde
inclusive aplicaciones clave quedan fuera del inventario, y cuando X hardware que lo tenía ya no
está empiezan las complicaciones.
Aquí también tienen que considerarse los esquemas nuevos y propuestos sobre licenciamiento de
software de oficina, como Microsoft Office, Antivirus, y principalmente licenciamiento de Software
ERP, así como todo el software asociado a esquemas de replicación, DRP (Disaster Recovery Plan-
Plan de recuperación de desastres), etc.
Los puntos que recomiendo tomar en cuenta para la transición de software son los siguientes:
Complementar el inventario y mapeo de hardware y software realizando un análisis
exhaustivo con personal de TI sobre todas las aplicaciones que se utilizan.
Identificar las aplicaciones de terceros actuales, para asegurar compatibilidad en nuevo
hardware y sistema operativo proyectado; esto puede afectar aplicaciones de pagos con
bancos, o similares que utilicen aplicaciones que tienen requerimientos de hardware y
software específicos y que en algunos casos podrían no ser compatibles con el nuevo
hardware y sistemas operativos planteados, para lo cual será necesario definir un esquema
de soporte a aplicaciones legacy (legadas), que deberán formar parte del programa. Se
tienen que hacer todos los esfuerzos al alcance para que las aplicaciones en estas
circunstancias sean las mínimas indispensables con las que el negocio no deje de operar.
Analizar la compatibilidad de bases de datos en aplicaciones clave de negocio;
Analizar posible migración de bases de datos compatibles, para evitar tener un número
elevado de servidores con los mismos manejadores de bases de datos, generando costos
elevados en licenciamiento. Será imprescindible analizar la factibilidad de migración de base
de datos, ya que lo que aparentemente podría ser un ahorro en costos de licenciamiento a
corto plazo, podría convertirse en una pesadilla a mediano y largo plazo por cuestiones de
cuello de botella, lentitud de aplicaciones, etc; es uno de los puntos más sensibles a cuidar
en el aspecto de software en base de datos.
Se tiene que hacer desarrollar una estrategia de migración de aplicaciones a nuevo
hardware, incluyendo todas las fases de pruebas unitarias, pruebas de usuario e integrales
necesarias por aplicación o grupo de aplicaciones relacionadas. Aquí se tienen que incluir
para aplicaciones claves de negocio y cuando así el presupuesto y riesgo asociado lo
permita de ejecución de sistemas corriendo en paralelo durante la etapa de transición.
El tema más sensible de cualquier transición de software será el ERP, ya que por su
complejidad necesitará de un proyecto generalmente independiente pero asociado al
programa sobre todo el esquema de migración de base de datos, pruebas unitarias, pruebas
de usuario, pruebas integrales, que dada su magnitud demandará por si misma la
elaboración de reportes para puntos de control, conciliación de cifras, transacciones, etc. Es
muy complejo y requiere de toda la atención necesaria este punto.
43
Capítulo III. Implementación SAP
El presente informe no pretende dar detalles confidenciales de SAP así como tampoco de su
implementación en JAFRA.
Lo compartido en el informe se redacta para fines didácticos y utilizando conocimientos adquiridos
durante las implementaciones de SAP en donde tuve la oportunidad de participar, por lo que les pido
en todo momento buscar información oficial sobre cualquier concepto de SAP aquí descrito.
3.1 ¿Qué es SAP?
Basados en mi experiencia con SAP, les comparto, que es una compañía de soluciones global que
tiene una amplia gama de productos dentro de los cuales destacan diversas soluciones de ERP –
Enterprise Resource Planing. Por favor hagan referencia al contexto general detallado en el subtema
2.2 Sistema Comercial ERP de este informe.
Las soluciones ERP que oferta SAP han evolucionado desde sus primeras versiones que se
implementaron desde 1972. SAP ha seguido durante las pasadas décadas en constante evolución
y continua ofreciendo soluciones que van a la par de la tecnología disponible en el mercado,
ofreciendo inclusive soluciones en la nube, y nuevas plataformas de procesamiento en memoria.
SAP ha seguido una estrategia de compra de soluciones de terceros, para ofrecer una mayor gama
de soluciones para diversos tipos de industria. La premisa de SAP al utilizar estas soluciones de
terceros es que una vez integradas, seguirán todos los estándares en desarrollo de aplicaciones
SAP y tendrán la misma garantía de soluciones centralizadas.
Para tener un marco de referencia acerca del tamaño de SAP, a continuación les comparto algunos
números que se encuentran publicados en el portal de SAP:
413,000 + de clientes en más de 180 países.
94,900 + de empleados en más de 130 países.
Euros 23.4 Bn total de ingresos reportados durante 2017.
150,000 suscriptores en soluciones en la nube.
91 % de Forbes Global 2000 son clientes de SAP.
17,000 + compañías socias globalmente.
46 + años de historia.
Con SAP escucharán algunos conceptos que van más allá de la mercadotecnia, ya que en realidad
forma parte de lo que percibo como una de sus grandes premisas: el uso de las mejores prácticas
en la industria (Best Practices in the Industry).
Con el tema del uso de las mejores prácticas, hay un reto sumamente delicado e importante dentro
de cualquier implementación SAP. Si partimos del hecho que SAP ERP nos oferta que está diseñado
y construido sobre las mejores prácticas y estándares de la industria, es razonable inferir, que
cualquier adaptación-cambio (customization) al mismo puede llegar a tener costos exponenciales en
su implementación. Un cambio, por pequeño que parezca puede tener muchas implicaciones de
fondo ya que algunos de estos cambios puede implicar cambios a nivel de código e inclusive a nivel
de base de datos.
44
SAP constantemente estará actualizando las versiones del ERP instaladas en N clientes, por lo que
SAP siempre recomendará evitar al máximo cualquier adaptación-cambio (customization) al ERP
durante su implementación, ya que además del costo adicional antes mencionado, también podría
ser un factor en cuanto a recibir las actualizaciones, que pudieran nuevamente disparar costos
adicionales.
SAP cuenta con metodologías propietarias, las cuales no detallaré en este informe, para determinar
todos los temas asociados a Hardware, incluidos plataformas, sistemas operativos, tamaño del
hardware, etc.
Desde un punto de vista de TI, el hardware será la base y pilar del ERP, por lo que es una de las
piezas fundamentales en la implementación.
Adicional al hardware, es igualmente clave el tema de la arquitectura dependiendo del conjunto de
soluciones propuestas por SAP.
El tema de la arquitectura tiene un peso desde mi perspectiva aún mayor o al menos en un sano
equilibrio con el hardware, ya que de aquí se desprenderán tiempos de respuestas en las
aplicaciones tanto back-end como front-end, frecuencia en la actualización de datos presentados en
sitios WEB (idealmente debería de ser en tiempo real), en reportes, actualización de soluciones
adicionales para Inteligencia de Negocios (Business Intelligence), y finalmente siendo lo más
importante le dará al usuario final la “perspectiva” de una buena, mala o pésima implementación de
SAP.
Hablando estrictamente del ERP, el presente informe se basa sobre la experiencia con algunos
módulos de SAP entre los cuales se destacan SD (Sales and Distribution – Ventas y Distribución) ,
FI (Finance-Finanzas), MM (Material Master-Maestro de Materiales), CRM (Customer Relationship
Management-Administración de Atención al Cliente), Hybris (Plataforma de desarrollo WEB) y Vistex
(Plataforma para manejo de promociones de producto, programa, y cálculo de comisiones).
Es muy importante compartirles que la implementación de SAP representa una complejidad
importante, ya que se necesitan recursos especializados en la herramienta, y utilizar metodologías
de implementación adecuadas al tamaño y ciclos de negocios de mi compañía, por lo que se debe
de llevar acabo un proceso de selección de un socio de negocio que se conocerá como Integrador
del Sistema (System Integrator, o SI por sus siglas en inglés) que nos lleve de la mano durante todo
el proceso de implementación. Hay muchas compañías certificadas por SAP para hacer las tareas
de SI (system integrator), cada una ofrecerá mayores ventajas sobre las otras dependiendo de
diversos factores entre los que destacan, costos, localidades, experiencia, metodologías, tiempos de
entrega, etc.
Muy importante y adicional al SI (System Integrator), se necesita también establecer recursos
especializados para la oficina de administración del proyecto (PMO) en donde también hay mejores
prácticas para llevar satisfactoriamente la implementación.
La información histórica de SAP de este subtema fue sintetizada del link:
https://www.sap.com/about/careers/who-we-are.html 6 Diciembre 2018
45
3.2 ¿Porque SAP?
Estamos frente a una pregunta que no tiene una respuesta trivial. Hablar de porque vamos a
implementar SAP, debería, en la mayoría de los casos obedecer a un profundo análisis de la
compañía en cuestión y de las ofertas de ERP en el mercado para hacer un comparativo imparcial.
SAP, es en si un ERP ¿cierto?, desde aquí podríamos pensar que cualquier ERP en el mercado ya
sea JDE, Oracle, Microsoft, entre muchos otros nos podría funcionar ¿cierto?, pero antes de pasar
a estas respuestas pensemos un poco acerca de que nos debería de llevar a decidir en usar SAP.
Dejemos los nombres o marcas de ERPs a un lado por unos instantes, y pensemos sólo en un ERP
“genérico”; Formalmente desde mi punto de vista, la decisión de implementarlo se debería de basar
primeramente en un profundo análisis de requerimientos de negocios, para primeramente tener MUY
CLARO, ¿Qué es lo que necesito como compañía?, y tantas otras preguntas muy relevantes, tales
como: ¿Qué problemas tengo actualmente que necesiten solución a corto, mediano y largo plazo?,
¿Los problemas antes revisados se pueden solucionar en mi ERP actual? ¿Cómo lo voy a
solucionar?, ¿Cuándo lo puedo implementar? , ¿Cuánto me va a costar?, ¿Qué tan fácil serán de
usar las herramientas de un nuevo ERP?, Si necesito un front-end WEB, ¿Qué tan intuitiva será mi
interfaz de usuario final?
También me debería de preguntar, si mis competidores usan SAP, y si lo usan, investigar ¿Cómo
les fue durante la implementación?, ¿Funciona en realidad?¿Se implementó en tiempo y
presupuesto? ¿Hay otras compañías utilizando con éxito el set de módulos que me ofrecen?
Retomemos ahora las respuestas pendientes acerca de porque SAP entre otras muchas marcas de
ERP. Idealmente se le debieron de haber dado respuesta a todos y cada una de las preguntas y
muchas otras más antes planteadas, y debimos de haber tenido un proceso de selección del ERP
en cuestión, si fue así, que fortuna y privilegio haber participado en tan ambicioso proceso de
selección; afortunada o desafortunadamente el DEBER SER en algunos casos de la vida práctica
no aplica, y nos enfrentamos a casos donde el uso de SAP simplemente se hereda, por lo que las
razones de implementación se deben entonces más a temas de estandarización y consolidación de
herramientas de grandes grupos en la industria donde mi compañía puede ser una de N y en donde
la compañía padre-dueña tenga como su estándar el uso de SAP, por lo que la tendencia natural
será perseguir la consolidación de todos los temas financieros en donde SAP tiene la reputación de
ser muy fuerte.
Es así, que el caso práctico sobre el cual se basa este informe se trata de un escenario donde SAP
fue heredado y en donde todos los esfuerzos de la implementación se orientaron a otros aspectos
tales como la identificación las mejores herramientas SAP para los requerimientos en cuestión, la
búsqueda de la mejor arquitectura, y al uso de las mejores metodologías para tener una
implementación exitosa.
46
3.3 Problemática Una vez establecidos los conceptos básicos sobre SAP, es importante establecer la problemática en
cuestión que nos lleva a una implementación SAP.
Más allá de haber mencionado que el caso práctico del informe nos habla de una implementación
heredada por parte de la compañía padre, y de los muchos beneficios financieros que se tendrían
al tener todas las unidades de negocio del grupo consolidadas a través de SAP, hay también otros
factores relevantes que se suman y que una compañía puede utilizar para complementar la
justificación en la implementación de SAP.
Si bien el principio fundamental de la implementación de SAP se debería de basar en cubrir cuando
menos los requerimientos de mi negocio actuales, también es un parteaguas en una revisión objetiva
en el portafolio de aplicaciones del ERP legado, así como de los procesos de negocio que lo rodean,
y que representan por si mismas áreas de oportunidad, sobre todo en lo relevante a estrategias de
cara a los usuarios finales, para la atracción de nuevas generaciones en el negocio y continuar con
un crecimiento sólido en un escenario globalizado, donde a mediano plazo deberé de tener la
capacidad de poder implementar una versión tropicalizada de mi nuevo SAP ERP para diferentes
mercados-países.
Los ERP legacy, generalmente son el resultado de décadas de mini implementaciones de nuevos
requerimientos y necesidades de negocio, en donde generalmente no hay un claro uso de prácticas
de negocio globales, y en donde en muchas ocasiones se termina teniendo un ERP tipo
“Frankenstein“; suena retador y duro a la vez, pero es también una realidad que en el transcurso de
esas décadas hubieron muchas manos y en ocasiones muy poco cuidado en el control de cambios
resultando en ERPs con escenarios complejos de soporte.
En escenarios globales, generalmente se hizo la implementación del ERP en X país, a determinada
década de evolución del ERP base, para posteriormente seguir desarrollándolo de forma
independiente, creando como resultado que tengo N versiones en mis M países donde el esquema
de soporte nuevamente se torna muy complejo.
Y es entonces como la implementación de SAP, al menos en intención profesional e ideología,
buscará evitar esos errores del pasado, para dar puerta a una estandarización de procesos apegado
a las mejores prácticas de la industria a través de SAP para poder justificar y hacer todo lo posible
por alcanzar un nuevo sistema global con apego al estándar de mi compañía padre que ya utiliza
SAP.
47
3.4 ¿Implementación Completa “Big Bang” o Parcial?
Durante la implementación de cualquier ERP, la pregunta obligada será vamos por la estrategia de
reemplazar todo nuestro sistema comercial (“Big Bang”) o lo haremos de forma parcial,
implementado módulos durante un periodo de tiempo determinado.
Basado en la experiencia, y no únicamente de SAP, les comparto que si el tema crucial en la mesa,
como es el caso de muchas compañías, se enfoca en el aspecto de ahorro en costos de
implementación y en ahorro de interminables dolores de cabeza potenciales, siempre se preferirá el
camino de implementación “Big Bang” ya que la implementación parcial implica por definición tener
dos ERPs corriendo en paralelo impactando al menos alguno de los siguientes puntos relevantes:
Doble Hardware, doble pago de servicios de: hosting, licenciamiento, almacenamiento,
respaldos, líneas de comunicaciones; normalmente y por razones de mucho peso en
hardware como tiempos de respuesta, capacidad de de procesamiento, etc los ERPs no se
ejecutarían sobre el mismo hardware. Aún cuando el plan sea implementar un par de módulo
de forma inicial, se tendrían que considerar tanto recursos de hardware como de
administración en una proporción del doble.
Control de cambios en procesos de negocios: Un negocio tiene vida propia, y es imposible
pensar en congelar cambios ya no digamos durante un par de semanas, sino durante meses
o años que podría durar una implementación paulatina. La administración de cambios se
volvería en si uno de los retos más importantes para mantener el nivel de cambios en ambos
ERPs.
Control de transacciones: Dependiendo del módulo en cuestión se tendrían que tener
procesos adicionales para poder tener en sincronía las transacciones tales como clientes,
pedidos, productos, etc.
Interfaces: Será un tema indispensable y muy doloroso técnica y profesionalmente hablando
mantener la comunicación entre dos ERPs; habrá retos tecnológicos, en procesamiento de
información entre muchos otros.
Doble equipo de soporte: Por su naturaleza, el conocimiento experto deberá de recaer en
cada equipo de soporte, por lo que implicará más allá del costo doble, coordinación en la
resolución de requerimientos, migración de datos, entre otros retos relevantes.
Desgaste de los usuarios: Si ya una implementación “big bang” es extremadamente
desgastante y demanda muchas horas extras de los usuarios durante todas las etapas, tener
dos aplicaciones corriendo en paralelo sería totalmente irracional.
Pruebas de regresión: Ligado al punto anterior, esto representa un costo, inversión de tiempo
y esfuerzo muy importante durante cada módulo implementado.
Entre más listo puntos a considerar para no tomar el camino de implementación parcial, más me
convenzo que es un escenario muy improbable, en mis más de 20 años de experiencia nunca lo he
experimentado; aunque debo de reconocer que mi lado conservador, a veces alza la mano, pero es
¡ lapidántemente controlado nuevamente por mi lado práctico y aventurero ¡
Ahora, con todo lo anterior, no estoy implicando o sugiriendo que una implementación “Big Bang”
es sencilla, en lo absoluto lo es, pero de las dos opciones, es la que más sentido de negocio
representa una vez entrados en gastos de una nueva implementación de un ERP.
48
3.5 Estructura Organizacional para la implementación
Le estructura organizacional es clave, por lo que recomiendo tomar en cuenta las siguientes
recomendaciones en base a mi experiencia como Project Manager de implementaciones SAP:
Establecer un equipo de Administración del control del cambio (OCM - Organizational
Change Management), ya que es la base de toda estructura organizacional desde mi punto
de vista,); desde aquí debe de partir la estrategia de comunicación, apoyo en la selección
de SMEs (Subject Matter Experts - Expertos de Negocio), planes de respaldo para los
SMEs, cuidado del recurso humano, entre muchos otros temas importantes.
Identificar a los patrocinadores del proyecto en cuestión; aquí se recomienda que el
proyecto no tome un matiz de ser proyecto de TI; existe desde mi punto de vista un
malentendido en el argot de negocio donde todos y cada uno de los problemas de una
compañía son culpa de TI; los proyectos de implementación de ERP deberían por
definición ser un proyecto de NEGOCIO, por lo que es clave identificar aquellos ejecutivos
que formaran parte de un comité de aprobación y escalamiento de requerimientos.
Identificar a los miembros de la oficina de proyectos (PMO- Project Management Office); se
deberá de contar con un líder técnico, un líder de negocio y un Project manager que en
conjunto deberán de establecer una serie de estrategias para la definición de
requerimientos, de comunicación, metodologías a utilizar, herramientas de comunicación,
entre otros temas muy importantes.
Con apoyo de OCM, identificar a los líderes del lado de negocio por módulo a implementar
quienes idealmente podrían ser también SMEs (Subject Matter Experts - Expertos de
Negocio), por cada área en el alcance de la implementación que tendrán la gran
responsabilidad de la definición de requerimientos que formarán parte del alcance; los
SMEs, apoyarán en gran medida en la toma de decisiones ejecutivas; se podrán identificar
áreas de oportunidad dentro de los procesos, así como la gran oportunidad de hacer
sinergias con otras áreas y lograr procesos más completos y mejor definidos. El líder de
negocio sería la cara hacia el negocio así como los patrocinadores durante todas las
etapas de la implementación que incluye pero no se limita a: Definición y Análisis de
requerimientos, aprobación de especificaciones, pruebas, pruebas de regresión, migración
de datos, participación en tareas de cut-over (implementación puesta en marcha), etc. En
escenarios de proyectos multi-pais, los líderes de negocio-SMEs, también fungirán como
mediadores y orquestadores de requerimientos entre diferentes países para llegar a un
punto de balance en requerimientos y alcances.
Identificar personal de apoyo para los Líderes de negocio-SMEs. Los Líderes de negocio-
SMEs por definición no podrán o no deberían ser los todólogos para además de ser
expertos, documentar, analizar, resumir requerimientos, hacer pruebas, etc etc.
Equipo SI - System Integrator: Este equipo estará formado por consultores funcionales
SAP, así como desarrolladores, personal encargado de configuración y administración de
servidores SAP (Basis SAP) y personal dedicado a la gestión de interfaces.
Los puntos antes mencionados, tienen una visión de helicóptero, ya que sería muy extenso tocar el
detalle de cada uno de ellos; para fines de este informe, estoy mencionando los puntos más
relevantes que en base a mi experiencia considero pueden ayudar como un buen marco de
referencia en al implementación de un proyecto de esta naturaleza.
49
3.6 Viajes al extranjero y situaciones familiares
Continuando sobre el caso práctico de una implementación multi país, tiene una implicación familiar
y de viajes al extranjero extensos muy importante, que a veces por la emoción del momento y en
ocasiones combinada con juventud no se miden, o no se perciben como un impacto directo.
Hacer una implementación simultanea para al menos dos países implica una serie de viajes,
considerando al menos el 50% del tiempo en cada ubicación geográfica. Estos viajes implican un
desgaste muy significativo, más aún cuando se trata de diferentes usos horarios entre localidades;
se tiene que definir una estrategia de viajes lo más balanceada posible considerando puentes, días
festivos, imponderables. El dormir fuera de casa un 50% del tiempo tiene implicaciones que pueden
llevar a situaciones críticas familiares de desgaste con la esposa (o), hijos (as).
Estos proyectos normalmente tienen duración que se mide en Años, incluyendo retrasos,
imponderables, cambios de ejecutivos, cambios en el presupuesto, cambios de estrategias que no
se pueden visualizar al inicio del proyecto, entre otros muchos factores propios de escenarios
multiculturales; por lo que me permito extenderles una amplia recomendación para hacer una pausa,
y detenidamente analizar todos los factores conocidos hasta ese momento, incluyendo idealmente
negociaciones para tener una mejor oferta laboral que incluya por ejemplo un bono, un incremento
salarial, o algún esquema de compensación que nos brinde un balance entre lo laboral y lo personal.
Si tienen la fortuna de tener una familia directa, hablando específicamente de esposa e hijos, les
recomiendo siempre revisar estos temas con ellos, será de vital importancia, que ellos conozcan
nuestras necesidades profesionales, las oportunidades de vida, y que también formen parte activa
en la decisión, porque se tratará de un “viaje” juntos aún cuando ellos en ocasiones no estén con
nosotros físicamente.
En ocasiones participar en estos proyectos puede traer de la mano oportunidades para cambiar de
residencia a otro país. Si están solteros, es una de las mejores oportunidades de vida que podrán
tener, conocer otras culturas, conocer otras formas de pensar, formas de trabajar, aprender o pulir
otro lenguaje, desarrollarse profesionalmente en otro entorno, entre muchos otros beneficios. Si en
cambio tienen una familia además de tener todos los beneficios antes mencionados, deberán de
hacer un análisis mucho más profundo considerando todos las necesidades de toda la familia,
incluyendo opciones laborales para su compañero(a), escuelas para sus hijos, mudanzas y menajes
de casa; tendrán que pensar en el entorno social a donde van a llegar, si por ejemplo expondrán a
su familia a conflictos raciales, a la falta de amigos, y a tantos otros imponderables que no vivirán
hasta que ya estén en el nuevo lugar de residencia. Se requiere tener o desarrollar una fortaleza
familiar; el trabajo en equipo será su mejor aliado ya que se enfrentarán a muchos retos. Es muy
importante que cuiden a su compañero (a) de vida, se tiene que estar al pendiente de sus
necesidades personales; porque que en la parte laboral y personal los que nos vamos a trabajar,
tendremos la cabeza llena de actividades ¿ pero nuestra (o) compañero(a) en casa?, será muy
importante revisar opciones de socialización, deporte, buscar una escuela, y en general cualquier
actividad que también le de el balance.
Retomando el entorno laboral en equipos de trabajo que participan en este tipo de proyectos, el
factor humano en ocasiones tiende a darse por un hecho, por lo que es indispensable tener el
cuidado de todos y cada uno de los miembros del equipo y tomar en consideración temas que podrían
parecer efímeros como la comida, los horarios, los viajes juntos, la renta de automóviles compartidos,
en algunos casos desafortunados tener que compartir un hotel o departamento.
50
Somos seres humanos, y los equipos laborales de este tipo de grandes proyectos tienden a formar
familias nos guste o no en donde tampoco pudimos escoger a nuestros padres y hermanos. Así que
nos enfrentaremos a muchos tipos de personalidades, a gustos personales, a estilos de vida, a
formas de trabajo, y como en cualquier buena familia existirán diferencias que se tendrán que pulir
a lo largo del camino.
Como en cualquier matrimonio, en etapas tempranas del proyecto todo será color de rosa, estaremos
en un status tipo luna de miel; las largas jornadas de trabajo, el desgaste emocional inmerso en
viajar, no ver a la familia, convivir todo el tiempo con las mismas personas, comer en los mismos
lugares, serán factores que poco a poco asentarán la personalidad del equipo de trabajo, y es
entonces cuando se tienen que cuidar las necesidades en lo personal de cada miembro del equipo;
habrá quien guste de irse a comer solo un par de días a la semana, habrá quien no quiera salir de
su habitación para hablar con su familia en lugar de salir a convivir en un paseo o cualquier otra
actividad recreativa. La invitación aquí es a verse y comprenderse como seres humanos con defectos
y virtudes, pero sobre todo con necesidades particulares que tendremos que respetar en virtud de
una sana convivencia profesional. Recordemos que afortunada o desafortunadamente vamos a
convivir mucho más tiempo con nuestra familia laboral que con la personal.
Retomando a nuestra familia personal y buscando un balance INDISPENSABLE entre lo profesional
y lo personal, será necesario desarrollar y precipitar momentos y espacios de CALIDAD con nuestra
familia. Como Mexicanos, como latinos que somos, la familia será nuestro eje, será nuestro motor y
por quienes en realidad hacemos tantos sacrificios, trabajamos y queremos ser exitosos en lo
personal y profesional.
Les recomiendo que hagan todo lo posible por NO DESCUIDAR a la esposa (o), a los hijos (as); bajo
estos escenarios laborales, se tienen que valorar aún más todos los momentos compartidos y es
muy fácil cometer errores involuntarios; si no tenemos cuidado, estos proyectos pueden tener un
costo familiar muy alto. Nadie quiere terminar divorciado (a), o con pequeños que sólo nos conozcan
por fotografía, ¿o si?
51
3.7 Retos en la comunicación
La comunicación en temas de implementación multi-país es todo un reto; hablando específicamente
de un escenario mexicano, cuando nos enfrentamos a estos proyectos, no es muy común que
nuestras áreas de recursos humanos persigan temas de capacitación para aprender o desarrollar el
idioma inglés. Habrá ocasiones que se manejará solamente un inglés técnico mínimo para continuar
con la comunicación; hay SMEs (Subject Matter Experts), que simplemente no hablan o no quieren
hablar inglés.
Salvo contadas excepciones, no se tendrán las mismas habilidades de negociación y argumentación
en una lengua que no sea la materna, para lo cual se tiene que estar consiente y se tiene que
perseguir el desarrollo individual; más allá de que lo cubra o no el área de recursos humanos,
nosotros tenemos que procurarnos dichas herramientas en la medida de lo posible.
Como mexicanos tenemos que hacer todo lo posible por quitarnos esos estigmas de que no podemos
hablar inglés, de que no lo entendemos, o de que medio lo entendemos; desde hace ya algunos
años el lenguaje ya no puede ser un pretexto, sino más una oportunidad de crecimiento que les
puedo compartir abre puertas reales.
Durante mi esfuerzo por elaborar este informe y revisar requisitos y opciones de titulación, me
percaté gratamente que los planes de estudios desde hace algunos años ya incluyen materias y
requisitos en inglés, mi recomendación es que lo aprovechen al máximo y que no sólo se queden
con la satisfacción de cursas las materias, den un paso más adelante e inviertan en clases
adicionales, es necesario practicar, practicar y practicar cualquier otro idioma constantemente. Para
aquellos que no hayan tenido la fortuna de ser forzados escolarmente en tomar clases de inglés, les
doy mi más amplia recomendación para que lo persigan tan pronto como les sea posible; hoy en día
hay muchas opciones a costos muy razonables y sin la obligación de un horario específico para
aprender otro idioma.
El inglés ha sido, y continuará siendo por varios años más, el lenguaje universal en los negocios y
proyectos de carácter internacional; Se dice que el mandarín será una tendencia hacia el estándar
como lenguaje de negocios a mediano plazo, por lo que también puede ser una opción más para
aprender otro lenguaje. Una buena comunicación verbal y escrita en otro lenguaje siempre marcará
la diferencia en una buena negociación y argumentación.
A continuación les comparto los retos más relevantes en la comunicación dentro del proyecto ERP
SAP en un escenario multicultural para México y EUA:
Consultores SAP multiculturales, predominando el lenguaje inglés.
Toda la documentación del proyecto estará en inglés
Sesiones de trabajo para: revisión de requerimientos, revisión de prototipos, revisiones de
alcance, confirmación de blue print, etc (prácticamente para todo el proyecto) en inglés
Todas las negociaciones clave para aprobaciones y escalamiento en inglés
Todas las herramientas de seguimiento para las pruebas unitarias e integrales en inglés
SMEs que sólo hablan español.
Pantallas, Reportes, con requerimientos de despliegue bilingüe.
Desarrolladores SAP del equipo remoto de India con un inglés técnico limitado en su
mayoría.
52
En general fácilmente podemos identificar una necesidad imperativa del uso de inglés verbal y
escrita. Durante la etapa de selección de los integrantes de un equipo de trabajo para este tipo de
proyectos, generalmente se solicita personal bilingüe en todas las áreas del proyecto, tanto técnicas
como PMO (Project Management Office) y de usuarios. La realidad es que no siempre se consigue,
por diferentes factores, como disponibilidad, la calidad de ser expertos en su ramo, rangos salariales,
etc. Y se tienen que enfrentar estos retos aplicando estrategias para mitigarlos, como por ejemplo:
Cursos de capacitación de inglés técnico
Facilitar talleres para practicar el inglés
Contratar servicios de traducción escrita
Contratar servicios de traducción durante las sesiones de trabajo para revisión de
requerimientos, escalamientos, aprobaciones.
En el caso de los servicios de traducción (escrita o en sesiones de trabajo) desafortunadamente se
pueden generar más confusiones que beneficios; se necesita tener una infraestructura y logística
particular, además de considerar que generalmente los servicios de traducción harán una traducción
literal palabra por palabra, en donde desafortunadamente se pueden encontrar términos muy
particulares a procesos de negocio que no tengan una traducción directa y por consiguiente generen
confusiones y tengamos una carísima estrategia de mitigación tipo teléfono descompuesto.
Todos los retos antes mencionados requieren de una atención en lo particular, sin embargo yo
enfatizaría especial atención a todo lo relacionado con el entendimiento claro y preciso de todos y
cada uno de los requerimientos de los procesos de negocio, y como consecuencia de toda la
documentación del proyecto que es significativamente extensa. Lo he mencionado en otros
subtemas de este informe y lo reafirmo aquí: si en nuestro propio idioma/lengua materna hay retos
importantes en la comunicación verbal y escrita y con frecuencia hay una percepción de “no nos
entendemos”, los retos son significativamente amplificados cuando se tiene un idioma adicional.
El lenguaje en los proyectos de ERP Globales, es un factor de riesgo que siempre debería estar
claramente identificado y entendido por los patrocinadores del proyecto. Para lo cual les recomiendo
utilizar los mecanismos de documentación de acuerdo a la metodología que se esté siguiendo en el
proyecto, incluyendo un plan para mitigar cada uno de los retos identificados en lo particular para el
proyecto y la cultura organizacional en cuestión. Se deberá también asignar una partida en el
presupuesto del proyecto.
53
3.8 Retos Multiculturales
Continuando con el caso práctico de implementación multi-país, necesitamos estar consientes de
nuestras virtudes y limitaciones culturalmente hablando. En el subtema 2.12 Escenario de Soporte
Multicultural, detallé características muy interesantes de algunos países, incluyendo México y
Estados Unidos. En este subtema amplificaré algunos de los detalles e incorporaré algunos
elementos que considero importante compartirles.
Dentro del mundo SAP, hay una amplia gama de culturas representada por un importante número
de consultores de diferentes países.
Las características culturales para Estados Unidos y México descritas en el subtema 2.12 se
mantienen y aplican desde mi punto de vista, para escenarios de consultores SAP; aquí me gustaría
agregar un cultura muy interesante, India.
India tiene una presencia muy importante en temas de TI a nivel internacional entre muchos otros;
compiten en muchas áreas con México, incluyendo compañías dedicadas a brindar servicios remotos
de soporte y recursos SAP en toda su amplia gama de aplicaciones. México también tiene
compañías dedicadas a estos servicios;
Tengo el honor de tener amigos en lo personal y profesional de la India, y considero que tenemos
más similitudes que diferencias; algunas de las características profesionales que me gustaría resaltar
en ellos son: dominio en sus áreas de conocimiento, alto grado de profesionalismo a través de
modestia y humildad profesional. En mi experiencia estas características suelen ser mutuamente
excluyentes en otras culturas. En lo personal, tengo problemas para entender el inglés de la mayoría
de ellos, y me atrevo a suponer que se puede deber a que es sus lenguas materna/dialectos hablan
con una cadencia y velocidad mayor comparado con el español y el inglés. En virtud al balance y
reciprocidad, supongo que ellos también encuentra difícil entender el acento de mi inglés hablado.
Retomando ahora los retos multiculturales en el proyecto, me atrevo a resumir que se mitigan en una
proporción importante al tener una metodología de implementación definida para SAP. Esto no quiere
decir de forma alguna que los rasgos culturales profesionales y personales antes compartidos no
existan, claro que se dan pero al menos en mi experiencia en menor medida; me atrevo incluso a
inferir que dado el contexto multicultural de SAP, tienen desarrolladas habilidades de convivencia
multicultural, las cuales afortunadamente se permean en su mayoría al resto del equipo como los
usuarios que no la tienen y es mucho más fácil entonces perseguir la armonía de una sana
convivencia multi-cultural. Es impresionante lo que se puede lograr con un ejemplo positivo.
.
54
3.9 TI en funciones de área usuaria
En un contexto de desarrollo de aplicaciones, a lo largo de mi experiencia profesional, he tenido gran
variedad de compañeros, clientes internos a quienes la gente de TI llamamos “usuarios” y quienes
formalmente hacen uso de una a N aplicaciones que sirven como herramientas de trabajo para poder
realizar sus tareas y responsabilidades de acuerdo a su perfil de puesto en el área o departamento
en específico.
Los usuarios son, o deberían de ser nuestros cómplices para poder lograr todos y cada uno de sus
requerimientos o necesidades en lo particular para cualquier aplicación.
Cualquier actividad de soporte en aplicaciones, se basa en el principio fundamental de comunicar
adecuadamente el problema o error encontrado, y en temas de nuevos requerimientos este principio
se debe de amplificar para detallar todos y cada uno de las características del requerimiento,
incluyendo idealmente ejemplos, diversos escenarios, datos de prueba, etc.
Hasta aquí la percepción de TI ¿cierto?, pues no del todo desde mi punto de vista. Considero que
basados en un mundo de percepciones, es muy común sobre todo en una etapa muy temprana en
las experiencias profesionales, que la gente de TI damos por hecho que el usuario DEBE de entregar
todos sus requerimientos de la misma forma en la que nosotros percibimos un problema, y es
entonces cuando inician las frustraciones y cuando el usuario necesitaba en realidad un círculo color
rojo, y el equipo de IT le entregó un cubo con motitas rosas; y entonces se tiene que pulir el principio
básico de comunicación entre usuario y TI a través de muchas estrategias, que pueden incluir pero
no estar limitadas a formatos de requerimientos, juntas de análisis de revisión de requerimientos,
presentaciones en power point revisando ejemplos, escenarios, para finalmente pedirles que firmen
con sangre y si… adivinaron, aún así son muy comunes las honrosas excepciones donde el
entregable no es exactamente lo que el usuario necesitaba.
Anteriormente mencioné que los usuarios deberían ser nuestros cómplices, y por supuesto que estoy
convencido de ello. Se tiene que desarrollar un equipo tipo Batman y Robin, donde haya un
compromiso y completo respeto por cada una de las partes, para desarrollar y llevarlos de la mano
en todas las actividades que nos ayuden a tener tan claro como sea posible el requerimiento, y los
“súper sabios de TI”, tenemos que bajarnos de la nube y también tener una mente abierta y
disposición de aprender sobre el negocio, porque en la gran mayoría de los casos, los usuarios
podrán no ser expertos en TI, podrían inclusive tener problemas para utilizar un teléfono Android o
Apple, pero suelen conocer muy bien su negocio y tareas, por lo que mi estrategia es y será siempre
formar y desarrollar un equipo de trabajo para tener complicidad profesional.
Y es con este preámbulo que retomo el tema de la implementación de SAP, porque tuve la fortuna
después de mas de 16 años de experiencia en TI, de formar parte del equipo usuario teniendo las
funciones de SME y Líder de Negocio. No es ajeno al equipo de TI, el desarrollar profundos
conocimientos del negocio, claro, no es un proceso sencillo ni mucho menos rápido, pero como
cualquier ser humano la gente de TI tenemos la capacidad de seguir aprendiendo en todo momento,
por lo que la complicidad profesional se puede capitalizar.
Teniendo una amplia experiencia en TI, me pareció una oportunidad de oro aplicar conceptos y
principios de TI en todas y cada una de mis tareas como usuario, porque entonces tuve la
oportunidad de ofrecer toda la empatía posible a mi contra parte de TI para que mis requerimientos
fueran tan claros como a mi me gustaría que fueran si yo fuera TI.
55
Así bien, tuve la oportunidad de aplicar TI en las siguientes funciones usuarias:
Revisión y Análisis de requerimientos: Considero una de las características más importantes
del perfil de TI, el pensamiento y análisis estructurado, mismo que permite entender y asociar
requerimientos de negocio de una forma más eficiente. Fueron mucho más fácil de seguir,
pero también cuestionar las estrategias de SAP, para llegar al balance sano durante todo el
proceso de las definiciones.
Documentación de requerimientos: Quizá debo de reconocer, uno de los puntos que como
gente de TI me cuesta más trabajo es la documentación en general, pero que también debo
de reconocer en específico para la toma de requerimientos que es clave.
Revisión y aprobación de requerimientos: Si, también tuve que firmar con Sangre mis
requerimientos, y me tocó vivir un lado muy humano, el cometer errores como usuario,
porque se me escapó una definición o cálculo importante, que yo sé que representa un
cambio en código, y mucho re-trabajo en pruebas principalmente. Al final del camino, y para
los que crean en el Karma, tuve mucho aprendizaje de regreso sobre mis propios errores;
porque siendo gente de TI, y con una tendencia a lo blanco y negro, tuve que reconocer y
renegociar algunos de mis requerimientos.
Pruebas Unitarias: SAP siguió la metodología de desarrollo SCRUM, en donde básicamente
se tiene un grupo de entregables en ciclos de trabajo predefinidos, con la intención primordial
de dar un sentimiento de avance firme y continuar con los siguientes pasos dentro de un
flujo de desarrollo. Desde un punto de vista TI, es interesante experimentar esta necesidad
de los usuarios desde ésa trinchera. Teniendo un punto de vista TI, fue muy natural realizar
las pruebas unitarias de determinado proceso, ya que la visión estructurada permite entender
que el entregable se tiene que probar con cierto alcance, y que el requerimiento final deberá
de probarse en un ciclo de SCRUM más adelante.
Pruebas Integrales: El concepto de pruebas integrales desde un punto de vista de usuarios,
suele ser muy compleja, ya que hay una tendencia humana de enfocarnos sólo en lo que le
corresponde a X área, y pasamos por alto características grandes o pequeñas que pueden
afectar el resultado completo dentro de un proceso. Gracias a la experiencia en TI, tuve la
facilidad para tener una visión holística de mis procesos, y tuve siempre el cuidado de dar
las recomendaciones a mis compañeros líderes de negocio en cuidar ciertas características
para que los resultados de las pruebas integrales agregaran valor al proceso de
implementación.
Migración y Validación de Datos: Es una de las áreas donde pude retomar muchos de los
conocimientos de UPIICSA de las materias de bases de datos y SQL. Un usuario
normalmente depende de TI para poder ejecutar las tareas de extracción de datos y
finalmente poder hacer un análisis de validación y obtención de cifras control. Gracias a
estos conocimientos tuve la oportunidad de utilizar con gran soltura las herramientas de SQL
que oferta SAP, y tuve la oportunidad de desarrollar Querys (consultas de bases de datos)
que no sólo ayudaron a mi área de responsabilidad sino a otros líderes de negocio en la
implementación. Considero un privilegio tener la oportunidad de enseñar, compartir y
entrenar a otros compañeros.
Revisión de Cut Over Plan (Plan de transición entre dos sistemas): Este es uno de los temas
más interesantes y que más me apasionan de TI, ya que representa la secuencia exacta de
todas y cada unas de las tareas, incluyendo responsables de ejecución, por mes, día, hora
e inclusive minutos, que se tienen que seguir para lograr la transición entre dos sistemas
hablando del caso de la implementación de SAP al pasar de un ERP legacy a SAP. Hay
diferentes tipos y usos de Cut Over Plans, por ejemplo para migración de base de datos,
56
para actualización de sistemas operativos en servidores, y en general en cualquier tarea o
grupo de tareas donde se necesite tener un plan exacto y secuencia de actividades y
responsables de ejecución. Durante etapas de implementaciones en ERPs o requerimientos
clave, me ha dado la sensación del famoso “Velo Negro” cuando los astronautas regresaban
a la tierra y donde por algunos segundos no se sabía si regresarían con vida. Es para mi un
tema crucial y definirá el éxito o fracaso de todas las tareas detrás de un plan de trabajo.
Entrenamiento: Gente de TI, tiene o debería de tener la capacidad de transmitir el
conocimiento; lo considero un arte, y considero también que no todos contamos don dicho
don. La formación TI da la capacidad de estructurar un material de entrenamiento,
incluyendo también ejemplos, ejercicios y casos prácticos. Considero que los puntos que
siempre tenemos que pulir en especial gente de TI, es que tendemos siempre a dar
explicaciones técnicas ante cualquier problema y con frecuencia tendemos a intentar
transmitirlo así utilizando tecnicismos y en ocasiones palabras rebuscadas que al final del
camino solo confunden a los usuarios más. Por lo que es aquí indispensable mantener y
transmitir el conocimiento de la manera más simple, utilizando analogías sencillas, limitando
el uso de palabras técnicas, acrónimos. No es fácil, sigo aprendiendo.
Liberación a producción y estabilización: Considero esta sección una de las áreas de mayor
desgaste emocional y físico de cualquier usuario. Lo he vivido desde un punto de vista de
TI, pero tiene un matiz muy diferente la experiencia como usuario. Aun con formación de TI,
y habiendo implementado SAP con anterioridad y otros ERPs, viví toda esta sensación de
lo desconocido, de las largas horas de trabajo, de la responsabilidad ante los usuarios
directos e indirectos si algo falla, si algo se retrasa, representando así toda una experiencia
y enriqueciendo al 1000 mi empatía por el área usuaria.
Les comparto que es impactante el tener la oportunidad de estar del otro lado de la moneda, y es
aquí cuando aún con más fuerza reafirmo que es indispensable tener y desarrollar la complicidad
profesional entre usuarios y TI. Hay momentos muy duros durante todas y cada una de las fases
antes descritas, momentos que podrían hacer a cualquier persona claudicar, y salir corriendo, pero
que nos forman como seres humanos y que nos dan la oportunidad infinita de aprender de nuestras
contrapartes. Hoy, yo no veo a los usuarios de la misma forma, aun cuando antes de tener esta
posición me preciaba de tener una gran empatía para ellos, es con otros ojos que en adelante
trabajaré de la mano con ellos,… a veces no hace daño dejar de ser tan TI.
Antes de cerrar, casi olvidaba incluir un tema fundamental de TI en áreas usuarias, la definición de
tiempos de entregables de trabajo. Si, quizá le zumbará el oído a más de 100,000 en TI, pero es
extremadamente común que a los tiempos de entregables se les incluye un alto % de margen de
seguridad, mejor conocido como “Colchón”. Pues bien, esto es universal, en desarrolladores en
cualquier parte de mundo así que no nos sintamos tan mal, sin embargo, es algo que con los años
y la experiencia se tiene que pulir para darle a TI el profesionalismo que se merece, y hacerlo si,
pero de la forma más balanceada posible; Así, no fue la excepción con SAP, y tener el conocimiento
TI, me ayudo a limitar incidencias de esta naturaleza durante el proyecto.
57
3.10 Toma de Requerimientos en base a múltiples modelos de negocio
Este tema lo toqué durante el capítulo anterior de este informe enfocado a temas de soporte de ERP
globales.
La complejidad de múltiples modelos de negocio, cuando se implementa desde 0 un ERP SAP con
alcance de implementación de varios mercados-países se amplifica significativamente. Y el tema de
estándares y prácticas de negocio comunes necesita ser reforzado durante todas y cada una de las
etapas de implementación.
Si tengo en frente una franquicia, mi problemática será menor, sin embargo como ya lo mencioné
con anterioridad, la complejidad del caso práctico motivo de este informe, radica en la necesidad de
una implementación para modelos de negocio y economías (desarrollada vs emergente) diferentes,
por lo que en módulos específicos se tuvieron que mantener características y funcionalidad que
permitiera cierto grado de tropicalización.
La estrategia para definir el grado de tropicalización, se puede basar entonces, en los modelos de
negocio más representativos para cada sector económico, desarrollado y emergente, para que a
partir de ahí cualquier implementación de mercado nueva pueda seguir los ejes principales, y
nuevamente permitir una tropicalización esperanzadamente menor.
Aquí me permitiré mencionar, que algunas de estas estrategias, podrían obedecer a escenarios
ideales, que no siempre se acercan a la realidad, ya que podríamos enfrentarnos a un nuevo
mercado donde condiciones gubernamentales puedan tirar por la borda nuestros principios y
estrategias de implementación; sin embargo creo que es muy válido y necesario definir estas
estrategias y documentarlas con todos los elementos que se tengan al alcance y con todo el soporte
ejecutivo para que esperanzadamente prevalezcan aún durante las etapas de transición y cambios
que cualquier compañía tiene a lo largo de su existencia.
En el mundo de SAP, es indispensable tener en cuenta que cualquier tropicalización por pequeña
que parezca tendrá repercusiones significativas en el costo de implementación así como en el costo
de las actualizaciones de nuevas versiones.
Es un reto impresionante el que se vive durante la etapa de definición de requerimientos, para que
las áreas usuarias compren primeramente la idea de la adopción de “mejores prácticas”, porque es
natural y humana la resistencia al cambio; es natural para cualquier usuario preguntarse: si he venido
trabajando así durante X años, ¿porqué ahora con un nuevo ERP tan moderno y de última
generación tengo que ser yo el que se adapte a él? La respuesta no es trivial, y la argumentación
nada sencilla para ser el promotor del cambio como parte de las funciones de líder de negocio en la
implementación.
Hay que reconocer que hay algunas prácticas de negocio que no tienen una justificación de uso real;
y es una etapa complicada, de estirar, aflojar y apretar tuercas con las áreas usuarias para llegar a
un consenso objetivo de todos y cada uno de los requerimientos; se pueden y tienen que seguir
estrategias para la clasificación de requerimientos, por ejemplo: 1. ¿El Negocio puede funcionar sin
el requerimiento?, 2. ¿ El negocio podría funcionar sin el requerimiento? 3 ¿ El negocio puede
funcionar sin el requerimiento?.
58
Ahora, sumemos a la complejidad, la realidad de la necesidad de soporte de múltiples modelos de
negocio, así que ahora tendré que valorar además, cada uno de los requerimientos para asegurarme
que son compatibles con los N modelos de negocio dentro del alcance; en la mayoría de los casos
se tendrán que escalar los mismos, para que en un escenario positivo, un modelo se ajuste un poco
y se empate con el otro, o bien negociar un requerimiento que de forma balanceada cubra ambos
modelos de negocio. Para lo cual será indispensable tener una estrategia de comunicación y
escalamiento para todos los temas de aprobaciones necesarios.
Nuevamente aquí y aún con mayor énfasis, se necesita mantener en la menor proporción posible
cualquier tropicalización derivada de requerimientos de múltiples modelos de negocio; aplica el
mismo principio que en los temas de soporte del capítulo anterior pero con una mayor escala dentro
del mundo SAP que no sólo debe limitarse durante la etapa de implementación sino también a lo
largo de la vida del sistema ya que dentro de SAP, la complejidad radica, en que normalmente todos
los objetos del ERP se comparten en todas las unidades de negocio, por lo que cualquier cambio a
alguno de ellos requerirá un control preciso y esfuerzos significativos para ejecutar pruebas de
regresión, aun y cuando para el nuevo requerimiento aplique únicamente para el mercado-pais X,
los países Y, Z, W, A, B, C, tendrán que verificar que su objeto compartido funciona correctamente
para cada uno de ellos, sumado a cualquier cambio necesario en aspectos de bases de datos que
implica alguna conversión y que agudice la complejidad de lo que pudo en principio parecer un simple
cambio para el país X.
Se tiene que establecer entonces, una unidad específica para el control de cambios, que tienen que
estar regulados idealmente desde un punto de vista de negocio a través de un área de
transformación al negocio global, que permita la coordinación e implementación de dichos cambios.
Entre más % de requerimientos no estándares se hayan permitido durante la implementación ,
mayores serán los retos en el soporte del mismo, ya que esto implica costos de mantenimiento muy
importantes, que con frecuencia se minimizan durante la concepción de los proyectos. Es por ello
que todas estas estrategias deben de estar respaldadas en todo momento por los altos ejecutivos
de la compañía para que así, el tema de la adopción de las mejores prácticas ofertadas por SAP sea
una de los principios a seguir principalmente durante la etapa de definición de requerimientos.
59
3.11 Manejo de Consultores SAP
Este subtema se abarcará principalmente desde un punto de vista de área usuaria, con tintes de TI,
inevitablemente.
Como consultor SAP entenderemos a todos aquellos consultores funcionales que tienen el trato y
contacto directo con los usuarios; por consultores funcionales nos referimos a expertos de SAP que
dominan el proceso o módulo X, y que tienen todos los conocimientos para configurar (idealmente
encender o apagar switches, o definir valores en parámetros) evitando en todo momento hacer un
desarrollo, porque recordemos, que desarrollo será igual a tropicalización y desarrollos fuera del
estándar y de las mejores prácticas.
No es un secreto, que hay una percepción en el mercado de que los consultores SAP se perciben
así mismos como hechos a mano y terminados a pincel. Me gustaría hacerles justicia como a
cualquier grupo profesional y poner mi granito de arena para compartirles que el león no es como lo
pintan.
Como en cualquier grupo social, de trabajo, existen las desafortunadas excepciones.
Al igual que en cualquier grupo profesional de cualquier otra firma, marca o como le queramos llamar,
JDE, Microsoft, etc, hay elementos extremadamente profesionales y algunos pocos no tanto, pero
en la generalidad hay un código de ética, y esquemas de escalamiento y evaluaciones muy objetivos
que ayudan en general a tener un equipo de consultores SAP muy eficiente.
Teniendo formación TI, los consultores SAP en ocasiones tienen esos vicios de TI que ya
puntualizaba yo en subtemas anteriores. Por lo que desde un punto de vista usuario, es importante
establecer una línea de comunicación y de confianza mutua, así como desarrollar la complejidad
profesional que también mencioné con anterioridad.
Tuve la experiencia de convivir con consultores SAP altamente especializados con un dominio de
sus módulos en su gran mayoría y con conocimientos en otros tantos que les dan una formación
muy sólida; desconozco si se debió a que el SI (Sytem integrator) en cuestión fue SAP directamente.
Quizá como área de oportunidad y recomendación, sería importante tanto como sea posible validar
soluciones SAP entre consultores y si es posible con algún consultor de firma externa; generalmente
siempre habrá un consultor que conozca de otros módulos y siempre será sano compartir
experiencias con el objetivo de enriquecer los resultados. Con la experiencia de haber seguido esta
estrategia, se pudieron identificar áreas de oportunidad en la implementación de X o Y funcionalidad;
explico, todos tenemos una forma en particular de por ejemplo matar a una hormiga… algunos
utilizarán un matamoscas, otros un insecticida, y algunos muy aventureros utilizarán un cañón ¡ .
Cualquiera de estas opciones, me llevaría al objetivo final de eliminar a la hormiga, ¿Cierto?, pero
no todas serán la forma más eficiente de hacerlo; cada una de las soluciones puede tener
implicaciones en costo y tiempo de implementación significativas, y más allá, de mantenimiento a
largo plazo.
El ejemplo de la hormiga, aplica tanto para configuraciones, como para desarrollos (tropicalizaciones)
de la funcionalidad.
60
En cuanto a la configuración, es extremadamente difícil para un usuario revisar, o validar que alguna
configuración se hizo como matamoscas, insecticida o cañón, por lo que la única estrategia viable
será realizar las pruebas unitarias, verificar que los tiempos de respuesta son los aceptables, verificar
que las pruebas integrales nos dan el resultado esperado, etc. Sobre todo en pruebas con carga de
trabajo, y de volumen podrían detectarse algunas desviaciones.
En cuanto a nuevos desarrollos, - por favor recordar que se deben de tener los mínimos
indispensables para que el negocio funcione – siempre habrá detrás una especificación que se
tendrá que firmar con sangre por ambas partes, el consultor SAP y el líder de negocio; el formato y
lenguaje en el que se tendrá la especificación deberán de ser idealmente fácilmente entendibles, y
es aquí como el tinte de TI, nos permite balancear principalmente el lenguaje, para que tenga todas
las características y descripciones posibles, incluyendo si se conocen, nombres de tablas y campos
para que el margen de error sea el mínimo.
Hay que considerar que aun con el mayor cuidado posible, y experiencia TI, siempre habrá un
margen de error, mismo que se tiene que apegar a una estrategia de flexibilidad con los consultores,
para que se permitan algunos mínimos ajustes sobre la marcha que son inevitables.
Es importante tener en cuenta que hay etapas y ciclos dentro de las implementaciones; inicialmente
podría decir que hay una dependencia de los consultores hacia el área usuaria, donde todo el
conocimiento es del negocio hacia el consultor; posteriormente, el consultor idealmente entra en
dominio completo de los requerimientos y la balanza en la dependencia cambia, siendo ahora el
usuario quien depende de todo el conocimiento del consultor, principalmente durante las etapas
finales de pruebas unitarias, integrales, puesta en producción y estabilización, por lo que es mi más
amplia recomendación siempre dar un trato profesional y de cordialidad a los consultores, que no va
más allá de ninguna teoría razonable en temas de comunicación y trato interpersonal, tendríamos
que tratar como nos gustaría ser tratados y entender que como en muchos aspectos en la vida,
estamos a una rueda de la fortuna, a veces arriba, a veces a un lado, a veces abajo.
Recomiendo por supuesto también desarrollar la complicidad profesional; es de vital ayuda sobre
todo en los tiempos más duros y álgidos que todo proyecto tiene, porque nos guste o no, hay una
analogía muy utilizada de la vida común para aquellos que estamos casados, la relación con
consultores, en particular SAP, con usuarios se puede equiparar a un matrimonio, habrá muchos
esfuerzos en común pero también algunas diferencias y sin sabores, por lo que tenemos que
mantener en todo momento el enfoque en el resultado final, todo orientado hacia los aspectos
profesionales aplicables a la etapa de implementación en turno.
61
3.12 Blue Print de SAP
Me permitiré utilizar el termino Blue Print, en inglés, ya que es como comúnmente se le conoce aún
en español.
El Blue Print, será un término que comúnmente se escuche en cualquier implementación de SAP, y
se trata de una fase de la implementación SAP donde se obtendrá como entregable la descripción
detallada, de todos y cada uno de mis requerimientos, tanto procesos de negocio, como de solución.
Representará la base a partir de la cual los consultores funcionales SAP identificarán todas las
configuraciones necesarias así como todos aquellos desarrollos nuevos.
En términos coloquiales en analogía a la construcción de una casa, podemos decir que el Blue Print,
es el plano de la misma, que detalla todas las características, dimensiones, espacios, etc. de cómo
la quiero construida.
Abro a continuación un paréntesis para compartirles la siguiente información que fue sintetizada del
link: https://www.guru99.com/sap-business-blueprint.html el 6 Diciembre 2018, ya que por
cuestiones de confidencialidad no incluiré metodologías o estrategias seguidas en lo particular para
JAFRA.
¿Porque necesitamos un Blue Print?
El proceso de Blue Print se enfoca en entender, verificar y documentar el alcance del proyecto y
especificaciones. También nos ayuda a definir su objetivo conceptualmente y de forma práctica.
Se puede crear un cuestionario para los usuarios del sistema, mismo que se puede aplicar a los
propietarios de los procesos de negocios, ellos llenarían el cuestionario y lo entregarían a los
consultores funcionales. Este proceso ayuda a que los consultores entiendan como funciona el
negocio, y cual sería la mejor forma de implementar dicho proceso en SAP.
En este proceso, se tiene una seria de sesiones de trabajo que formarán la base para la
implementación. Aquí todos los detalles deberán de ser mapeados a los procesos de negocio,
mismos que se deberán plasmar en la documentación.
Proceso para crear un Blue Print SAP paso a paso:
1. Desarrollar un inventario de procesos: Es el primer paso para hacer un inventario de todos
los tipos de procesos. Este paso ayuda también a determinar el orden de dichos procesos.
Aquí se puede planear la implementación del sistema actual. Es esta etapa, también se
pueden identificar las necesidades de desarrollo para una pantalla en particular, algún
reporte, tropicalización o flujo de trabajo.
2. Crear la base para la creación del blue print de negocios: Esta etapa ayuda a desarrollar el
alcance del proyecto SAP. Aquí se tiene que crear un plan antes empezar a desarrollar un
nuevo ERP. Reunir autorizaciones de seguridad y requerimientos de entrenamiento. La
definición del alcance ayuda a definir los límites entre los diferentes procesos. También nos
da información básica de un proceso en particular.
3. Crear el Blue Print: Crear el blue print involucra entender en que parte del proceso la
responsabilidad cambia entre dos áreas o departamentos. El paso necesita aplicar la
información explicando que departamento o individuo trabaja que parte del proceso de
62
principio a fin. Aquí también se necesita definir la información asociada a Datos Mestros
(Master Data) al enfocarse en los puntos de integración y dando soporte a las actividades
de la organización/compañía.
4. Estimar Tiempos y Costos: Antes de establecer los objetivos de los procesos es vital tener
una línea base de medición. En esta fase, se necesita determinar el costo y tiempo de
implementación para cada proceso. Este paso también ayuda a definir los parámetros que
se utilizarán para mejorar los objetivos de la organización.
5. Verificar el Blue Print SAP: En esta fase, es esencial tener retroalimentación de las áreas
usuarios. Esto nos permite asegurar que lo identificado y definido en el blue print refleja la
realidad. Esta fase también ayuda a tener todo el soporte y recomendaciones de los
patrocinadores del proyecto.
6. Entregar técnicas de mejoramiento: Siguiendo un esquema organizado para la mejora de los
procesos utilizando métodos como la evaluación de valor agregado a las tareas, eliminando
redundancia en los procesos, reduciendo tiempos de procesamiento, y utilizando
automatización cuando sea posible. Esto entonces, ayudará a crear un valor para el negocio
(business value)
7. Desarrollar controles y métricas internas: El siguiente paso será de crear un control y
métricas internas que ayudaran a dar seguimiento y monitorear el progreso. También ayuda
a crear herramientas para incrementar la eficacia y eficiencia de la implementación de
procesos de negocio en SAP.
8. Ejecutar una prueba de concepto: Es esencial ejecutar una prueba de concepto tanto como
lo sea posible, ya que ayuda a verificar el sistema SAP sin la necesidad de mayores
inversiones. Este paso ayuda a resolver errores y ayuda a tener certeza de que el proceso
trabaja de acuerdo a las necesidades del negocio.
9. Implementar los cambios: En este paso, los nuevos procesos diseñados son implementados.
Este paso permita comunicar la información correcta a la gente correcta.
10. Perseguir el mejoramiento continuo: En este último paso, se necesita seguir un concepto de
flujo de mejora continua. Este paso se trata completamente de establecer mejoras a los
procesos de negocio, para lo cual se tendrán que realizar evaluaciones continuas de
efectividad.
Se cierra el paréntesis de la teoría.
La mayoría de los pasos planteados en esta metodología teórica, tienen su uso en la vida real, sin
embargo, cada compañía tiene una cultura organizacional diferente, objetivos y presupuestos
diferentes, por lo que X metodología que seguí para la compañía A, podría no funcionar del todo bien
para la compañía B aún siendo de la misma industria o competidores.
Por lo que entonces toma una gran relevancia la selección de nuestro SI (system integrator) socio
de negocio, ya que será a través del proceso de selección del mismo que seremos expuestos a
diferentes estrategias y metodologías pensadas y diseñadas en base a un acercamiento inicial con
cada uno de los participantes en el proceso de selección de SI.
Cada aspirante a SI, deberá de detallar entonces las estrategias y metodologías propuestas de Blue
Printing, y será responsabilidad de los patrocinadores del proyecto y del equipo PMO (Project
Management Office) del proyecto de evaluar la estrategia y metodología que mejor se adapte a la
cultura organizacional, objetivos del proyecto, y presupuesto.
63
Son grandes decisiones, de las cuales se derivarán directamente los buenos o malos resultados de
la implementación. No es un viaje sencillo, ni tampoco es corto e igualmente aplica la analogía de
un matrimonio pero en este caso lo veo de 3 cabezas: SAP, el SI y la compañía en cuestión, así que
la complejidad y retos serán muy significativos.
Desde el punto de vista usuario, los grandes retos durante el blue printing están enfocados a toda la
estrategia interna para realizar el inventario de los procesos, analizarlos, orquestarlos,
documentarlos, considerar cuando aplique múltiples modelos de negocio para realizar los ajustes,
escalamientos y aprobaciones necesarias. Se requiere así de un gran esfuerzo previo a cualquier
implementación de SAP tan sólo identificar en donde estamos parados desde un punto de vista de
requerimientos, sin olvidar que muchos procesos de negocio tienen caducidad, que cumplen un ciclo
y tendrán que renovarse, por lo que se tratará de un ente llamado “requerimientos” viviente el cual
se tendrá constantemente que actualizar, sin olvidar que aún dentro del periodo de implementación
seguirá vivo.
64
3.13 Indispensable involucramiento con los usuarios
Durante el desarrollo de este informe, tanto en el capítulo del soporte al sistema comercial-ERP
JAFRA, como en actual de Implementación SAP, he insistido y recomendado ampliamente acerca
de una complicidad profesional entre áreas de IT y los usuarios.
En lo particular durante la implementación SAP, las recomendaciones se amplifican, ya que no
únicamente se tratará de tener la cercanía durante la etapa de definición de requerimientos, sino que
se debe de tener el contacto durante todas y cada una de las etapas de la implementación.
Las metodologías de implementación SAP incluyen pasos específicos para mantener este contacto,
sin embargo también es responsabilidad del equipo PMO (Project Management Office), el
asegurarse de que en todo momento el usuario está presente.
No se debe en lo absoluto, involucrarlos únicamente durante las etapas “convenientes” durante la
implementación; en algunos proyectos frecuentemente sólo se les involucra mientras se toman los
requerimientos, y pasan meses y meses sin volver a tener un contacto, hasta que se presentan las
etapas de pruebas y entonces es cuando con mucha frecuencia se encuentran discrepancias entre
lo que definí como usuario, y el SI entregó.
Recordemos que en especial proyectos de esta magnitud y alcance para una organización, no debe
tratarse el proyecto como un proyecto más de TI, porque entonces los usuarios entran en un área
de confort, y no se la da la prioridad e importancia que debería tener al tratarse en realidad en un
proyecto de Negocio, para el Negocio.
El involucrar constante a los usuarios no es un tema sencillo, requerirá de un liderazgo firme pero
balanceado por parte del SME-Líder de Negocio; En este role, fue indispensable para mi mantener
tareas de entrenamiento y asignación de tareas con los usuarios para precisamente mantener el
compromiso y prioridad en el proyecto, y tener una estrategia de comunicación verbal y escrita
indicando en todo momento es SU proyecto, y que estamos compartiendo las responsabilidades
para llevarlo a una implementación exitosa en un enfoque completamente de hacer equipo.
Las etapas de implementación consistieron así en:
Toma de requerimientos; un proceso extremadamente complejo, donde se deben de
identificar y documentar los procesos de negocio, siguiendo como base un inventario de los
mismos.
Mejoramiento de procesos de negocio clave, evitando redundancias y persiguiendo
eficiencias. Se necesitan extensas sesiones de trabajo para lograrlo; será necesario escalar
algunos temas que tengan un impacto significativo en el negocio.
Revisión de procesos de negocio con un enfoque de múltiples modelos de negocio para
poder empatar, negociar, escalar cualquier ajuste a los mismos y que cumpliera con los
requerimientos de los mercados-países involucrados.
Sesiones de trabajo exhaustivas con los consultores, para poder permear el conocimiento
de los procesos de negocio y aclarar cualquier duda sobre los requerimientos
documentados.
Revisión de la documentación Blue Print con consultores SAP, para validar los procesos de
negocio ya con funcionalidad SAP; tener sesiones de “estirar, aflojar, apretar” con los
65
consultores cuidando en todo momento la eficiencia de los procesos de negocio a
implementarse.
Revisión de prototipos disponibles; hay funcionalidad estándar en SAP que para ciertos
módulos y funciones de una organización pueden presentarse a los usuarios y tener
retroalimentación de primara mano sobre como podría funcionar determinado proceso;
recordemos que una de las premisas en SAP es mantener una línea muy rígida para que el
negocio adopte procesos estándares evitando las repercusiones antes mencionadas en
subtemas anteriores, como costos, tiempos, etc. Es muy interesante esta etapa ya que con
un enfoque objetivo y propositivo, podemos ajustar algunas actividades del negocio
fácilmente al estándar presentado, dejando a un lado la rigidez de ciertos pasos.
Recordemos temas anteriores como la resistencia al cambio; el hecho de que se tenga un
proceso de negocio que se ha ejecutado de X forma, o siguiendo cierta secuencia de pasos,
no quiere decir que es la forma más eficiente de resolverlo, recordemos la analogía de cómo
a una hormiga; en SAP se encontrarán algunas opciones en su estándar, con la premisa de
seguir las mejores prácticas de negocio para llegar al mismo resultado.
Revisión de datos maestros: Los datos maestros en SAP, se determinan por cada módulos,
por ejemplo SD (Sales & Distribution), MM( Material Master), FI (Finance), etc; siendo
algunos de los más representativos el Maestro de Clientes, el Maestro de Materiales
(productos de venta tipo SKU), Maestro Ordenes, Maestros de registros financieros, etc, etc,
etc. Es todo universo de datos maestros. Toda esta información es lo que en realidad le da
vida a toda la funcionalidad en SAP, sin datos maestros no puedo pensar en prototipos y
mucho menos iniciar etapas de desarrollo. Se trata de una tarea muy exhaustiva para definir
todos y cada uno de los objetos de la base de datos (tablas, campos, relaciones,
cardinalidad, etc), para estar seguros que toda la información relevante e indispensable para
el funcionamiento de mi negocio en SAP forme parte de los datos maestros. Aun cuando
todos los temas técnicos específicamente hablando de estrategias de migración, mapeo con
bases de datos legadas, etc, se revisan y validan con el o las áreas de TI de los sistemas
legados, siempre será responsabilidad de los usuarios validar y asegurar sin considerar
ternísimos que todos y cada uno de los atributos de las diferentes entidades del negocio
estén presentes y tengan un sentido de uso en el nuevo sistema SAP; es también así una
oportunidad para ejecutar un cierto grado de limpieza de las bases de datos.
Un aspecto muy positivo de utilizar la metodología SCRUM, es precisamente como apoyo
directo a los usuarios en el sentido de presentar funcionalidad real, palpable hasta cierto
punto y que de una percepción de tranquilidad y avance de la implementación. Los
entregables se pueden derivar idealmente de configuraciones (recordemos el apagado o
encendido de Switches, valores en parámetros, etc) y en el mejor de los casos de desarrollos
nuevos mínimos. Así que los usuarios tendrán la oportunidad de revisar como se ven sus
procesos en SAP conforme el ciclo de desarrollo avanza; esto permite iniciar en etapas
relativamente tempranas del proyecto con pruebas unitarias de funcionalidades específicas;
cuando ya se tiene avance importante en el desarrollo, esta misma metodología permite
identificar funcionalidad unitaria disponible entre N módulos, para iniciar etapas de pruebas
integrales.
Embajadores del nuevo ERP SAP: Estamos en un mundo tan humano como lleno de
percepciones, por lo que es indispensable que todos los usuarios involucrados durante las
etapas antes mencionadas den el soporte como embajadores del nuevo ERP SAP, como
embajadores del cambio, como pruebas vivientes y miembros del equipo que puedan
compartir un testimonio con el resto de la organización. Aquí se ligan muchos temas y
estrategias con el quipo OCM (Organizactional Change Management) del proyecto.
66
Todas las actividades antes mencionadas a lo largo de las etapas de la implementación del nuevo
ERP SAP, que como podemos reflexionar son clave para el éxito del proyecto, deben de estar
soportadas por una estrategia de OCM (Organizational Change Management) del proyecto.
Tan sólo en base al número de actividades descritas por cada etapa, podemos inferir que se trata
de largas jornadas de trabajo, por lo que parte de las actividades de OCM será precisamente
identificar todos esos usuarios clave, para que liderados por el SME-Líder de Negocio, formalmente
sean parte del proyecto; habrá usuarios que dadas sus actividades actuales, se pueda percibir que
pueden dar el 50% de su tiempo, sin embargo la realidad nos enseña que es muy difícil tener una
persona asignada 50% de su tiempo a la tarea X, y el otro 50% a la tarea Y; por lo que idealmente
se recomienda dedicar recursos de usuarios dedicados al proyecto 100%, para lo cual hay todo un
apoyo de OCM y las áreas de recursos humanos para generar estrategias de reemplazo temporal,
incentivos, etc, que permitan tener a todo el equipo con un nivel de motivación importante.
Involucrar a los usuarios durante todas las etapas del proyecto, en un escenario de ERP SAP Global,
incrementa la complejidad de las tareas antes mencionadas ya que nos guste o no, el lenguaje de
negocios por excelencia es el inglés; si bien se trata de equipos multiculturales, aquellos cuya
situación de vida tienen como lengua materna el inglés, no sufrirán tanto como la contraparte del
equipo para quienes la comunicación en inglés verbal y escrita no es natural.
El idioma es en realidad un tema complejo; ¿ Cuántas veces hemos escuchado que “aún hablando
el mismo idioma (desde un punto de lenguaje materno), no nos entendemos”? ahora, extrapolemos
el idioma a cada una de las tareas antes mencionadas, todo un reto ¿Cierto?; No me queda más
seguir insistiendo en la recomendación de ver cada reto o problema como una oportunidad, y en el
caso del idioma se tratará de un crecimiento a nivel personal, así que siempre valdrá la pena invertirle
todo el tiempo y esfuerzo que sea necesario.
67
3.14 Requerimientos que cambian durante la implementación
Como se ha mencionado con anterioridad, los proyectos de implementación ERP SAP, se miden
normalmente en años.
Con este preámbulo, es imposible pensar que durante una implementación de cuando menos un par
de años, el proyecto pueda dictar al negocio que se paren las prensas, que no haya más innovación
porque estaríamos entonces impactando directa y negativamente al negocio.
Idealmente, se debe tener una estrategia de comunicación respecto a cualquier cambio en el
negocio, invitando a todos y cada uno de los ejecutivos a que se comunique esta estrategia a los
niveles más bajos de la organización, por lo que habrá una planeación durante la etapa de
implementación del proyecto, y dichos cambios planeados deberán de formar parte de los
requerimientos en el alcance del proyecto.
¿Pero qué hay de todos aquellos cambios o desviaciones no planeados? Hablando del deber ser,
desde mi punto de vista, parte de las funciones de PMO, necesitan incluir actividades y funciones de
control de cambios.
Es con una desafortunada frecuencia, que aún teniendo un involucramiento tan serio de áreas
usuarios en el proyecto como se describió en el subtema anterior, se presenten casos en donde el
negocio por las razones que hayan sido, realiza cambios en sus procesos de negocio actuales sin
ninguna comunicación al equipo de PMO ni a los SME-Líderes de Negocio, ni a los usuarios
involucrados.
Como ejemplos se pueden presentar, desde temas relativamente sencillos de solucionar como
omisiones de forma de facturas, hasta temas más complejos que impliquen cambios de fondo de
diferentes magnitudes, como un campo de base de datos olvidado que se tiene que imprimir o
desplegar en el back-end o front-end, un campo que no se haya calculado correctamente (aun
cuando un requerimiento esté firmado con sangre), o un campo que el negocio inicio a comunicar
con sus clientes finales y para el cual no tengamos un proceso que lo calcule en SAP, entre muchos
otros.
Aún cuando se hayan planeado y comunicado estrategias para evitar desviaciones en los
requerimientos, es un hecho que algunos casos desafortunados se van a presentar en cualquier
implementación de ERP, ya sea SAP o no SAP.
En el caso de SAP, el impacto en costo de algunas de estas “omisiones”, pueden tener implicaciones
de costo y tiempo significativas; dependiendo de la etapa de la implementación en las que se hayan
descubierto, podrían incluso poner en jaque una fecha de puesta a producción.
No aplicable a SAP, he tenido amargas experiencias donde un par de días antes de la puesta a
producción se descubren errores que verdaderamente ponen a todo el mundo a correr para
solucionarlos sin importar quien o quienes hayan cometido el error o la omisión.
Todos estas omisiones, errores, se tendrán que revisar y priorizar con el negocio para determinar si
todos y cada uno de estos cambios son realmente necesario e indispensables para que el negocio
función; en algunos casos se podrá negociar una liberación posterior a la puesta en marcha del
68
nuevo ERP, o se podría reducir el alcance de dicho cambio, nuevamente entrando a etapas de
aprobaciones y escalamientos.
El tema del impacto económico, es irreversible. Todas las omisiones y errores tendrán que ser vitas
objetivamente en blanco y negro y tendrán un costo, por lo que el impacto desde un punto de vista
de costo, deberá estar de la mano con el impacto al negocio y a la fecha de puesta en marcha del
nuevo sistema.
Los presupuestos en los proyectos son finitos, las expectativas de tiempos de entrega y fechas de
puestas en producción tienen que respetarse tanto como humana y profesionalmente sea posible,
por lo que todas las desviaciones o cambios a requerimientos no planeados deben de evitarse a
toda costa.
69
3.15 Seguriad en SAP A título personal, puedo compartirles que SAP es uno de los ERP en el mercado donde la seguridad
es un tema muy serio.
SAP tiene funcionalidad dedicada para la administración de la misma, y tiene una flexibilidad digamos
sana, que permite definir perfiles de puesto con accesos específicos a transacciones u opciones de
menú.
SAP tiene una reputación, incluso entre sus consultores de ser muy “chismoso”, ya que todas y cada
unas de las acciones que los usuarios realicen serán registradas, y no hay forma de borrarlas.
Cualquier buen o mal uso de cualquier transacción u opción de menú tendrá la firma del usuario que
lo ejecutó, ¡no hay escape¡
En los temas de seguridad asociadas a transacciones u opciones de menú, se tiene que seguir una
estrategia donde todos y cada uno de los procesos de negocio, deberán de tener asociadas un grupo
de transacciones u opciones de menú que permitirán a los usuarios ejecutar todos y cada uno de los
pasos del proceso de negocio en cuestión en base al uso de ciertas pantallas o ejecución de
procesos que siempre tendrán ligada un código de transacción SAP.
Cada SME-Líder de negocio, tendrá así la responsabilidad de definir los perfiles de usuario con los
códigos de transacciones necesarios para poder ejecutar determinado proceso de principio a fin.
Como ejemplos prácticos en SD (Sales & Distribution), hablando de usuarios de áreas de Servicio al
Cliente, deberá de haber diferentes perfiles de usuario, por ejemplo, un perfil para ejecutar
transacciones y poder abrir de sólo lectura, habrá otros perfiles que puedan además de visualizar,
también realizar cambios a datos maestros, y más allá de perfiles de usuario específicos habrá
usuarios que además de acceso al módulo SD, tendrán acceso a transacciones/pantallas en otros
tantos módulos de acuerdo a los perfiles de puesto.
La definición de los perfiles de usuario es un tema complejo, que requiere de esfuerzos significativos
para tenerlos en su punto; los perfiles de usuario tienen una gran relevancia en el uso del sistema
que en etapas tempranas del proyecto tiende a minimizarse, a restarle importancia, porque en etapas
tempranas del proyecto siempre se asignarán usuarios todos poderosos con acceso a todas las
transacciones incluyendo muchas transacciones que en una vida productiva real, nadie debería de
tener acceso, por diferentes políticas preestablecidas y de mejores prácticas de SAP.
Sin embargo, de acuerdo a las etapas de desarrollo basadas en SCRUM, no resulta tan práctico la
definición de los perfiles de usuario en etapas tempranas; mi recomendación para sufrir lo menos
posible este gran tema, será el actualizar constantemente la documentación de perfiles de usuarios,
incorporando durante cada entregable de ciclos SCRUM las nuevas transacciones, para primero
tener un inventario confiable de todos los códigos de transacciones/pantallas, y con ello sentar la
base de todos los perfiles que se tendrán que definir en base al uso de todos y cada uno de los
procesos de negocio definidos en la documentación de Blue Print.
Siguiendo el enfoque de desarrollo SCRUM, y recordando los dos grandes temas de pruebas
unitarias y pruebas integrales, se tendrá que iniciar tan pronto como las configuraciones de seguridad
lo permita la ejecución de dichas pruebas utilizando ya usuarios específicos asociados a los perfiles
de usuario documentados y configurados. Es de vital importancia que se realicen estas pruebas
70
utilizando los perfiles de usuario, y es muy fácil pasarlo por alto, porque siendo muy prácticos y
honestos, realizar las pruebas unitarias e integrales con usuarios todos poderos es lo mejor desde
un punto de vista de un usuario que tiene muy poco tiempo para realizar las pruebas; Y aquí una
recomendación más; les puedo asegurar que el tiempo invertido en hacer pruebas unitarias y
pruebas integrales con usuarios asociados a los perfiles de usuario, se capitaliza ampliamente de
mediano a largo plazo, porque, nos guste o no, y de forma inevitable, se tendrán que hacer las
pruebas con perfiles de usuario, y el trabajar directa y constantemente con usuarios todo poderosos
en realidad genera una serie de re-trabajos exponenciales, porque todas y cada una de las
aprobaciones unitarias e integrales se tendrán que volver a realizar ahora con los perfiles de usuario,
así que lo más conveniente es ordenarnos, e incluso forzar el uso de los perfiles de usuario tan
pronto como el desarrollo SCRUM lo permita. Es imprescindible hacer las pruebas y encontrar todos
los errores posibles asociados a seguridad de perfiles de usuario.
Han existido muchos casos reales en implementaciones SAP, donde el tema de seguridad se dejo a
un lado, y después al otro lado, después se dejo al final, para finalmente nunca ejecutarlo, y no es
muy difícil imaginar el resultado cuando llega el go-live.
Durante el go-live, todos y cada uno de los usuarios finales tendrán asociado uno o más perfiles de
usuario de seguridad, y si nunca se configuraron, y mucho menos se hicieron las pruebas
correspondientes, terminarán con un sistema SAP que nadie va a poder usar, y que empezará a
generar cualquier cantidad de errores que NADA tendrán que ver con la funcionalidad de SAP
misma, porque con los usuarios todo poderosos funcionó ¿cierto?; y es entonces cuando esto genera
una pésima percepción en la implementación de SAP, porque escucharán frases como “nada
funciona”, “todo marca errores”, etc.
Esta es una tarea como ya lo indique compleja, requiere de una inversión de tiempo importante, aún
en etapas de la implementación cuando pareciera que no queda tiempo para la “latosa” seguridad,
que “flojera para que sirve”, se tiene que enfatizar su importancia a través del equipo de PMO (Project
management office), y porque no, si nadie responde se valdrán estrategias hasta de desactivar a los
usuarios todo poderosos para “invitar” amablemente al uso de los perfiles de usuario de seguridad.
No lo olvidemos, la seguridad es un factor de éxito del proyecto, y pueda dar una pésima percepción
de implementación si no nos aseguramos que ha sido implementada correctamente.
71
3.16 Simulación de carga de trabajo productiva del nuevo ERP
Este tema es sumamente importante y es motivo de fracasos y cancelaciones de proyectos.
El objetivo de un nuevo ERP además de cubrir con todos y cada uno de los requerimientos de
negocio, será el de también cubrir con los requerimientos de un sistema ERP, dentro de los cuales
destacan pero no se limita a:
Tiempos de respuesta de procesamiento batch: Dentro de los procesos más importantes
destacarían: facturación, recepción de pagos, procesamiento de pedidos para centros de
distribución, procesos de impresiones de documentos en centro de distribución,
procesamiento de comisiones, entre otros.
Tiempos de respaldo: de bases de datos, del sistema, DRP (Disaster recovery plan), entre
otros.
Tiempos de respuesta de pantallas de usuarios back-end: Todas aquellas pantallas de
usuario en donde se ejecute cualquier tarea con el nuevo ERP.
Tiempos de respuesta de aplicativos WEB de clientes finales front-end: Orientado a clientes
finales, se trata de un punto extremadamente importante a cuidar, ya que de ello dependerá
la buena o mala percepción de nuestro usuario final, recordemos que el objetivo final de
cualquier sistema de información, es tener contento a nuestro usuario final, a quienes
colocan un pedido para realizar una compra, quienes entran a su portal a realizar un pago,
a consultar una amplia gamas de reportes para el soporte de sus actividades, entre muchos
otros usos.
Tiempos de actualización de sistemas Business Intelligence: Especialmente en escenarios
SAP, hay una tendencia importante de implementar a la par implementar sistemas Business
Intelligence que complementan la amplia gama de aplicaciones disponibles. Sin entrar a
detalles técnicos, todos estos sitemas en base a cubos de información requerirán de una
frecuencia de actualización en base a todos los registros transaccionales en tiempo real. Es
un tema generalmente complejo.
Las comparaciones siempre serán inevitables, nuevamente, vivimos en un mundo lleno de
percepciones, y en un tema tan relevante como “un nuevo” sistema son inevitables.
Pensemos en un escenario hipotético, digamos favorable para SAP, donde nuestro sistema legado
está plagado de problemas de performance, y en donde el nuevo sistema será el salvador, el mesías
de los sistemas tan esperado.
Ahora, pensemos en un escenario hipotético contrario, donde los temas de performance, pueden ser
la fortaleza del sistema legado.
En este punto les pido recordar sobre un tema tocado con anterioridad: La Arquitectura de mi nuevo
ERP. Y Es precisamente aquí donde los escenarios hipotéticos o de la vida real convergen, para
formar una percepción positiva, negativa, neutral, o en casos extremos me llevan a cancelar un
proyecto por extraño o ajeno que pueda parecer.
Todos los proyectos siguen estrategias en lo particular para diferentes temas, en la arquitectura
misma, hay toda una serie de metodologías para determinar especificaciones de servidores,
arquitectura de hardware, procesadores, memoria, espacio en disco, etc.
72
Hay estrategias que dictan que no es necesario involucrar a los usuarios, que los temas de
performance, incluyendo la simulación de carga de trabajo productiva, es sólo de los gurus de TI y
SAP.
Y es aquí como en base a la experiencia, el deber ser, desde mi punto de vista, me dicta que no
pueden ser sólo tareas de TI y SAP unilaterales y ajenas a los usuarios. Hay un principio básico muy
importante para mi respecto a los puntos ciegos y el tener una soberbia profesional que nos de una
mala autopercepción de que todo se conoce, y de que no hay nada nuevo por aprender.
La vida real nos enseña que hay escenarios completamente inesperados, aun y cuando existan
implementaciones anteriores “similares”, siempre se tiene que dar el beneficio de la duda, y escuchar
y hacer participe en todas las pruebas de performance a los usuarios, porque no hay nadie mejor
que los usuarios que conozcan el negocio, que conozcan los tiempos de respuesta esperados,
quienes sepan de los impactos, por ejemplo de una captura de pedidos WEB que no debería de
pasar de X número de minutos, ya no en sí del flujo mismo, porque el usuario participó en la definición
de dichos requerimientos, sino específicamente de la percepción del tiempo de respuesta cuando yo
doy un click y espero una respuesta del sistema.
Pueden ser temas dolorosos en lo profesional y personal; temas que impliquen incluso el
cuestionamiento de las metodologías, de los ejecutores de las tareas, del equipo de administración
del proyecto, pero ¿Qué preferimos?, omitirlo y que este tema ocasione incluso la cancelación de un
proyecto con todo lo que ello implica; o bien, hacer una inclusión balanceada de los usuarios clave,
que quizá represente una pequeña desviación de presupuesto, y seguramente en tiempos de puesta
a producción.
Podríamos preocuparnos en el corto plazo por una desviación en presupuesto y tiempos de puesta
a producción, pero les aseguro, que a largo plazo será mucho menos costoso que un escenario de
cancelación, re-planeación y re-liberación de la solución.
Retomando el escenario hipotético de un sistema legado donde el performance no es un problema,
es todo un reto para SAP competir en el mundo de percepciones, se tienen que cuidar a demás de
todos los temas de procesos de negocio de una excelente arquitectura; y aquí hago una pregunta
obligada: ¿Quién quiere un sistema ERP nuevo con tecnología de punta cuya percepción en el día
a día de clientes internos y externos dicta que es más lento que el sistema “viejo” legado?
En un mundo de percepciones, una mala percepción puede mover montañas, y puede ser muy difícil
retomar el camino, y más difícil aún aguantar el impacto en el negocio, las ventas pueden caer
significativamente y representar todo un reto volver a ganar la confianza de los clientes finales.
73
3.17 Entrenamiento a Usuarios del nuevo ERP SAP
El entrenamiento es un área crucial para la adopción y aceptación del nuevo sistema ERP.
El reto más importante será determinar los temas sobre los cuales se establecerá una capacitación
formal. Estos temas se tendrán que definir de lo general a lo particular.
Respecto al entrenamiento para usuarios internos, las estrategias a seguir son comúnmente
definidas entre el equipo de OCM (Organizational Change Management) y el área de capacitación
de Recursos Humanos de la organización.
Hablando de clientes externos, normalmente se trata de aplicativos WEB, para los cuales se
recomienda seguir las estrategias de entrenamiento existentes ya que no hay nadie mejor que el
negocio mismo que ya ha experimentado los retos de diferentes perfiles de clientes, localidades
geográficas, cultura organizacional entre muchos otros factores que se tienen que cuidar y que muy
difícilmente consultores SAP podrían tener el conocimiento.
Entrenamiento de clientes internos
A continuación listaré una serie de pasos que recomiendo seguir en base a la experiencia dentro de
mis funciones como SME-Líder de Negocio del módulo SD (Sales & Distribution):
Identificación y secuenciación de procesos de negocio: Idealmente se debe de utilizar como
base el inventario de procesos de negocio documentados durante la fase de blue print; esto
nos dará la columna vertebral y secuencia de los cursos.
Identificar al Capacitador: Desde mi punto de vista transmitir el conocimiento es un arte, un
don, que no cualquiera tiene, pero que en ocasiones se puede desarrollar teniendo cierto
perfil y personalidad. Es ideal, que un miembro del equipo de usuarios del módulo, sea el
capacitador. Identifico los siguientes beneficios de seguir este enfoque:
o Siempre será mejor recibido el conocimiento si alguien “conocido” en el negocio
imparte la capacitación. Se reduce considerablemente la barrera de comunicación
asociada al miedo a preguntar.
o Un usuario que haya participado durante todas las etapas de la implementación,
tendrá un claro conocimiento de los procesos de negocio legados, y de los procesos
de negocio nuevos, brindando una riqueza en el entrenamiento que permitirá
fácilmente identificar las diferencias y ayudar a entender porque un nuevo proceso,
idealmente optimizado hará mejor sentido al negocio.
o Teniendo idealmente una formación de usuario (con excepción de mi caso con un
enfoque de TI), el entrenamiento se dará con un lenguaje coloquial, de usuario a
usuario, sin tecnicismos, dando ejemplos prácticos y generando una empatía con
los participantes.
Definir el material de entrenamiento: El material de entrenamiento juega un papel muy
importante dentro de la capacitación, además de ser un eje para el capacitador por
definición, también nos ayuda a documentar la capacitación y se podrá y deberá utilizar como
material de referencia ante cualquier duda al utilizar el nuevo ERP.
Elaboración de estrategias de evaluación: Nos guste o no, necesitamos tener una métrica
sobre todos los temas de capacitación, así que se necesitan incorporar evaluaciones al
término de cada sesión de capacitación. Tendrá que haber un apoyo por parte del área de
recursos humanos para incorporar los resultados de las evaluaciones como parte de los
74
objetivos de evaluaciones anuales de los usuarios (empleados al final del camino) que
inclusive sean considerados para temas de bonos y de aumentos de salarios anuales. Se
tiene que generar un compromiso.
Definir un calendario por proceso de negocio o tema, con un número de horas de
entrenamiento suficientes: Es muy importante dar la capacitación de temas considerando
todos los aspectos desde la presentación, teoría, procesos actuales-procesos nuevos,
demos, simulaciones, ejercicios y evaluaciones; ninguno de estos temas se deberían de
minimizar, por lo que es necesario un buen análisis de cada proceso de negocio o tema para
darle el tiempo razonable.
Identificar necesidades generales de capacitación: Por ejemplo, la nueva interfaz de usuario.
SAP puede parecer a una primera vista “imponente”, sobre todo para aquellos usuarios que
vengan de ERPs legados con interfaces de usuarios viejas como por ejemplo las pantallas
“verdes” AS/400 referidas en el capítulo anterior, que básicamente tienen una funcionalidad
gráfica limitada, y no existen conceptos como íconos, botones, menús, etc. Hay casos no
tan extremos, sin embargo es imperativo que TODOS los usuarios tengan un entrenamiento
sobre la nueva interfaz de usuario y conocer temas que pueden parecer triviales, pero que
pueden representar una barrera para muchos usuarios finales y nuevamente retar a la
adopción del nuevo ERP.
Es muy importante mencionar, que SAP tiene herramientas de capacitación extremadamente
buenas, personalmente no había tenido la oportunidad de conocerlas. En lo particular me gustaría
compartir acerca de una herramienta que permite grabar una simulación, misma que no se limita a
sólo ser un simple video, sino que es interactiva, incluso se le pueden programar eventos, respuestas
múltiples, reaccionar a las respuestas tecleadas por los usuarios y en algunos casos servir como una
herramienta para evaluar a los participantes en el entrenamiento y lo más importante como una
herramienta donde siempre se podrá practicar la funcionalidad sin necesidad de utilizar en vivo el
nuevo ERP.
También cuenta con herramientas que facilitan la documentación de los procesos y que son de
mucha ayuda.
Hay consultores SAP dedicados exclusivamente a ejecución de estrategias de capacitación,
utilizando las herramientas antes mencionadas y otras más. Siendo la capacitación un tema crucial
en el éxito y adopción del nuevo ERP es altamente recomendable como estrategia general del
proyecto que sea incluidas tanto como el presupuesto lo permita.
Una ventaja del ERP SAP es que tiene inmersa en su diseño funcionalidad multilenguaje. Esto es
un factor de éxito muy importante ya que el nuevo ERP se podrá implementar sin ninguna limitación
de lenguaje y la adopción será aún más natural.
En escenarios de implementaciones de ERP globales, es crucial eliminar la barrera del lenguaje
escrita y verbal, por lo que las capacitaciones se deberán de dar en el lenguaje materno de los
participantes, generalmente se tendrá la versión en diferentes idiomas sobre el mismo tema, lo cual
agrega un reto adicional durante la revisión de los materiales de entrenamiento, sea la forma que
sea - simulación, video, documento escrito- se tiene que cuidar que los conceptos de negocio no
cambien o se desvirtúen por temas de traducciones. Hablando de lenguajes Inglés y Español, es
muy importante considerar que algunos términos en inglés no tienen traducción directa en español,
y viceversa, por lo que en algunos casos se deberán de utilizar los términos que mejor hagan sentido
a la audiencia en cuestión.
75
Una pregunta obligada a este punto sería ¿Cuándo es el mejor momento para dar la capacitación
de usuarios internos? Somos seres humanos, ¿Cierto? Y como tales tenemos limitaciones naturales,
siendo una de las más importantes, que se nos olvidan con mucha facilidad nuevos conocimientos
que no practicamos o que no utilizamos con frecuencia. Por lo que en base al plan de trabajo del
proyecto, se tiene que identificar zonas de tiempo lo más cercanas a la fecha de la puesta en
producción del nuevo ERP.
Algunas acciones para mitigar el “olvido” del entrenamiento que se pueden seguir son:
Habilitar tanto como el presupuesto y las actividades lo permitan, un ambiente de pruebas
de usuario, asumiendo que se han finalizado todas las etapas de desarrollo y pruebas
unitarias e integrales. Tiene que ser terminadas las tareas antes mencionadas, ya que
debemos de evitar a toda costa que los usuarios estén practicando sobre funcionalidad
incompleta o que no se haya aprobado unitaria e integralmente hablando.
Hacer un plan para dedicar ciertas horas del día o de la semana a repasar los materiales de
entrenamiento, en particular las simulaciones con todas las ventajas anteriormente descritas
ya que darán una sensación y uso 99% cercano a la realidad.
Aun cuando se hayan ejecutado las mejores estrategias de capacitación, es increíble, pero no
sorprendente que una vez que el sistema fue liberado algunos conceptos se olviden. Trataré algunas
estrategias para mitigar estos retos en un subtema subsecuente dedicado a la puesta a producción
(Go Live) y periodo de estabilización.
Entrenamiento de clientes externos
Hay también muchas herramientas utilizadas para clientes externos que igualmente pueden aplicar
a clientes externos, sin embargo, hay temas de logística, como la distribución, que se tienen que
tomar en cuenta considerando en todo momento el universo de clientes externos y sus perfiles.
Anteriormente mencioné y reafirmo que se pueden hacer uso de las estrategias actuales de
capacitación de clientes externos de la organización ya que debe idealmente se cuenta con una
experiencia y madurez que las respalda, y en casos particulares se podrán combinar con las
herramientas SAP ofertadas.
Para clientes externos, es necesario enfatizar el uso de lenguaje coloquial, de utilizar ejemplos, y
siguiendo tantas estrategias de capacitación disponibles para que se ajusten lo más posible al perfil
de los clientes.
Algunas de las herramientas que oferta SAP, como las simulaciones también se pueden “publicar”
en alguna sección del portal de negocio de nuestros clientes externos de tal forma que siempre estén
a la mano.
76
Recomendaciones generales
En general, la estrategia de capacitación descrita en este subtema, fue muy buena, sin embargo me
gustaría proponer una serie de recomendaciones como resultado de la retroalimentación de los
usuarios una vez terminada la etapa de capacitación.
Entrenamientos de procesos integrales.
La estrategia se derivó de lo general a lo particular, y desde mi punto de vista se pasó por alto un
tema muy importante; para describirlo me permitiré primero hacer una analogía en el área de pruebas
de usuario, teniendo pruebas unitarias y pruebas integrales; así el entrenamiento debería seguir el
mismo enfoque, ya que una vez que se dieron las capacitaciones de los procesos de negocio
asociados a los módulos SAP en lo particular, se deben también planear sesiones de capacitación
de procesos en forma integral, en un enfoque de procesos de principio a fin relacionados.
No es una recomendación que se tiene que seguir para todos los casos, pero si para los procesos
de negocio clave, ya que ayudarán a que los usuarios entiendan la razón de ser de ciertos pasos por
ciertos módulos como una entrada y flujo de datos del proceso A al B, al C, etc. Un ejemplo práctico
podría ser el proceso de captura de pedidos, que si bien inicia a través de un aplicativo WEB, tiene
que seguir un flujo de facturación y de comunicación al centro de distribución para que la caja del
pedido pueda surtirse, empacarse y finalmente enviarse al cliente final.
Las etapas de migración de datos, pruebas unitarias y pruebas integrales idealmente terminadas
Durante el desarrollo de este subtema hable en específico sobre algunas herramientas que SAP
oferta en temas capacitación; sin embargo aunque podría suponerse, es necesario enfatizar que las
etapas de migración de datos, pruebas unitarias y pruebas integrales idealmente deberán de estar
terminadas, ya que de lo contrario sería un desgaste e implicaría muchos re-trabajos para los
materiales de entrenamiento, lo cual impactaría en tiempo y costo para el proyecto y en general
impactaría a todas las actividades planeadas para cada módulo a implementar en SAP.
La recomendación la oriento entonces a tener presente en todo momento que la capacitación
depende de la ejecución de las etapas antes mencionadas, no es sólo pensar o sentir que ya las
terminé o que puedo más adelante hacer malabares para concluirlas y que no tendrá un impacto. El
entrenamiento es uno de las etapas dentro de la implementación del ERP que reflejará la calidad de
la ejecución de las etapas indicadas, por lo que siempre hay que tenerlo presente y hacer todos los
esfuerzos a nuestro alcance por concluirlas en tiempo y forma.
Capacitación de SME-Lideres de negocio y miembros del módulo
Finalmente, recomiendo a título personal, que se busque y precipite incorporar en el presupuesto y
en el plan del proyecto la capacitación formal SAP de todos los usuarios formalmente parte del
proyecto. Es sumamente retador tener que aprender SAP “pescando” conceptos aquí y allá, ya que
considero en detrimento del resultado del proyecto que las soluciones SAP propuestas por los
consultores fueron las más adecuadas/acertadas, por que sin el conocimiento, y haciendo una
analogía en el deporte de Béisbol, “¿ Cómo le podemos alegar al ampáyer? “.
77
3.18 Cutover – Plan de transición
Durante el desarrollo del subtema “3.9 TI en funciones de área usuaria” establecí brevemente
conceptos muy básicos acerca de los Cutover Plan (Plan de Transición en Español, me permitiré
utilizar el término en inglés ya que nos da una mejor connotación sobre el tema).
Me parece muy importante profundizar en el tema, por lo que abro un paréntesis para compartir los
siguientes conceptos teóricos sintetizados del link:
https://www.slideshare.net/SanjayChoubey7/concepts-of-cutover-planning-and-management-
59788246 el 6 Diciembre 2018
¿ Qué es un Cutover?
Cutover es el proceso de planeación, administración y ejecución de todas las tareas y actividades
que permitirán a las funciones o procesos de negocio de transicionar “cuotver” al nuevo ERP SAP.
Dentro de los componentes claves de un cutover tenemos: la preparación del negocio y las
actividades relacionadas a la transición e integración/apagado de sistemas legacy.
La planeación de cutover y la ejecución de actividades están organizadas y administradas bajo las
siguientes categorías:
Construcción del Sistema (Tecnica y Funcionalmente)
o Construcción Técnica/infraestructura
Construir el ambiente de producción
Conectividad de middleware, Bolt-ons, y ambientes legados
Configuración de impresoras y scaners
o Construcción funcional
Aplicar todos los transportes (Configuración, seguridad y desarrollos)
Ejecutar pasos manuales
Migración y Validación de Datos
o Pruebas de veracidad de datos
o Extracción y transformación de datos
o Carga de datos maestros en ambiente de producción con la aprobación de usuario
final
o Carga de datos transacciones en ambiente de producción y reconciliación con la
aprobación del usuario final
Preparación del negocio
o Todas las actividades y procedimientos de negocio que soporten el proceso de
Cutover, por ejemplo:
Ultimo procesamiento de transacciones de negocio
Inventario de procedimientos
Integración/apagado de sistemas legados
o Calendarios de System Freeze (no más actividades en el sistema)
o Procedimientos para apagar-desactivar
o Redireccionamiento de interfaces legacy
Actividades de inicio de negocio
o Reanudando el negocio en base a la nueva solución (procesos, datos, tecnología)
o Enfocado en áreas clave identificadas
78
Un plan para el plan
Para preparar un plan de Cutover detallado, tomando como base los recursos del proyecto y de
varias unidades de negocio, un plan para el plan es necesario. El plan para el plan ayuda en la
planeación y seguimiento de varios milestones (se utilizará el término en inglés ya que la
traducción hito carece de contexto) y esfuerzos. Los milestones se definen como sigue:
Planeación Cutover inicial
o Definir roles y responsabilidades, frecuencia de las juntas de Cutover
o Establecer el calendario de Cutover
o Definir el alcance, enfoque de las sesiones de trabajo iniciales para Cutover
o Ejecutar las sesiones de trabajo para cutover iniciales
Planeación detallada de Cutover
o Ejecutar sesiones de trabajo detalladas de cutover con los procesos y los equipos
Horizontales
o Revisar el plan de comunicación, plan de preparación del sitio (Site Readiness
plan)
o Crear y revisar el plan de contingencia
o Ejecutar sesiones de trabajo para los issues
o Comunicación del borrador de plan de Cutover
Práctica del cutover
o Crear un plan de práctica
o Ejecutar el cutover de práctica
o Proveer lecciones aprendidas de la práctica de cutover
Liberación del plan de cutover final
Se cierra el paréntesis de los conceptos teóricos.
Los conceptos teóricos antes listados, se pueden utilizar como un marco de referencia de muy
buen nivel y muy acercado a la realidad de implementaciones en SAP. Por favor tengan en cuenta
que como toda teoría, puede diferir en la práctica y en el mundo real ya que hay características y
culturas organizacionales muy variadas y algunos puntos tendrán que ajustarse a las condiciones
particulares.
El cutover plan en cualquier implementación de ERP, pero aún con mayor énfasis en escenarios
SAP representa un tema medular, será conceptual y prácticamente la columna vertebral para una
implementación exitosa. El equipo de PMO (Project management Office) será el encargo de
analizar y definir todas sus etapas, así como de acompañar junto con el Project Manager en su
ejecución para asegurar que no hay ningún impedimento y para facilitar cualquier escalamiento con
los patrocinadores o con la organización misma. Todos y cada uno de los pasos establecidos en el
Cutover plan deberán de ejecutarse en tiempo y forma; no hay generalmente márgenes de error,
gracias a que parte de su definición final requiere la práctica del mismo tantas veces como sea
necesario.
¡El cutover plan no puede fallar!
79
3.19 Go Live – Puesta en producción del nuevo ERP SAP El Go Live, es en concreto para mi, la culminación de todos los maratónicos esfuerzos humanos, y
técnicos dentro del proyecto.
Una de las herramientas básicas para saber el status de un go-live será el Cutover Plan, ya que ahí
estarán detallas todas y cada unas de las tareas necesarias para poder iniciar actividades
comerciales utilizando el nuevo ERP SAP.
La adrenalina de un cualquier go-live es para mi “vivir”, la adrenalina de un go-live en SAP es para
mi “vivir al extremo”, ya que la complejidad y el uso de interminables estrategias habrán generado
para el punto previo al go-live cansancio, agotamiento, desvelos, frustraciones, y cuanta cantidad de
sentimientos encontrados se puedan imaginar; sin embargo, siempre existe una luz al final del túnel,
y el go-live en SAP no será la exepción.
Se necesitará entonces el apoyo de toda la organización, a todos los niveles, el enfoque es y tiene
que ser sólo el go-live. Todos los involucrados directos de TI, áreas usuarias, patrocinadores del
proyecto, ejecutivos de la organización se encontrará en un estado de inmersión exclusiva al nuevo
ERP SAP.
A este punto, no existen de mi parte más recomendaciones que las antes expuestas en el desarrollo
de este capítulo incluyendo principalmente la ejecución al pie de la letra del cutover plan, y de estar
preparados con el plan de contingencia, que también es parte del plan para el plan mencionado en
el subtema anterior.
Es el momento de la verdad a una nueva vida de un ERP para la organización con todas las
expectativas puestas sobre la mesa.
Se tiene que estar preparado para cualquier imponderable, para levantar gente al teléfono, para
trabajar muy largas jornadas de trabajo; el nivel a la frustración deberá de permanecer a tope, y es
en estos momentos cuando nuestras complicidades profesionales podrán rendir frutos porque ante
cualquier eventualidad, que siempre las habrá, el objetivo será resolver el problema a toda costa, sin
apuntar dedos, porque el trabajo en equipo siempre, siempre moverá montañas.
80
3.20 Soporte a producción y estabilización
¿Pensaron que con el go-live se había terminado todo? Afortunada o desafortunadamente, no.
Inevitablemente después de la etapa de go-live, tendrá que haber un periodo de soporte directo por
parte de TODO el equipo que formó parte de la implementación, conocido como Hyper Care
(Cuidado intensivo, me permitiré utiliza el término en inglés ya que su traducción pierde contexto).
El inicio del hyper care, comienza en el segundo 1 justo después del go-live. Su duración varía de
acuerdo a las complejidades y problemáticas encontradas. En una implementación de SAP, con un
esquema de cierres comerciales mensuales, recomiendo considerar cuando menos de dos a tres
meses de duración, lo cual nos dará la oportunidad de brindar el soporte incluyendo actividades de
cierres, que generalmente incluye procesos batch grandes con cálculos complejos, temas
financieros, entre muchos otros.
Retomando el tema del entrenamiento de usuarios internos y externos, y aún cuando se hayan
seguido al pie de la letra todas y cada una de las estrategias de capacitación, habrá que estar
preparado y mentalizado para enfrentar el hecho de que algún usuario olvidará casi por completo su
entrenamiento; aquí es cuando el equipo usuario dedicado al proyecto tendrá que tener guardias en
todo momento, para asegurar que los procesos y subprocesos son ejecutados de acuerdo al diseño
y solución entregada por los consultores SAP. En algunos casos, habrá que ejecutar prácticamente
de la mano ciertos pasos o procesos con ellos.
Retomando el tema de seguridad, en ocasiones como ya lo indiqué en el subtema anterior
correspondiente, los perfiles de seguridad no funcionarán correctamente, porque hubo alguna
omisión involuntaria en planeación, definición, configuración o prueba; Se tendrán que atacar a la
brevedad posible cualquier desviación en los perfiles de seguridad; por increíble que parezca, una
falla en la planeación puede generar usuarios aun días después de go-live que aún no tendrías
acceso a las transacciones para poder realizar su trabajo del día a día.
Siempre existirán situaciones excepcionales en temas de seguridad, por lo que siempre vamos a
necesitar usuarios tipo “Bombero” (fire fighter), y si, literalmente para apagar fuegos; para poder
ejecutar transacciones, pasos, procesos con el único objetivo de permitir la continuidad del negocio,
mientras se hacen los ajustes pertinentes en los aspectos de seguridad.
Me permitiré hacer la analogía con un bebé recién nacido, y Dios y la santísima virgen nos amparen
si se trata de padres primerizos, pues bien, no estará nada alejado de la realidad del nuevo ERP, ya
que igualmente se tratará de un reciente nacido, el cual podrá darle gripa, tos, temperatura o todas
combinadas, dependiendo de que tan eficientes fueron todos nuestros esfuerzos durante la
implementación. Tenemos que estar preparados y estar mentalizados para que durante la etapa de
soporte a producción y estabilización se tengan esquemas de niñeras profesionales tanto de TI, SAP
como de negocio para atacar cualquier incidente, desde una caída de comunicación, un fallo en
algún servidor, algún proceso que con carga de trabajo este consumiendo muchos recursos y que
se tenga que suspender y ejecutar de forma nocturna, entre muchos otros retos normales dentro de
estas fases del proyecto.
Se tendrán que tener ya planeadas y definidas las estrategias y herramientas para la identificación
y reportes de incidentes, así como la categorización y definición de tiempos máximo de solución
basados en un SLA (Service Level Agreement) previamente establecido.
81
Se deberán tener equipos de desarrollo-soporte listos para trabajar 24 x 7 durante el periodo de
hyper care.
Una vez transcurrido el periodo de Hyper Care, será necesario ejecutar el plan previamente
establecido para transicionar el soporte del equipo Hyper Care desde un punto de vista técnico, al
equipo de soporte establecido para el día a día durante ya la vida normal del ERP. El equipo de
soporte Hyper care desde el punto de vista usuaria, deberá de transicionar igualmente todas sus
tareas y responsabilidades a los usuarios finales, lo cual podrá llevar todavía algún tiempo adicional
incluyendo idealmente un ciclo más de procesos de cierres comerciales.
Durante cada etapa de cierre comercial, se tendrá que hacer un análisis y evaluación de KOIs (Key
Operation indicators – Indicadores clave de negocio), para tener una métrica real del comportamiento
del negocio ahora funcionando en un nuevo ERP.
Idealmente se deberán de ejecutar estrategias de lecciones aprendidas, porque siempre habrá, y
muchas, incluyendo aquellas que nadie pudo anticipar, que se encontraron en todo momento en un
punto ciego pero que normalmente durante el go-live y periodos de soporte y estabilización salen a
la luz. Es muy importante que se permite el análisis “post mortem“ de cualquier implementación, es
sano y muy necesario aprender de todos los errores presentados por más dolorosos que hayan sido.
Todos los miembros del equipo de negocio, idealmente deberán de regresar a sus funciones de día
a día, no sin antes considerar que habrá oportunidades de crecimiento, nuevas posiciones, y en
algunos casos desafortunados salidas de la organización ya que la tarea se ha concluido.
82
Conclusiones
Me permito a continuación identificar mis experiencias más valiosas tanto en la parte técnica como
en la parte profesional como resultado de este interesante informe de experiencias profesionales.
En lo técnico, no tengo duda alguna que mi formación en UPIICSA sentó las bases durante todas
las asignaturas asociadas a lenguajes de programación, estructuras de datos, bases de datos. Aun
en la actualidad todo lo que he aprendido y desarrollado en las aulas lo he utilizado ampliamente,
desde escribir y entender líneas de programación hasta conceptos de SQL que permiten consultar
bases de datos y generar informes simples.
En un crecimiento profesional sano, la parte técnica es necesaria, ya que en posiciones de TI como
analista, líder de proyecto, gerencias, direcciones, vicepresidencias, la parte técnica siempre será
una herramienta que permitirá la toma de decisiones, y evitar que alguien quiera o pretenda abusar
de conceptos técnicos para sorprendernos. Aún en tecnologías más modernas, todas estas bases
técnicas siguen y seguirán vigentes ya que no importa el lenguaje de programación, o el sistema de
base de datos, o sistemas de reporteo, hay conceptos fundamentales que siempre formarán parte
de la vida profesional.
Es importante aclarar que no debemos de esperar que la escuela y los profesores nos den todo, es
imposible, una buena escuela como UPIICSA más allá de la parte académica y las calificaciones,
que insisto nos dan la base, necesita ser combinada con un interés personal que nos lleve siempre
más allá de buscar otros conceptos, de comparar puntos vista y sobre todo de desarrollarnos en un
mundo real. Es importante en todo momento buscar la actualización y mantenernos vigentes
técnicamente.
En lo profesional, mis experiencias más valiosas están asociadas al entorno multicultural y a la gran
oportunidad de implementar diversos proyectos fuera de México. Las bases técnicas me han
permitido desarrollar otras habilidades combinadas con mi personalidad (la personalidad en este
contexto está estrictamente mencionada por mis preferencias como individuo de estructurar y de
llevar tareas paso a paso, entre muchos otros conceptos asociados) que me dan la gran satisfacción
de manejar equipos de trabajo grandes en las áreas de desarrollo y soporte de sistemas así como
de un tema de actualidad como lo es la gestión y administración de proyectos.
El entorno multicultural para mi ha sido mágico, ya que he tenido esa dicha de trabajar mano a mano,
como iguales e incluso como cabeza de equipo en entornos internacionales como en Estados
Unidos, Alemania, Italia, Suiza, Rusia, Brasil, Indonesia; y es con esta experiencia que me queda
clarísimo que como mexicanos podemos dar resultados de primer nivel; hay algo más allá para mi
del conocimiento técnico, y ha sido el hecho de representar a México y poner mi granito de arena
para retirar esos estigmas negativos sobre nuestro país y cultura. Necesitamos sentirnos orgullosos
de ser mexicanos en donde sea, y bajo las condiciones que sean, tenemos el nivel, pero más
importante tenemos todo el potencial para ir a cualquier nivel que se nos exija o presente como
oportunidad de vida.
En estos ámbitos de carácter internacional, como lo especifiqué en el informe, es indispensable al
menos, dominar el idioma inglés, por lo que fue una gran sorpresa y orgullo para mi encontrar que
como parte de los requisitos de titulación en UPIICSA (en los programas más recientes) el Inglés es
83
obligatorio; deseo que como país, desde el kínder y primaria en la educación pública el inglés
también lo sea.
Me permito sugerir ampliamente que se fomenten talleres para practica de idiomas; si bien es
importante tener una certificación (que regularmente tienen vigencia) y una buena calificación en
inglés por ejemplo, es igual o mayormente importante tener la oportunidad de practicarlo, recordemos
que “lo que no se usa, se atrofia”.
En el ámbito de sugerencias para la carrera, respetuosamente me permito recomendar incluir
asignaturas específicas, o buscar académicamente alguna asignatura a fin para incluir los siguientes
temas:
Generar emprendedores: Me gustaría ver gente politécnica emprendedora, que nos
regalaran las bases para desarrollar oportunidades de negocio, etc.
Administración de Proyectos: Lo considero como un área de oportunidad en cualquier
empresa, hay en realidad muchas oportunidades en el mercado, en donde por su naturaleza
pueden destacar personas de carreras de informática o fines, dada la formación estructurada
y organización de procesos de negocio.
Metodologías de gestión de proyectos SCRUM y Agile: Modas de TI van y vienen,
algunos conceptos de esta naturaleza ya son “viejos”, sin embargo, están teniendo un auge
en proyectos más recientes derivado de nuevas estrategias para la implementación de
proyectos.
Como conclusiones finales, todas las experiencias técnicas y profesionales al día de hoy las
considero en un sano balance con todos los conocimientos adquiridos en la UPIICSA, que como lo
mencioné antes, sembraron esas bases que han rendido muchos frutos a la largo de todos estos
años de experiencia y de orgullo de ser politécnico, de ser UPIICSA de corazón, y de poder
representar a mi México querido, en cualquier parte del mundo y a la par de cualquier otra cultura o
país.
84
Referencias
https://www.guru99.com/sap-business-blueprint.html
https://www.ibm.com/ibm/history/documents/pdf/as400.pdf
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/rzahg/rzahgrpgcode.htm
https://www.jafra.com
https://www.prince2.com/eur/what-is-prince2#prince2-definition
https://www.prince2.com/eur/what-is-prince2#prince2-history
https://www.sap.com/about/careers/who-we-are.html
https://www.slideshare.net/SanjayChoubey7/concepts-of-cutover-planning-and-
management-59788246
85
Anexos
Como anexos para este informe de experiencias profesionales, me permitiré hacer la traducción de
algunos subtemas al idioma inglés, que considero de mayor relevancia y que me ayudarán a dar
toda la transparencia de este informe para la compañía que autorizó el desarrollo de este informe,
quienes preferirán leerlo en inglés, ofreciendo un respeto a donde tuve la oportunidad de desarrollar
los diferentes aspectos y conocimientos redactados a lo largo del informe.
Respetaré la numeración original de dichos subtemas, cubriendo ambos capítulos: “El soporte al
sistema comercial-ERP JAFRA” e “Implementación SAP”.
Chapter II. Commercial System ERP-JAFRA Support.
2.1 Problematic
We will always have areas of opportunity in any problematic or professional challenge; there are
development opportunities that are trigger when we are on the right time for the unfortunate
problematic.
A global support & development area, face very important challenges by itself; in the vast majority of
the cases is complicated to point to persons or situations in specific, since in most of the cases, there
are economical scenarios within countries, budgets, executive directions and so many other elements
that could develop adverse scenarios for which we will not always find the reasons to judge, and even
could result in a lack of ethics and useless to go deeper; thus, the presented problematic for this
chapter will objectively focus in the main areas of opportunity that I identified since the point I got the
responsibility to lead the global support & development team:
Verbal and written communication limited due to the use of English language: From my point
of view this is the essence of the support; if I can’t communicate properly with my clients, in
this case we are talking about markets-countries, as a repercussion it is very complicated to
understand the requirements and it is quite challenging to delivery results with quality.
Lack of SLAs( Service Level Agreements): This is a basic principle in any support team. This
point will be reviewed with greater detail along the development of the sub topic regarding to
the challenges on doing support in this inform; to initially open the context I share with you
that SLAs represent formal support agreements between the support unit and a given client
in case any incident arise in a given ERP, for example the modular down of the order entry
web page, I can’t process payment thru the internet system, system does not respond, etc.;
SLA’s establish the type of tickets for a given incident (1, 2, 3 or any other classification similar
to set the priority) associated to maximum resolution response times. A SLA is to me the
formality to define in black & white the responsibilities and conditions between the support
unit and the client, even functioning as a help to the support unit on establishing a framework
and communication with the clients to always have, for a given incident, a support to have in
a clear way the conditions as of how the problem will be fixed.
Support team limited skills set: Within this inform I will describe the strategies that I followed
in order to develop the skill sets for the support team. Here we have several skills within
which these stand out:
86
o Communication: in either English or Spanish, to first and fore most understand the
incidents and requirements.
o Unit Test Quality: It is imperative to avoid extended rework.
o Technical skills to cover all technical needs, avoiding to segregate human resources;
the goal is to have any human resource to solve any kind of incident for either back-
end or front-end applications. This topic will be detailed along the “green screens”
and “web” technical following sub topics.
o Service Attitude oriented to final clients: to establish basic questions such as: ¿ To
who do I impact if I make a mistake? ¿What can I do to improve the quality of my
work? ¿ Am I doing anything possible to develop my applications with an intuitive
usage approach?, etc.
o We need a Project Administration area (Project Management Office); nowadays from
my point of view, an internal PMO team is essential; it is needed to segregate
functions and to establish clear strategies to handle new requirements, or strategies
to develop and accelerate new requirements definitions.
To develop the trust from our external and internal clients: further in this inform I will detail
the importance to know the external and internal clients. The main goal in this area of
opportunity is to develop an strategy to gain the trust in the results of each and every
deliverable whether these are incidents or new requirements and to be the number one
solution provider for all our external and internal clients to avoid in this way third party
solutions following the support unit dynamic.
To accelerate/trigger new projects: Further in this inform you will find a subtopic on how to
gain projects, which in essence consolidates several presented areas of opportunities.
Vendors Management: It is essential to develop any vendors that work with the support team,
as a business partners in order to get greater efficiencies in different aspects, since the most
important one: human resources, until the cost and strategies to develop technical skills sets.
I also found other areas of opportunity, for instance, budget management, work areas administration,
and other less impacting topics which due to the lack of space on this inform I will not be able to cover
them.
I am convinced that each support unit in the world may or may not agree with the areas of opportunity
earlier mentioned, thus it is not my intention in this inform to set a rigid framework, on the contrary,
we need to provide flexible solutions that we can adapt to real world companies, always keeping in
mind the changes, since in many companies the only constant aspect are precisely the changes, for
which is needed to develop a full emotional flexibility for processes strategies, project management,
resources management and many other aspects that I consider basic and that I will detail in this
inform.
87
2.2 Commercial System ERP
ERP General Context
ERP, is a common IT acronym which stands for Enterprise Resource Planning; it has been defined
as the ability to deliver a group of business applications. The ERP tools share a process and a data
model in common, covering broadly and deeply end to end business processes, such as Finance,
Human Resources, Distribution, Manufacturing, Customer Service and supply chain.
ERP applications automatize and provide support to an abroad set of operational and administrative
business processes across different kind of industries, including business lines, client contact,
administration and enterprise assets administrations.
ERP implementation tends to imply a high cost, where business benefits are commonly hard to
understand and justify.
Look for business benefits in four areas:
Information Technology costs saving.
Business Process efficiency.
Business Process platform for process standardization.
Catalyst for business innovation
Most enterprises focus on the first two areas, because there are the easiest to quantify; however, the
latter two areas often have the most significant impact on the enterprise.
88
2.3 JAFRA’s ERP: Hardware y Software
The commercial system in JAFRA, goal of this chapter was developed in house for the Mexican
market. This was based initially in hardware architecture based on IBM AS-400 servers, through
emulation sessions type Client Access, where the final users could use applications thru a user
interface known as “Green Screens”.
Such system was developed approximately along 30 years.
In the earlier stages this commercial system provided all the needed support for all internal business
areas, giving support to the full business cycle going from the registry and maintenance of
consultants, thru order entry, invoicing, credit and collection, commission processes until the products
ship out to consultants houses. This commercial system from an IT stand point, was a fully handmade
suit to the needed which evolved together with the business model developed in México since JAFRA
started operations in Mexico, thus its seniority and continued improvements along 30 years.
Along the 90’s, JAFRA Mexico had the first opportunity to establish a global IT support model. Thanks
to this and to new markets opened in Europe, a global version was implemented with global
aspirations. The system was implemented in the same 90’s for JAFRA Germany, from which the
support was provided to the European market.
JAFRA Mexico’s and Germany commercial system then followed separate ways; JAFRA USA, had
it’s own commercial system based on a local solution. This situation gives me the opportunity to
mention one of the biggest challenges along any application with a global approach, which I will detail
in a special section in this inform further: To have more than one version of a given commercial
system implies by itself headaches in any known support aspect.
In 2007 due to budget reasons and significant savings, there was a new implementation for USA,
based on Mexico’s commercial system, putting down the USA commercial system based on JD
Edwards, while the version in Germany could not be updated since its implementation in the 90’s.
After the US implementation, other implementations followed for Switzerland, Russia and Brazil.
Under this scenario, in 2013 I got the opportunity and the big responsibility with a Director role to
provide support to a global commercial system, having different implemented versions of the previous
mentioned countries.
It is worth to mention, that Mexico’s commercial system was at the time supported by a fully dedicated
support team, outside of my responsibilities scope, thus it is not part in any way in this inform.
The support, for the other mentioned countries, was initially done with by the team I received for about
7-8 people approximately, including me; however thanks to the great Mexican work the team could
be expanded across three years growing the team to 40-45 people, including developers, system
analysts, project leaders, project managers and project support.
89
Hardware
The hardware architecture as mentioned earlier, was based initially on IBM AS-400 servers, which
have been evolving until what today we know as IBM iSeries servers.
AS/400 and iSeries context
In 1988, IBM introduces in June to the market the IBM application system /400, a new family of easy
to use computers design for small to medium enterprises. As part of this introduction, IBM and IBM
Global Business Partner announced more that 1,000 software packages being the biggest
announcement of simultaneous released applications in computer history.
The AS/400 rapidly become in one of the most popular systems at global scale in business computer
systems.
The AS/400 # 400,000 was presented in October 1996 in Rochester, Minesota to Greg Lemond, 3
times winner of the tour de France, a small business entrepreneur.
The AS/400 family was replaced in 2000 by the IBM eServer iSeries – high performance, integrated
business servers for intermediate size companies.
The content of this sub topic was extracted and synthetized from link:
https://www.ibm.com/ibm/history/documents/pdf/as400.pdf on Dec 6, 2018.
In the real world
The IBM AS/400 hardware platform has been the most stable I have known in my professional career;
I can testify that its processing power is extremely reliable and by far superior to many other hardware
platforms on the AS/400’s heyday and even today it continues to be one of the main pillars in the
orders processing capacity and daily tasks in JAFRA Mexico.
The architecture of this server was initially used for batch processing; it capacity was extraordinary in
comparison to other parallel solutions in the market. It’s security approach, operating system,
database system have been the strongest which I have had the experience and opportunity to work
with; it’s reliability and support by IBM were extremely good.
The AS/400 in early stages, had a great acceptation at a global scale. Along the 90’s to be able to
see and work with emulated “green screens”, was the most advance known technology for its time.
That simplicity in the user interface helped greatly in a minimum system resources usage; resources
were really used to exploit it’s great strength to process millions of records in seconds.
Unfortunately we live in a world full of perceptions; in some cases, a perception is all, and it can
influence heavily in an executive decision, when the years pass by, the “green screen” my not get old
healthy, and when are competitors system solutions with heavy graphical user interfaces, allowing
the mouse movements and clicks, windows, interactive events, that although they gave the perception
of a “modern” system, they were very short in batch processing capacities; and here one of the biggest
debates of all times for enterprises using AS/400, efficient “green screens” with a very high processing
power vs “nice” graphical screens and limited processing.
90
This battle was very hard to be justified for the “green screens” in JAFRA.
As the years passed by, and with the arrival of the year 2000, the internet boom in Mexico was
imminent, for which IBM had great progress in regards to the user interface graphical view in order
to make it user friendly and give a fight to the modernity perceptions.
This topic opened the business opportunity for the web applications development based on the
AS/400, where the system worked as a web server application in addition to the application and
database server, where web applications could be developed having direct access to the database.
This last point will be further detailed in the next Software section.
In as AS/400 like in any other hardware platform used as a commercial system, there is always a
battle mainly for memory resources, processor and storage. This to the hardware level, represented
a full challenge regarding the configuration and monitoring of the hardware itself.
Depending upon the business dynamic where AS/400 where used, there were challenges like in
JAFRA, where the sales pike, and the resources usage (memory, processor and storage) was
significantly high along end of commercial months. Once the WEB Order Entry application was
implemented in JAFRA, it added a significant variable, that even today requires a detailed resources
plan.
Along the stage for commercial system implementations for USA, Switzerland, Russia, Germany,
Italy, Brazil IBM iSeries systems were already available, which allowed the partitions management of
a big one server, where resources could be assigned on demand for each partition. For the support
team and developers, it was in a practical way a dedicated “virtual”server for each market-country.
Telecommunications in Mexico by its nature, geographical conditions, and several other external
factors, have always represent a challenge. The servers initially where hosted in Mexico using the
top available facilities.
There is a known IT saying in Mexico, “los fierros no tienen palabra” (the hardware has no word in a
honor context). Even though for many cases this is a true statement, along my most direct contact in
the support team for around 16 years, the hardware failures were really minimal, the most common
areas of opportunity were the telecommunication and the compilation or push/release objects to
production.
Even though my direct responsibility was not the hardware as such, I shared 100% the responsibility
of it, since when a consultant was not able to process a payment, or to entry an order, as in any other
kind of business, it does not really matter if the problem is software or hardware related, or both, the
problem simply had to be solved as soon as possible.
Software
Before going into the subject, it is very important to mention important strengths due to the hardware
and the AS/400- iSeries system architecture that belong to the software topic:
Operating System: OS-400
Database System: DB-400
Compilators (several): C, RPG
Programming Languages/Scripts: Java Scripts, XML
91
Security: within the OS-400
As a base programming language it was used RPG, which acronym stands for Report Program
Generator; it has several evolutions such as RPG II, RPG III, RPG IV until the last I knew RPGLE or
RPG ILE. RPG is a very old language, created in 1959, and used in IBM systems of the time, including
punched card systems, going thru systems 3, 32, 34, 36, 38, AS/400, iSeries. In each and every
stage it has significantly evolved.
From an academic point of view, RPG in its base, it’s just another programming language, which as
any other programming language, uses basis aspects of programming, and as such it uses arrays
definitions, files opening, known cycles, basic conditions and anything else that one can see in other
languages such as Basic, C, etc., thus the basis presented by professors in UPIICSA formed the
basic understanding and usage of it, of course, every language will always have its peculiarities and
tricks that can be learned with the usage, practice and communities around the globe.
A strong recommendations taking advantage of this topic, is to never limit the learning; even though
my function when I joined JAFRA never dictated to be an RPG developer, my curious nature, and the
developer I always keep in my heart, took me to set and fulfill to the challenge to learn how to create
applications for the “green screens” and later opening other doors developing prototypes for WEB
graphical interfaces using RPG and a set of libraries (CGI- Common Gateway Interfaces) that
allowed its exposure to the world wide web; these development did a broader use of other languages-
scripts such as JavaScript, XML and additional graphical tools such as style sheets development,
graphical buttons, etc.
Keeping in mind that my initial functions in JAFRA were to lead WEB projects, I assigned to myself
programming tasks in parallel to my development team so that I could keep learning, having in
addition a competitive advantage versus my project leaders peers in other areas, since aside of
coordinating the projects I had the knowledge on how to do it, which facilitate greatly the development
time estimations accuracy so that this could be projected as deliverables expectations for the users
and all derived benefits of it, an even further, with Manager and Directors roles, as indicated in this
inform, this bases where essential, since this greatly facilitated my duties in other organizational
levels, giving me the healthy power of knowledge that allowed me to spread and coordinate it to new
generations and to be able to provide solutions internationally along the development stages.
In addition to RPG, I also had the opportunity to implement UPIICSA programming language C
knowledge; along the commercial system implementation for USA, there was a need to implement a
solution for tax purposes, which by the way was pretty complex, since it required the combination of
Postal Code, County, City, so that in a very accurate way a TAX % could be determined. So, one of
the hardest integration challenges was that TAX software, which even though it ran in the AS/400
platform, its integration with RPG programs for green and WEB screens was not natural, so it
demanded the development of a C language program to interface this with an RPG program; this
development was proudly mine when I was doing manager functions in JAFRA, since we could not
found a C developer for AS/400, and due to the business urgency and necessity; it was not a trivial
task and I dedicated an important number of hours in the research and implementation of the solution
since there was a critical dependency on delivering and approving this key functionality.
The RPG conceptual theory for this subtopic were synthetized from link:
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/rzahg/rzahgrpgcode.htm
Dec 6, 2018.
92
2.4 Applications Portfolio
Within the applications portfolio, there were basically two important classifications, internal use and
WEB for JAFRA consultants usage.
Internal use Applications
Listed in a general approach here the most relevant applications:
JAFRA Consultants Inquiries: All consultants general data
New Consultants Registration: The creation of a new consultant record to be added to the
JAFRA program, including initial promotions approach, sponsor assignation, manager, both
key data elements for commissions processes.
Statement Balance: All transactions history for a given consultant in specific, where you
could see the balance, payments details, orders, promotions, and all relevant consultant
information within the business cycle.
Order Entry: Order entry by item code, quantity, showing achieved promotions, including
price adjustment.
Orders History: Even though this information was available in the statement balance, this
provided specific historical information with a more user friendly approach.
Customer Service: Registry and Inquiry for claims, including returns and exchanges and all
the different options for the correct service to the consultants when visited or call the main
office.
Commission Calculations: Backbone functionality for JAFRA program; this application
allowed the parameters definition, and calculation.
Product Promotions: Configuration for all product promotions, for example, Buy A and get
B free, Buy C and we apply a discount X% and n variants specific to JAFRA by market-
country.
Invoicing: Configuration and execution for orders invoicing process following the distribution
center rules by market-country. For example, by geographical zone, etc.
Payments: All associated with the payments, banks interfaces, credit cards, etc.
Credit & Collection: Following each market-country needs, there was a defined approach
for credit with specific business rules; collection handled according to specific market-country
needs as well.
Distribution: Generally a module to handle the needed interfaces with third party softwares
in the warehouse.
Reports: An abroad set of different reports, mostly custom made according to specific
business rules for internal use, including government regulations, etc.
WEB Applications
The great challenge in this set of applications, was to provide custom made solutions following an
intuitive and easy to use approach, aiming to provide usability to any consultants generation, social
status and education level.
This set of applications was focused on enable the consultants business providing easy follow up:
93
New Consultants Registration: The goal was to allow new consultants entry thru a WEB
interface; in some markets-countries, this was configured to allow the first order withing the
same registration process.
WEB Order Entry: One of the most demanded and used applications primarily in promotional
specific dates and with a great peak of usage at the end of the commercial cycle.
Follow up-Inquiry WEB Orders: All orders follow up, including status, tracking information, etc
WEB Payments: All the payments follow up; for specific markets-country credit card payment
were allowed.
Reports: A broadly set of reports aiming to provide a healthy follow up by each consultant,
including their direct and indirect groups; these reports were key during promotional specific
dates and during the end of the commercial month.
94
2.5 Global ERPs support and its complexity.
Global ERPs, require specific features from its base in the architecture and the design, as oppose to
follow patches approach or improvements to an existing system.
Some of the core basic and needed features are:
High grade of standardized Business Processes
Multi-Country
Multi-Company
Multi-Currency
Multi-Language
Multi-schedule-time-date
Modular and configurable for critical processes
Hardware architecture, telecommunications and high capacity batch processing.
Strong database.
The maintenance costs, hardware, operations and implementation times are pretty high when the
application has not being designed considering at least all of these points.
There are some international companies that along the 80’s, 90’s bet for the design and in-house
development of such global ERPs applications, having dedicated internal IT teams for the applications
development and infrastructure; this was motivated in most of the cases due to the lack of a given
solution in the market that could fulfill the business needs.
Some software companies identified this as a business opportunity opening the door to the all times
big ERPs since then, for example SAP, JD Edwards, IBM, etc.
The dream of any international company is to have one ERP that allows the opening of new markets
in the short term, with the less possible hardware and software cost and the overall minimum possible
investment.
For example, in the world of multi-level sales companies that have a pyramidal sales structure of two,
three level, or N levels, there are some key processes, such as promotional calculations, that could
be product or program related and commissions calculations payouts, that by themselves represents
a very high complexity in their processes, and these being the core of a given business could dictate
then the strategy to in-house develop the applications to support such needs. Nowadays, in this
commercial segment for example, there is no ERP software or application module in the market that
can cover the needed processing volume and even more challenging the specific commissions
payout calculations in companies like JAFRA.
Therefore, like in the last example, and in several commercial areas there are processes that makes
a given business unique, which will always represent the biggest challenges along a new ERP
implementation, since in most of the cases this will represent a new development in a new ERP
platform, taking all the complexity and challenges immerse on these processes.
95
Chapter III. SAP Implementation
This inform is not intended to provide confidential details of SAP nor for its implementation in JAFRA.
The shared information has academic purposes only by describing the acquired knowledge along
SAP implementations where I had the chance to participate, thus I kindly request at all times to search
for official sources in regards to any SAP concept depicted here.
3.1 ¿What is SAP?
Based on my experience with SAP, I can share that is one of the global solutions companies from
which we can highlight several ERP -Enterprise Resource Planning-. Please refer to the general
context provided in this inform in 2.2 Commercial System ERP for further details.
The ERP solutions offered by SAP has evolved since its first versions implemented in 1972. SAP
have been constantly evolving since last decades and it continues offering solutions that goes
together with the available technology in the market, offering as well cloud solutions and new
platforms for memory processing.
SAP has followed an strategy to buy third party solutions, to offer a broader set of solutions for diverse
type of industries. The SAP premise when using these third party solutions is that once integrated,
they will follow all the standards in SAP applications development and they will have the same
warranty as the centralized solutions.
To have a framework about SAP size, following I am sharing some numbers published in the SAP
official portal:
413,000 + clients in more than 180 countries.
94,900 + employees in more than 130 countries.
Euros 23.4 Bn total income reported in 2017.
150,000 subscriptions in cloud solutions.
91 % of Forbes Global 2000 are SAP clients.
17,000 + associated companies globaly.
46 + years of history.
With SAP you will hear some concepts that goes beyond the marketing, since in reality it is part of I
perceive as one of their main premises: the usage of the industry best practices.
With this best practices usage approach, there is a quite very delicate challenge immerse in any SAP
implementation. If we start with the basis that SAP offers that it has been designed and build based
on the industry best practices, it is reasonable to infer, that any customization could reach exponential
costs along its implementation. A change, for minimal that it may look, could have several deep
implications since some of these changes could imply as well changes at the code and database
level.
SAP in regular basis will be updating the installed ERP versions on N clients, thus SAP will always
recommend to avoid always possible any customization to the ERP along its implementation, since
in addition to the high cost earlier mentioned, it could also impact to get any new upgrades, since this
96
will trigger additional costs due to the fact the any customization would need to be recoded-
implemented in the new/updated version.
SAP has proprietary methodologies, which I will not cover in this inform, to determine all topics
associated with hardware sizing, hardware platforms, operating systems, etc.
From an IT stand point, the hardware will be the base and pillar for the ERP, thus this is one of the
core pieces during the implementation phase.
In addition to the hardware, it is equally key the overall architecture depending upon the group of
solutions offered for a give implementation. Remember that SAP commonly offers third party solutions
that needs to be orchestrated properly.
The architecture topic, from my view point, has a greater or equal weight with the hardware, since
from here several aspects will be set, such as: applications response times will be set for either back-
end or front-end applications, data updates frequency for published in WEB applications (ideally this
should be in real-time), reports, updates frequency for additional business intelligence solutions, and
finally and most importantly it will give to the final user the “perspective” of a good, bad or terrible SAP
implementation.
Strictly talking about the ERP, this inform is based on the experience with several SAP modules such
as: SD Sales & Distribution, FI Finance, MM Material Master, CRM Customer Relationship
Management, Hybris WEB framework, Vistex Promotional modules.
It is very important to share with you that a SAP implementation represents an important complexity,
since it is necessary to include specialized resources on the tools-modules, and to use
implementation methodologies according to the size and business cycles for a given company; thus
it will be key to follow a selection process for the system integrator (SI), a key piece in the
implementation, who will hold hands along the implementation process. There are many SAP certified
companies for this SI functions, each of them may have advantages or disadvantages depending
upon diverse factors such as: costs, localities, experience, methodologies, delivery times, etc.
Very important and additional to the SI, it is key to establish human specialized resources for the
project management office (PMO) where we also have best practices to happily and accurately go
thru the implementation process.
The historic SAP information of this sub topic was synthetized from the link:
https://www.sap.com/about/careers/who-we-are.html on Dec 6, 2018.
97
3.2 ¿Why SAP?
We are facing with no trivial answer. To talk about why we are going to implement SAP, should, in
most of the cases follow a real deep analysis of the target company and the ERP offers in the market
so that an impartial comparative can be made.
SAP, it is an ERP ¿Right?, from here we could think that any ERP in the market that could be JD
Edwards, Oracle, Microsoft, among many other could work for us ¿Right?, but before answering this,
let’s think a little about what could lead us to decide to use SAP.
Let’s keep aside ERP names and brand for a moment, and let’s just think in a “generic” ERP; formally
from my point of view, the decision to implement it should be based first and fore most in a deep
business requirements analysis, so that first and fore most have crystal clear ¿What do I need as a
company? And so many other relevant questions such as: ¿What problems do I currently have that
needs solution in the short, mid or long term?, ¿The problems earlier listed can be solutioned in my
current ERP?, ¿How am I going to solve it?, ¿When can I implement them?, ¿How much is going to
cost me?, ¿How easy to use will be the tools in a new ERP?, if I need a WEB front-end, ¿How intuitive
and easy to use will be for the final user?
I should also ask, ¿Are my competitors using SAP?, if they do, to research ¿How well their
implementation did go?, ¿Does it actually works?, ¿Was it implemented on time and on budget?,
¿Are there any other companies successfully using the set of modules offered by SAP?
Let’s now go back to the pending answers regarding why SAP among many other ERP brands and
solutions. Ideally you should have answer each and every question listed before about the deep
analysis, and we should have had a ERP selection process, if that’s the case, what a fortune and
privilege to have participated in such ambitious selection process; fortunately or unfortunately the
SHOULD BE in many cases of the practical life it does not apply, and we face many situations where
the use of SAP it is imply inherited, where the implementations reasons are really dictated by
standardization and consolidation approaches for given tools from really giants in the industry where
“my company” is in reality one of many others, and where the parent company simply has as standard
the usage of SAP; therefore the natural tendency would be to pursue the consolidation of all the
financial aspects where SAP has a strong reputation.
It´s like this, that the practical case in which this inform is based, SAP was inherited by its parent
company and where all the implementation efforts where focused to other aspects such as the
identification of the best SAP tools for the job for the given requirements, the search of the best
possible architecture, and the usage of the best methodologies for a successful implementation.
98
3.3 Problematic
Once the basic SAP concepts have been established, it is important to establish the problematic in
regards to what it takes to implement SAP.
Beyond having mentioned about the practical case of this inform, where the scenario is an inherited
implementation by the parent company, and the so many financial benefits by having all business
units consolidated thru SAP, there are other relevant factors that sum here and that a given company
could use to complement the justification to implement SAP.
While the fundamental principle of a SAP implementation should be based on cover at least my
current business requirements and needs, it is as well a turning point for an objective review of the
applications portfolio for the legacy ERP, including the business process surrounding it, which
represent by themselves areas of opportunity, especially in regards to the strategies facing the final
users, aiming to attract new generations into the business and continuing with a solid growth in a
globalized scenario, where at a mid-term I should be able to implement a tropicalized SAP-ERP for
different markets-countries.
Legacy ERPs, generally are the result of decades of mini implementations for new requirements and
business needs, where generally there is no clear usage of global business practices, and where in
many cases we ended up having an ERP like a “Frankenstein”; it sounds harsh and challenging at
the same time, however it was a reality that along those decades there were many hands and in
many occasions lack of care in the changes control resulting in very complicated ERP to be
supported.
In global scenarios, generally the ERP implementation was done for country X, at certain point of the
base ERP evolution, from which point the base version was again updated/modified independently,
creating as a result, N versions for my M countries where again the support approach is extremely
complicated.
And it is then when the SAP implementation, at least in professional good intention and ideology,
would search to avoid mistakes from the past, to provide a door to the business processes
standardization following the best business practices in the industry thru SAP in order to justify and
make all things possible to reach a new global system following my parent company standard who
already uses SAP.
99
3.4 ¿Partial or Full “Big Bang” Implementation?
Along the implementation of any ERP, a obliged questions will be, ¿Are we following the strategy to
replace all of our commercial system ERP (“Big Bang”) or are we doing it partially, implementing
modules in specific periods of time?
Based on my experience, and not only in the SAP world, I share with you that, if the crucial topic in
the table, as in many companies, is focused in the implementation saving costs aspects and aiming
to avoid potential uncountable headaches, it will be usually preferred the “Big Bang” implementation
strategy, due to the fact that partial implementations it implies by definition to have at minimum two
ERPs running in parallel impacting at least one of the following relevant points:
Double hardware, double services payments for: hosting, licensing, storage, backups,
communication lines; usually and due to heavy reasons in regards to hardware such as
response times, processing capacity, etc two ERPs would not be running in the same
hardware. Even though the plan would be to implement initially a couple of modules, there
has to be plans and considerations for hardware resources administration by the double.
Change control management for business processes: A business is a living entity, and it is
impossible to freeze changes, let’s not say for a couple of weeks, further more for months or
years that a partial implementation could last. The changes management would be one of
the most important challenges to keep to the same changes level in both ERPs.
Transactions Management: Depending upon the module or modules to be implemented,
there would be a need of additional processes to have in sync the transactions such as
clients, orders, products, payments, etc.
Interfaces: This will be a needed topic in the table, very painful technically speaking to keep
the communication between the two ERPs; there would be technological challenges for data
processing among many others.
Double support team: By its nature, the expert knowledge should fall in each support team,
so this would imply further to the double cost, coordination in the requirement resolution, data
migration, among other relevant challenges.
Final user impacts: If a “big bang” implementation is extremely exhausting and demands
extensive hours from the users along all implementation stages, having two running
applications in parallel could be totally out of the question.
Regression tests: Linked to previous point, this represents significant a cost, time and effort
for each implemented module.
As more list these points to avoid the partial implementation, further more I got convinced that is a
very unlikely scenario. In my more than 20 years of experience I have never seen this happening;
even though I have to admit that my conservative side, in some cases raise the hand for it, is definitely
controlled again by my practical and adventurer side! Towards the big bang approach.
Having said the this, I am not implying by any means that a “Big Bang” implementation is a walk in
the park, it is not at all, however from both options, to me is the one that makes more sense for the
business once we have started the implementation path.