INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE
INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS
SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
“Administración de Proyectos para Optimizar la Implementación de un Software ERP”
TESIS QUE PARA OBTENER EL GRADO DE:
MAESTRO EN ADMINISTRACIÓN
PRESENTA: ICTZEL ANGELICA MORALES ARANDA
DIRECTORES: DRA. MARTHA JIMÉNEZ GARCÍA
M. C. GUILLERMO PÉREZ VÁZQUEZ
MÉXICO, D.F. 2016
Administración de Proyectos para Optimizar la Implementación de un Software ERP
4
Agradecimientos
Al Instituto Politécnico Nacional, en especial a todo el personal del área de posgrado
de UPIICSA que siempre está en apoyo de los alumnos, logrando mejores
profesionistas en este país que tiene tanto por desarrollar.
A la Dra. Martha Jiménez García y al M. C. Guillermo Pérez Vázquez por convertirse
en mis guías a lo largo de la maestría. Gracias por todos los momentos y
conocimientos compartidos.
A mis compañeros con los que recorrí este camino y juntos nos dimos ánimos hasta
concluirlo y lograrlo.
A mi familia por ser mi principal pilar que me ha hecho ser quien soy día a día, y
siempre darme ese empujón y apoyo incondicional.
A Esthela Sanchez y Francisca Juárez por ser los mejores ejemplos de mujer que
podía tener.
A Dante J. Morales por tu compañía y sonrisa en esas noches que necesitaba fueran
más largas. Por darme una razón más para querer poner un granito de arena y no
perder la fe en que siempre se puede hacer más por un mejor futuro.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
5
Resumen
Considerando la importancia de las Tecnologías de Información y Comunicación
que generan innovación y crecimiento económico, se realizó esta investigación en
la ciudad de México donde reside el corporativo de las empresas que han
implementado un ERP, así como los proveedores de este tipo de servicios. Con el
objetivo de proponer una metodología acorde a las empresas mexicanas para la
implementación de un software ERP, definiendo el inicio y final de cada fase del
proyecto, así como sus respectivos entregables, incorporando factores de
complejidad ambiental (ECF) de acuerdo a las características y necesidades de las
empresas mexicanas para una mejor estimación del proyecto.
Utilizando principalmente de base la guía del PMBOK® (Project management body
of knowledge), el cual es un estándar sólido para la administración de proyectos.
Así mismo la metodología conocida como Scrum basada en métodos agiles y el
modelo conocido como UML (Unified Modeling Language) el cual es uno de los
lenguajes de modelado de sistemas de software más conocido y utilizado en la
actualidad.
Teniendo como resultado una metodología dividida en 6 fases con el principio de
ser flexible para adaptarse al entorno, en el cual se desarrollará el proyecto,
manteniendo en todo momento el objetivo de lograr una implementación no solo en
tiempo y costo sino también funcional logrando mejorar la operación y
administración de la empresa por medio del ERP.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
6
Abstract
Considering the importance of Information and Communication Technologies that
generate innovation and economic growth, this research was carried out in Mexico
City where the corporate that have implemented an ERP and the suppliers of this
type of services, reside. With the objective of proposing a methodology according to
Mexican companies for the implementation of ERP software, defining the beginning
and end of each phase of the project, as well as their respective deliverables,
incorporating environmental complexity factors (ECF) according to the Mexican
companies’ characteristics.
Using mainly the PMBOK® (Project management body of knowledge) guide, which
is a solid standard for project management. Also, the methodology known as Scrum
based on agile methods and the model known as UML (Unified Modeling Language)
which is one of the languages of modeling of systems of software better known and
used today.
The result is a methodology divided into 6 phases with the principle of be flexible to
adapt to the environment in which the project will be developed, maintaining the
objective of achieving an implementation in time, cost and functional, improving the
operation and administration of the company powered by ERP.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
7
CONTENIDO
RESUMEN .........................................................................................................................................5
ABSTRACT........................................................................................................................................6
INTRODUCCIÓN .............................................................................................................................10
JUSTIFICACIÓN ...............................................................................................................................11 OBJETIVO.......................................................................................................................................12 ALCANCES Y LIMITACIONES ..............................................................................................................12 METODOLOGÍA ...............................................................................................................................12
CAPITULO I. EL ERP PARA LA ADMINISTRACIÓN EMPRESARIAL .........................................15
1.1 ERP - CONCEPTO .....................................................................................................................15 1.2 EVOLUCIÓN DEL ERP ................................................................................................................21 1.3 SELECCIÓN DE PROVEEDOR ......................................................................................................26 1.4 BASES MÍNIMAS Y ESQUEMA ORGANIZACIONAL PREVIO A LA IMPLEMENTACIÓN. ..............................30 1.5 ADMINISTRACIÓN DE PROYECTOS EN LA IMPLEMENTACIÓN DEL ERP. ............................................33
1.5.1 ASAP (Accelerated SAP - SAP Acelerado) .....................................................................34 1.5.2 AIM (Applications Implementation Methodology - Metodología para la implementación de
aplicaciones) y OUM (Oracle Unified Method - Metodo Oracle Unificado) ...............................36 1.5.3 Microsoft Dynamics Sure Step (Paso seguro de Microsoft Dynamics) ............................38
CAPITULO II. ADMINISTRACIÓN DE PROYECTOS .....................................................................42
2.1 ADMINISTRACIÓN DE PROYECTOS - CONCEPTOS .........................................................................43 2.2 GUÍA DE LOS FUNDAMENTOS PARA LA DIRECCIÓN DE PROYECTOS (PMBOK®) ..............................43
2.2.1 Inicio ................................................................................................................................48 Desarrollar el Acta de Constitución del Proyecto ............................................................................... 48
2.2.2 Planeación .......................................................................................................................50 Planeación de la comunicación ........................................................................................................ 51 Alcance del proyecto ........................................................................................................................ 52 Administración del tiempo del proyecto ............................................................................................. 54 Administración de los riesgos del proyecto ....................................................................................... 55
2.2.3 Ejecución .........................................................................................................................56 2.2.4 Supervisión y Control ......................................................................................................57 2.2.5 Cierre ...............................................................................................................................58
2.3 SCRUM.....................................................................................................................................60 2.4 PROGRAMACIÓN EXTREMA (XP) ................................................................................................63 2.5 METODOLOGÍAS TRADICIONALES VS METODOLOGÍAS AGILES .......................................................65
CAPITULO III.- PROPUESTA DE FACTORES DE COMPLEJIDAD AMBIENTAL PARA
SISTEMAS ERP EN MÉXICO..........................................................................................................68
3.1 FACTORES DE COMPLEJIDAD AMBIENTAL (ECF DE G. KARNER) ...................................................68 3.2 ANÁLISIS DE LOS ECF ...............................................................................................................69 3.3 INTEGRACIÓN DE LOS FACTORES DE COMPLEJIDAD AMBIENTAL PROPUESTOS ...............................73
Administración de Proyectos para Optimizar la Implementación de un Software ERP
8
CAPITULO IV.- PROPUESTA DE METODOLOGÍA PARA LA IMPLEMENTACIÓN DEL ERP ....77
4.1 DEFINICIÓN DEL ALCANCE .................................................................................................78 4.1.1 Definir los objetivos y requerimientos ..............................................................................79 4.1.2 Análisis de la estructura e infraestructura de la organización ..........................................81 4.1.3 Alcance Funcional de manera estándar del ERP ............................................................83 DIAGRAMAS PARA EL ANÁLISIS DE PROCESOS................................................................86 4.1.4 Análisis de cambios y limitaciones derivados de la estructura e infraestructura
organizacional. .........................................................................................................................97 4.1.5 Redefinir los objetivos y requerimientos (Alcance Funcional) ....................................... 104
4.2 PLANEACIÓN DEL PROYECTO .......................................................................................... 108 4.2.1 WBS (Estructura de Descomposición del Trabajo - Work Breakdown Structure) .......... 108 4.2.2 Lista de actividades y sus relaciones ............................................................................ 110 4.2.3 Recursos necesarios y costo ......................................................................................... 111
4.3 NEGOCIACIÓN .................................................................................................................... 111 4.3.1 Programa del proyecto vs limitaciones de costo, recursos y tiempo ............................. 112 4.3.2 Establecer el presupuesto base .................................................................................... 112
4.4 IMPLEMENTACIÓN ............................................................................................................. 113 4.4.1 Determinar los recursos disponibles formando el equipo de trabajo ............................. 113 4.4.2 Ejecución del programa ................................................................................................. 120
4.5 CONTROL DE PROYECTO ................................................................................................. 120 4.5.1 Avance real del progreso del trabajo ............................................................................. 120 4.5.2 Informar y evaluar el desempeño .................................................................................. 122 4.5.3 Administración de control de cambios ........................................................................... 124
4.6 CIERRE DE PROYECTO ..................................................................................................... 124 4.6.1 Entrega de licencias y documentación .......................................................................... 125 4.6.2 Análisis de resultados .................................................................................................... 126 4.6.3 Carta de cierre de proyecto ........................................................................................... 126
RESULTADOS ............................................................................................................................... 128
CONCLUSIONES .......................................................................................................................... 130
GLOSARIO .................................................................................................................................... 132
REFERENCIAS .............................................................................................................................. 134
Administración de Proyectos para Optimizar la Implementación de un Software ERP
10
INTRODUCCIÓN
En México la implementación de sistemas integrados de planificación de los
recursos empresariales (ERP - Enterprise Resource Planning) representa un área
de oportunidad tanto para las empresas que lo solicitan como para consultores y
proveedores dedicados a este tipo de soluciones basadas en tecnologías de la
información. El Banco Mundial [World Bank] (2012) indica que, con la llegada de las
computadoras personales, Internet y los teléfonos móviles, las Tecnologías de
Información y Comunicación (TIC) se han convertido en un motor importante en el
fomento de la innovación lo que genera una mayor productividad de las empresas
y crecimiento económico. Por lo cual se considera apoyar el uso de la innovación
de las TIC como fuente de competitividad económica.
Las empresas requieren la implementación de un ERP para cubrir la necesidad de
un sistema informático que cubra la función de una herramienta estratégica para
planificar sus recursos y así mismo mantener un control sobre estos, agilizando los
procesos de los distintos departamentos, contando con información confiable, fácil
de extraer y analizar con lo que también se reduce el tiempo que se requiere
administrativamente.
Por lo que esta investigación surge con base a experiencias previas con distintas
empresas comercializadoras que han decidido realizar una implementación de un
software ERP esperando éste sea una solución para sus problemas actuales de
operación o como un recurso para incrementar sus ganancias, sin lograr al 100%
los resultados esperados.
Se ha observado a las empresas invertir en la solución de un ERP basándose en
su posibilidad económica, en ocasiones sin realizar un análisis profundo del alcance
funcional del ERP contra las necesidades actuales de infraestructura de la empresa.
Sin embargo, no todas las empresas nacionales están listas para una
implementación de este alcance, mientras que para otras es indispensable realizar
Administración de Proyectos para Optimizar la Implementación de un Software ERP
11
una implementación de este tipo para que puedan continuar creciendo. Para tomar
esta decisión se debe considerar el estado actual de la empresa tal como: tamaño,
desarrollo tecnológico y perfil del personal.
Los autores Galy y Sauceda, 2014 determinaron que en base a cálculos de
rendimiento o retorno sobre la inversión (ROI por sus siglas en ingles Return on
investments) y rendimiento o retorno del Activo (ROA por sus siglas en ingles Return
on Assets) desde el punto de vista financiero la implementación de un ERP no refleja
una ganancia monetaria a corto plazo. Comprendiendo que la rentabilidad de la
implementación de un ERP radica en la mejora de la administración en la
organización reduciendo costos de operación.
Para lograr que la implementación sea exitosa y funcional se propone utilizar una
metodología de administración de proyectos con la que se pretende que ambas
partes estén conscientes del tiempo y de las fases que implica la implementación
de un ERP y las bases que se deben tener a una pre implementación.
Justificación
La presente investigación surge de la necesidad de definir la metodología adecuada
para implementar un ERP en empresas situadas en México, logrando que las
empresas obtengan un beneficio y una satisfacción de la inversión realizada,
alcanzando una implementación exitosa y funcional que culminara en empresas
más productivas y competitivas en un mercado global beneficiando la economía
nacional.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
12
Objetivo
Proponer una metodología de administración de proyectos para la implementación
de un ERP, definiendo el inicio y final de cada fase del proyecto, así como sus
respectivos entregables. Determinando los factores y/o elementos que se deben
considerar en la implementación de un ERP.
Alcances y limitaciones
La investigación se realizó en la ciudad de México durante el periodo 2015-2016,
aplicándolo en una empresa comercializadora que lleva más de 50 años en el
mercado, con una solidez financiera y gran experiencia operacional. Su oficina
central se encuentra ubicada en el Distrito Federal.
El tamaño de la empresa considerando sus ingresos anuales está clasificada como
media, contando con un plantel de 250 empleados fijos.
Metodología
Se consideró como base la guía del PMBOK® (Project management body of
knowledge), el cual es un estándar sólido para la administración de proyectos
desarrollado y actualizado durante varios años por los expertos del PMI (Project
Management Institute). Así mismo la metodología conocida como Scrum basada en
métodos agiles y el modelo conocido como UML (Unified Modeling Language) el
cual es uno de los lenguajes de modelado de sistemas de software más conocido y
utilizado en la actualidad.
Cabe mencionar que la guía del PMBOK® contiene una descripción de cuarenta y
siete procesos y que en este estudio no se abarcaran todos estos procesos ya que
Administración de Proyectos para Optimizar la Implementación de un Software ERP
13
se pretende garantizar una implementación exitosa aplicando una metodología
esbelta, por lo tanto, solo se tomaran los procesos indispensables y absolutamente
necesarios para obtener una implementación exitosa sin extralimitar la función de
Project Manager (Administrador de Proyectos). Así mismo como su propia
descripción lo indica la guía del PMBOK® es una guía mas no un manual lo cual
permite solo aplicar los procesos necesarios dependiendo el tipo de proyecto.
Así mismo se realizó un análisis de la investigación documental aportada por los
autores especialistas en ERP (Aguilera y Riascos, 2009; Boltena y Gómez, 2012;
Candra, 2012; Díaz, Gonzales y Ruiz, 2005; Galy y Sauceda, 2014; Lineke, 2014;
Maldonado, 2008; Monk y Wagner 2012; Rajnoha, Kádárová, Sujová y Kádár, 2014;
Ram, Wu y Tagg, 2014; Razmi, Sangari y Ghodsi, 2009) y una recopilación de
investigación descriptiva aportada por expertos en el tema que actualmente laboran
en una empresa dedicada a la consultoría, desarrollo y venta de sistemas para la
administración empresarial, analizando la información histórica de proyectos
pasados de empresas mexicanas en su mayoría comercializadoras de tamaño
medio según su número de empleados y que implementaron un ERP.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
14
CAPITULO I
EL ERP PARA LA ADMINISTRACIÓN
EMPRESARIAL
Administración de Proyectos para Optimizar la Implementación de un Software ERP
15
CAPITULO I. El ERP para la administración empresarial
En este primer capítulo se plantean los conceptos básicos necesarios para entender
el propósito de un sistema ERP. Revisando de manera general su estructura,
arquitectura, módulos y el alcance funcional. Retomando sus antecedentes y los
principales problemas que dieron origen a la necesidad de un sistema robusto como
lo es el ERP. Y que, si bien para algunas empresas ha sido la solución a dichos
problemas administrativos y de control, no en todas las empresas ha sido la solución
óptima. Recopilando información de diversos expertos sobre los factores que
infligen y determinan el éxito de la implementación, se concluye que los sistemas
ERP son sistemas con la capacidad de integrar la información de una organización
siendo grandes repositorios de información. Sin embargo, la estructura, análisis de
flujo de procesos, atomización de procesos y carga de información debe ser
establecida principalmente por la organización que desea implementar el sistema y
asesorarse primeramente en estos temas.
1.1 ERP - Concepto
Los ERP son sistemas de información gerenciales desarrollados para integrar los
procesos de negocio de la compañía y manejar adecuadamente las operaciones de
producción y distribución. Estos sistemas pueden ser adoptados por compañías
dedicadas a la producción de bienes o servicios, teniendo como objetivo la
generación de valor y reducción de costos operacionales al disponer de la
información relevante y correcta para los perfiles adecuados dentro de la
organización y en el momento adecuado. Por lo consiguiente se puede definir como
una herramienta tecnológica y estratégica que apoya a la administración en la toma
de decisiones logrando una administración oportuna y correcta de los recursos para
un máximo desempeño (Monk y Wagner, 2012).
Un ERP se compone de varios módulos que sirven y apoyan múltiples funciones de
la empresa para lograr una mayor eficiencia organizacional. La principal diferencia
entre un ERP y cualquier otro software de administración es que el ERP tiene la
Administración de Proyectos para Optimizar la Implementación de un Software ERP
16
capacidad de integrar todos los departamentos de la organización y por lo
consecuente toda la información. Los módulos estándares en los ERP se dividen
con base al tipo de gestión que abarca dicho modulo, siendo los más comunes los
siguientes 6 módulos: finanzas, ventas, compras, distribución y logística,
planificación de la producción y RRHH (Figura1).
Gestión
financiera
Gestión y
planificación de
la producción
Gestión de
compras
Gestión de
ventas
Gestión de
recursos
humanos
Gestión de la
distribución y
logística
Módulos ERP
Figura 1. Módulos por tipo de administración en un ERP (Elaboración Propia)
Cuando se habla de un sistema ERP siempre se debe considerar que es un sistema
con la capacidad de integrar de manera ordenada toda la información organizacional
a pesar de estar dividida por módulos.
Lineke (2014) define las siguientes dos características como básicas para cualquier
ERP:
1. Integración de la Información:
Como ya se había mencionado los ERP deben tener la capacidad de integrar
toda la información. Tomando como ejemplo el caso de la información de los
clientes, es común que se tenga la necesidad de duplicar o recapturar la
información del cliente en los distintos procesos que lo involucran,
Administración de Proyectos para Optimizar la Implementación de un Software ERP
17
ocasionando muchas veces discrepancias en la información dentro los
diferentes departamentos, teniendo como consecuencia una difícil
actualización y homogeneidad de datos. Siendo este tan solo un ejemplo ya
que existen procesos más extensos como lo son los de compra o venta en
los cuales cuando no se cuenta con un ERP existe la necesidad de duplicar
la operación en los distintos sistemas “aislados” de la organización.
Los sistemas ERP tiene el beneficio de compartir la información entre los
distintos departamentos de la organización, siendo posible automatizar
procesos y reducir el margen de error del factor humano. Por ejemplo, en el
caso de una orden de venta o pedido se puede generar una orden de
transferencia del CEDIS (centro de distribución) hacia la sucursal o en su
caso una orden de compra al proveedor, posteriormente la sucursal registra
la entrada de mercancía ingresando y actualizando el inventario para concluir
la venta y generar la factura al cliente; todos estos documentos quedan
referenciados entre sí, lo cual facilita su administración en los distintos
departamentos de la empresa y evita duplicidad de información. En este
ejemplo podemos observar las diversas áreas que tienen accesos a la
información del cliente, los servicios o productos que está adquiriendo, el
periodo o fecha en que se están realizando dichas operaciones y al mismo
tiempo el registro del usuario (empleado) que realiza dichos documentos.
Al compartir la información e integrarla no solo se facilita su administración,
también se puede estar seguro que la información que está percibiendo
ventas, compras, producción, contabilidad y mercadotecnia no difiere, por lo
que se puede asegurar la consolidación de dicha información ahorrando
tiempo operativo y administrativo.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
18
2. Procesos con mejores prácticas:
Se les conoce como mejores prácticas de negocio a los procesos y políticas
estándares y generales que han sido utilizados en varias empresas u
organizaciones concluyendo que estos procesos son funcionales, prácticos
y necesarios.
Tenido un aprendizaje significativo a lo largo del desarrollo y evolución de los
sistemas gerenciales sobre el flujo de los procesos para facilitar la
administración y operación se han establecido estas “mejores prácticas” así
mismo las políticas necesarias para un mayor control, tal como son las
políticas de crédito para asegurar el control del capital. Los ERP están
diseñados para que la empresa que adopte el sistema asuma estas mejores
prácticas de negocio. Un ejemplo es el límite de crédito para cada cliente,
cuando se genera una venta a crédito se consulta el límite de crédito del
cliente y si este tiene una venta a crédito anterior guardada como vencida, la
nueva venta a crédito no se concluye manteniéndola en espera hasta el
momento que se liquide la venta a crédito anterior.
Por otro lado, los autores Díaz, Gonzales y Ruiz (2014) mencionan que al adoptar
un sistema integrado le permite a la organización mantenerse en el mercado con
una ventaja estratégica o en algunos casos es imprescindible para mantenerse
dentro de la competencia. Actualmente es indispensable que la alta dirección cuente
con información confiable. Otras ventajas con la integración total de todas las
operaciones de la organización son: reducción de costos, aumento de la
productividad, automatización y estandarización de procesos y disminución del
riesgo de tomar decisiones equivocadas por falta de información, evitando pérdidas
económicas por administrar inadecuadamente las áreas de la empresa.
La administración e integración de los distintos departamentos dentro de las
organizaciones se debe ver como una formulación estratégica a largo plazo.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
19
Integrando la información de los distintos departamentos se logra un enfoque de la
empresa en su totalidad logrando analizar y coordinar sus procesos internos de
manera óptima con su entorno exterior como lo pueden ser proveedores y clientes
(Aguilera y Riascos, 2009).
Al integrarse la organización y/o empresa de una manera eficaz logra una ventaja
competitiva generando una mejor administración del negocio y diferentes beneficios
operacionales como son: mejor desempeño en la cadena de suministro
manteniendo inventarios reducidos y bajos costos de este; un mejor flujo de
comunicación entre socios ayudando a planificar, prevenir situaciones, tomar
decisiones con una visión más amplia e información de calidad y una mayor
eficiencia en el proceso de producción o la prestación de servicios (Ram, Wu y Tagg,
2014).
Lineke Sneller (2014) argumenta que la arquitectura de un ERP debe considerar
principalmente tres elementos.
1. El primer elemento es de interacción (interface)
2. El segundo elemento es la base de datos
3. Y el tercer elemento la lógica del negocio
Es decir el ERP tiene una interface que interactuara con los usuarios, periféricos y
de ser necesario con otros software de administración empresarial para la entrada
y salida de la información; esta información es almacenada de forma ordenada y
especifica en una base de datos dinámica con tablas relacionadas y la estructura
está diseñada con base a la lógica del negocio que considera mejores prácticas del
negocio, con parámetros programables o configurables adecuando el ERP a las
necesidades específicas del cliente y su giro empresarial.
Existiendo en la actualidad una gran variedad de herramientas y aplicaciones
especialistas que se enfocan en cubrir y desarrollar todo su potencial en una sola
estrategia o requerimiento del negocio. Como lo pueden ser el comercio electrónico
Administración de Proyectos para Optimizar la Implementación de un Software ERP
20
(e-commerce) por medio de ventas por internet o aplicaciones móviles, análisis del
flujo de consumistas dentro de los centros comerciales (ShopperTrak), tendencia de
consumo, Cubos como lo es la Inteligencia de Negocios (BI) y un sin fin de
herramientas especialista que se encuentran en auge hoy en dia, también existen
los desarrollos para cubrir las normas fiscales como lo es factura electrónica que si
existe algún cambio por disposición oficial es necesario hacer la adecuación en
dicho desarrollo. No obstante, nunca se debe perder de vista uno de los objetivos
del por qué tener un ERP, que es “centralizar la información” siempre respetando la
lógica del negocio, es necesario desarrollar interfaces de dichas aplicaciones y
herramientas externas al ERP con el ERP para continuar manteniendo un solo punto
para la consolidación de la información.
Así mismo para mantener centralizada la información es necesario contar con la
infraestructura y arquitectura adecuada de hardware. A continuación, se muestran
gráficamente los elementos que se pueden integrar al ERP, ya que, si se llegan a
manejar o administrar de manera independiente, se perdería ese objetivo principal
de integración y centralización, perdiendo en muchas ocasiones la integridad y
utilidad de la información siendo que la integridad y utilidad de la información
almacenada en el ERP es uno de los parámetros más importantes para validar si la
implementación fue exitosa o no del ERP.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
21
Figura 2. Arquitectura y elementos de integración del ERP (Elaboración Propia)
1.2 Evolución del ERP
Los sistemas ERP son considerados sistemas de información. Los denominados
sistemas de información han existido tiempo antes del desarrollo de las tecnologías
de información, sin embargo, la importancia e impacto del desarrollo de las
tecnologías de información ha sido de tal grado, que actualmente es difícil
considerar la administración de una empresa sin éstas. La historia de los sistemas
de información informáticos se puede dividir en tres etapas:
Servidor Central ERP
Directivos
Servidor Local Back Office
Servidor Local Factory
Cliente(Finanzas)
Cliente(RRHH)
Cliente(n)
Cliente(Distribución)
Cliente(n)
Cliente(Producción)
POS (Punto de Venta)
Caja 1
Caja 2
Caja n
E-COMMERCE
XML
Web service
BD
RSS
Administración de Proyectos para Optimizar la Implementación de un Software ERP
22
1. Electronic Data Processing (EDP), se concentraron únicamente para la
solución de problemas administrativos cotidianos enfocándose a la eficiencia.
2. Management Information Systems (MIS), en esta etapa aparte de considerar
la información para la solución de problemas directivos, se consideró la
información en la parte operativa disponiendo de información actualizada en
las operaciones diarias, orientándose en la eficiencia y eficacia.
3. Decision Support Systems (DSS), la dirección comenzó a necesitar procesos
más flexibles que tomaran en cuenta su entorno y permitieran el aprendizaje
tomando decisiones enfocadas a la planeación estratégica.
Por lo que actualmente cualquier sistema de información informático debe
considerar estos tres elementos (eficiencia, eficacia y flexibilidad) facilitando la
información requerida en los distintos niveles dependiendo el tamaño de la empresa
u organización de una manera lógica (Sierra y Escobar, 2007).
Sin embargo, los sistemas ERP no son tan recientes como se cree en el mercado,
Lineke Sneller (2014) comenta que el concepto ERP tiene más de 40 años. Las
primeras implementaciones fueron solo para grandes compañías internacionales
que contaban con un esquema descentralizado, por consiguiente mantenían
procesos de decisión divididos por funciones o unidades teniendo como
consecuencia islas de información que generaban grandes costos de
mantenimiento, para poder reducir estos grandes costos se analizó la posibilidad de
eliminar procesos repetidos en cada isla y centrarse en los procesos que realmente
generan valor y están relacionados con las necesidades del cliente, pasando de la
simple necesidad de flujos de información disponibles y necesarios en cada área, a
la necesidad del desarrollo de sistemas que integran toda la información,
permitiendo a los directivos administrar de forma más rápida y eficaz, así mismo se
pretendía eliminar operaciones y datos duplicados. Estos hechos dieron lugar al
desarrollo de sistemas ERP, posteriormente fueron adoptados por organizaciones
Administración de Proyectos para Optimizar la Implementación de un Software ERP
23
gubernamentales y actualmente han sido adecuados para medianas y pequeñas
empresas, aumentando en gran medida su mercado potencial.
Los autores Martínez, Fa y Elguezabal (2014) hablan de la evolución histórica de
los sistemas ERP considerando sus antecedentes desde las primeras
computadoras, sin embargo su función y creación fue desarrollada para cubrir
necesidades militares durante la segunda guerra mundial, que no son parte del
propósito ni bases de un ERP por lo que retomaremos de manera histórica como
predecesor de los sistemas integrados de planificación de los recursos
empresariales a los sistemas que fueron desarrollados para cubrir necesidades
empresariales siendo estos desarrollados en los años 60's definidos como
Administración Informatizada de las listas de Materiales o BOM (Bill of Materials), el
cual estaba orientado a la administración de inventarios.
La industria comenzó a adquirir nuevas experiencias dando lugar a nuevos
problemas de control y operación, Buffa (1973) agrupo estos problemas en 7
clasificaciones:
1. Pronósticos
2. Inventarios
3. Planeación y programación por agregación
4. Programación y control detallados
5. Mantenimiento
6. Control de calidad
7. Control de la mano de obra y los costos.
Manejándolos en 5 sistemas
1. Sistemas de distribución
2. Sistemas de producción-distribución para volúmenes altos de productos
estandarizados
3. Taller cerrado
Administración de Proyectos para Optimizar la Implementación de un Software ERP
24
4. Taller sobre pedidos
5. Proyectos grandes a tiempo definido
Estos sistemas a pesar de no ser informáticos fueron las bases del desarrollo de los
sistemas MRP (Materials Requirements Planning, planeación para las necesidades
de materiales) comenzando sus primeros desarrollos cerca de 1975 (Martínez, Fa
y Elguezabal, 2014) y si observamos detalladamente los problemas de operación y
control actuales solo han evolucionado. Con los sistemas ERP se han integrado
nuevos sistemas como son el Financiero, Recursos Humanos y Mercadotecnia. A
pesar de estas grandes diferencias generacionales, consideraremos estos sistemas
como la base de los sistemas ERP para dar un enfoque Productivo-Administrativo
en el presente trabajo y no informático.
Los sistemas MRP fueron evolucionando con los años y adecuándose a nuevas
necesidades, como actualmente se encuentra en evolución el ERP. Los MRP
estaban dirigidos a empresas manufactureras que al ir creciendo se tuvieron que
enfrentar a numerosos productos, procesos e incertidumbres con una demanda
impredecible. Posteriormente también fueron adecuados a las organizaciones de
servicios como apoyo a sus sistemas de prestación de servicios al administrar sus
inventarios. La principal característica de los MRP era la distinción que marcaba
entre los inventarios con demanda independiente los cuales están sujetos a
condiciones de mercado siendo independientes de las operaciones (ejemplo:
productos terminados y refacciones) y los inventarios con demanda dependiente los
cuales están sujetos al mercado y sus condiciones; los cuales dependen de un nivel
(inventario) más alto de la demanda de partes con base al programa de producción
maestro (ejemplo: materias primas) (Schroeder, Goldstein y Rungtusanatham,
2011).
Los sistemas MRP son sistemas impulsados por la demanda a partir del programa
maestro de producción encargados de pronosticar la demanda futura a través de la
función producción, sin embargo, el enfoque de los sistemas MRP está dirigido a la
Administración de Proyectos para Optimizar la Implementación de un Software ERP
25
cadena de suministro y producción, a diferencia de un ERP el cual tiene un enfoque
hacia determinar mejores procesos e integración de todos los departamentos y
subsidiarias de la empresa considerando su exterior.
Por lo que un sistema ERP es el resultado de la evolución tanto del software en sus
distintas maneras como lo son: lenguajes de programación, bases de datos,
comunicación, costo de desarrollo, etc. así como la evolución de la misma
administración como disciplina y ciencia, teniendo nuevas exigencias. Resultando
sistemas basados en tecnologías de la información y comunicación para la solución
de problemas administrativos ya sean vistos como estrategia de negocios,
especialización del trabajo o para la dirección y toma de decisiones. Hoy en día
estos sistemas informáticos siguen evolucionando para cubrir nuevas necesidades
y exigencias, teniendo la opción de agregar distintos módulos para cubrir tareas
específicas o realizando una interfaz con otros softwares de funciones específicas,
alimentándose uno de otro.
Un claro ejemplo de esta evolución continua lo describen los autores Grabot,
Mayere, Lauroua y Houe (2014) con su trabajo en el cual ejemplifican la integración
de funciones web 2.0 basadas en el almacenamiento de datos a gran escala y su
procesamiento a través de herramientas como lo son los web services y diversas
interfaces, mencionándolos como ejemplo para ilustrar el alto grado de desarrollo y
evolución que actualmente se está viviendo de manera acelerada, desarrollando
herramientas cada vez a un menor costo, manejando funciones y lógicas del
negocio que antes se veían inalcanzables o con un alto grado de complejidad, sin
embargo cada vez son más fáciles de usar, ocultando la complejidad de las
herramientas de software a los usuarios con una interfaz intuitiva y amigable pero
con gran alcance para la recolección y procesamiento de datos de forma local o
distante de manera centralizada como lo son los ERP. Es decir, los ERP
actualmente se encuentran en una continua evolución debido a su propia naturaleza
como software y al origen de su creación que es la solución a problemas y
necesidades para la administración empresarial.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
26
Sierra y Escobar (2007) puntualizan los argumentos antes mencionados en tres
fenómenos que han impulsado la evolución del ERP:
1. Necesidad de más información. Para poder cubrir la demanda y los
requerimientos del cliente los distintos departamentos de las organizaciones
necesitan mayor cantidad y calidad de información.
2. Desarrollo del conocimiento. El acceso a la información ha propiciado un
mayor conocimiento sobre los problemas globales y económicos, generando
nuevas técnicas de administración.
3. Evolución tecnológica. Se ha desarrollado tecnología con mayor capacidad y
menores costos siendo más accesible.
1.3 Selección de Proveedor
Hessman (2013) publicó un artículo sobre el caso de la implementación de un ERP
en una empresa estadunidense con 144 años en el mercado, por lo tanto, sus
procesos de operación eran obsoletos y basados en el conocimiento de los
empleados con mayor antigüedad. A pesar de que México es considerado un país
en vías de desarrollo, con base a experiencias con distintas empresas nacionales
su manera de operar es similar a este ejemplo, sin embargo, como comento
Hessman "la implementación de un ERP no es sencilla, pero no tienen por qué ser
dolorosa, sin embargo, se tiene que comenzar con un plan claro y este siempre
comienza en el mismo lugar: seleccionar el proveedor adecuado".
Determinando que la selección del sistema es uno de los elementos más importante
para una implementación exitosa y que la evaluación y selección entre miles de
opciones es el primer reto para la empresa que desea adquirir un ERP, ya que a
simple vista de manera funcional todos los sistemas parecen cubrir los mismos
criterios y la única diferencia entre uno y otro es el precio.
Sin embargo, en una entrevista de Travis (2015) con el director de la consultora
CPA Crowe Horwath Josh Cole comenta que la verdadera diferencia es lo que
Administración de Proyectos para Optimizar la Implementación de un Software ERP
27
denomina "criterios estratégicos de inversión" divididos en cuatro pasos clave que
las empresas deben seguir para encontrar su proveedor:
1. Reducir verticales: Cada vez existen más ERP para mercados específicos y
no genéricos, con lo que se reducirá la lista de proveedores en base a las
necesidades específicas o particulares por el giro o tipo de producto que
maneje la empresa.
2. Pruebas piloto: Es necesario comprobar la réplica de un proceso completo
del diario en vivo.
3. Pruebas de usuario: Los sistemas deben ser fáciles de usar ya que, si es
demasiado complejo para utilizar, la gente no lo utilizara u optaran por tener
una aplicación muy básica del sistema, sin aprovechar toda la capacidad que
puede brindar el sistema. Básicamente estas pruebas deben contestar 3
preguntas principales: ¿Puedo obtener la información que quiero? ¿Puedo
hacerlo rápido? y ¿Puedo conseguirlo cuando lo necesito? Es recomendable
tomarse el tiempo necesario haciendo todas las pruebas necesarias con el
software, introduciendo datos y adaptando cada operación actual con los
nuevos procesos.
4. Verificar bajo la cubierta: Es necesario tener claro qué tipo de tecnología
utiliza el software, así como la capacidad que deberá tener la empresa para
aplicar y darle mantenimiento a esta tecnología. Dependiendo de esto se
deberá elegir a veces entre un software con una interfaz vistosa pero difícil
de mantener por el conocimiento que tendrá que manejar el personal de
sistemas o una aplicación más sencilla y de bajo mantenimiento.
Por otro lado, Parveen y Maimani (2014) hicieron un estudio comparativo entre los
tres principales desarrollos de ERP: Oracle, SAP y Microsoft. Comentaron que al
considerar la implementación de un ERP es conveniente comparar distintos
proveedores con distintas alternativas de adaptación de procesos y estudiar
detalladamente las fases de implementación de dicho software y el cómo repercutirá
el tiempo de implementación y post implementación en la producción o prestación
Administración de Proyectos para Optimizar la Implementación de un Software ERP
28
de servicios. En dicha evaluación se debe considerar si el proveedor maneja un plan
de contingencia y la flexibilidad del software a adaptarse a procesos particulares
dependiendo el giro y tamaño de la empresa, así como los costos adicionales que
puedan representar dichas adaptaciones.
Cuando una función o aplicación estándar del ERP no concuerda exactamente con
los requerimientos de negocios o sus procesos, se puede:
a. Modificar los procesos de negocios para que se adapten a los del ERP,
tomando en cuenta que al modificar lo menos posible el software ERP, este
tendrá un menor índice de errores y la actualización a versiones posteriores
no tendrá ninguna complejidad de compatibilidad. Por otro lado, implicara
modificaciones en los procesos actuales de la empresa y puede llegar a
afectar los roles y responsabilidades de las personas aumentando la
resistencia al cambio. Esta opción es la que se recomienda a las empresas
con el argumento que a través de diversas implementaciones los ERP han
adoptado las mejores prácticas del negocio.
b. Modificar de ser posible el ERP o desarrollar un plugin (programa informático
que se relaciona con otro software para agregarle una función nueva) para
que se adapte a los procesos de negocios actuales de la empresa. Esta
opción no se recomienda en primera instancia, debido a que representa un
retraso importante en la implementación y puede llegar a afectar la
estabilidad del ERP, complicando las futuras actualizaciones y en algunos
casos la fiabilidad de la información. Por lo que se opta por esta opción
cuando la empresa antepone ciertos procesos prioritarios para el buen
funcionamiento del negocio o fundamentales en su estrategia de negocios.
Otra desventaja a considerar es que representa un costo adicional para su
desarrollo y pruebas de funcionalidad.
Comúnmente las empresas al decidir implementar un ERP suelen comenzar
solicitando una cotización a diversos proveedores enfocándose primeramente en
una comparación de precios, no cabe duda de la importancia de saber si el ERP se
Administración de Proyectos para Optimizar la Implementación de un Software ERP
29
encuentra dentro del presupuesto o no, pero es en esta parte donde muchas veces
no se considera el costo adicional de los desarrollos extras. Por lo que se
recomienda primero estudiar los ERP adecuados al segmento de mercado de la
empresa y el que implique menos desarrollos a la medida ya que se reducirán
costos y riesgos del proyecto. Para validar que tanto se adapta a las necesidades
de la empresa un ERP es conveniente que los proveedores seleccionados
contesten un tipo de cuestionario conocido comúnmente como RFI (Request For
Information) con el cual se califica el porcentaje de cumplimiento del ERP a los
requerimientos de manera estándar y/o por medio de desarrollos. Este cuestionario
debe de ser estándar y tener la capacidad de evaluar a los distintos proveedores
siendo hoy en día una primera etapa y prácticamente un requisito en el ciclo para la
determinación de la elección del sistema ERP. Los proveedores responden
indicando en cada requerimiento si lo cumplen o no, con una breve descripción de
la manera en que se cumple e indicando el tipo de desarrollo que se necesita en
caso de requerirse para cubrir el requerimiento. Una vez que se acorta la lista de
posibles proveedores es necesario verificar la veracidad de las respuestas por
medio de una demostración práctica del software.
El costo de la implementación también será directamente proporcional al tiempo
total de implementación ya que normalmente los servicios profesionales de los
consultores son cotizados por día u hora, considerando que en la mayoría de los
casos en los que el software requerirá de varios desarrollos terminará costando más
que cualquiera de los otros ya sea directamente o indirectamente. Otro factor
importante a considerar es el tiempo o grado de desestabilización que se generara
dentro la empresa en el periodo de implementación, por otro lado, las historias de
éxito que mencione el proveedor de empresas similares en giro y/o tamaño también
servirán de referencia como grado de experiencia del proveedor.
Con respecto a los principales proveedores de ERP, han surgido bajas y altas en el
mercado. Al principio era un mercado especializado con poca competencia, pero
debido a su auge este se incrementó y surgieron varios proveedores que
Administración de Proyectos para Optimizar la Implementación de un Software ERP
30
posteriormente fueron absorbidos por las grandes compañías, debido al cambio del
mercado con un enfoque globalizado, se estima que en 1993 operaban cerca de
100 proveedores y a principios del 2003 se redujeron a 30 proveedores (Sierra y
Escobar, 2007).
Actualmente debido a las nuevas tecnologías de programación con diseños más
simples y flexibles se ha dado nuevamente un incremento en el desarrollo de
diversos ERP desde desarrollos personales a la medida, hasta ERP desarrollados
por medianas empresas consultoras en tecnologías de la información. Por lo que es
importante tomar en cuenta el prestigio y antigüedad del proveedor por la misma
circunstancia que se dio posterior a 1993, es decir si se toma la decisión de adquirir
un ERP desarrollado por una consultoría o por programadores propios de la
empresa, no se contara con precedentes que avalen dicho software, por lo cual a
pesar de que seguramente es más económico se corre el riesgo de que ese
software con el tiempo desaparezca, no se le pueda dar mantenimiento, soporte o
adquirir nuevas licencias. Por lo tanto, es recomendable optar por proveedores que
cuentan con distribuidores autorizados y certificados que ofrezcan respaldo y
garantía de poder ir actualizando el ERP y/o ampliando los módulos o subsidiaras
en el mismo ERP al ir creciendo la empresa.
1.4 Bases mínimas y esquema organizacional previo a la implementación.
El éxito de la implementación de un sistema integrado de planificación de los
recursos empresariales no radica simplemente en el software, se debe considerar
el entorno, contexto y situación de la empresa previo a la implementación. Dos de
los principales factores que se deben considerar es la competencia tecnología de la
organización y el apoyo total de la dirección general. Si el nivel de competencia
tecnológica es bajo, el perfil de los usuarios ante la tecnología también lo será por
lo que se debe contar con el apoyo total de la dirección general y ser conscientes
que la capacitación será más extensa. Así mismo cualquier cambio organizacional
se debe asumir de arriba hacia abajo, es decir si la alta dirección no está totalmente
convencida del cambio y piensa que el cambio ocasionará problemas y
Administración de Proyectos para Optimizar la Implementación de un Software ERP
31
contratiempos, trasmitirá esa idea a los demás niveles de la organización. (Galy y
Sauceda, 2014).
El tiempo que dura el proyecto es un factor relevante en la implementación, ya que
este es un parámetro que influye directamente en la satisfacción global de la
empresa y su futuro crecimiento y desarrollo. Para ser realista en la medición del
tiempo se deben considerar distintos factores referentes a las bases y estructura de
la empresa. El tiempo de implementación se ve afectado por el nivel de
adiestramiento y nivel de habilidades en tecnologías de la información de la
empresa, si el tiempo total del proyecto se evalúa de manera incorrecta u optimista
puede que el proyecto no sea rentable y en lugar de generar un crecimiento se
generará un déficit en la empresa (Maldonado, 2008).
Los autores, Boltena y Gómez (2012) clasificaron los problemas que se presentan
al implementar un ERP, en tres tipos.
a) La primera clasificación son problemas culturales, donde es común que un
porcentaje de usuarios se resistan al cambio
b) La segunda clasificación son problemas de negocios, ya que siempre es
necesario y recomendable la adaptación de nuevos procesos que
representen mejores prácticas de operación
c) La tercera clasificación son problemas técnicos, un ejemplo claro es la
migración de históricos donde se debe contemplar y evaluar el tiempo
necesario para esta, incluyendo las pruebas pertinentes para la
corroboración de la exactitud y veracidad de la información.
La solución oportuna de estos problemas se traducirá en tiempo, por lo que es de
vital importancia evaluar el esfuerzo que esto implicara y las actividades que se
tendrán que postergar para poder atender este tipo de problemas. Por otro lado, el
estudio de Candra (2012) determinó que el 28% del éxito en la implementación de
un ERP reside en el factor de la capacidad de conocimiento, medida por tres
indicadores: comprensión, asimilación y aplicación.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
32
Por lo tanto, dependiendo de los objetivos que la empresa quiera lograr al
implementar un ERP se debe considerar su situación previa a la implementación,
así como la capacidad y perfil del personal. Un esquema perfectamente definido con
una estructura organizacional solida donde todo el personal tiene comprendido de
una forma clara y limitada sus funciones, así como su nivel jerárquico se adaptará
de una forma más sencilla y rápida al sistema ERP. Otro factor importante a
considerar es el tamaño de la organización, es decir para una empresa nacional con
un negocio especializado será más rápida la implementación que para una empresa
trasnacional con diferentes unidades de negocio, debido al tiempo inicial que se
requiere para adaptar la estructura organizacional al flujo natural de información
dentro del ERP y las peculiaridades que se deben manejar en cada país
especialmente las fiscales. Así mismo cuando no se cuenta con una estructura
perfectamente definida, previamente a comenzar con un análisis de procesos, se
tendrá que definir primeramente el límite y poder de decisión de cada departamento
o gerente, influyendo en el tiempo total del proyecto.
Básicamente existen tres modelos a seguir para el flujo de los procesos de
negocios.
1. En el primero se estandarizan todos los procesos y son regidos por el ERP,
adecuándose cada departamento y unidad de negocio a estos.
2. El segundo en el que centralmente se estandarizan procesos y de manera
local se da cierta flexibilidad en los procesos para su adecuación siempre y
cuando se respete la estructura de la información central.
3. El tercero en el que cada unidad de negocio define sus propios procesos,
teniendo el inconveniente que se pierde la integración, por lo que a menos
que se desee un esquema descentralizado y el giro industrial así lo requiera
no es recomendable la tercera opción.
Los investigadores Razmi, Sangari, & Ghodsi (2009) evaluaron la etapa inicial de
un programa de implementación de ERP para identificar las debilidades o problemas
que pueden conducir al fracaso del proyecto, determinando que la preparación o
Administración de Proyectos para Optimizar la Implementación de un Software ERP
33
situación de la empresa previa a una implementación de ERP es el primer factor
relevante para lograr el éxito en la implementación, dividiéndola en cinco elementos
clave:
1. Proyecto: Establecer un proyecto claro y bien definido.
2. Visión y objetivos: La empresa sabe a dónde quiere llegar y tiene estrategias
de negocio y objetivos estratégicos claros para lograrlo.
3. Sistemas y procesos: Los procesos actuales son adecuados y estructurados,
de no ser así están dispuestos a modificarlos.
4. Cultura y Estructura: Los departamentos se encuentran estructurados y
definidos, se cuenta con una cultura organizacional con los requisitos del
ERP.
5. Recursos humanos: El nivel y perfil de los empleados es suficiente y
adecuado.
1.5 Administración de proyectos en la implementación del ERP.
Si bien, los ERP son una herramienta que ayudan a mejorar la productividad y
eficiencia de la empresa también son un software que implica un proceso extenso y
costoso en su implementación, por lo que sino se determina de manera correcta los
factores que implicaran su éxito se puede correr el riesgo de hacer una inversión
demasiado costosa y difícil de recuperar.
Los investigadores Rajnoha, Kádárová, Sujová y Kádár (2014) comentaron que la
implementación de un ERP es un cambio significativo que afecta la situación actual
de la empresa y que los directivos son conscientes de las consecuencias
económicas y técnicas que se enfrentaran en la implementación del ERP en sus
empresas. Por lo que es necesario un enfoque basado en administración de
proyectos considerando los siguientes puntos:
1. Complejidad del sistema
2. Factor humano
Administración de Proyectos para Optimizar la Implementación de un Software ERP
34
3. Cambio de cultura corporativa
4. Resistencia al cambio
5. Nivel de experiencia
De lo cual podemos destacar la importancia y estrecha relación que existe entre una
implementación exitosa del ERP y el correcto manejo y control de la implementación
por medio de administración de proyectos, con el cual se hace una planeación
detallando las actividades de cada fase del proyecto y los involucrados para
concluirla satisfactoriamente, previniendo los riesgos que se tendrán a lo largo del
proyecto, es decir entre más información se tenga de la situación actual de la
empresa, los recursos disponibles para la implementación y una definición clara de
sus objetivos y expectativas de la implementación del ERP mayor será la
probabilidad de éxito.
Por lo tanto, diversas compañías consultoras y los principales desarrolladores de
ERP han definido sus propias metodologías con sus propias herramientas de
software disponibles a descargar desde su página web para sus partners (socios de
negocio), con el fin de agilizar la implementación del ERP. A continuación, se
mencionan las metodologías de las 3 casas más importantes de ERP.
1.5.1 ASAP (Accelerated SAP - SAP Acelerado)
El diseño de esta metodología está basado en los procesos del PMBOK® para
implementar el ERP SAP enfocándose principalmente en pequeñas y medianas
empresas con el objetivo de minimizar costos, el tiempo de implementación se
agiliza y se reduce el proyecto. Dividiéndose en cinco fases que se encuentran
compuestas por diversas actividades que al mismo tiempo están compuestas por
diversas tareas. A continuación, las cinco fases de esta metodología y una
descripción general de las actividades a realizar en cada una de ellas.
1. Project Preparation (Preparación del proyecto): Planeación y preparación
inicial.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
35
a) Identificar y Planear las áreas de principal interés
b) Definición de objetivos generales
c) Integración del equipo de trabajo
d) Establecer el horario del proyecto y días no laborales
e) Establecer la frecuencia de reuniones
f) Establecer la frecuencia y detalle de informes de avances (semanales,
mensuales)
g) Establecer la documentación del proyecto y cartas de cierre de fase
h) Definición del plan de comunicación con métodos y procesos globales
para compartir la información del proyecto.
2. Business Blueprint (Plano Empresarial): Objetivos organizacionales
a) Revisión de requerimientos para el logro de los objetivos
organizacionales
b) Definir el plan empresarial: Consiste en un documento que de forma
gráfica muestra la estructura organizacional, a partir de esta se definen
de manera preliminar los procesos de negocio en forma de diagrama
y escrita.
c) Definir el alcance de los procesos de SAP.
3. Realization (Realización)
a) Implementar los procesos requeridos en la fase anterior
b) Pruebas Generales
c) Carta de liberación
4. Final Preparation (Preparación final)
a) Pruebas Finales: Pruebas de los procedimientos y programas de
conversión; volumen y carga; y pruebas de aceptación final
b) Capacitación del administrador del sistema
c) Capacitación a usuarios finales
d) Actividades de migración
Administración de Proyectos para Optimizar la Implementación de un Software ERP
36
5. Go Live and Support:
a) Pasar del ambiente de pruebas a producción
b) Capacitar al personal interno para soporte de usuarios finales
c) Monitorear transacciones
d) Mejorar el desempeño
e) Cierre de proyecto
1.5.2 AIM (Applications Implementation Methodology - Metodología
para la implementación de aplicaciones) y OUM (Oracle Unified Method
- Metodo Oracle Unificado)
Oracle se ha basado en metodologías estándares para la administración de
proyectos de software. AIM (Applications Implementation Methodology) es la
metodología aplicada anteriormente por Oracle y es muy similar a la metodología
comúnmente conocida como "Cascada", actualmente está utilizando un nuevo
enfoque de implementación OUM (Oracle Unified Method) que está basada en la
metodología estándar "Procesos Unificados" para el desarrollo de software.
La metodología AIM está compuesta por seis fases que a continuación se describen
de manera general:
1. Fase de definición: Planeación del proyecto y evaluación de viabilidad del
proyecto en tiempo, recursos y presupuesto.
2. Fase de análisis operacional: Análisis y determinación de requerimientos con
base a las limitantes del sistema.
3. Fase del diseño de la solución: Diseño de desarrollos que cubran futuros
requerimientos y procesos.
4. Fase de construcción: Implementación de la solución
5. Fase de transición: Los usuarios finales se incorporan al nuevo sistema
6. Fase de producción: Se comienza a utilizar el ERP en el ambiente productivo
Administración de Proyectos para Optimizar la Implementación de un Software ERP
37
La metodología OUM tiene un enfoque más flexible con el objetivo de acelerar los
proyectos, esta metodología tiene su propia herramienta de software la cual está
disponible en la página web de Oracle para sus partners. Se mantienen las mismas
seis fases del proyecto de AIM con la diferencia de que está diseñado para que
cualquiera de las tareas se pueda repetir a lo largo del proyecto con el objetivo de
mejorar las mismas ya sea por un análisis propio o por parte de los clientes.
Figura 3 OUM Fases de Implementación por Área de Enfoque (fuente: oracle)
Administración de Proyectos para Optimizar la Implementación de un Software ERP
38
Figura 4. OUM Administración del proyecto (fuente: oracle)
1.5.3 Microsoft Dynamics Sure Step (Paso seguro de Microsoft
Dynamics)
La metodología de Microsoft Dynamics está dividida en seis fases principales y dos
fases de pos-implementación para la optimización y actualización del sistema. A
continuación, se describen de manera general las ocho fases con los procesos a
realizar en cada fase:
1. Diagnostico
a) Preparación del diagnostico
b) Análisis de alto nivel
c) Detalle del análisis
d) Determinación del alcance (Scoping)
e) Análisis de infraestructura
f) Propuesta
2. Análisis
a) Planeación
b) Capacitación
Administración de Proyectos para Optimizar la Implementación de un Software ERP
39
c) Análisis para la definición de los procesos de negocio
d) Determinar la información que se migrara
e) Documentación de los requerimientos actuales
f) Propuesta
3. Diseño
a) Planeación
b) Especificaciones del diseño de la solución
c) Diseño para la migración de información
d) Especificación técnica del diseño
e) Propuesta
4. Desarrollo
a) Planeación
b) Configuración del entorno
c) Desarrollo
d) Pruebas del cliente y aceptación
5. Implementación
a) Planeación
b) Implementación Rápida
c) Configuración
d) Pruebas
e) Salida a productivo
6. Operación
a) Cierre de proyecto
b) Soporte en la salida a productivo
c) Revisión del proyecto
d) Firma de cierre
e) Soporte en productivo
f) Administración de cuentas en productivo
7. Optimización
a) Planeación
Administración de Proyectos para Optimizar la Implementación de un Software ERP
40
b) Análisis
c) Diagnostico
d) Planeación del proyecto
e) Propuesta
f) Ejecutar optimizaciones
g) Desplegar optimizaciones
8. Actualización
a) Planeación
b) Análisis
c) Diagnostico
d) Planeación del proyecto
e) Propuesta
f) Ejecutar actualización
g) Pruebas
h) Salida a productivo de la actualización
Figura 5. Metodología Sure Step (Fuente: Microsoft)
Administración de Proyectos para Optimizar la Implementación de un Software ERP
41
CAPITULO II
ADMINISTRACIÓN DE PROYECTOS
Administración de Proyectos para Optimizar la Implementación de un Software ERP
42
CAPITULO II. Administración de Proyectos
Actualmente las empresas e instituciones han adoptado la administración de
proyectos como un área de especialización para la organización y planeación de los
recursos, actividades y tareas con el fin de alcanzar un objetivo único. Las prácticas
han demostrado que con la adecuada administración de proyectos se garantiza la
obtención de resultados positivos derivados del desarrollo del proyecto; con
entregas en tiempo, presupuesto, alcance y calidad.
Teniendo una especial importancia en los proyectos de implementación de
tecnologías de la información y comunicación, donde la innovación suele ser
presente. Para lograr una correcta asignación de recursos y una administración
eficaz es necesario dominar técnicas y herramientas de administración de
proyectos, estas herramientas nos permitirán identificar los riesgos del proyecto y
los posibles impactos negativos, teniendo la oportunidad de definir planes para
mitigarlos o eliminarlos (Antoniolli, Argoud, Benevides, Pires, Herbert, Ene y Lima).
En este segundo capítulo se analizan tres metodologías para la administración de
proyectos, la primera es el PMBOK®; el cual se puede considerar como una de las
metodologías más conocidas, probadas y robustas, debido a que se aplica y ha sido
adecuada para distintos sectores. La segunda y tercera metodología son conocidas
como métodos agiles o metodologías esbeltas, las cuales son Scrum y
Programación Extrema XP, siendo que esta última se aplica mayormente para el
desarrollo de software y no para la implementación de un software robusto como lo
es un ERP, se ha decidido incorporar XP, ya que se considera importante analizar
una metodología propia para los desarrollos que se tienen que programar en las
implementaciones para lograr la customización del ERP
Administración de Proyectos para Optimizar la Implementación de un Software ERP
43
2.1 Administración de proyectos - Conceptos
La guía del PMBOK® (Project management body of knowledge) define un proyecto
como "un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o
resultado único" haciendo hincapié que por su naturaleza temporal se infiere que
tiene un inicio y final definido. A diferencia del proyecto que es temporal, el resultado
de este se espera perdure por el tiempo estimado o necesario. Los proyectos
pueden involucrar a 1 sola persona, una unidad de trabajo o múltiples unidades.
Por otro lado, define la dirección de proyectos como "la aplicación de conocimientos,
habilidades, herramientas y técnicas a las actividades del proyecto para cumplir los
requisitos del mismo". La dirección de proyectos normalmente implica en primer
lugar identificar requisitos; posteriormente analizar las diversas necesidades y
expectativas de los interesados con base a la planificación y ejecución del proyecto;
equilibrando las restricciones contra la calidad, el alcance, el tiempo, los recursos,
el presupuesto y el riesgo del proyecto.
Por lo que se puede decir que la administración de proyectos es una disciplina
importante que sirve de guía para la correcta planeación y control del desarrollo de
actividades temporales teniendo una perspectiva global del alcance y una mejor
visión y análisis de riesgos, aumentando o garantizando las probabilidades de éxito
del proyecto.
2.2 Guía de los fundamentos para la dirección de proyectos (PMBOK®)
La guía del PMBOK® (Project management body of knowledge) es un estándar
sólido para la administración de proyectos desarrollado y actualizado durante varios
años por los expertos del PMI (Project Management Institute). Considerando que el
estándar es un documento, aprobado y establecido por consenso por un organismo
reconocido, que pronostica el uso común y repetido de reglas, características y/o
directrices para resultados y actividades encaminadas al logro óptimo de orden en
un argumento dado. Los estándares del PMI proporcionan pautas para el logro de
Administración de Proyectos para Optimizar la Implementación de un Software ERP
44
los resultados del proyecto, del programa y de administración de carteras
específicas.
Los estándares son desarrollados y aprobados en un proceso basado en el
consenso asegurando que todos los interesados puedan participar. El PMI es
miembro del Instituto Nacional Estadounidense de Estándares (American National
Standards Institute, ANSI) como desarrollador de estándares acreditados cumple
con los procedimientos del ANSI. Estos estándares proporcionan la base del
conocimiento para la administración de proyectos divididos en cuatro áreas de la
profesión las cuales son: programas, proyectos, carteras y el enfoque de
organización para la administración de proyectos, así mismo se encargan de
desarrollar la base sobre la que se construyen las prácticas y extensiones
específicas de la industria.
Para el presente trabajo nos enfocaremos en el área de proyectos, los cuales tienen
las siguientes características:
Alcance: Todos los proyectos tienen objetivos específicos y definidos. El
alcance se realiza gradualmente durante el ciclo de vida del proyecto.
Cambios: Se deben prevenir los cambios, así mismo diseñar procesos
flexibles para mantener dichos cambios administrados y controlados.
Planificación: La información de alto nivel se va transformando en planes
detallados y específicos a lo largo del ciclo de vida del proyecto.
Dirección/Administración: El equipo de trabajo es guiado y dirigido por el líder
de proyecto con el propósito de cumplir los objetivos del proyecto.
Éxito: El éxito del proyecto se puede medir con diversos indicadores, no
obstante, siempre se deme medir la calidad del producto y del proyecto por
medio de la puntualidad y cumplimiento de fechas de entrega, cumplimiento
con el presupuesto y el grado de satisfacción del cliente.
Seguimiento: El líder de proyecto realiza un seguimiento de los productos,
servicios o resultados para los cuales el proyecto fue emprendido, analizando
los resultados obtenidos, así como el cumplimiento de los objetivos.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
45
Los proyectos no se dan de manera aislada, es decir son derivados para el
desarrollo de algo específico el cual afectara a diversos elementos de manera
interna en la organización o de manera externa en su entorno. Por lo que se deben
definir los interesados los cuales pueden ser personas u organizaciones que se
involucraran en el proyecto ya sea de forma directa o indirecta mientras sus
intereses se vean afectados positivamente o negativamente con la ejecución o
terminación del proyecto. A continuación, la gráfica que detalla la relación entre los
interesados y el proyecto.
Figura 6: Relación entre los interesados y el proyecto (Fuente: PMBOK®)
La comunicación del proyecto siempre es crucial por lo que se tiene que determinar
desde un principio el canal de comunicación y definir el grado de involucramiento
de cada persona u organización especificando responsabilidades y definiendo a las
personas aptas para la toma de decisiones.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
46
Cada proyecto es divido en fases, ya que manejando subconjuntos se puede lograr
una mejor dirección, planificación y control, teniendo metas claras en cada fase. En
la mayoría de los proyectos las fases son secuenciales por lo que el cierre de una
fase termina con el entregable de la fase considerándola cerrada y un punto de
revaluación conocido como punto de decisión, este cierre se debe asentar antes de
proseguir con la siguiente fase. Otro tipo de relación entre fases es de
superposición, en donde la fase consiguiente es empezada antes de cerrar la fase
anterior, muchas veces aumentando el riesgo por no tener la información precisa de
la fase previa. Otro tipo es la relación iterativa entre fases, donde se planifica la
primera fase y la consiguiente se planificará conforme avance el trabajo de la fase
actual, manteniendo la planeación únicamente a corto plazo, siendo recomendable
en ambientes poco definidos o cambiantes. Cada fase se diferencia por su trabajo
con enfoque único el cual involucra diferentes elementos o áreas de la organización,
definiendo los límites de cada fase.
La guía PMBOK® cuarta edición está contenida por cuarenta y dos procesos
divididos en cinco grupos de procesos, exponiendo que "la aplicación del
conocimiento requiere de la dirección eficaz de los procesos apropiados". Por lo que
para los proyectos de implementación o desarrollo de sistemas informáticos para el
almacenamiento y ordenamiento de la información se parte principalmente de estos
cinco grupos y posteriormente se utilizan solo los procesos convenientes en cada
grupo dependiendo el tipo de proyecto. Debido a que comúnmente se parte de
requerimientos generales en este tipo de proyecto y conforme avanza el proyecto y
se tiene información más tangible de una forma más visual se dan requerimientos
más precisos que posteriormente facilitaran la operación o la toma de decisiones a
nivel estratégico. Las fases difícilmente se darán de manera secuencial y por lo tanto
los procesos a utilizar se deben ir adecuando dependiendo el avance y complejidad
de las reglas del negocio.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
47
Marcando a continuación los cinco grupos con sus procesos y la manera en que interacciona de manera cíclica cada proceso a lo largo del proyecto.
Figura 7: Interacciones entre procesos de la dirección de proyecto (Fuente: PMBOK®)
Administración de Proyectos para Optimizar la Implementación de un Software ERP
48
A continuación se detalla la manera estandar de forma general en que se lleva la
administración de proyectos por medio de estas cinco fases:
1. Inicio
2. Planeación
3. Ejecucion
4. Control
5. Cierre
2.2.1 Inicio
En este grupo están definidos los procesos necesarios para declarar un nuevo
proyecto o una fase por medio de la autorización del patrocinador para dar inicio al
proyecto. Involucrando los siguientes procesos:
Desarrollar el Acta de Constitución del Proyecto
Consiste en crear un documento con el cual se autoriza de manera formal el
proyecto, este es formado a partir del contrato, enunciado del trabajo del proyecto
(SOW), procesos de la organización y los factores ambientales de la empresa. En
el documento se incluyen los requisitos iníciales y objetivos generales para cumplir
las necesidades y expectativas del proyecto.
El propósito del Acta de Constitución del Proyecto es establecer una relación de
cooperación entre la organización solicitante (cliente) y la organización ejecutante
(proveedor). Los líderes de proyecto por parte del cliente y del proveedor participan
en la elaboración de este documento, ya que son los que asignan los recursos a
cada actividad del proyecto.
El contrato constituye una entrada y un respaldo legal para garantizar el
cumplimiento de las partes convenidas.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
49
El Enunciado del Trabajo del Proyecto (SOW) es el documento que define y
especifica cada producto o servicio que será resultado del proyecto, este documento
es redactado con base a los siguientes puntos:
a) Los requisitos o necesidades de la empresa derivados por diversas
situaciones como puede ser, una regulación fiscal o política gubernamental,
o por una creciente demanda del mercado o al avance tecnológico o un
requisito legal.
b) El alcance del producto. Se debe de especificar la necesidad comercial a
cubrir, la manera en que se cubrirá, los puntos a abarcar y sus limitaciones.
c) Plan estratégico. A pesar de que la metodología o hasta el tipo de proyecto
pareciera igual a otro proyecto anterior, el hecho es que cada organización
es diferente, con diferentes personas, diferentes factores etc… lo cual hace
que algunos proyectos sean más complicados que otros. Por lo cual cada
proyecto necesita sus propias estrategias, dependiendo el medio en el que
se desarrollara. Siendo de gran importancia definir estas estrategias al inicio
del proyecto.
Procesos de la organización es necesario tener claro los procesos y políticas
organizacionales y en caso de tener procesos normalizados y/o certificados que no
se pueden modificar.
Los factores ambientales de la empresa se pueden dividir en factores
ambientales externos e internos. Los factores externos pueden ser: condiciones del
mercado, normas gubernamentales o industriales y los factores internos dependen
de la infraestructura de la organización. Estos factores deben ser definidos y
considerados ya que pueden influir para tomar decisiones del proyecto.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
50
Por lo tanto, el Acta de Constitución del Proyecto se encarga de documentar las
necesidades y requerimientos comerciales en conjunto con la información que se
dispone de las necesidades del cliente para lo cual se llevara a cabo el proyecto
definiendo el producto o servicio que resultara del proyecto. Este documento se
puede diseñar según las necesidades, tipo y tamaño de cada proyecto, agregando
o disminuyendo información tal como: el nombre y el nivel de autoridad del
patrocinador quienes autorizan el acta de constitución del proyecto; el propósito o
la justificación del proyecto; los requisitos de alto nivel; la descripción del proyecto
de alto nivel; un resumen del cronograma de hitos; un resumen del presupuesto; los
requisitos de aprobación del proyecto, los objetivos medibles del proyecto y los
criterios de éxito relacionados; quién decide si el proyecto es exitoso y quién firma
la aprobación del proyecto; los riesgos de alto nivel; el líder de proyecto, su
responsabilidad y su nivel de autoridad.
2.2.2 Planeación
En el grupo de procesos de Planeación se detallan las actividades y su itinerario
para el logro de los objetivos planteados en el alcance y lograr el cumplimiento y
entrega del producto o servicio para lo cual fue solicitado el proyecto. Considerar
los siguientes puntos:
1. Definir las actividades a realizar.
2. Determinar los recursos necesarios para realizar las actividades y el perfil
necesario para poder realizar dichas actividades.
3. Determinar los posibles documentos que serán sujetos a un control de
cambios avanzado el proyecto.
4. Detallar técnicamente la manera en que se administrara el proyecto.
5. Adaptar el proceso para cumplir con las necesidades del proyecto.
Los procesos de planeación son la base para el cumplimiento en tiempo y costo del
proyecto, si se logra una buena planeación del proyecto, los siguientes procesos se
Administración de Proyectos para Optimizar la Implementación de un Software ERP
51
podrán ejecutar de una manera fluida y prácticamente sin contratiempos. Teniendo
los siguientes procesos dentro de este grupo.
Planeación de la comunicación
La comunicación y la manera de recopilar, almacenar y difundir la información
referente al proyecto es fundamental, ya que si se tiene una mala comunicación esta
puede ocasionar desacuerdos entre los involucrados y malos entendidos. Por lo
cual dentro de la planeación se debe elaborar el “Plan de Comunicación”
especificando los canales y horarios para la comunicación. Así mismo siempre es
bueno definir un repositorio de información donde los involucrados puedan consultar
avances, estatus y los acuerdos a lo largo del proyecto. A continuación, los puntos
a considerar.
1. Identificar a los Interesados: Consiste en identificar las organizaciones, áreas
y personas involucradas en el proyecto, documentando sus interés y grado
de impacto que tienen sobre el proyecto.
2. Planificar las Comunicaciones: Se debe definir el periodo de comunicación y
grado de detalle a dar a conocer dependiendo el perfil de cada interesado.
Es conveniente realizar juntas de avance del proyecto donde simplemente se
revisan estatus y actividades siguientes a realizar. También se define el canal
y forma de abordar la comunicación dependiendo el nivel del involucrado.
3. Distribuir la Información: es poner la información a disposición de los
interesados de acuerdo al plan establecido.
4. Administrar las Expectativas de los Interesados: Es el proceso de
comunicarse y trabajar en conjunto con los interesados para satisfacer sus
necesidades y abordar los problemas conforme se presentan.
5. Informar el Desempeño: Es el proceso de recopilación y distribución de la
información sobre el desempeño, incluyendo los informes de estado, las
mediciones del avance y las proyecciones.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
52
El entregable de este proceso es el plan de comunicación en el cual queda
establecido los integrantes del equipo del proyecto y los involucrados, definiendo su
grado de responsabilidad y capacidad para tomar decisiones en cada tema
relevante a lo largo del proyecto.
Alcance del proyecto
Los procesos que se aplicaran son recopilar requisitos y definir el alcance. En la
recopilación de requisitos se definen y documentan las necesidades para cumplir
los objetivos del proyecto, a partir del acta de constitución del proyecto y el registro
de interesados se define la matriz de rastreabilidad de requisitos y se documentan
los requisitos creando el documento alcance del proyecto y la EDT (Estructura de la
División de Trabajo).
Recopilar Requisitos
Es importante limitar los siguientes tres conceptos para contextualizar la
recopilación de requisitos del proyecto:
a) Metas del proyecto (Project Goals): Están expresadas en el lenguaje del
patrocinador del proyecto, y están dirigidas hacia la meta o razón de ser del
negocio.
b) Objetivos (Objectives): Son los resultados que el proyecto produce en forma
directa. Alcanzar los objetivos en tiempo, en presupuesto y con calidad, son
el trabajo del administrador del proyecto.
c) Requerimientos (Requirements): Son las características necesarias de los
objetivos para que se cumplan las metas y para que el proyecto pueda ser
entregado.
Por lo tanto, se puede decir que la recopilación de requisitos consiste en documentar
las necesidades y expectativas de manera específica de los interesados para
cumplir los objetivos del proyecto.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
53
El éxito del proyecto dependerá directamente del cuidado con el que se recaben los
requerimientos así mismo del detalle con el cual sean documentados dichos
requerimientos. la documentación tiene que ser tan especifica como sean
necesarias para poder medir el cumplimiento de dichos requerimientos a lo largo
del proyecto y por supuesto al concluirlo.
Existen diversas herramientas para administrar y documentar los requerimientos un
ejemplo es la matriz de rastreabilidad de requisitos, sin embargo, este tipo de
matrices son muy extensas lo cual las hace imprácticas dificultando la
administración de requerimientos y haciendo laboriosa su actualización. Por lo cual
se recomienda dividir los requerimientos por áreas o cumplimiento de objetivo o
funcionalidad.
Documentación de Alcance del proyecto
En este documento se detalla la forma en que cada requerimiento será cubierto, así
como las premisas, supuestos, riesgos y limitaciones. Este documento puede tener
un lenguaje técnico siempre y cuando sea entendible para el cliente y se redacte de
manera clara el alcance que tendrá el producto o servicio al finalizar el proyecto.
El alcance del proyecto define el trabajo que se realizará y el que se excluirá, el
detalle dependerá del tipo y tamaño del proyecto y puede ser directamente en el
documento de alcance o por referencia a otros documentos, normalmente las partes
a incluir son las siguientes:
1. La descripción y características del alcance del producto, servicio o resultado
definido en los procesos anteriores (acta de constitución del proyecto y
documentación de requisitos).
2. Los criterios de aceptación del producto, servicio o resultado.
3. Los entregables del proyecto.
4. Identificar las limitaciones o exclusiones del proyecto.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
54
5. Las premisas, supuestos y posibles riesgos en caso de supuestos
desfavorables.
EDT (Estructura de la División de Trabajo)
Crear la EDT consiste en subdividir un proyecto en piezas pequeñas para que sea
más manejable y se tenga un mayor control. La EDT se realiza en forma de árbol
jerárquico de los elementos finales que el equipo de proyecto realizará durante el
proyecto, realizándola siempre de lo más general a lo más específico, por lo que
cada nivel inferior en la EDT representará un mayor detalle. El principal propósito
de la EDT es organizar y definir el alcance total del proyecto de una manera más
manejable. Incluyendo los siguientes puntos.
1. Identificar y definir los entregables y el trabajo relacionado.
2. Estructurar la EDT.
3. Detalla la división del trabajo de arriba hacia abajo, de lo genera a lo
especifico, de los niveles superiores hacia niveles inferiores.
4. Verificar que el grado de detalle y descomposición sea el adecuado.
Administración del tiempo del proyecto
La administración del tiempo del proyecto abarca los procesos necesarios para que
el proyecto se realice en el tiempo establecido y con el costo presupuestado.
Incluyendo los siguientes procesos.
1. Definir las Actividades: Es la base del plan de trabajo, en donde se
determinan todas las acciones a realizar para concluir los entregables
parciales y final del proyecto
2. Secuenciar las Actividades: Es necesario identificar la relación y
dependencia que existe entre las actividades, de esta manera se definen las
tareas consecutivas y las que pueden realizarse de forma paralela.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
55
3. Estimar los Recursos necesarios para cada actividad: Consiste en estimar el
tipo y cantidad de recursos necesarios para cada tarea, incluyendo
suministros, materiales, personas y equipos.
4. Estimar la Duración de las Actividades: Consiste en estimar el periodo
normalmente calculado en horas o días para cada tarea con los recursos
estimados
5. Desarrollar el Cronograma: Consiste en documentar y coordinar las
actividades dependiendo su secuencia, estimación de duración y recursos
asignados.
6. Controlar el Cronograma: Conforme avanza el proyecto es necesario
actualizar el estatus del cronograma y de ser necesario ajustarlo.
En algunos casos estos 6 procesos son vistos como un único proceso, esto depende
en gran medida del tamaño del proyecto, ya que los proyectos de corto alcance
tienen una vinculación más estrecha entre estos procesos, lo cual permite que su
definición sea más concreta y rápida. Sin embargo, independientemente al tamaño
del proyecto el cronograma debe realizarse como un proceso iterativo que
determina las fechas de inicio y fin de manera planificada para las actividades del
proyecto y los hitos.
A lo largo del proyecto es necesario revisar y actualizar el cronograma, debido a
que mientras se avanza y realizan las tareas definidas, el panorama de la dirección
de proyecto, así como los riesgos van evolucionando, y en ocasiones es
indispensable incorporar nuevas tareas y recursos.
Administración de los riesgos del proyecto
El proceso a aplicar es conocido como “identificar los riesgos”, en este proceso se
determinan los posibles riesgos que pueden afectar el tiempo del proyecto o su
resultado, por lo tanto, se debe planificar la respuesta a los riesgos definiendo las
acciones opcionales, reduciendo y previniendo las amenazas que generen
incumplimiento en el éxito del proyecto. Considerando que cualquier evento incierto
Administración de Proyectos para Optimizar la Implementación de un Software ERP
56
o condición incierta son representados como riesgos debido a que si llegaran
acontecer surtirán efecto en por lo menos uno de los objetivos del proyecto, estos
se ubican en el futuro y pueden tener uno o más orígenes y uno o más impactos.
Los riesgos pueden ser originados por distintas fuentes como puede ser: un
requisito, una restricción, un supuesto o una condición que crea la posibilidad de
consecuencias negativas o positivas.
2.2.3 Ejecución
En este grupo se encuentran los procesos realizados para completar el trabajo
definido en el plan, con el propósito de cumplir las especificaciones de los procesos
de planeación. El proceso a aplicar dentro de este grupo de procesos es dirigir y
administrar la ejecución del proyecto, a partir del cronograma del proyecto y
solicitudes de cambio aprobadas teniendo como resultado los entregables
correspondientes, información sobre el desempeño del trabajo, solicitudes de
cambio y la actualización del plan y los documentos del proyecto.
Dirigir y Administrar la Ejecución del Proyecto
Dirigir y Administrar la Ejecución del Proyecto es el proceso que consiste en ejecutar
las actividades definidas en el plan de trabajo. El líder de proyecto, junto con el
equipo administra y dirige la realización y desempeño de las actividades planificadas
del proyecto. Cada actividad o fase del proyecto se concluye con un entregable que
sirve de indicador que se ha concluido la actividad o fase logrando los objetivos de
esa actividad. El proceso es el siguiente.
1. Obtener y administrar los recursos necesarios para realizar las actividades
2. Administrar los medios de comunicación internamente y externamente
3. Dirigir al equipo implementando los métodos planificados
4. Realizar las actividades del cronograma
5. Realizar los entregables
6. Actualizar el avance del proyecto, registrando su costo real y avance técnico
Administración de Proyectos para Optimizar la Implementación de un Software ERP
57
7. Documentar el control de cambios y de ser aprobados adaptar los nuevos
requerimientos
8. Gestionar los riesgos implementado la respuesta planificada
2.2.4 Supervisión y Control
En este grupo se encuentran los procesos que sirven para monitorear, examinar y
regular el avance y desempeño del proyecto por medio de los cambios
correspondientes en caso de ser necesarios, los procesos por aplicar son:
Monitorear y controlar el trabajo del proyecto
Consistiendo en revisar, examinar y regular el avance del proyecto con el fin de
cumplir los objetivos definidos en el plan del proyecto, por medio de KPI (key
performance indicator – indicador clave de desempeño) y solicitudes de cambio se
debe supervisar y controlar el proyecto. El seguimiento es una tarea del líder de
proyecto que debe realizar a lo largo de todo el proyecto, mientras que el control
consiste en realizar acciones preventivas o correctivas y de ser necesario modificar
los planes de acción, siempre continuando con el seguimiento de las actividades y/o
cambios con el fin de determinar si se logró resolver el problema. A continuación,
las actividades implicadas en este proceso:
1. Comparar el avance y costo real vs lo planeado
2. Evaluar la calidad y desempeño de los resultados
3. Identificar y analizar acciones correctivas o preventivas
4. Recomendar las acciones acertadas
5. Monitorear los riesgos e identificar si existen nuevos riesgos
6. Implementar la respuesta apropiada hacia los riesgos
7. Mantener la información y documentación del proyecto actualizada
sustentando el estatus del proyecto
8. Hacer los ajustes del cronograma y costos con base a la proyección
dependiendo el estatus real del proyecto.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
58
9. Monitorear la implementación de los cambios autorizados.
Realizar el control integrado de cambios
El control de cambios implica revisar y analizar la factibilidad de los nuevos
requerimientos o solicitudes de cambio, documentando de manera formal el alcance
y sus implicaciones, el detalle de este documento dependerá del estatus de avance
del proyecto. Adaptando el plan de trabajo y recursos necesarios para llevar a cabo
los cambios aprobados.
2.2.5 Cierre
Este grupo se conforma por el proceso conocido como cierre de fase o del proyecto
dando fin a todas las actividades con el propósito de cerrar formalmente el proyecto
o fase. El cierre se presenta como un documento formal que autoriza el cierre y
aceptación del patrocinador. No obstante, se debe realizar una revisión tras el cierre
del proyecto o la terminación de una fase, registrando todos los documentos
sobresalientes del proyecto como son: las lecciones aprendidas, los impactos de la
adaptación a un proceso, las actualizaciones que fueron apropiadas para la
organización, etc. Toda esta información se debe archivar e ir consolidando en una
base de datos con el conocimiento de cada proyecto.
Sánchez-Arias y Solarte-Pazos (2010) hacen una crítica hacia la guía PMBOK® por
las limitaciones en las especificaciones de la propia guía en la administración de
proyectos, argumentando que los proyectos en la práctica real son más complejos
de lo que se pueden comprender con la guía PMBOK®, señalando que el ciclo de
trabajo del proyecto en los grupos de procesos analizados en el PMBOK® no
promueven una retroalimentación que permitan cuestionar y corregir el trabajo
sobre la marcha. Asumiendo supuestos de una correcta planificación en situaciones
poco dinámicas y sin considerar el factor humano o social, como pueden ser
decisiones de carácter ético. Así mismo mencionan que en la administración de
proyectos se debe partir del análisis y la definición de niveles por complejidad,
Administración de Proyectos para Optimizar la Implementación de un Software ERP
59
promoviendo mecanismos y técnicas para la evaluación del contexto, ofreciendo
diferentes técnicas, herramientas y modelos que permitan avanzar con una mayor
estructuración del esquema de trabajo, y así el líder de proyecto pueda enfrentarse
a la incertidumbre con las herramientas necesarias para negociar y tomar
decisiones en contextos de ambigüedad reales y no empíricos.
Sin embargo el PMI esclarece que la guía PMBOK® es como su propio nombre lo
indica una guía y que cualquiera que utilice el documento debe depender de su
propio juicio y experiencia profesional como administrador de proyectos para
determinar el curso de acción o especificación conveniente para el proyecto, es
decir la guía PMBOK® no está definida como un manual que se debe seguir al pie
de la letra, por lo que no es un documento que defina a detalle los pasos a seguir y
elegir para implementar un proyecto debido a que la guía está estructurada de una
forma estándar y general para que se pueda aplicar y adecuar a las distintas áreas
y particularidades en los distintos tipos de proyectos, ya sea para proyectos de la
construcción o como lo es en nuestro caso para la implantación y/o desarrollo de
sistemas informáticos, los cuales difieren en gran medida uno de otro.
Por lo tanto, para la implementación o análisis de desarrollo de software se
complementarán los procesos descritos en la guía PMBOK® y en algunos casos se
simplificará u omitirá la generación de documentos que para fines prácticos en la
implementación de un ERP se pueden considerar excesivos y de poco valor. Estos
procesos se complementarán con diversas metodologías y técnicas, como lo es la
metodología conocida como Scrum, la cual está basada en métodos agiles
apoyándose principalmente en las relaciones directas y la correcta organización de
los miembros del equipo del proyecto, acelerando y optimizando el tiempo del
proyecto en actividades que generan valor teniendo como resultado proyectos
menos costos y por lo consiguiente óptimos.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
60
2.3 Scrum
Una de las diferencias más marcadas entre metodologías tradicionales conocidas
como metodologías predictivas y las metodologías agiles, está en la definición de
requerimientos. Las metodologías predictivas como su mismo nombre lo indica,
esperan tener el control y conocimiento de todo el proyecto desde antes de
comenzarlo, en cambio las metodologías agiles están diseñadas para que a partir
de objetivos generales el proyecto se desarrolle y posteriormente se comience a
trabajar con requerimientos detallados con base a los resultados, dependiendo el
punto de vista del cliente. Sin embargo, esto no quiere decir que no se cuente con
una planeación, sino más bien que la planeación tiene que ser flexible para
adaptarse a cambios, siendo una característica importante al hablar de sistemas
con tecnologías de información.
Otra diferencia entre ambos tipos de metodologías es el tipo de administración entre
los integrantes del equipo, ya que los métodos agiles propician el involucramiento
por parte de todo el equipo en el diseño de la solución, fomentando mayor
creatividad generando soluciones más innovadoras.
El término "Scrum" aparece por primera vez en 1986 en el artículo llamado ”The
New New Product Development Game” por Takeuchi y Nonaka los cuales hacen
referencia entre la metodología para desarrollo y al juego de rugby donde existe una
formación conocida como Scrum, sin embargo fue hasta 1995 que Ken Schwaber
presentó el escrito “Scrum Development Process” formalizando la metodología y en
el 2009 funda Scrum.org encargada de difundir y certificar en esta metodología,
obteniendo un gran reconocimiento a nivel mundial.
Scrum es una metodología desarrollada para entornos con alta incertidumbre en
donde no se cuentan con requisitos estables, teniendo como principio básico la
flexibilidad por medio de una implementación pragmática. Consistiendo en que la
metodología se adapte a la organización y no al revés, poniendo mayor énfasis en
la adaptabilidad y no en la previsibilidad. Realizando una administración experta
Administración de Proyectos para Optimizar la Implementación de un Software ERP
61
más que una administración técnica, es decir una administración dirigida desde el
conocimiento, experiencia y criterio del líder de proyecto. Logrando una
administración basada en las personas antes que, en el modelo.
La metodología de Scrum utiliza sus propias definiciones para los integrantes del
equipo, fases de proyecto y herramientas para la administración del proyecto y cada
definición cuenta con peculiaridades propias de la metodología. Las iteraciones son
definidas como sprints los cuales van ligados con los entregables parciales que se
realizan o incrementos funcionales; los integrantes del equipo se dividen en lo que
se definen como “roles”; las herramientas para la administración del proyecto se
definen como “artefactos” y las fases son definidas como: pre juego, juego y post
juego.
A continuación, una descripción muy breve de lo que abarca cada fase con base a
la metodología Scrum:
1. Pre Juego: Es la fase en donde se planifica y se revisan los requerimientos
y objetivos generales del proyecto y la estimación de tiempo.
2. Juego: Es la fase de desarrollo, incluyendo la presentación de entregables
para una continua retroalimentación hasta concluir el desarrollo, sin perder
de vista el tiempo y costo establecido.
3. Post Juego: Es la fase en la que se autoriza la salida a productivo, por lo
tanto, considera las últimas pruebas integrales, capacitación, documentación
y detalles previos al lanzamiento en productivo.
Los Roles se dividen de la siguiente manera:
1. Scrum Master: Se encarga de guiar al equipo para utilizar la metodología
Scrum, a diferencia de un líder de proyecto tradicionalista que se encarga de
dividir el trabajo y dirigirlo, el Scrum Master es más bien un facilitador del
trabajo en equipo. Siendo el intermediario entre el Product Owner y el Scrum
Administración de Proyectos para Optimizar la Implementación de un Software ERP
62
Team, uno de sus principales deberes es mantener al equipo en un continuo
progreso.
2. Scrum Team: Son los encargados del desarrollo del proyecto, siendo
aconsejable manejar máximo 9 personas en un mismo Scrum Team. Una de
las características de esta metodología es que son grupos auto organizados
por lo que normalmente el Scrum Team se divide el trabajo de acuerdo a las
aptitudes de cada integrante en común acuerdo.
3. Product Owner: Es la persona asignada por el cliente que cuenta con la
perspectiva general del proyecto y los objetivos a nivel del negocio, el product
owner es el intermediario entre los usuarios finales e interesados y el Scrum
Master.
4. Stakeholders: Normalmente son varias personas las cuales se verán
afectadas por el resultado del proyecto, pueden ser internas a la organización
como lo son usuarios finales o externas como lo son proveedores.
Los artefactos se dividen en tres tipos los cuales son:
1. Product Backlog (Pila de Producto): Incluye los requerimientos iniciales y
posteriormente sus detalles y/o actualizaciones a lo largo del proyecto. El
Product Backlog abarca los requerimientos funcionales, tecnológicos,
mejoras al producto y correcciones; ordenando cada requerimiento
dependiendo su prioridad, estimación de tiempo y el criterio para su
validación.
2. Sprint Backlog (Pila de iteración): Es el desglose de actividades a realizar
para cubrir cada requerimiento estipulado en el product backlog, indicando el
responsable, estatus y tiempo invertido en cada actividad.
3. Incremento funcional potencialmente entregable: Básicamente son los
entregables parciales listos para que los usuarios los puedan probar o
corroborar.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
63
2.4 Programación Extrema (XP)
XP es una de las metodologías más esbeltas debido a su poca documentación y
forma de comunicación. Considerando como una de sus claves para el éxito del
desarrollo las relaciones interpersonales promoviendo la comunicación directa y
fluida entre todos los integrantes, así como la trasmisión del conocimiento de
persona a persona. Esta metodología fue descrita por primera vez por Kent Beck en
1999 en su libro “Extreme Programming Explained: Embrace Change” (Ingeniería
de Software, 2015).
Esta metodología esta enfocada principalmente para proyectos de desarrollo de
software con un tiempo muy limitado, su proceso es incremental con continuas
demostraciones, pruebas y aprobaciones parciales por parte del cliente, lo cual logra
equilibrar la carga de trabajo a lo largo de todo el desarrollo y no solo al final de él.
A continuación, los Roles definidos en XP.
1. Programador: Produce el código del sistema y escribe las pruebas unitarias.
Cabe señalar que debe existir una comunicación y coordinación adecuada
entre los programadores y otros miembros del equipo.
2. Cliente: Se encarga de escribir las historias de usuario, asigna la prioridad
de las mismas, realiza las pruebas funcionales con el objetivo de validar y
dar el visto bueno para su implementación.
3. Tester (Encargado de pruebas): Ejecuta las pruebas y difunde los
resultados hacia el equipo.
4. Tracker (Encargado de seguimiento): Comprueba el grado de acierto entre
las estimaciones realizadas y el tiempo real que fue dedicado, con la
intención de mejorar futuras estimaciones, realiza el seguimiento del
progreso de cada iteración y proporciona retroalimentación al equipo.
5. Coach (Entrenador): Es el responsable del proceso global del proyecto, su
función en suministrar guías al equipo, para que se apliquen las prácticas de
la metodología XP y se alcancen los procesos de forma correcta.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
64
6. Consultor: Integrante con conocimientos específicos sobre algún tema que
pueda ser necesario para el proyecto y con su apoyo erradicar los problemas
que puedan surgir.
7. Big boss (Gestor): Coordina al equipo y es el intermediario entre los clientes
y programadores, crea las condiciones adecuadas para que el equipo trabaje
eficientemente.
Los requerimientos se recaban en forma de historias de usuario considerando las
siguientes fases de forma cíclica, para cada requerimiento hasta completar el
producto.
1. Análisis
2. Diseño
3. Código
4. Pruebas e Integración
5. Implementación
Figura 8: Calendario (Schedule of work). (Fuente: http://www.agile-process.org/byfeature.html)
Administración de Proyectos para Optimizar la Implementación de un Software ERP
65
Figura 9: Fichas de Requerimientos (Story Cards). (Fuente http://www.agile-process.org/byfeature.html)
2.5 Metodologías Tradicionales vs Metodologías Agiles
A continuación, un cuadro comparativo entre las metodologías tradicionales vistas
como “Gestión Predictiva” y las metodologías agiles como “Gestión Evolutiva”,
observando de manera concreta su forma de trabajo para la administración del
proyecto.
Figura 10: Diagrama de conceptos de la administración de proyectos (Fuente: Iubaris Info
4 Media SL, 2016).
Administración de Proyectos para Optimizar la Implementación de un Software ERP
66
Diversos estudios como el del organismo The Standish Group International Inc
(2011) que declara “El proceso ágil es el remedio universal para el fracaso de los
proyectos de desarrollo de software. Las aplicaciones de software desarrolladas a
través del proceso ágil tienen tres veces más tasa de éxito que el proceso de
cascada tradicional y un porcentaje mucho menor de los excesos de tiempo y
costos. El secreto está en el ensayo y error, y la entrega del producto iterativo”
afirmando que los proyectos de desarrollo con métodos agiles tienen un mayor
índice de éxito. Sin embargo al implementar un software tan robusto como lo es un
ERP y que si bien es común incorporar desarrollos durante la implementación
también debemos considerar la cultura laboral y regional en donde se desenvolverá
el proyecto, siendo que hoy en día en México aún somos una sociedad
tradicionalista, por lo tanto el cambio y la innovación no son aceptados de una
manera rápida y fácil.
Por lo tanto, el incorporar este tipo de metodologías agiles para implementar un ERP
y hacer los desarrollos necesarios para la implementación no fue del todo aceptada,
ni muy bien vista por todos los involucrados en el proyecto. Decidiendo incorporarlas
al proyecto de una manera sutil con fines prácticos y dejando como base la
metodología del PMBOK®, surgió una nueva inquietud para el correcto desarrollo
del presente trabajo que fue el estudio y propuesta de los “Factores de Complejidad
Ambiental” para sistemas ERP en México ayudándonos a considerar las
peculiaridades en el que se desarrollara el proyecto y el cual es descrito en el
siguiente capítulo.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
67
CAPITULO III
PROPUESTA DE FACTORES DE
COMPLEJIDAD AMBIENTAL
PARA SISTEMAS ERP EN MÉXICO
Administración de Proyectos para Optimizar la Implementación de un Software ERP
68
CAPITULO III.- PROPUESTA DE FACTORES DE COMPLEJIDAD
AMBIENTAL PARA SISTEMAS ERP EN MÉXICO
En la práctica al incluir metodologías agiles, reducir documentación y teniendo una
comunicación más directa y rápida, distintos niveles de los involucrados de ambas
partes (cliente y proveedor) no reaccionaron muy favorablemente, debido a distintos
factores y presiones externas e internas a la organización, por lo tanto, es necesario
considerar la cultura laboral y entorno en donde se desarrolla el proyecto.
La metodología por sí sola no bastará para alcanzar el éxito del proyecto ya que
difícilmente se logrará sin la colaboración de los integrantes del equipo del proyecto
y la aprobación de los principales involucrados, por esta razón es necesario
considerar el entorno en el que se desenvolverá el proyecto. Siendo así en este
capítulo se incorpora el estudio sobre los factores de complejidad ambiental en las
empresas mexicanas, para poder tener un mejor enfoque de cómo aplicar las
metodologías antes vistas, en entornos, donde hoy en día se vive una
desestabilidad económica y política, que indirectamente afecta el desempeño
laboral de los involucrados y poder de toma de decisión.
Así mismo como sociedad se maneja una ideología del trabajo en equipo, diferente
a la descrita por Takeuchi; Nonaka; Ken Schwaber y Kent Beck, siendo necesario
en algunas fases del proyecto y una mejor practica laboral la sustentación escrita
del proyecto respaldada con la firma de los principales involucrados tanto del
proveedor como del cliente. A continuación, se describen las bases que se tomaron
en cuentan para la definición de dichos factores.
3.1 Factores de Complejidad Ambiental (ECF de G. Karner)
Considerando como base los factores de Karner los cuales son conocidos y
utilizados de manera estándar en el desarrollo y diseño de software por UML
(Unified Modeling Language) el cual es uno de los lenguajes de modelado de
Administración de Proyectos para Optimizar la Implementación de un Software ERP
69
sistemas de software más conocido y utilizado en la actualidad. Los factores de
Karner son los siguientes:
1) Familiaridad con el proceso de ingeniería, 2) Experiencia en la aplicación, 3)
Experiencia con orientación a objetos, 4) Capacidad de los analistas, 5) Motivación,
6) Estabilidad de los requisitos, 7) Personal de medio tiempo y 8) Dificultad del
lenguaje de programación, los cuales se ilustran en la Figura 11.
ECF08Dificultad del lenguaje de
programación
ECF07Personal de
medio tiempo
ECF06Estabilidad de los requisitos
ECF05Motivación
ECF04Capacidad de los analistas
ECF03Experiencia con
orientación a objetos
ECF02Experiencia en
la aplicación
ECF01Familiaridad con
el proceso de ingeniería
ECF
Figura 11. Factores de Complejidad Ambiental Estándar (Elaboración Propia)
3.2 Análisis de los ECF
Se realizó un análisis de cada factor para las empresas mexicanas considerando la
investigación documental aportada por los autores especialistas en ERP (Aguilera
y Riascos, 2009; Boltena y Gómez, 2012; Candra, 2012; Díaz, Gonzales y Ruiz,
2005; Galy y Sauceda, 2014; Lineke, 2014; Maldonado, 2008; Monk y Wagner 2012;
Administración de Proyectos para Optimizar la Implementación de un Software ERP
70
Rajnoha, Kádárová, Sujová y Kádár, 2014; Ram, Wu y Tagg, 2014; Razmi, Sangari
y Ghodsi, 2009) y la investigación descriptiva aportada por los expertos en el tema
que actualmente laboran en una empresa dedicada a la consultoría, desarrollo y
venta de sistemas para la administración empresarial.
Así mismo, se realizó un análisis de cada factor con base al histórico de los
proyectos de las empresas mexicanas que implementaron un ERP las cuales son
de distintos giros y tamaños, teniendo en los datos históricos a empresas
farmacéuticas a nivel internacional, comercializadoras en su mayoría de tamaño
medio según su número de empleados, boutiques, comercializadoras de mascotas,
por mencionar algunos ya que no se cuenta con autorización para publicar dicha
información.
Se realizó un modelo de regresión lineal múltiple por el método de mínimos
cuadrados ordinarios, se consideraron datos de las empresas mexicanas que han
implementado un sistema ERP. Se obtuvo un valor asignado y un peso a los
factores que se proponen. El modelo utilizado es el siguiente:
𝒀𝒕 = 𝜷𝟎 + 𝜷𝟏𝒙𝟏 + 𝜷𝟐𝒙𝟐 + ⋯ + 𝜷𝒑𝑿𝒑 + 𝜺
Donde:
𝒀𝒕: Es el Valor asignado para cada ECF01,..., ECF14
𝒙𝟏, 𝒙𝟐, … , 𝑿𝒑: Es la diferencia en tiempo del tiempo real contra el estimado
de las tareas que afecto dicho factor.
𝜷𝟏, 𝜷𝟐, … , 𝜷𝒑: Parámetro según la repetición del factor en las tareas del plan
de cada proyecto
𝜷𝟎: Es la intersección que es el peso según su ponderación de cada factor
(constante)
Analizando los históricos de los proyectos de las empresas mexicanas, en cuanto a
la estimación del tiempo y costo de las implementaciones de un sistema ERP, se
observa un incremento de aproximadamente el 50% más en lo real a lo estimado.
Por lo que se definieron los factores no considerados y que afectaron en tiempo real
al proyecto.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
71
Se tiene como resultado factores que se adecuan con mayor exactitud a las
organizaciones en México, los cuales son: 1)Familiaridad con el negocio, sus
procesos y políticas, 2)Experiencia en la aplicación, 3)Experiencia con orientación
a objetos, 4)Capacidad de los analistas, 5)Motivación, 6)No se cuenta con requisitos
claros, solo objetivos generales y algunos específicos, 7)Personal externo,
8)Personal con sobrecarga de trabajo cubren 2 o más funciones (multitask),
9)Dificultad del lenguaje de programación, 10)Información del sistema en otro
idioma (normalmente Inglés), 11)Falta de compromiso e involucramiento en toma
de decisiones por parte del cliente, 12)Tiempo disponible por parte del equipo del
cliente, 13)Cambio de líder de proyecto o consultor y 14)Bases y estructura
organizacional no lista para la integración de un ERP. En la figura 4 se perciben los
factores propuestos.
ECF09Dificultad del lenguaje de
programación
ECF07Personal externo
ECF06No se cuenta con requisitos claros,
solo objetivos generales
ECF05Motivación
ECF04Capacidad de los
analistas
ECF03Experiencia con
orientación a objetos
ECF02Experiencia en la
aplicación
ECF01Familiaridad con el negocio, sus
procesos y políticas
ECF
ECF14Bases y estructura organizacional no
lista para la integración de un
ERP
ECF13Cambio de líder de
proyecto o consultor
ECF12Tiempo disponible
por parte del equipo del cliente
ECF08Personal con
sobrecarga de trabajo
ECF11Falta de
involucramiento en toma de
decisiones por parte del cliente
ECF10Información del sistema en otro
idioma
Figura 12. Propuesta de Factores de Complejidad Ambiental (Elaboración Propia)
Administración de Proyectos para Optimizar la Implementación de un Software ERP
72
De acuerdo a las experiencias de expertos en el tema de diversas empresas
situadas en México y sus históricos considerando principalmente el plan de trabajo
estimado comparando contra el real y el análisis de que tareas fueron las más
afectadas en tiempo y el motivo de retraso de dichas tareas, se observó que el
tiempo y los costos de los proyectos se ve afectado por otros factores no
considerados por Karner. Los factores propuestos actuales y típicos de empresas
mexicanas son: 1) estructura organizacional, 2) sobre carga de trabajo, 3) alta
rotación de personal, 4) falta de información en idioma nativo (español), 5) forma de
contratación (outsourcing) de los empleados, en especial de los programadores.
Estos y otros factores se proponen para ser considerados en el cálculo de la
estimación de esfuerzo ya sea calculada en horas o días y así tener un costo más
certero de los servicios profesionales para la implementación de sistemas ERP en
México. Con esta información se pretende hacer una mejor evaluación de la
inversión tanto monetaria como en tiempo para determinar si realmente se podrá
concluir con el proyecto de manera satisfactoria.
La Figura 5 se encuentra dividida en cuatro secciones, la sección ESTANDARES se
encuentran los factores ambientales considerados de manera estándar. En la
sección ADECUACION A LOS ESTANDARES se renombró a tres de estos factores.
Posteriormente en la parte inferior de la figura 5 se tiene la sección “ECF
PROPUESTOS” y por último se tiene la sección ECF PARA SISTEMAS ERPEN MEXICO
(INTEGRACIÓN DE FACTORES), lo cual es el resultado final del estudio de los factores
de complejidad ambiental para sistemas ERP en México.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
73
3.3 Integración de los Factores de Complejidad Ambiental propuestos
FACTORES DE COMPLEJIDAD AMBIENTAL (ECF)
.PR
OPU
ESTA
ADECUACION A LOS ESTANDARESESTANDARES
ECF PARA SISTEMAS ERP EN MÉXICO(INTEGRACIÓN DE FACTORES)
ECF PROPUESTOS
Figura 13. Factores de Complejidad Ambiental (Elaboración Propia)
Integrando los Factores de complejidad ambiental (ECF) para sistemas ERP y como
resultado del modelo de regresión lineal múltiple con datos obtenidos de diversas
empresas, se obtuvo el siguiente resultado con los “Pesos” y “Valores asignados”
que se muestran en la siguiente tabla.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
74
Factores de complejidad ambiental (ECF) para sistemas ERP en México
PROPUESTA Peso
(factor de ponderación)
Valor asignado
1 ECF01
Familiaridad con el negocio, sus procesos y políticas
1.50 5.00
2 ECF02 Experiencia en la aplicación 0.50 3.00
3 ECF03 Experiencia con orientación a objetos 1.00 3.00
4 ECF04 Capacidad de los analistas 0.50 4.00
5 ECF05 Motivación 1.00 1.00
6 ECF06
No se cuenta con requisitos claros solo objetivos generales y algunos específicos
2.00 5.00
7 ECF07 Personal externo -1.00 4.00
8 ECF08
Personal con sobrecarga de trabajo cubren 2 o más funciones (multitask)
-1.00 4.00
9 ECF09 Dificultad del lenguaje de programación -1.00 4.00
10
ECF10 Información en otro idioma (normalmente ingles) con lenguaje Técnico
-1.00 4.00
11
ECF11 Falta de compromiso e involucramiento en toma de decisiones por parte del cliente
1.50 5.00
12 ECF12
Tiempo disponible por parte del equipo del cliente
1.50 5.00
13 ECF13 Cambio de líder de proyecto o consultor 1.00 5.00
14 ECF14
Bases y estructura organizacional no lista para la integración de un ERP
2.00 5.00
Administración de Proyectos para Optimizar la Implementación de un Software ERP
75
A pesar de la diversidad del ramo industrial o comercial de las empresas, se poseen
ciertas características semejantes en las organizaciones, como es: la forma de
trabajo, cultura laboral y compromiso con el proyecto, por lo que se pueden manejar
los catorce factores propuestos, como factores acordes para las empresas
mexicanas en vías de crecimiento. Y se recomienda ser considerados para obtener
una gestión del proyecto más certera y flexible, congruente a la situación real y no
idealista. Considerando que los factores más relevantes y de mayor impacto son el
factor ECF06 (No se cuenta con requisitos claros solo objetivos generales) y ECF14
(Bases y estructura organizacional no lista para la integración de un ERP), se
propone que ambos factores sean planeados antes de empezar con el diseño del
ERP. Pues estos factores impactan directamente en la estimación del tiempo y costo
de un proyecto, lo cual provoca proyectos inconclusos o ineficientes en el
desempeño operacional de las empresas. Los factores ECF07 (Personal externo),
ECF08 (Personal con sobrecarga de trabajo), ECF09 (Dificultad del lenguaje de
programación) y ECF10 (Información en otro idioma con lenguaje técnico), son
derivados de la brecha cultural y tecnológica que se tiene en comparación con
países desarrollados.
Al considerar los factores de complejidad ambiental que se proponen, se obtienen
planeaciones de proyectos de forma más certera en cuanto a tiempo real y costos
de un proyecto. Lo cual previene los impactos negativos en la operación diaria de la
organización por el periodo de desarrollo y adaptación del ERP. Por lo tanto, en la
metodología propuesta se utilizan estos 14 factores con su puntuación respectiva
para la estimación del tiempo del proyecto de implementación, teniendo su mayor
utilidad para el cálculo del esfuerzo necesario para realizar los desarrollos
customizados necesarios para la adaptación del ERP en la organización y sus
requerimientos de negocio utilizando el modelo UML para la definición y estimación
de dichos desarrollos. Logrando mejores estimaciones de tiempo y costo y una
mejor visualización para el cliente del alcance de dichos desarrollos por medio del
modelado.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
76
CAPITULO IV
PROPUESTA DE METODOLOGÍA
PARA LA IMPLEMENTACIÓN DEL
ERP
Administración de Proyectos para Optimizar la Implementación de un Software ERP
77
CAPITULO IV.- PROPUESTA DE METODOLOGÍA PARA LA
IMPLEMENTACIÓN DEL ERP
Posterior al análisis de las metodologías mencionadas con anterioridad y el análisis
de los ECF para una correcta administración del proyecto, es común pensar que se
requiere una metodología robusta y extensa para poder llevar a cabo una
implementación exitosa de un ERP. Sin embargo, al definir esta metodología, se
pretende simplificar y descartar procesos “No relevantes” sustituyéndolos por
actividades que generen “Valor al proyecto” para obtener resultados satisfactorios
al concluir el proyecto. Por lo que la base de esta metodología considera los
procesos del PMBOK, sin embargo, practicando los principios de las metodologías
agiles.
A continuación, la división y estructura general por fases de la metodología
propuesta. Considerando que estas fases no serán en forma de cascada, sino que
en determinado periodo se empalmarán para agilizar el proyecto, asumiendo un
modelo flexible que nos permite ajustar detalles durante el desarrollo del proyecto.
Teniendo el siguiente diagrama.
Figura 14. Diagrama de Fases del Proyecto (Elaboración Propia)
Administración de Proyectos para Optimizar la Implementación de un Software ERP
78
Como se puede observar en el diagrama de la figura 14, la metodología propuesta
se divide en seis fases, cada fase tiene sus propios procesos que a continuación se
mencionan:
4.1 DEFINICIÓN DEL ALCANCE
La primera fase “Definición del alcance” es la más extensa, ya que prácticamente
durante todo el proyecto se debe recurrir a los procesos de esta fase para obtener
parámetros más claros de los objetivos planteados en el análisis, el cual se tiene
que elaborar de manera flexible pero delimitada, es decir se deben establecer
inicialmente parámetros y criterios que se puedan configurar de un modo u otro y a
lo largo del proyecto se deben definir y cerrar estos parámetros para obtener una
operación estandarizada en toda la organización, sin perder de vista el principal
objetivo que es simplificar y optimizar los procesos operativos, administrativos y
estratégicos de la organización.
Siendo utópico o impráctico querer dar por cerrada esta fase cuando apenas se
comienza el proyecto. Es por esto que en el diagrama de fases de la metodología
propuesta (figura 14) se muestra esta fase, con una mayor área que las demás,
empalmándose en varios puntos con las otras fases. Incluyendo los siguientes
procesos.
Definir los objetivos y requerimientos.
Análisis de la estructura e infraestructura de la organización.
Alcance Funcional de manera estándar del ERP
Análisis de cambios y limitaciones derivados de la estructura e
infraestructura organizacional.
Redefinir los objetivos y requerimientos (Alcance Funcional)
Administración de Proyectos para Optimizar la Implementación de un Software ERP
79
4.1.1 Definir los objetivos y requerimientos
Se solicita preferentemente un documento por parte del cliente que es
“Especificación de Requerimiento” con el propósito de tener la descripción del
requerimiento del Negocio, desde el punto de vista de funcionalidad y necesidades
que la herramienta debe cubrir.
Describiendo módulos generales solicitados y en caso de requerir una funcionalidad
específica, la descripción de esta y su interacción.
A partir de este documento el proveedor del ERP genera el Project Charter o Acta
de Constitución de Proyecto.
Debido a la extensión del documento a continuación se detalla portada e índice del
documento elaborado y utilizado previo a la implementación con un cliente real,
como parte de la metodología.
PORTADA
Administración de Proyectos para Optimizar la Implementación de un Software ERP
81
Este documento fue realizado prácticamente por el equipo de parte del cliente
apoyándose del proveedor.
4.1.2 Análisis de la estructura e infraestructura de la organización.
Se presenta un documento con los requerimientos técnicos de hardware, VPN y
seguridad necesarios para operar de manera centralizada, habiendo distintos tipos
de ERP se debe considerar el que mejor se adapte no solo a nivel de procesos sino
a nivel infraestructura. Hay algunos sistemas que trabajan forzosamente en línea
(deben tener internet), sin embargo, considerando que en México es un tanto común
tener fallas con el internet, se recomienda trabajar con un ERP que tengan la
disponibilidad de trabajar “offline” y configurar ciclos periódicos de comunicación
con el servidor central que puede estar en la nube o ser un servidor físico del cliente.
El formato del documento lleva una portada e índice, los principales elementos son
los siguientes:
2.1 Requerimientos de Hardware
2.2 Infraestructura y Seguridad
2.3 Mantenimiento de software
Administración de Proyectos para Optimizar la Implementación de un Software ERP
82
Los dos puntos anteriores también es posible manejarlos en forma de check list, con
el cual es más sencillo determinar el % de requerimientos cubiertos y analizar la
infraestructura y mantenimiento que requiere el software, así como sus funciones.
A continuación un ejemplo, por la extensión del archivo solo se muestran los dos
primeros puntos del documento.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
83
4.1.3 Alcance Funcional de manera estándar del ERP
Siempre es importante contar con la “Especificación de Requerimiento” antes de
presentar los módulos estándares del ERP, para tener una visión de las reglas de
negocio particulares del cliente y saber si forman parte de la funcionalidad estándar
del ERP, si se pueden adecuar o si se necesitara un desarrollo personal para
cubrirlo. Considerando que lo ideal es que sea parte de la funcionalidad estándar o
en su defecto sea una adecuación mínima, en caso de ser un desarrollo extenso o
en su defecto fuera de alcance lo conveniente es cambiar la selección de ERP a
uno especialista al giro de la empresa.
Posteriormente a recibir la “Especificación de Requerimiento” por parte del cliente,
el proveedor debe revisar con el cliente los módulos y opciones disponibles en el
ERP. Para lo cual se realizó el documento “Diagramas para el Análisis y Definición
de Procesos de Negocio”, en el cual partiendo del diagrama de procesos del ERP
se detalló por modulo las opciones de configuración del sistema para agilizar la
Administración de Proyectos para Optimizar la Implementación de un Software ERP
84
definición de la estructura personalizada del sistema para el cliente, así como el
flujo, procesos, operaciones y políticas que marcaran los procesos de negocio del
cliente. Los diagramas se diseñaron con las diversas opciones y flexibilidad de cada
módulo del ERP, visualizando el panorama general y las diversas opciones de
personalización del software con base a las necesidades específicas del cliente
dependiendo su giro y tamaño de empresa. Con apoyo de estos diagramas se logra
la definición de los procesos de negocio para el cliente, obteniendo el mayor
beneficio posible del sistema utilizando la funcionalidad estándar del ERP.
El siguiente documento se lleva a cabo en forma de entrevista con los distintos
involucrados dependiendo del módulo y el departamento al cual va dirigido. Al igual
que los formatos anteriores este documento lleva una portada e índice con el
siguiente contenido.
Alcance Funcional del Sistema
1. Administración de la distribución y logística
• Recepción de Mercancías
• Control de Inventarios
• Máximos y Mínimos
• Administración por Categorías
• Inventarios Físicos
• Listas de Precios
• Etiquetado
2. Planificación de la Producción
• Ordenes de Venta
• Ordenes de producción
• Lotes y números de serie
• Caducidad
Administración de Proyectos para Optimizar la Implementación de un Software ERP
85
3. Administración de Compras
• Proveedores
• Órdenes de Compra
4. Administración de Recursos Humanos
• Registro de Empleados
• Administración por Grupos
• Tiempos y Asistencias
• Administración de Comisiones
5. Administración de ventas
• Apertura y Cierre de Caja
• Arqueos y Cierre final
• Ventas y Apartados
• Devoluciones
• Descuentos y Promociones
• Múltiples formas de pago
• Registro de Clientes
• Perfiles de Clientes
6. Administración Financiera
• Cuentas por cobrar
• Cuentas por pagar
• Estados de resultados
• Factura Electrónica
Administración de Proyectos para Optimizar la Implementación de un Software ERP
86
DIAGRAMAS PARA EL ANÁLISIS DE PROCESOS
MERCANCÍA:
DCS CODE (9 caracteres)
VENDOR CODE(6 caracter)
Inventario(Definición de estructura del catago)
DESCRIPTION 1 y 2(30 caracters)
Attr y Size(8 caracteres)
Otros Campos "Auxiliares"
(50 caracteres)
DEPARTAMENTOPK
NOMBRE
CODIGO DE 3 CARACTERES (ALFANUMERICO)
NOMBRE
CODIGO
CLASEPK
CODIGO DE 3 CARACTERES (ALFANUMERICO)
GRUPO DE ESTILO: Definición de campos obligatoriosPK
DCS CODE (Clasificación de lo mas general a mas especifico)
VENDOR CODE (Proveedor)
DESCRIPTION 1 o DESCRIPTION 1 y DESCRIPTION 2
ATTR (Atributo, Color, Presentación)
SIZE (Talla, Tamaño, Empaque)
NOMBRE
SUBCLASEPK
CODIGO DE 3 CARACTERES (ALFANUMERICO)
NOMBRE
DESCRIPTION 1PK
Codigo por modelo
Descripcion general
DESCRIPTION 2PK
AttrPK
Definir de manera estandar (ejemplo: si se define: Blanco, Negro; no usar: White, Black)
Definir de manera estandar (ejemplo: si se define: S, M, G; no usar: CHICO, MED, GD)
SizePK
UDF 7: Aduana
UDF 8: Fecha (aaaa-mm-dd)
UDF 9: Numero de pedimento
Items de Importación-No: dejar UDF 7, 8 y 9 vacios-Si: capturar información aduanera
PK
En total existen 14 auxiliares, se recomienda usar maximo 6 por el futuro mantenimiento al catalogo y solo si son necesarios
PK
Administración de Proyectos para Optimizar la Implementación de un Software ERP
87
CÓDIGO DE BARRAS Y ETIQUETADO:
UPC (código de barras)numérico a 13 dígitos
InventarioCódigo de barras, SKU y etiquetado
ALU (código alternativo)
Etiquetado
Información para formato de etiqueta
Único código por ítem: Local UPC = Global UPC
PK
UPC (código de barras)PK
Si se tiene otro código de barras diferente a 13 dígitos o alfanumérico
PK
SKU Código de otro sistema (ejemplo ERP)
Código del proveedor
Todos los ítems ya están etiquetadosPK
El tamaño y tipo de etiqueta es igual para todos los ítems
Siempre se imprime de la misma impresora las etiquetas
Algunos ítems están etiquetados y otros noPK
ALUPK
Único por ítem
Corresponde el mismo código a diferentes ítems
Existe mas de un tamaño y tipo de etiqueta
EtiquetadoPK
Código por estilo, OC, Vendor: Local UPC se repite entre ítems; Global UPC es único por ítem
PK
Definido por el sistema de forma consecutiva
PK
Definido por el usuarioPK
Ningún ítems esta etiquetadosPK
Existen diversas impresoras
UPC, ALU
Precio
Descripcion: 1, 2, 3, 4
Attr, Size
Auxiliares
Administración de Proyectos para Optimizar la Implementación de un Software ERP
88
RECEPCIÓN:
Opciones Con referencia
Recepciones
ASN (Nota de seguridad)
Sin referencias
Actualizar Costos de orden
Limitar a los ítems de la OC
Despues de actualizar ir a una nueva o a las notas anteriores
PK
Con referncia a un documento previo (OC o ASN)
Recepciones directas sin referencia a una OC o ASN
Recepcion de una transferencia
ASN (de una transferencia)
PK
Copiar qty recibida de la qty inicial en la nota ASN
Actualización de Precios y Costos
PK
Permitir que la NR actualice precios
Recepciones directas hasta que llega la mercancia (multimarca)
PK
Orden de Compra (OC)
PK
Permitir Cantidades negativas
PK
Notas de Recepcion de devolucion al proveedor
PK
Requerir siempre #OC en recepcion o devolución
Administración de Proyectos para Optimizar la Implementación de un Software ERP
89
TRANSFERENCIAS:
OPCIONES
Transferencias
Reglas de Transferencia
DisponibilidadPK
Disponibles
Transferir ítems sin existencia
Asignado
AUTOVERIFICARPK
MultisubsidiariaPK
Definir Reglas de transferencia por tienda
Definir reglas de transferencia por subsidiaria
CON SEGURIDAD POR MEDIO DE UN ASNPK
Requerir comentarioPK
Subsidiaria ÚnicaPK
Administración de Proyectos para Optimizar la Implementación de un Software ERP
90
MÉTODO DE COSTEO:
Costo de Inventario
Inventario(Costeo y Precios)
Precios de Inventario
Descuentos y Promociones
Se maneja un solo costo por ítem ya sea con impuestos o sin impuestos, con cada recepción existe la opción de:
PK
Dejar costo
Sobreescribir costo
Prorratear costo
COSTO DE INVENTARIO (Un solo costo por ítem)PK
Listas de PreciosPK
Por cliente
Por tienda
PrecioPK
De forma manualPK
A nivel venta
Con base a la información de algún campo (DCS, Vendor Code, Auxiliar, etc...)
De forma automáticaPK
PRECIO DE INVENTARIOPK
Precios netos con desglose de impuesto IVA
Precios netos con desglose de diferentes impuestos IVA, IEPS
Precios mas impuesto IVA
Sin redondear
Redondeo en lista de PreciosPK
Precios enteros con redondeo normal o siempre hacia arriba o siempre hacia abajo
Precios mas diferentes impuestos IVA, IEPS
Precios con menos un numero (ejemplo: 99, 99.99, 90)
Redondeo en venta sin centavosPK
A nivel ítem
Sin redondear
Precios enteros con redondeo normal o siempre hacia arriba o siempre hacia abajo
Administración de Proyectos para Optimizar la Implementación de un Software ERP
91
COMPRAS:
Opciones Cargos y Descuentos
Ordenes de Compra
Maximos y Minimos
Pedidos
Tipo de EnvioPK
Centralizado
A Tienda
Repartir cargos y descuentos
Repartir entre subsidiarias
Numero de OCPK
Capturar # OC del proveedor
Ordenes de Compra por proveedor (ingresadas de forma manual)
Ordenes de Compra por una orden especial u orden de venta
Con base a maximos y minimos
Por sistema de forma consecutiva
Por dias de suplementoPK
Necesario historicos de minimo 1 año
Definidos manualmente
PK
Con o sin vencimientoPK
Cargos adicionales por envio, impuestos, etc.
PK
Restringir un proveedor por OC
PK
Descuentos por volumen, temporada, etc
PK
Permitir recibir despues de la fecha de cancelación
MultisubsidiariaPK
Preguntar para cada OC
Mejor Reabastecimiento
PK
ítems en catalogo sin existencia
PK
ítems propuestosPK
Administración de Proyectos para Optimizar la Implementación de un Software ERP
92
EMPLEADOS:
Empleados
En:Estructura
Perfiles de usuarioPK
Recibos
Ordenes de Venta
Alta SeguridadPK
Notas de Recepción
Transferencias
Info1 y 2 Nombre Login Name Password Perfil Auxiliares
Ajustes
Administración de Proyectos para Optimizar la Implementación de un Software ERP
93
VENTAS:
Formas de Pago
Venta
Información del cliente mandatoría por forma de pago
Tarjeta de Crédito
Moneda Extranjera
Formato de Tickets
Efectivo
Cheque
Cargo
Recibo Normal
Cancelaciones, Devoluciones y Cambios
Venta Perdida
Venta en espera
Ordenes de Venta
Tarjeta de crédito
Compañía
Pago contra entrega
Tarjeta de Débito
Tarjeta de Regalo
Crédito de tienda
Certificado de Regalo
Cheque de viajero
Moneda Extranjera
Nombre
Código Postal
Info 2
Info 1
Apellido
Calle
Colonia
Numero
Nombres (Visa, AMEX, Master, etc.)
Introducir Numero de Tarjeta
Divisas que acepta
Tipo de Cambio
CamposPK
PolíticasPK
ReimpresiónPK
Administración de Proyectos para Optimizar la Implementación de un Software ERP
94
CIERRE DE CAJA:
Opciones
Apertura Cierre de Caja (X/Z Out)
Opciones
Formato de Cierre de Caja
Creación automatica del siguiente registro
Requerir entrada de montos de apertura
Maximo en Efectivo
Apertura de Caja
Cierre Parcial
Cierre de Caja
Permitir cero en monto abierto
Requerir entrada de montos de cierre
Contar moneda de apertura
Cajero
Cajon de dinero
Minimo en Caja
Tienda
Estacion de Trabajo
Requerir cierre ciego
Monto de variación permitido
Depositar Monto por Default
Agragar comentarios
Formas de PagoPK
TotalesPK
DescuentosPK
Retiros de cajaPK
Definir Registro porPK
Administración de Proyectos para Optimizar la Implementación de un Software ERP
95
CLIENTES:
Búsqueda de Clientes
Clientes
Información requerida
Estructura
Nombre
ID
Apellido
GlobalesPK
Nombre Completo
Teléfono
Por tienda o subsidiariaPK
Compañía
Teléfono
Info 1 o 2
Info 1 o 2
Auxiliar
Info1 y 2 Nombre Apellido Address 1: Calle Address 2: No. interior / exterior Address 3: Delegación o Municipio Address 4: Ciudad Address 5: Estado Address 6: Referencias C.P. Teléfono E-mail Auxiliares para fecha de
cumpleaños, genero, etc..
Administración de Proyectos para Optimizar la Implementación de un Software ERP
96
Estos diagramas fueron elaborados con fundamento a “la filosofía del proceso”
manteniendo un enfoque de que todo trabajo puede verse como un proceso
conformando un sistema, marcando sus limitantes o fronteras, y los flujos del
mismo. Antes de poder empezar con el detalle y los diagramas de flujo del proceso,
es primordial la definición del sistema, visualizando a la organización de negocios
como un sistema; sus partes son las funciones de mercadotecnia, operaciones,
finanzas, contabilidad, recursos humanos, etc. en donde cada una de estas
funciones no realiza nada por sí misma. Un negocio no puede vender lo que no tiene
o no puede producir y no sirve de nada elaborar un producto que no pueda
venderse. Por lo tanto, las funciones dentro de la organización son altamente
interactivas y pueden lograr más cosas trabajando en forma conjunta que separada.
Una empresa puede visualizarse no sólo como un sistema, sino como un conjunto
de procesos interconectados; algunos de éstos son la planeación estratégica, el
ingreso de órdenes, el suministro del producto, la recepción del pago del cliente, la
satisfacción del cliente y la administración de recursos humanos.
Con base al análisis de las entrevistas, apoyándonos de estos diagramas se
definirán los procesos de negocio específicos para cada organización que se
aplicaran en el sistema, identificando los posibles desarrollos que se tendrán que
incorporar para cubrir operaciones customizadas. Así mismo facilita la elaboración
de los diagramas de flujo de su futura operación considerando los siguientes
aspectos clave:
1. Un prerrequisito para el análisis del flujo del proceso es la definición del
sistema a analizar la cual demanda el aislamiento del sistema de interés con
respecto a su ambiente a través del establecimiento de las fronteras, los
clientes, los productos finales, los insumos, los proveedores y los flujos del
proceso.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
97
2. La perspectiva del proceso conduce a la idea de que un negocio es un
conjunto de procesos horizontales que están interconectados con el objetivo
de satisfacer las necesidades del consumidor.
3. La medición es indispensable para el mejoramiento del proceso. Algunas
mediciones clave de un proceso son el tiempo de capacidad específica de
producción de un equipo, la tasa de flujo y el inventario. Si un proceso se
convierte en un cuello de botella determinara la capacidad de todo el proceso.
4. La meta es generar diagramas de flujo, visuales, que sean fáciles de
entender por personas que pueden no estar familiarizadas con el proceso o
tecnicismo del mismo.
5. La reingeniería del proceso de la empresa se usa para el rediseño radical de
los procesos; es de naturaleza internacional e implica un
reacondicionamiento de los métodos de trabajo, los flujos y los sistemas de
información.
4.1.4 Análisis de cambios y limitaciones derivados de la estructura e
infraestructura organizacional.
Posteriormente al análisis de los requerimientos del cliente y todas las posibilidades
que se pueden explotar en el ERP se define un plan de acción solo en caso de ser
necesario para corregir la infraestructura y poder aprovechar el ERP en su totalidad
sin repercutir en su operación.
A la par el equipo de implementación comienza con en el plan de trabajo y propuesta
para llevar a cabo la implementación, o en su defecto en caso de que una o varias
reglas de negocio requieran una función no cubierta de manera estándar por el ERP
se debe generar un SOW (Statement of Work - Declaración de Trabajo) que
describa el análisis, funcionalidad y alcance a desarrollar para cubrir dicho
requerimiento.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
98
A continuación, el formato de dicho documento con un ejemplo de Facturación
Electrónica integrada con el POS (Punto de Venta) y el ERP. Este formato debe
llevar una portada, índice y una tabla de control de cambios para documentar futuras
versiones.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
102
Manteniendo el siguiente formato de manera general para cada desarrollo
1. Portada
2. Índice
3. Control de cambios
4. Objetivo
5. Alcance
6. Características generales
7. Diagrama de proceso
8. Documentación requerida para el cliente o premisas
9. Aceptación
Utilizando para el punto 7 la herramienta “bizagi” para el diseño de diagramas de
los procesos, a continuación, el diagrama de procesos de una interfaz para integrar
el archivo del catálogo de mercancías con el POS
Figura 15 Diagrama de procesos para la carga del catálogo del ERP al POS. (Elaboración
Propia)
Administración de Proyectos para Optimizar la Implementación de un Software ERP
103
.
Y en el caso de ser un desarrollo extenso y/o complicado utilizar el modelado UML
con la herramienta “Enterprise Architect” para una correcta evaluación del tiempo y
complejidad del desarrollo. La herramienta “Enterprise Architect” permite incorporar
los 14 factores (ECF) vistos en el capítulo 3 del presente trabajo, logrando una
estimación más precisa del tiempo, costo y alcance para cada desarrollo, así mismo
el modelado con UML facilita la documentación siendo una forma fácil, practica y
rápida de tener una visualización grafica de los componentes que involucran dicho
desarrollo y por lo tanto determinar su complejidad.
Manteniendo el mismo formato anterior para la documentación, se anexa el modelo
UML y dependiendo del desarrollo se puede en ocasiones hasta sustituir por el
diagrama de proceso, logrando agilizar la documentación en gran medida sin afectar
el común entendimiento del requerimiento y objetivo para dicho desarrollo.
1. Portada
2. Índice
3. Control de cambios
4. Objetivo
5. Alcance
6. Características generales
7. Diagrama de proceso
8. Modelo UML
9. Documentación requerida para el cliente o premisas
10. Aceptación
Administración de Proyectos para Optimizar la Implementación de un Software ERP
104
Figura 16. UML para la administración de pedimentos (Elaboración Propia)
4.1.5 Redefinir los objetivos y requerimientos (Alcance Funcional)
Al tener un panorama más claro de la funcionalidad y procesos a llevar a cabo se
modifica el Project Charter con objetivos más específicos y certeros para el
proyecto. Así mismo se integra el alcance funcional y SOW definidos con los
acuerdos y procesos revisados en este primer análisis.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
105
A continuación, el formato para el “Project Charter”
Administración de Proyectos para Optimizar la Implementación de un Software ERP
107
Alcance Funcional
El alcance presentado en esta primera etapa se le llama funcional ya que la
funcionalidad implícita acordada en esta primera etapa será la limitante para
cualquier cambio, es decir en este punto se mantiene cierta flexibilidad en la
definición de los procesos, sin embargo, cualquier requerimiento totalmente fuera
de la funcionalidad se tendrá que manejar por medio de un control de cambios
implicando el cálculo del esfuerzo, tiempo, costo y alcance para la nueva
funcionalidad.
Debido a la extensión del documento no se anexa completo, pero a continuación se
detalla su estructura:
1. Portada
2. Control de Cambios
3. Índice
4. Objetivo
4.1 Objetivo General
4.2 Estructura corporativa
4.3 Alcance servidor central
4.4 Alcance servidor secundario y Estaciones de Trabajo
4.5 Requerimientos de Hardware
4.6 Infraestructura
4.7 Licenciamiento
4.8 Mantenimiento de software
4.9 Soporte
4.10 Capacitación
4.11 Idioma de la aplicación
4.12 Personalización de pantallas de trabajo
4.13 Personalización de formatos impresión
4.14 Reportes
Administración de Proyectos para Optimizar la Implementación de un Software ERP
108
5. Alcance Funcional
5.1 Arquitectura
5.2 Comunicación entre servidores
5.3 Ingreso al Sistema
5.4 Perfiles de Usuario
5.5 Integracion con otros sistemas
5.6 Definicion de Interfacez
5.7 Datos Maestros
5.8 Procesos Operativos
6. Aceptación.
4.2 PLANEACIÓN DEL PROYECTO
Teniendo un buen análisis se puede lograr una buena planeación, por lo tanto esta
fase se traslapa junto con el alcance ya que desde el análisis del alcance se
comienza a realizar la proyección del futuro del proyecto, también se traslapa junto
con la implementación ya que todo el tiempo se tiene que estar planeando y dar
seguimiento a las actividades siguientes y se traslapa en conjunto con el control, ya
que la planeación siempre será la base para tener métricas cuantitativas del
proyecto y su desviación si es que así lo presenta.
4.2.1 WBS (Estructura de Descomposición del Trabajo - Work
Breakdown Structure)
Teniendo como base el plan de trabajo en Project es muy sencillo obtener el WBS
con la herramienta “WBS Chart”, sin embargo, al igual que el plan de trabajo de la
implementación completa es muy extenso y no se alcanza a visualizar del todo, por
lo que este se actualizara de manera parcial a lo largo del proyecto y posteriormente
al concluir el proyecto nos cercioraremos de que este actualizo al 100% para poder
obtener métricas de comparación entre lo real y lo planeado.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
109
A continuación, se muestra el WBS completo solo a manera de ejemplo ya que no
se logra visualizar el detalle de las ramificaciones y posteriormente se muestra el
ejemplo de un nodo en el cual se puede ver el detalle y normalmente es como se
va revisando a lo largo del proyecto.
Figura 17. WBS Implementación del Sistema (Elaboración Propia)
Figura 18. Nodo del WBS Instalación y Configuración (Elaboración Propia)
Administración de Proyectos para Optimizar la Implementación de un Software ERP
110
4.2.2 Lista de actividades y sus relaciones
La manera más sencilla de visualizar la lista de actividades y su desglose, así
como la relación que mantienen entre una y otra es por medio de una gráfica de
Gantt. A continuación, el ejemplo del plan de trabajo para la implementación.
Figura 19. Plan General para la Implementación del Sistema (Elaboración Propia)
El plan de trabajo se puede elaborar por medio de Project, Siendo un plan de trabajo
muy extenso es un tanto tedioso de actualizar cuando se está en pleno proyecto,
por lo tanto se recurre a parte de los principios de las metodologías agiles donde las
reuniones son recurrentes e interpersonales, sin embargo siempre es bueno tener
un plan tangible, el cual se pueda consultar para tener claro las siguientes
actividades a realizar por lo tanto las actualizaciones del plan de trabajo y tareas a
realizar una vez que comienza de lleno el proyecto se marcan de manera
independiente en otro Gantt definido como “Three Week Go Ahead” que se elabora
en Excel y es más rápido y sencillo actualizar, permitiendo ir todos al corriente y
entendimiento del porcentaje de avance realizado y necesario a cumplir en la
semana actual. En este pequeño Gantt se muestran las actividades de la semana
pasada, la semana en curso y las siguientes dos semanas. A continuación, un
ejemplo
Administración de Proyectos para Optimizar la Implementación de un Software ERP
111
Figura 20. Three Week Go Ahead (Elaboración Propia)
4.2.3 Recursos necesarios y costo
Teniendo el plan de trabajo se determinan los días y personal necesario para
realizar la implementación, así mismo se considera los días de desarrollo para las
aplicaciones customizadas que requieran o integración con otros sistemas de
acuerdo al tiempo estimado y definido en cada SOW. Los recursos necesarios y
costos se establecen en el contrato final que firman ambas partes, es por tal razón
que es importante tener una estimación certera ya que una estimación incorrecta
será el principal riesgo para no tener un proyecto exitoso o en muchos casos
inconcluso.
4.3 NEGOCIACIÓN
La negociación del Proyecto se comienza desde antes de iniciar el proyecto, y en
muchas ocasiones duran tanto como el proyecto mismo y a veces hasta dura más
tiempo en concretarse esta negociación que el mismo tiempo de implementación.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
112
Esto quiere decir que a pesar de que la negociación esta propuesta como la fase 3
no inicia posterior al alcance y a la planeación, sino que como se ha comentado
anteriormente, las fases no se proponen en forma de cascada, por lo tanto, es
común que la negociación comience mucho tiempo antes de comenzar el proyecto
y posteriormente se continua en la definición del alcance, al definir el plan y durante
la implementación si es que se requiere un control de cambios por falta de
funcionalidad.
4.3.1 Programa del proyecto vs limitaciones de costo, recursos y
tiempo
Una vez se comienza con el análisis la negociación toma más intensidad, debido a
que el cliente prácticamente ya está decidido de implementar cierto sistema y ya
tiene decidido que proveedor cree más conveniente para este critico proceso que
atravesara la organización. Por lo tanto, una vez definidos los recursos necesarios
para cubrir todos sus requerimientos se tienen diversas opciones para ajustarse a
un presupuesto.
1. La más común es recurrir a solicitar un descuento argumentando volumen o
crecimiento futuro
2. Formas y plazos de pagos.
3. Iniciar con una funcionalidad base y posteriormente ir incorporando más
módulos o desarrollos
4.3.2 Establecer el presupuesto base
Una vez se tiene este límite de presupuesto en el cual el cliente tiene que ser
consiente que entre mayor funcionalidad solicite mayor costo tendrá el proyecto por
tiempos de implementación y desarrollos, se parte de un proyecto “alcanzable” es
decir, realista a la situación económica y organizacional de la empresa, y
posteriormente cuando los usuarios se sientan cómodos trabajando con el sistema,
se pueden incorporar más módulos o plugins necesarios, de manera paulatina sin
afectar el presupuesto y su operación.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
113
Por lo tanto, no siempre es conveniente hacer un “Big Bang” sino que una vez hecho
el análisis de adonde se quiere llegar, se puede empezar con lo básico y/o
prioritario, muchas veces facilitando la adaptación y aceptación del cambio.
4.4 IMPLEMENTACIÓN
Al inicio la implementación del Proyecto se traslapa en gran medida con la
planeación, proponiéndolo de este modo ya que el equipo apenas se empieza a
acoplar y si bien en cada implementación se llevan a cabo casi las mismas
actividades, las características del equipo que lo conforma son distintas, así como
el tipo de empresa, políticas y ambiente laboral, haciendo esto que cada proyecto
sea único. Conforme se avanza en el proyecto y cada involucrado tiene
perfectamente claro la forma de trabajar y sus actividades siguientes, la
implementación toma su ritmo, traslapándose mayormente con la fase de Control y
por ultimo con la fase de Cierre.
4.4.1 Determinar los recursos disponibles formando el equipo de
trabajo
Figura 21. Comparación de la formación del equipo de trabajo (PMBOK vs SCRUM)
Administración de Proyectos para Optimizar la Implementación de un Software ERP
114
Si bien en varios trabajos podemos observar una disputa de qué tipo de margen de
trabajo es mejor, si las practicas agiles o las tradicionalistas. La mejor estrategia a
seguir en la práctica, es la que mejor se adapte según el tipo de proyecto, entorno,
cultura y hasta actividad a realizar. Considerando en cada momento las
características del método que convienen más utilizar en el momento, sin forzar el
proyecto a encasillarse al método completo.
En las implementaciones de softwares robustos como lo es un ERP existen varios
mini-proyectos que conformaran el conjunto del proyecto final, es decir tenemos un
software probado y que no es necesario desarrollar, sin embargo, es necesario
adaptarlo a los procesos del negocio, involucrando a diversos expertos de cada
módulo del ERP. Y a la par comúnmente se tienen desarrollos los cuales involucran
a programadores que normalmente no tienen contacto directo con el cliente. Por lo
tanto, a pesar de que la teoría de “SCRUM” menciona que un “SCRUM Master” es
diferente a un líder de proyecto, en la práctica todo proyecto necesita un líder o
coach, realmente la terminología que se le dé es irrelevante, es necesario que
alguien guie y lleve el control en ambas partes, así como un canal de comunicación.
Por lo tanto, en la práctica con el cliente se tuvo una mayor aceptación con términos
tradicionalistas “Lider de Proyecto”, “Patrocinador”, “Usuarios”. Sin embargo,
internamente con el “Equipo del líder de proyecto” se logró mantener mayormente
un perfil de “Scrum Master” ya que los desarrolladores mantuvieron una capacidad
de auto organización la mayor parte del tiempo, conservando la comunicación,
compromiso y colaboración, evitando rigidez y considerando las observaciones de
los “usuarios-stakeholders” logrando mayor funcionalidad, y aceptación al cambio
por parte de los mismos.
A continuación, el formato del “Plan de Comunicación”
Administración de Proyectos para Optimizar la Implementación de un Software ERP
120
4.4.2 Ejecución del programa
En esta fase se ejecuta el plan de trabajo, según el calendario de actividades.
Trabajando la mayor parte del tiempo con el documento “Three Week Go Ahead”
manteniendo actualizadas las fechas de inicio y termino para cada actividad e
integrante. Cuando el proyecto está en marcha, el control del proyecto sólo es
posible si se conoce el estado del proyecto en el momento, siendo fundamental
acumular todos los progresos hasta el punto de revisión. Los estatus utilizados son:
concluido, en curso y no empezado.
4.5 CONTROL DE PROYECTO
El control del proyecto se traslapa principalmente con la implementación, sin
embargo, si existe algún control de cambios que se da cuando existe un cambio o
requerimiento funcional totalmente fuera del alcance inicial, se traslapara tambien
con la fase de “Definición de Alcance” y “Planeacion” para poder incorporar este
nuevo requerimiento.
4.5.1 Avance real del progreso del trabajo
Como se comentó anteriormente tener el avance real del proyecto es fundamental
para poder mantener el control del proyecto ya que sin métricas no se puede tener
un parámetro o informe del estatus general del proyecto y puntos críticos de avance.
Se realizan juntas o conferencias en las cuales no es imprescindible que sean de
manera presencial, pueden ser vía remota, con un periodo de cada tercer día en la
cual deben estar los integrantes o involucrados de las actividades correspondientes
con base al “Three Week Go Ahead”
Manejando reportes de los KPI una vez a la semana por medio de la herramienta
de Excel. A continuación, se muestra un ejemplo del proyecto en la fase de
migración del sistema.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
121
Figura 22. Reporte de KPI en la fase de Roll-Out (Elaboración Propia)
Administración de Proyectos para Optimizar la Implementación de un Software ERP
122
4.5.2 Informar y evaluar el desempeño
Así mismo se manejan juntas de manera semanal o quincenal con los involucrados
de alto nivel, en las cuales se menciona de manera general el avance del proyecto,
las tareas realizadas y los posibles riesgos para las siguientes actividades y el
desarrollo del proyecto. A continuación, un ejemplo del reporte y guía para esta
junta, la cual no debe durar más de 30 minutos, siendo una junta informativa.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
124
4.5.3 Administración de control de cambios
La administración y control de cambios se da cuando se solicita un requerimiento
que es imposible de cubrir con la funcionalidad estándar del sistema o en los
desarrollos analizados de manera inicial, es decir es un requerimiento totalmente
nuevo. Lo recomendable es mandar este nuevo requerimiento a una segunda etapa,
cuando este cubierto el alcance original y la operación de la organización se
encuentre estable. Sin embargo, si es un requerimiento imprescindible para la
operación por políticas o reglas del negocio y no fue anticipado o considerado en la
primera etapa, se tendrá que contemplar y considerar una vez sea detectado,
siempre y cuando se autorice por el “Patrocinador” el nuevo alcance y recursos
necesarios.
El control de cambios se documenta prácticamente con el mismo documento que
un SOW incorporando el análisis, funcionalidad y alcance a desarrollar para cubrir
el nuevo requerimiento.
4.6 CIERRE DE PROYECTO
Por último, la fase más anhelada, el cierre del proyecto. Esta fase se traslapa con
la implementación ya que prácticamente al estar en la última etapa de la
implementación se comienzan con los preparativos para el cierre, así mismo se
traslapa con el alcance, ya que en el cierre se realiza una comparación cuantitativa
y cualitativa del alcance solicitado a lo largo del proyecto y el real que se está
entregando. No obstante, si se le dio seguimiento oportuno a cada actividad y/o
incidente a lo largo del proyecto, esta fase será la de mayor satisfacción, siendo
común que, a pesar de haber firmado la carta de cierre, algún miembro del equipo
del líder del proyecto le dé seguimiento personal por un periodo determinado
(normalmente 1 mes) a la operación ya con el ERP en productivo. Posteriormente
se mantiene una póliza de soporte de 2do Nivel por un periodo mínimo de 1 año.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
125
4.6.1 Entrega de licencias y documentación
Se entrega una carpeta con la documentación impresa referente al proyecto, así
mismo se entrega un CD con la documentación y manuales de manera electrónica
y el CD del software con la versión del cliente. A continuación, el formato para la
entrega de licencias del cliente.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
126
4.6.2 Análisis de resultados
El análisis de resultados sería imposible sin la documentación, por lo que a pesar
de minimizar en lo posible la documentación siempre es recomendable elaborarla y
mantenerla actualizada, ya que sin ella se pierde el control de lo real y se puede
convertir el cierre del proyecto en una pesadilla de rumores y entre dichos. El
análisis de resultados aparte de otorgarnos métricas para histórico de mejores
prácticas para futuros proyectos, apoya para que tanto el proveedor como el cliente
se mantengan en común acuerdo.
4.6.3 Carta de cierre de proyecto
Administración de Proyectos para Optimizar la Implementación de un Software ERP
128
RESULTADOS
Existen distintos métodos para el análisis de resultados, sin embargo, los
parámetros más significativos y de carácter cuantitativo en la administración de
proyectos principalmente son el tiempo y el costo. Ambos parámetros se van
obteniendo a lo largo del proyecto para mostrarse en las juntas de avance junto con
sus métricas, no obstante, al concluir el proyecto se puede decir que se obtiene el
marcador final y por lo tanto el más importante; ya que determina si el proyecto
resulto exitoso. A continuación, se observa el resultado y desviación en tiempo y
costo del proyecto utilizado la metodología propuesta.
Figura 23. Plan vs Real – Tiempo (Elaboración Propia)
Figura 24. % desviación de Tiempo (Elaboración Propia)
226
150
60
260
164
65
DIAS HABILES LINEALES
DIAS IMPLEMENTACION
DIAS DE DESARROLLO
0 50 100 150 200 250 300
Plan vs Real (Tiempo)
Real Plan
100%
102%
104%
106%
108%
110%
112%
114%
116%
0
50
100
150
200
250
300
Dias habiles lineales Dias implementacion Dias de desarrollo
% desviacion de TiempoPlan Real %
Administración de Proyectos para Optimizar la Implementación de un Software ERP
129
Figura 25. Plan vs Real - Costo (Elaboración Propia)
Figura 26. % desviación en Costo (Elaboración Propia)
0
500
1000
1500
2000
2500
3000
Dias implementacion Dias de desarrollo TOTAL
Plan vs Real (Costo)
Costo Plan Costo Real
100%
101%
102%
103%
104%
105%
106%
107%
108%
109%
0
500
1000
1500
2000
2500
3000
Dias implementacion Dias de desarrollo TOTAL
Desviación en Costo
Costo Plan Costo Real % Extra
Administración de Proyectos para Optimizar la Implementación de un Software ERP
130
CONCLUSIONES
Para agilizar el proyecto de implementación del sistema es recomendable tener una
metodología de base, con los procesos generales aplicables a cualquier proyecto
de implementación de un ERP, teniendo que adaptar estos procesos y
documentación a la situación y requerimientos específicos de cada organización o
empresa que atraviesa o está por comenzar con esta etapa de selección o
implementación.
Aplicando la metodología propuesta se presentaron distintas circunstancias,
algunas siendo favorables y otras no tanto, debido al rechazo de lo desconocido,
consecuencia de tener la ilusión de pérdida de control de un resultado favorable que
fuera comprobable anticipadamente y de manera tangible.
A pesar de realizar el análisis de históricos de proyectos anteriores y adaptar los
procesos que no estaban generando valor, agilizando la implementación, no se
podía demostrar inicialmente que utilizando esta metodología se lograría un
proyecto exitoso, por lo tanto, al principio se tuvo una actitud de rechazo,
desconfianza y de manera general inicialmente fue juzgada como informal,
representando poco compromiso.
Sin embargo, después de un largo proceso de comunicación, trabajo y sobre todo
adecuaciones a la metodología; actualmente después de poco más de un año, se
ha logrado obtener resultados favorables. El éxito no ha sido solo consecuencia de
la parte metodológica, sino también a la par se ha contado con el apoyo y
experiencia de consultores, permitiendo reaccionar y guiar el proyecto de la manera
y el camino más conveniente, según el tipo de empresa y personal con el que se
esté trabajando.
Los resultados favorables se han medido en distintas etapas a lo largo del proyecto
por medio de tres parámetros cuantitativos: 1. Tiempo, 2. Costo y 3. Funcionalidad.
El primer parámetro se obtiene comparando el avance del proyecto planeado vs el
avance real en tiempo; el segundo parámetro se calcula comparando el costo inicial
Administración de Proyectos para Optimizar la Implementación de un Software ERP
131
del proyecto propuesto en contrato vs costo real, y la tercera medición es la
comparación de los requerimientos vs la funcionalidad entregada.
Otro parámetro es el flujo de trabajo y desarrollo del proyecto, el cual fue más ligero
y no tan sofocante para ambas partes (cliente – proveedor) siendo este último un
parámetro cualitativo y no cuantitativo.
Obteniendo los siguientes resultados: desfase cronológico entre avance real y
planeado 15%; Costos adicionales incurridos en el proyecto 8% más (los cuales
fueron absorbidos por el proveedor ya que fueron indirectamente amortiguados en
la cotización y contrato inicial); funcionalidad acordada mediante los documentos de
alcance fue del 100%, la cual abarco aproximadamente un 95% de la funcionalidad
deseada.
No obstante, los sistemas para el manejo de información hoy en día se encuentran
en continua evolución, por lo tanto, este trabajo es tan solo la base para una
continua adaptación a los distintos cambios que se presentaran en el futuro, con el
objetivo de tener empresas mexicanas más productivas.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
132
Glosario
Administración de proyectos: Es una metodología usada a nivel mundial, por
empresas e instituciones para alcanzar objetivos en un tiempo determinado.
ERP: Se refiere a los sistemas de planificación de recursos empresariales por sus
siglas en inglés, enterprise resource planning. Son los sistemas de información
gerenciales que integran y manejan muchos de los negocios asociados con las
operaciones de producción y de los aspectos de distribución de una compañía en
la producción de bienes o servicios.
Factor de Complejidad Ambiental (ECF): Es un factor aplicado al estimado del
software con el fin de considerar los factores ambientales del sistema. Se determina
mediante la asignación de una puntuación entre 0 (sin experiencia) y 5 (experto)
para cada factor ambiental.
KPI (key performance indicator): Conocido también como indicador clave o
medidor de desempeño o indicador clave de rendimiento, es una medida del nivel
del desempeño de un proceso. El valor del indicador está directamente relacionado
con un objetivo fijado de antemano y normalmente se expresa en valores
porcentuales. Un KPI se diseña para mostrar cómo es el progreso en un proceso o
producto en concreto, por lo que es un indicador de rendimiento.
Plugin: En informática, un complemento es una aplicación (o programa informático)
que se relaciona con otra para agregarle una función nueva y generalmente muy
específica. Esta aplicación adicional es ejecutada por la aplicación principal e
interactúan por medio de la interfaz de programación de aplicaciones. También se
conoce por el término en inglés, plug-in ("enchufable" o "inserción") o add-on
("añadido"), y como conector o extensión.
Proceso: Es una unidad de actividad que se caracteriza por la ejecución de una
secuencia de instrucciones, un estado actual, y un conjunto de recursos del sistema
asociado.
Project Charter: Es una declaración del alcance, los objetivos y los participantes
en un proyecto. Proporciona una delimitación preliminar de las funciones y
responsabilidades, se exponen los objetivos del proyecto, se identifican los
principales grupos de interés, y define la autoridad del director del proyecto. Sirve
como una referencia de la autoridad para el futuro del proyecto. Los términos de
referencia son generalmente parte de la carta del proyecto.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
133
Puntos de Casos de Uso (UCP): Es una técnica utilizada en la estimación de
software para predecir el tamaño del software para proyectos de desarrollo de
software. Se maneja cuando UML se utiliza para el diseño y desarrollo de
software. El concepto de UCP se basa en los requisitos para el sistema que está
siendo escrita usando casos de uso , que es parte del conjunto de técnicas de
modelado UML.
Sistema: Es un objeto complejo cuyos componentes se relacionan con al menos
algún otro componente; puede ser material o conceptual. Todos los sistemas tienen
composición, estructura y entorno.
SOW (declaración de trabajo): Es un documento empleado habitualmente en el
campo de la gestión de proyectos. Definiendo las especificaciones del proyecto y
sus actividades, entregables y los plazos para un proveedor de la prestación de
servicios al cliente. Típicamente incluye requisitos detallados y precios, con términos
y condiciones regulatorias y de manera estándar.
UML: Se refiere al lenguaje unificado de modelado por sus siglas en inglés, Unified
Modeling Language. Es el lenguaje de modelado de sistemas de software más
conocido y utilizado en la actualidad; respaldado por el Object Management Group
(OMG). Es un lenguaje gráfico para visualizar, especificar, construir y documentar
un sistema. Incluye aspectos conceptuales tales como procesos, funciones del
sistema, y aspectos concretos como expresiones de lenguajes de programación,
esquemas de bases de datos y compuestos reciclados.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
134
Referencias
Aguilera Castro, A., & Riascos Erazo, S. C. (2009). Direccionamiento estratégico apoyado en las TIC. Estudios Gerenciales, 25(111), 127-143.
Antoniolli, P. D., Argoud, A. R. T. T., Benevides, G., Pires, S. R. I., Herbert, W. E., Ene, E. E., ... & Lima, C. R. C. FMEA as a Tool for Managing Risks in ICT Projects, based on the PMBOK. Globalization, 1, 24.
Boltena, A. S., & Gómez, J. M. (2012). A successful ERP implementation in an Ethiopian company: A case study of ERP implementation in Mesfine industrial engineering Pvt. Ltd. Procedia Technology, 5, 40-49.
Buffa, E. S. (1973). Dirección de operaciones: problemas y modelos. Limusa-Wiley.
Candra, S. (2012). ERP implementation success and knowledge capability.Procedia-Social and Behavioral Sciences, 65, 141-149.
Díaz, A., Gonzales, J. C., & Ruiz, M. E. (2005). Implantación de un sistema ERP en una organización. Revista de investigación de Sistemas e Informática,2(3), 30-37.
Galy, E., & Sauceda, M. J. (2014). Post-implementation practices of ERP systems and their relationship to financial performance. Information & Management, 51(3), 310-319.
Grabot, B., Mayere, A., Lauroua, F., & Houe, R. (2014). ERP 2.0, what for and how?. Computers in Industry, 65(6), 976-1000.
Hessman, T. (2013). Tales of an ERP implementation. IndustryWeek
Iubaris Info 4 Media SL (2016). Scrum Manager, Guía de formación, Versión 2.6 – Julio 2016, http://www.scrummanager.net/files/scrum_manager.pdf
Lineke Sneller RC (2014). A Guide to ERP: Benefits, Implementation and Trends 1st edition bookboon.com, ISBN 978-87-403-0729-0
Maldonado, M. (2008). El Impacto de los Factores Críticos de Éxito en la Implementación de Sistemas Integrados de ERP. The bi-annual academic publication of Universidad ESAN, 13(25), December-2008.
Administración de Proyectos para Optimizar la Implementación de un Software ERP
135
Martínez, J. M. A., Fa, M. C., & Elguezabal, I. Z. (2014). Evolución Histórica de los Sistemas ERP: de la administración de materiales a la empresa digital. Revista de dirección y administración de empresas, 1(12).
Monk, E., & Wagner, B. (2012). Concepts in enterprise resource planning. Cengage Learning.
Parveen, M., & Maimani, K. (2014). A Comparative Study between the Different Sectors Using the ERP Software in Jeddah Region-KSA. Life Science Journal, 11(3s).
Project Management Institute. (2008). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Project Management Institute, Incorporated.
Rajnoha, R., Kádárová, J., Sujová, A., & Kádár, G. (2014). Business Information Systems: Research Study and Methodological Proposals for ERP Implementation Process Improvement. Procedia-Social and Behavioral Sciences, 109, 165-170.
Ram, J., Wu, M. L., & Tagg, R. (2014). Competitive advantage from ERP projects: Examining the role of key implementation drivers. International Journal of Project Management, 32(4), 663-675.
Razmi, J., Sangari, M. S., & Ghodsi, R. (2009). Developing a practical framework for ERP readiness assessment using fuzzy analytic network process. Advances in Engineering Software, 40(11), 1168-1178.
Rivera Martínez, F., & Hernández Chávez, G. (2010). Administración de Proyectos, Guía para el aprendizaje. México, Editorial Prentice Hall.
Sánchez-Arias, L. F., & Solarte-Pazos, L. (2010). The body of knowledge of the Project Management Institute-PMBOK® Guide, and the specificities of project management: a critical review. Innovar, 20(37), 89-100.
Schroeder R. G., Goldstein S. M. y Rungtusanatham M. J. (2011). Administración de operaciones: Conceptos y casos contemporáneos 5a Edición, McGRAW-HILL
The Standish Group International Inc. (2011). Chaos Manifest 2011.
http://www.versionone.com/assets/img/files/ChaosManifest_2011.pdf
Administración de Proyectos para Optimizar la Implementación de un Software ERP
136
Travis (2015). Change-Ups & Calendar. Grand Rapids Business Journal; Vol. 33
Issue 30
World Bank (2012) ICTs for Greater Development Impact – World Bank Group Strategy for Information and Communication Technology 2012–2015, World Bank, Washington, DC.
http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.html
http://scn.sap.com/community/asap-methodology
http://www.agile-process.org/
https://www.agilealliance.org/
http://www.axxonconsulting.com/en/admin/download/sure_step_methodology.pdf
http://www.oracle.com/us/products/consulting/resource-library/oracle-unified-method-069204.pdf
https://www.scrummanager.net/