INSTITUTO POLITÉCNICO ACIONAL148.204.210.201/tesis/1488568963351TesisIctzelMo.pdf · Así mismo la...

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

2


3


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.


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.


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.


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


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


9

INTRODUCCIÓN


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


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.


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


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.


14

CAPITULO I

EL ERP PARA LA ADMINISTRACIÓN

EMPRESARIAL


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


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,


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.


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.


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


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.


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


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


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


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


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.


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


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


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


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


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


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.


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


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


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.


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


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


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)


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


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


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)


41

CAPITULO II

ADMINISTRACIÓN DE PROYECTOS


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


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


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.


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.


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.


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®)


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.


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.


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


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.


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.


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.


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.


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


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


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.


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,


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.


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


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


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.


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.


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)


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).


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.


67

CAPITULO III

PROPUESTA DE FACTORES DE

COMPLEJIDAD AMBIENTAL

PARA SISTEMAS ERP EN MÉXICO


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


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;


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.


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)


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.


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.


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


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.


76

CAPITULO IV

PROPUESTA DE METODOLOGÍA

PARA LA IMPLEMENTACIÓN DEL

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)


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)


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


80

ÍNDICE


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


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.


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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..


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.


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.


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.


99


100


101


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)


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


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.


105

A continuación, el formato para el “Project Charter”


106


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


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.


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)


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


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.


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.


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)


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”


115


116


117


118


119


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.


121

Figura 22. Reporte de KPI en la fase de Roll-Out (Elaboración Propia)


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.


123


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.


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.


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


127


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 %


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


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


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.


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.

https://es.wikipedia.org/wiki/Sistemas_de_informaci%C3%B3n_gerencial

https://es.wikipedia.org/wiki/Sistemas_de_informaci%C3%B3n_gerencial

https://es.wikipedia.org/wiki/Producci%C3%B3n_(econom%C3%ADa)


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.

https://en.wikipedia.org/wiki/Software_estimation

https://en.wikipedia.org/wiki/Software_estimation

https://en.wikipedia.org/wiki/Use_cases


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.


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


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/

INSTITUTO POLITÉCNICO ACIONAL148.204.210.201/tesis/1488568963351TesisIctzelMo.pdf · Así mismo la...

Documents

Transcript of INSTITUTO POLITÉCNICO ACIONAL148.204.210.201/tesis/1488568963351TesisIctzelMo.pdf · Así mismo la...