T E S I S - 148.204.210.201148.204.210.201/tesis/1443798581687TesisCarlosI.pdf · instituto...

INSTITUTO POLITÉCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS

SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN

"ELEMENTOS MÍNIMOS EN

UNA ORGANIZACIÓN,

PREVIOS A LA

IMPLEMENTACIÓN DE UN

ERP”

T E S I S

Que para obtener el grado de

Maestro en Administración

presenta:

Lic. Carlos Ignacio Gil Camacho

Director de tesis

M. en C. Jesús Manuel Reyes García

México, D.F., 2015.

AGRADECIMIENTOS

Al Instituto Politécnico Nacional por creer en mí como

estudiante para ser parte del desarrollo de nuestro país.

A la Unidad Profesional Interdisciplinaria de Ingeniería y

Ciencias Sociales y Administrativas por la oportunidad

de seguir creciendo ahora como Maestro en Administración.

A mi director de tesis M. en C. Jesús Manuel Reyes

García, por su apoyo en la planeación de este proyecto de

tesis.

A mis sinodales:

M. en C. María Guadalupe Obregón Sánchez

M. en C. Manuel Jesús Guerreo Briseño

Dr. Juan Ignacio Reyes García

Dr. Ángel Eustorgio Rivera González

Por su esfuerzo, paciencia y apoyo en todo momento en la

elaboración de mi trabajo de tesis.

A todos mis profesores de la Maestría en Administración,

gracias.

DEDICATORIAS

A mi mejor amiga, por todos sus cuidados incondicionales,

por tanto y tanto amor, porque me enseñó a hacer las cosas

con el “corazón”, y cuando se me enferma o cansa el mío,

siempre esta ella para prestarme el suyo para continuar

superándome, gracias Leo, gracias Mamá.

A mi mejor amigo, que me enseñó disciplina y

perseverancia, que no pierde la oportunidad de darme un

consejo, y que cada que necesito recargarme en alguien,

siempre esta él para apoyarme, gracias Carlos, gracias

Papá.

A mis ángeles, que siempre que se me ha lastimado o roto

alguna de mis alas, me prestan las suyas para seguir

soñando, gracias a mi hermana Tania y a mi hermano León

Arturo.

A mi cuñada y a mi cuñado, por su amistad y apoyo en

todo momento; por acompañar y cuidar a mis ángeles,

gracias Lupita, gracias Víctor.

A mis sobrinas, por ser parte de mi inspiración y mi

alegría, gracias Liam Zóe, gracias Iyari Adamay.

A mi esposa y compañera de viaje, por su paciencia y por

regalarme a mi princesa, por la que siempre estaré en

deuda, gracias Yolanda.

A mi princesa, por todo lo que me ha enseñado, por el

amor tan grande que siempre irradia y la felicidad que

siempre nos contagia, gracias Dayra Valeria por haberme

elegido, es un honor y un privilegio ser tú Papá.

Gracias a Dios por tanta salud, tanto amor y todas sus bendiciones.

Un abrazo y un beso a todos, los quiere Charly.

¡Lo logramos!

ÍNDICE GENERAL

RESUMEN .......................................................................................................................................... I

SUMMARY ........................................................................................................................................ II

INTRODUCCIÓN ............................................................................................................................. III

1 ANTECEDENTES Y EVOLUCIÓN DE LOS SISTEMAS ERP .......................................... 1

1.1 Historia de los sistemas ERP ......................................................................................... 3

1.2 Identificación histórica del problema ............................................................................. 5

1.3 Demarcación del fenómeno ............................................................................................ 9

1.4 Planteamiento del problema ......................................................................................... 11

1.5 Objetivos del estudio ...................................................................................................... 12

2 GENERALIDADES Y METODOLOGÍAS DE IMPLEMENTACIÓN DE LOS SISTEMAS

ERP EN PYMES ............................................................................................................................. 13

2.1 Clasificación de las organizaciones ............................................................................. 13

2.2 Sistemas de Planificación de Recursos Empresariales (ERP) ............................... 15

2.2.1 Definiciones generales de los sistemas ERP ..................................................... 16

2.2.2 Características de los sistemas ERP .................................................................. 19

2.2.3 Flujo estándar de un ERP ..................................................................................... 22

2.3 Metodologías utilizadas para la implementación de sistemas ERP ....................... 23

2.3.1 Metodología de PMI (Project Management Institute, guía del PMBok) ......... 26

2.3.2 Metodología AIP de SAP ....................................................................................... 29

2.3.3 Metodología Sure Step de Microsoft ................................................................... 33

2.4 Herramientas utilizadas para la implementación de los sistemas ERP. ................ 37

2.4.1 La Planeación de los Sistemas de Información ................................................. 37

2.4.2 Calendario para la implementación de un proyecto .......................................... 38

2.4.3 Ingeniería de Requerimientos............................................................................... 40

2.5 Factores Críticos de Éxito en la Implementación de Sistemas en las Empresas

(CFS, Critical Factors for Succesful Implementation of Enterprise Systems) ................... 53

2.5.1 Clasificación de los beneficios de los sistemas ERP ........................................ 55

2.5.2 Comparativo de estudios ....................................................................................... 55

3 ESTUDIO Y DESARROLLO DEL OBJETO DE INVESTIGACIÓN ................................ 62

3.1 Diseño de investigación ................................................................................................. 64

3.1.1 Diseño específico de la investigación ................................................................. 65

3.1.2 Limitaciones de la investigación ........................................................................... 68

3.2 Población y unidad de análisis de datos ..................................................................... 68

3.2.1 Distribución de las empresas por tamaño .......................................................... 68

3.2.2 Áreas o procesos del negocio en los que utiliza SAP ...................................... 69

3.2.3 Definición de la población objetivo....................................................................... 69

3.3 Muestra de estudio ......................................................................................................... 70

3.3.1 Determinación del tamaño de la muestra ........................................................... 71

3.3.2 Limitaciones de la muestra ................................................................................... 71

3.4 Selección de instrumentos ............................................................................................ 72

3.4.1 Recopilación de datos ............................................................................................ 72

3.4.2 Cuestionario aplicado en campo .......................................................................... 74

4 HALLAZGOS Y RESULTADOS ........................................................................................... 76

4.1 Análisis de la información obtenida ............................................................................. 77

4.1.1 Giros de las empresas ........................................................................................... 77

4.1.2 Número de usuarios que utilizan el ERP ............................................................ 79

4.1.3 Motivos de la implementación del ERP ............................................................... 80

4.1.4 Razones por las que seleccionó el ERP ............................................................. 81

4.1.5 Implementaciones hechas en tiempo .................................................................. 82

4.1.6 Porcentaje de variación del tiempo de implementación respecto al planteado

en un inicio ............................................................................................................................... 83

4.1.7 Porcentaje de variación del costo de implementación respecto al planteado

en un inicio ............................................................................................................................... 84

4.1.8 Porcentaje de las empresas que cubrieron sus necesidades ......................... 85

4.1.9 Factores críticos por lo que no se tuvo una implementación exitosa ............. 86

4.2 Comparación de información obtenida vs estudios realizados por otros

investigadores ............................................................................................................................. 87

4.3 Resultado de la comprobación de la problemática ................................................... 88

CONCLUSIONES ........................................................................................................................... 90

GLOSARIO DE TÉRMINOS, ABREVIATURAS Y ACRÓNIMOS ........................................... 93

BIBLIOGRAFÍA ............................................................................................................................... 96

ANEXOS ........................................................................................................................................ 105

FIGURAS, TABLAS y GRÁFICAS

Figura 1. Ciclo de Información (CIO, 2002). ................................................................................ 1

Figura 2. Cuestiones sobre la necesidad de un sistema ERP. ................................................. 6

Gráfica 3. Porcentaje de proyectos exitosos (Standish Group, 2001). .................................... 7

Figura 4. Alineación de un sistema a los procesos de una organización (Elaboración

propia). ............................................................................................................................................... 9

Figura 5. Caricatura de un proceso de requerimiento (Intelligenia, 2013). ........................... 11

Figura 6. Clasificación de las empresas (INEGI, 2009). .......................................................... 15

Figura 7. Áreas de los sistemas ERP (Elaboración propia). ................................................... 16

Figura 8. Sistemas ERP en el Mercado. ..................................................................................... 20

Figura 9. Gestores de bases de datos en el mercado (Elaboración propia). ........................ 21

Figura 10. Proceso de un ERP (Elaboración propia). ............................................................... 22

Figura 11. El ciclo de vida del desarrollo de sistemas (Oz, 2008). ......................................... 25

Figura 12. Etapas de la gestión de proyectos (PMI, 2015). ..................................................... 28

Figura 13. Ciclo de Implementación de SAP Business One (SAP Partner Edge, 2015). ... 29

Figura 14. Metodología AIP para la implementación de SAP Business One (SAP Partner

Edge, 2015). .................................................................................................................................... 30

Figura 15. Metodología Microsoft Dynamics Sure Step (Microsoft, 2015). ........................... 34

Figura 16. Pasos para la planeación de los Sistemas de Información. (Oz, 2008). ............ 37

Figura 17. Calendario para la implementación de un proyecto (ACE, 2015). ...................... 39

Figura 18. Ingenierías involucradas relacionadas con la Ingeniería de Requerimientos

(IEEE, 1984). ................................................................................................................................... 44

Figura 19. Proceso de Ingeniería de Requerimientos (IEEE, 1984). ..................................... 46

Figura 20. Jerarquía de requerimientos (IEEE, 1984). ............................................................. 47

Figura 21. Fases generales para la investigación y obtención de requerimientos (IEEE,

1984). ............................................................................................................................................... 49

Figura 22. Taxonomía de los factores críticos para la implementación del sistema ERP (Al-

Mudimigh, Zairi & Al-Mashari, 2001). .......................................................................................... 56

Tabla 23. Comparación de estudios de factores críticos de éxito en la implementación de

sistemas ERP (Elaboración propia). ............................................................................................ 58

Figura 24. Esquema general del Proceso de Investigación (Arias Galicia, 2012). .............. 63

Figura 25. Diagrama general del Proceso de Investigación (Elaboración propia). .............. 65

Tabla 26. Diseño de la Investigación (Elaboración propia). .................................................... 67

Figura 27. Áreas o procesos del negocio en los que se utiliza SAP (Elaboración propia). 69

Figura 28. Cuestionario aplicado a las organizaciones (Elaboración propia). ...................... 74

Tabla 29. Rol desempeñado durante la implementación (Elaboración propia). ................... 77

Gráfica 30. Giros de las empresas entrevistadas (Elaboración propia). ............................... 78

Gráfica 31. Usuarios que usan el ERP en la empresa (Elaboración propia). ....................... 79

Gráfica 32. Motivos de la implementación del ERP (Elaboración propia). ............................ 80

Gráfica 33. Razones por las que se seleccionó el ERP (Elaboración propia). ..................... 81

Gráfica 34. Implementaciones hechas en tiempo (Elaboración propia). ............................... 82

Gráfica 35. Porcentaje de variación del tiempo de implementación respecto al planteado

en un inicio (Elaboración propia). ................................................................................................ 83

Gráfica 36. Porcentaje de variación del costo de implementación respecto al planteado en

un inicio (Elaboración propia). ...................................................................................................... 84

Gráfica 37. Porcentaje de las empresas que cubrieron sus necesidades (Elaboración

propia). ............................................................................................................................................. 85

Gráfica 38. Factores críticos por lo que no se tuvo una implementación exitosa

(Elaboración propia). ...................................................................................................................... 86

Tabla 39 Factores críticos de éxito coincidentes con otros estudios (Elaboración propia). 87

Tabla 40 Factores críticos de éxito detectados adicionalmente (Elaboración propia). ....... 88

RESUMEN

Con el boom de los sistemas de cómputo, las organizaciones que contaban con

esta tecnología, comenzaron a desarrollar sus propios programas apegados a sus

necesidades y con el tiempo estos sistemas se fueron aprovechando para

implantarse en otras organizaciones con características similares, dando origen a

los paquetes de programas y posteriormente a lo que hoy en día conocemos como

los sistemas ERP o planificación de recursos empresariales.

Casi al mismo tiempo del surgimiento de los sistemas ERP, nacieron las

Metodologías de Implementación, que son una secuencia de pasos lógicos y

sistematizados para la implementación de los ERP en las empresas. Estas

metodologías sirven para planear y administrar los proyectos, así como guiar a los

líderes de proyecto durante el proceso de implementación, dando como resultado,

control del proyecto, disminución de riesgos y logro de los objetivos originalmente

planteados.

A pesar de las metodologías y de los muchos estudios que existen respecto a los

problemas presentados al momento de implementar un sistema ERP, se siguen

presentando desviaciones de tiempo, costo y logro de objetivos, pareciera que

todos los estudios hechos y herramientas que se tienen en la actualidad, no han

sido considerados. Por lo tanto, el desgaste y frustración de los participantes sigue

latente.

Hace algunos años cuando se empezó con el desarrollo de los sistemas de

información, lo primero que se definía era la misión de la empresa, el plan

estratégico, los objetivos de la organización hasta llegar a los procesos detallados,

los cuales tenían que estar validados y documentados antes de comenzar a

desarrollarse. Hoy en día las metodologías omiten esta parte y lo sustituyeron por

una tarea que le llaman alineación de procesos donde buscan forzar a la

organización a apegarse al funcionamiento del ERP, que defienden como las

mejores prácticas en las organizaciones.

Analizando las metodologías y herramientas de implementación actuales además

de una investigación de campo, se obtiene un conjunto de elementos mínimos con

los que debe contar una organización previos a la implementación de un sistema

ERP. La investigación se hizo en PYMES de la Zona Metropolitana del Valle de

México que llevaron a cabo una implementación de un sistema ERP.

I

SUMMARY

With the boom of computer systems, organizations that had this technology began

to develop their own programs attached to their needs, and over time these

systems were implemented advantage to other organizations with similar

characteristics, giving rise to packages program and then what we know today as

ERP systems.

Almost simultaneously with the emergence of ERP systems, were born

Implementation Methodologies, which are logical and systematized sequence of

steps for the implementation of ERP systems. These methodologies are used to

plan and manage projects and lead project leaders during the implementation

process, resulting, project control, risk reduction and achievement of the objectives

originally proposed.

Although the methodologies and the many studies that exist with respect to the

problems presented when implementing an ERP system, there continue to be

deviations of time, cost and achieving goals, it seems that all the studies done and

tools that take into currently, they were simply ignored. Therefore wear and

frustration of the participants is still present.

Some years ago when it started with the development of information systems, the

first thing that was defined was the company mission, strategic plan, the objectives

of the organization down to the detailed processes, which had to be validated and

documented before starting to develop. Today methodologies omit this part and

replaced it with a task that called alignment processes which seek to force the

organization to adhere to the operation of ERP, who defend as best practices in

organizations.

Analyzing the current methodologies and implementation tools in addition to field

research, it’s found that there are minimum elements that should tell a prior to the

implementation of an ERP system organization. The research was done in small

and medium-sized enterprises in the metropolitan area of Mexico City who

conducted an implementation of an ERP system.

II

INTRODUCCIÓN

En la actualidad, tenemos contacto en todo momento con sistemas de

información, desde los servicios a los que tenemos acceso como bancos, pagos

de servicios, etc., hasta los sistemas que utilizamos en las diversas actividades

que realizamos participando en alguna área de alguna empresa.

En nuestros tiempos las organizaciones, sin importar su tamaño o sector de

actividad, están operando o están planeando implementar en el corto o mediano

plazos un sistema ERP o de Planeación de Recursos Empresariales (por sus

siglas en inglés Enterprise Resource Planning Systems), que soporte sus

funciones clave de negocio y las interconexiones entre ellas.

Los sistemas ERP, constituyen actualmente la herramienta más importante de la

Tecnología de Información, por 3 aspectos fundamentales: la practicidad, el

control y la oportunidad de la información. Es recomendable que las empresas

antes de pensar en otro tipo de aplicación de tecnología de información para algún

objetivo estratégico específico, se enfoquen en implementar un sistema ERP, una

vez lograda la integración departamental, se pueden empezar a implementar

elementos adicionales que eleven la funcionalidad.

Como usuarios finales generalmente requerimos que la mayoría de las cosas que

implican mucho trabajo se automaticen, y no solo eso, sino que además

requerimos que los sistemas sean: amigables, intuitivos, rápidos, estables,

seguros y que nos proporcionen información útil, en sí, que respondan

adecuadamente a nuestras necesidades.

A los proveedores de sistemas les interesa implementar o producir sistemas de

información útiles, que cubran adecuadamente las expectativas de los usuarios,

que les permita cubrir sus necesidades e inclusive que les ofrezcan una ventaja

competitiva, generando un beneficio económico y profesional.

Sin embargo, es común que los usuarios no sean especialistas en sistemas, por lo

que no expresan de forma adecuada en términos generales e informáticos sus

necesidades, no saben lo que realmente requieren o peor aún no identifican sus

verdaderos problemas.

III

En cuanto al equipo de implementación del proveedor, generalmente están

preparados para ofrecer soluciones adecuadas desde el punto de vista

informático, mas no es experto en los procesos del negocio donde se va a

implementar el ERP como lo pueden ser los usuarios de la organización, en este

caso del cliente.

Es necesario tener claramente identificado el objetivo general y los objetivos

específicos de la implementación del sistema ERP, para lo cual es indispensable

acordar el alcance a través de tener documentados claramente los requerimientos

de la organización.

La mayoría de las veces no se le da la importancia necesaria a la situación

organizacional de la empresa y a elementos tales como procesos documentados y

especificaciones de requerimientos, lo que deriva en implementaciones costosas y

largas que a nadie conviene. Esto no es nuevo, de hecho, uno de los motivos de la

llamada “crisis del software” en los años 60, fue precisamente la insuficiente

especificación y falta de control en los requerimientos.

¿Cómo lograr disminuir los riesgos la implementación de un sistema ERP en las

organizaciones?

Para dar respuesta a la pregunta se hizo un estudio de los factores que han

ocasionado problemas en la implementación de sistemas de información en las

organizaciones.

Esta tesis está conformada por 4 capítulos, el capítulo 1 expone los antecedentes

y evolución de los sistemas ERP, el cuál describe la historia de los sistemas, la

problemática durante las últimas décadas, además de la demarcación del

fenómeno a estudiar y el objetivo del estudio.

El capítulo 2 abarca, generalidades y metodologías de los sistemas, en el cuál se

describen algunos elementos importantes que se relacionan ampliamente con el

objeto de estudio, como información acerca de los sistemas ERP, algunas

metodologías utilizadas actualmente, herramientas que pueden ayudar a definir

requerimientos. Y por último algunos estudios que algunos investigadores acerca

de los factores críticos de éxito en la implementación de sistemas ERP.

IV

El capítulo 3 señala, el estudio y desarrollo del objeto de investigación, describe el

proceso de investigación en campo que se llevó a cabo para un análisis en

PYMES de la Zona Metropolitana del Valle de México, que implementaron o están

terminando una implementación del sistema ERP SAP Business One. Aquí se

menciona el tipo de investigación, alcance, instrumentos utilizados, así como las

limitaciones y acotaciones que se tienen.

El capítulo 4 muestra, los hallazgos y resultados, incluye un análisis de la

información de los datos recopilados, así como una comparación con los

resultados de otras investigaciones, con la finalidad tanto de encontrar

coincidencias como elementos adicionales que puedan ser importantes para las

conclusiones y discernir los elementos mínimos en las organizaciones.

V

Elementos mínimos en una organización, previos a la implementación de un ERP

IPN UPIICSA 1

1 ANTECEDENTES Y EVOLUCIÓN DE LOS SISTEMAS ERP

Al encontrarse las empresas en un entorno de competencia continua, han tenido

que buscar la forma de crecer o inclusive simplemente lograr su permanencia en

el mercado. Uno de los factores determinantes para este logro, ha sido

indudablemente el tema de la Tecnología, muchas empresas han cambiado su

sistema de información (SI) mediante la adopción de estrategias de paquetes de

software de aplicación en lugar de hacer un desarrollo interno (Laudon & Laudon,

1996).

Una de las principales inversiones que se hacen hoy en día en las empresas es la

que tiene que ver con tecnologías de información (TI), en la última década ha sido

el sistema de planificación de recursos empresariales (ERP) (Stallaert y Whinston,

2000). Según la revista “Fortune 1000”, el 70% de las empresas de tamaño

pequeño con ingresos brutos de menos de $250 millones, tienen un sistema ERP

o pronto lo instalarán (Bingi, Sharma y Golda, 1999).

En la figura 1 se muestra la interrelación que existe entre los datos, la información y cómo interactúan para poder tomar decisiones y como consecuencia acciones.

Figura 1. Ciclo de Información (CIO, 2002).


IPN UPIICSA 2

“La información se ha convertido en el elemento clave en el diseño de estrategias

empresariales en el nuevo siglo, por ser la materia prima necesaria para la toma

de decisiones” (CIO, 2002).

Los Sistemas ERP o Sistemas de Planeación de Recursos Empresariales, se

pueden considerar como, "el acontecimiento más importante en el uso corporativo

de tecnología de la información en la década de los años 90 (Davenport T. , 1998).

Las implementaciones de los sistemas ERP son generalmente proyectos grandes,

complejos, que involucran a grandes grupos de personas y otros recursos, que

trabajan juntos bajo una considerable presión de tiempo y que se enfrentan

muchos acontecimientos imprevistos (Avnet, 1999).

No es una sorpresa que muchas de estas implementaciones resulten ser menos

exitosas de lo previsto originalmente (Davenport T., 1998; Avnet, 1999).

Se entiende por proyecto exitoso aquel que se termina con los recursos

razonablemente estimados y que satisface las expectativas de los clientes y

usuarios (Avnet, 1999).

Por otro lado, los proyectos que fracasan, son por ejemplo, aquellos que se

retrasan, se cancelan, sobrepasan por mucho los recursos inicialmente estimados

para su desarrollo, nunca se utilizan o no satisfacen las expectativas de los

usuarios (Avnet, 1999).

De algunos años a la fecha, se han realizado muchas investigaciones acerca de

los factores críticos de éxito, para implementación de un sistema ERP (por sus

siglas en inglés CSF, Critical Success Factors for ERP implementation) para las

implementaciones de ERP (Holland & Light, 1999; Sumner, 1999); y las

implementaciones de TI, Tecnología de Información en general (Reel, 1999;

Marble, 2000).

Los estudios realizados acerca de los Factores Críticos de Éxito incluyen

regularmente elementos muy generales que se deben contemplar y establecer

desde el inicio del proyecto, como son: soporte superior de gestión, planificación,

capacitación al usuario final, relaciones con los proveedores, promotores del

proyecto, la colaboración interdepartamental y la comunicación entre otros. Hoy se

tiene también disponible una versión clasificada de una lista de este tipo, basado

en una encuesta entre gerentes de las organizaciones que han pasado

recientemente a través de un proceso de implementación de ERP (Somers &

Nelson, 2001). Aunque aún no está claro cómo estos marcos comunitarios de


IPN UPIICSA 3

apoyo se interrelacionan. Parece poco probable que todos ellos trabajan de forma

aislada. En la actualidad, lo que tenemos son lo que Richmond denomina “listas

de lavandería” o factores críticos de éxito pertinentes (Richmond, 1993). Sin

embargo, por el momento, tenemos poco de teoría sobre cómo estos marcos

comunitarios de apoyo afectan entre sí.

1.1 Historia de los sistemas ERP

El enfoque de sistemas de producción en los años 60, estaba en el control de inventario. Empresas italianas se daban el lujo de mantener grandes cantidades de ''just-in-case'' (inventario en mano), para satisfacer la demanda del cliente y aún permanecer competitivo. Las técnicas de hoy en día se centran más en gestionar de manera más eficiente y eficaz el abastecimiento y surtido de inventario, obedeciendo a nuevas estrategias de reducción de costos (Shankarnarayanan, 2000; Ptak y Schragenheim, 2000).

En los años 70, se hizo cada vez más claro que las empresas ya no podían darse

el lujo de mantener grandes cantidades de inventario, provocando la introducción

de los sistemas de planificación de requerimientos de los materiales (por sus

siglas en inglés MRP, Material Requierements Planning). Los sistemas MRP

representan un enorme paso en el proceso de planificación de materiales.

Por primera vez, el uso de un horario, un plan maestro de producción, con el

apoyo de listas de materiales específicos necesarios para producir cada producto

terminado y un registro de la materia prima disponible al momento y lo que estaba

programado por recibir de los proveedores, una computadora podría ser usada

para calcular las necesidades de material.

Los MRP impulsaron actividades como registrar un pedido de fabricación, la

cancelación de un pedido o la modificación de los pedidos existentes. Esto

también permitió contar con un mecanismo oficial para administrar las prioridades,

dando control de cambios en el entorno de fabricación. La capacidad del sistema

de planificación de forma sistemática dio eficiencia para programar todas las

partes en un solo paso, incrementando la productividad, la calidad y el

cumplimiento en las entregas (Hammer y Stanton, 1999; Henderson y

Venkatraman, 1993; Hopp y Spearman, 1996).


IPN UPIICSA 4

La planificación de la capacidad de producción representa un reto igual. En

respuesta, las técnicas para la planificación de capacidad de producción se han

añadido a las capacidades básicas del sistema de planificación de necesidades.

Estas herramientas fueron desarrolladas para apoyar la planificación de los niveles

de producción y ventas totales (ventas y planificación de las operaciones), el

desarrollo del cronograma de construcción específica (programación maestra de la

producción), previsión, planificación de ventas, pedidos negociados de clientes

(gestión de la demanda), y el análisis de recursos de alto nivel (capacidad de

planificación corte de re-abastecimiento). También se contemplaron técnicas de

programación para control de piso sincronizándolo con entregas de proveedores.

Cuando esto ocurrió, los usuarios comenzaron a considerar sus sistemas para

todas las áreas de la empresa. Estos desarrollos dieron como resultado la

siguiente etapa evolutiva que se conoció como closedloop MRP (Oden,

Langenwalter y Lucier, 1993).

En los años 80, las empresas comenzaron a tomar ventaja del aumento de la

potencia y la asequibilidad de tecnología disponible y fueron capaces de acoplar el

movimiento de inventario con la coincidente actividad financiera. La planificación

de los recursos de fabricación, sistemas MRP II, evolucionó para incorporar el

sistema de contabilidad financiera y el sistema de gestión financiera, junto con la

fabricación y sistemas de gestión de materiales. Esto permitió las empresas tener

un sistema del negocio más integrada que deriva en los requisitos de materiales y

de capacidad asociada a un plan de producción, permitió la entrada de las

actividades detalladas, traducido todo esto a un estado financiero, y sugirió un

curso de acción para hacer frente a esos artículos que no estaban en equilibrio

con el plan deseado (Ptak y Schragenheim, 2000).

Para los años 90, las continuas mejoras en tecnología permitieron ampliarse al

MRP II para incorporar toda la planificación de los recursos para toda la empresa.

Las áreas tales como el diseño de productos, la información de almacenamiento,

la planificación de materiales, la capacidad planificación, sistemas de

comunicación, los recursos humanos, la gestión de las finanzas y proyectos podría

ahora ser incluida en el plan, fue entonces que el término ERP fue acuñado (Ptak

& Schragenheim, 2000). Los sistemas ERP pueden ser utilizados no sólo en

empresas que fabrican, sino en cualquier empresa que quiera mejorar la


IPN UPIICSA 5

competitividad y la utilización eficaz de todos sus activos, incluyendo la

información (Shankarnarayanan, 2000).

1.2 Identificación histórica del problema

Para intentar encontrar soluciones a los problemas que se presentan con las implementaciones de sistemas ERP, tanto académicos como consultores, a lo largo del mundo han realizado investigaciones sobre su proceso de implementación y específicamente sobre la determinación de los factores que contribuyen al éxito de la implementación, más conocidos como los factores críticos de éxito en la implementación de sistemas ERP (Sumner, 1999; Umble, Haft y Umble, 2003; Hong y Kim, 2002). No obstante, en los países menos desarrollados es poca la investigación realizada sobre el tópico de implementación de sistemas ERP. A continuación se presenta una lista de preguntas que han publicado algunas casas consultoras como Software Sin Fronteras (2015), y que pueden guiar a las empresas para determinar si realmente requieren implementar un ERP, observe la figura 2.

Es necesario un ERP si…

1. Surgen necesidades de gestión administrativa y de información que no cubre el programa actual.

2. Se realizan tareas o procesos de forma poco racional y con mucho trabajo.

3. Se quieren mejorar los sistemas de trabajo, los procesos existentes en la actualidad y los flujos intermedios de datos.

4. Se quiere actuar de forma más global, en más ubicaciones y con distintas actividades.

5. El hardware de la empresa está anticuado en prestaciones.

6. El sector, el tipo de actividad y la competencia hacen que surja la necesidad de instalar un nuevo sistema de gestión más eficaz.

7. Se necesita gestionar y estructurar mejor el conocimiento del negocio y aumentar la independencia empresa-empleado.

8. Se dispone de un programa desfasado en prestaciones.

9. Los usuarios del sistema deben entrar la misma información varias veces en distintos puntos del sistema.

10. Los usuarios usan software online, hojas de cálculo o pequeñas aplicaciones de bases de datos para hacer su trabajo o mantener información que necesitan para desempeñarlo.

11. Se necesita mucho tiempo para analizar los datos de la empresa puesto que están muy repartidos y resulta difícil unirlos y sacar conclusiones de ellos.


IPN UPIICSA 6

12. Se tienen problemas de gestión de inventario, no sabes lo que tienes en el inventario y lo que cuesta.

13. Hay quejas crecientes de los trabajadores respecto a que no pueden trabajar lo rápido que querrían por culpa del sistema.

14. Cada vez es más difícil cumplir con los requerimientos que se nos piden de formato y tiempos de entrega cuando se nos pide cierta información tanto por parte de los clientes como de los proveedores.

15. No se está sacando el suficiente provecho de internet.

16. Hemos pensado o descrito las actuales virtudes y deficiencias de nuestro actual sistema, y las deficiencias son importantes como para afectar significativamente al rendimiento global de la empresa.

17. La empresa no podría funcionar sin la presencia del gerente.

18. Si un comercial deja la empresa se perdería negocio.

19. Nos da la sensación de no poder controlar la empresa, ya que no se conocen todos los detalles del negocio o no se conocen todos los productos que se venden y sus precios.

20. Existen oportunidades de negocio que mi empresa querría abordar pero el sistema actual no podría abarcar las nuevas actividades.

21. Necesito que algunos clientes tengan una entrada a mi sistema y actualmente no la tienen.

22. No se conoce qué productos o servicios del negocio dan más rentabilidad económica.

23. Se utiliza un alto porcentaje de las funcionalidades del sistema actual, y no existe posibilidad de ampliarlas ante los nuevos requerimientos que van surgiendo en la empresa (sistema poco escalable).

Figura 2. Cuestiones sobre la necesidad de un sistema ERP.

Algunos estudios demuestran que la mayoría de las organizaciones no han

alcanzado plenamente los beneficios esperados de los sistemas ERP, remarcando

que: a) más del 40% de los grandes proyectos de software no terminan con éxito,

b) 90% de las implementaciones de sistemas ERP terminan por encima del costo

presupuestado originalmente, c) la continua falta de personal y la rotación durante

un proyecto de implementación de sistema ERP provoca un aumento en los

costos del proyecto de implementación del ERP; d) la continua proliferación de

empresas implementadoras de sistemas ERP han llevado a un aumento de

métodos, técnicas y herramientas que provocan dificultades en la implementación,

y e) 67% de las iniciativas de aplicaciones ERP pueden ser consideradas como

contraproducentes o sin éxito (Davenport T.H., 1998).


IPN UPIICSA 7

Estudios más recientes como se muestra en la gráfica 3, indican que las

estadísticas de la industria del software según el Standish Group, CHAOS, 2001

revelan que el 28% de los proyectos son exitosos contra un 72% que fracasan.

Gráfica 3. Porcentaje de proyectos exitosos (Standish Group, 2001).

Otros números interesantes son que el costo real de un proyecto casi se triplica

con respecto a lo estimado en un inicio, es decir, el promedio del costo

sobrepasado es de 190% (Standish Group, 2001). El tiempo de retraso promedio

es de 222%, es decir, los proyectos se retrasan por más del doble de lo estimado.

El promedio de fallas según las expectativas iniciales es de 61%. Más de la mitad

de las fallas tienen que ver con las perspectivas iniciales del proyecto.

Asimismo, el estudio demuestra que los factores que conllevan a errores

relacionados con los requerimientos son principalmente (Standish Group, 2001):

una escasa participación del usuario en el proyecto, objetivos no claros desde un

principio, requerimientos y especificaciones incompletas, cambios en los

requerimientos y especificaciones, falta de planeación y gestión del riesgo.

Después, en otro estudio de CHAOS de The Standish Group en el año 2006,

revela que en todos los sectores sólo el 35% de las implementaciones de software

se consideran finalizadas con éxito, el 19% se considera un fracaso y el 46% son

cuestionables. El 65% de los proyectos no terminan con éxito porque, los costos

Proyectos exitosos

28%

Proyectos que

fracasan 72%


IPN UPIICSA 8

sobrepasan el presupuesto, se requiere más tiempo del planificado o la

funcionalidad no es la esperada (Standish Group, 2006).

Otros investigadores sostienen que el proceso de implementación del ERP

compromete las operaciones normales del negocio y los recursos disponibles, por

tanto, el tiempo de implementación es un factor crítico a considerar. Otros estudios

indican que los resultados son variados y en algunos casos desalentadores. Estos

autores citan un estudio que indica que el 35% de las implementaciones de los

sistemas ERP han sido canceladas, 55% han incurrido en excesos de tiempo y

solo el 10% han sido completadas dentro del tiempo previsto (Bajwa, Garcia, &

Mooney, 2004).

“Un inadecuado o insuficiente análisis de requerimientos da inicio a un proyecto

con el pie izquierdo” (Schwalbe, 2000).

“El costo de agregar o corregir requerimientos una vez entregado un sistema es

aproximadamente 100 veces más que hacerlo durante la definición inicial del

sistema” (Gruia-Catalin, 2015).

“The Roman bridges of antiquity were very inefficient structures. By modern

standards, they used too much stone, and as a result, far too much labour to build.

Over the years we have learned to build bridges more efficiently, using fewer

materials and less labour to perform the same task” (Clancy, 1991).


IPN UPIICSA 9

1.3 Demarcación del fenómeno

Una de las principales causas detectadas de las fallas de las implementaciones de los sistemas ERP, es la relativa invisibilidad del proceso de implementación (Griffith, Zammuto y Aiman-Smith, 1999). Markus y Robey (1988) atribuyeron la invisibilidad a la impredecible compleja interacción social de las TI y las organizaciones. El reto fundamental de una implementación de un sistema ERP es la adaptación mutua entre la TI y el entorno del usuario (Volkoff, 1999). Al proceso de adaptación se le conoce como alineación, la adaptación mutua trae procesos operativos existentes en la organización y funcionalidad embebida del software empaquetado, logrados a través de una combinación en la configuración del software y el cambio organizacional (Volkoff, 1999). En cuanto a las adaptaciones, se tienen diferentes ángulos de observación, adaptación paquete o la adaptación de la organización, es más deseable en los diferentes contextos. En la figura 4 se trata de dar al lector una panorámica de lo que se lleva a cabo cuando se implementa un sistema ERP en una organización, de manera general se lleva a cabo un proceso de alineación entre las áreas y las funciones de cada integrante de una organización con los módulos y procesos del sistema ERP.

Figura 4. Alineación de un sistema a los procesos de una organización (Elaboración propia).


IPN UPIICSA 10

La implementación de un sistema ERP es una tarea ardua y costosa (Akkermans y Van Helden, 2002) que requiere de un amplio esfuerzo y compromiso en todos los niveles de la organización. Los problemas que confrontan las organizaciones para su implementación exitosa han sido ampliamente difundidos en la literatura, por ejemplo ver a (Esteves y Pastor, 2001).

Los ERP son sistemas de información que interconectan e integran la información

derivada de todas las funciones de todas las áreas de la empresa, sirviendo a

todos los departamentos y dando como consecuencia información estratégica y

táctica a la empresa dándole la capacidad para planear y administrar sus recursos

con un enfoque integral. (Turban, Mclean y Wetherbe, 2003; Zhang, Lee y

Banerjee, 2002).

Los sistemas empresariales parecen ser un sueño hecho realidad. Los paquetes

de software disponibles en el mercado prometen cabal integración de los flujos de

información en la empresa, la información financiera y contable, información de

recursos humanos, información sobre la cadena de suministro, y la información del

cliente.


IPN UPIICSA 11

1.4 Planteamiento del problema

El desconocimiento de lo que se va a implementar, el cómo se va a implementar y

la mala o nula documentación de los requerimientos en las organizaciones

(cliente), derivan en una implementación de un sistema ERP en PYMES de la

Zona Metropolitana del Valle de México no exitosa.

Problemática especifica

Se plantea a través de una pregunta que se tendrá que resolver en este estudio,

¿es necesario contar con ciertos elementos mínimos para que se logre llevar a

cabo una implementación de un sistema ERP en PYMES de la Zona Metropolitana

del Valle de México de forma exitosa o es suficiente con contratar a un proveedor

con buenas referencias para dicho fin?.

La figura 5 muestra un ejemplo gráfico de cómo se puede llegar a distorsionar la

comunicación entre un cliente y un proveedor desde un inicio, cuando se hace

incorrectamente un requerimiento y si no se tienen los elementos para darle

seguimiento, al final podemos obtener un resultado no esperado.

Figura 5. Caricatura de un proceso de requerimiento (Intelligenia, 2013).


IPN UPIICSA 12

1.5 Objetivos del estudio

General

Investigar si es necesario contar con ciertos elementos mínimos para que se logre

llevar a cabo una implementación de un sistema ERP en PYMES de la Zona

Metropolitana del Valle de México de forma exitosa o es suficiente con contratar a

un proveedor con buenas referencias para dicho fin.

Particulares

1. Concientizar e involucrar más a las organizaciones para que se preparen

para la implementación de un sistema ERP, logren llevar a cabo una

negociación justa y asegurar que el alcance sea el esperado.

2. Proporcionar documentación que las organizaciones que puedan acceder

para consultar los aspectos que deben considerar previo a la

implementación de un sistema ERP, para que sea exitosa y se pueda tener

certidumbre en todo momento del estatus del proyecto.

Personales

1. Aportar información importante a la sociedad y que esté al alcance de

todos.

2. Entender y mejorar mi entorno en todos los aspectos.

3. Desarrollo personal.


IPN UPIICSA 13

2 GENERALIDADES Y METODOLOGÍAS DE IMPLEMENTACIÓN DE LOS

SISTEMAS ERP EN PYMES

El ambiente de negocios es dramáticamente cambiante. Las empresas hoy en día

se enfrentan al reto de aumento de la competencia, la expansión de los mercados,

y el aumento de las expectativas de los clientes. Esto a su vez aumenta la presión

sobre las empresas para reducir los precios y por ende reducir los costos totales

de toda la cadena de suministro, acortar los tiempos de rendimiento, reducir

drásticamente los inventarios, ampliar su portafolio de productos, proporcionar

fechas de entrega más fiables, mejor servicio al cliente, mejorar la calidad y

eficiencia, coordinar la demanda global, el de suministro y producción

(Shankarnarayanan, 2000).

A medida que el mundo de los negocios se mueve, cada vez es más necesario

acercarnos a una implementación de un sistema de información integral ya que los

competidores también trabajan en mejorar sus capacidades para seguir siendo

competitivos, las organizaciones deben mejorar sus propias prácticas de negocio y

procedimientos. Las empresas también deben compartir cada vez más con sus

proveedores, distribuidores y clientes la información crítica de la empresa para

protegerse y ser competitivos (Loizos, 1998).

2.1 Clasificación de las organizaciones

Los criterios para clasificar a la micro, pequeña y mediana empresa son diferentes

en cada país y en cada organismo, dependiendo de lo que se quiere estudiar o

analizar, de manera tradicional se ha utilizado el número de trabajadores como

criterio para estratificar los establecimientos por tamaño y como criterios

complementarios se tienen el total de ventas anuales, los ingresos y/o los activos

fijos.

De acuerdo a los censos del INEGI del 2009, la clasificación que se le da a las

empresas es, “la Microindustria.- que son las empresas que ocuparan hasta 15

personas y el valor de sus ventas netas fuera hasta 30 millones de pesos al año.

Industria Pequeña.- que son las empresas que ocupan hasta 100 personas y sus

ventas netas no rebasan la cantidad de 400 millones de pesos al año y la Industria

Mediana.- que son las empresas que ocuparan hasta 250 personas y el valor de


IPN UPIICSA 14

sus ventas no rebasara la cantidad de mil 100 millones de pesos al año” (INEGI,

2009).

“Desde entonces, el marco normativo y regulatorio de las actividades económicas

de las: micro, pequeñas y medianas empresas lo ha establecido la Secretaría de

Economía (antes SECOFI). A partir de 1990 existen seis pronunciamientos acerca

de los criterios para la definición de las micro, pequeñas y medianas empresas,

realizados los primeros cuatro de ellos por la entonces Secretaría de Comercio y

Fomento Industrial, y los últimos dos, por la actual Secretaría de Economía”

(INEGI, 2009).

Como se observa en la figura 6, INEGI maneja varias clasificaciones para las

empresas, que van desde personal, ventas o combinadas inclusive contra el tipo

de industria. En cuanto a las ventas se representan en una aproximación en

salarios mínimos.


IPN UPIICSA 15

Figura 6. Clasificación de las empresas (INEGI, 2009).

2.2 Sistemas de Planificación de Recursos Empresariales (ERP)

Las funciones dentro de la empresa deben actualizar su capacidad de generar y

comunicarse oportunamente y contar con información más precisa. Para lograr

estos objetivos, las empresas están recurriendo cada vez más a la planificación de

recursos empresariales con un sistema ERP (Allen, 1997).

Los sistemas ERP proporcionan dos ventajas importantes que no lo hacen los

sistemas no integrados departamentales: una visión empresarial unificada del

negocio que abarca todas las funciones y departamentos (Angerosa, 1999)

además de una base de datos de la empresa, donde todas las transacciones

comerciales se introducen, registran, procesan, supervisan y reportan. Esta visión

unificada aumenta el requisito para un alcance interdepartamental, dando control y

coordinación. Los sistemas ERP permiten a las empresas alcanzar sus objetivos,

aumentando la comunicación y la capacidad de respuesta a todos los interesados

(Dillon, 1999).


IPN UPIICSA 16

2.2.1 Definiciones generales de los sistemas ERP

Los sistemas ERP están definidos como los sistemas que ayudan a integrar toda

la información y todos los procesos administrativos de las empresas, además de lo

anterior también proveen la capacidad para planear y administrar sus recursos con

un enfoque integral (Turban, McLean y Wetherbe, 2003). Un número importante

de autores en el ramo de Sistemas de Información (SI) han investigado y/o escrito

acerca de los sistemas ERP remarcando su importante característica de integrar

información, departamentos, funciones y procesos a lo largo de la empresa

(Zhang, Lee, & Banerjee, 2002).

En cuanto a los módulos que abarca un sistema ERP se pueden mencionar de

manera general los del segmento de finanzas que abarcan las áreas de:

contabilidad, bancos, cuentas por cobrar, cuentas por pagar, principalmente,

presupuestos. En cuanto a los módulos del segmento de distribución incluyen las

áreas de: ventas, compras, inventarios, etc. Para los módulos del segmento de

producción consideran las áreas de: administración de listas de materiales,

registro de producción, mrp, entre otros, como se muestra en la figura 7.

Figura 7. Áreas de los sistemas ERP (Elaboración propia).


IPN UPIICSA 17

Otros módulos que incluyen algunos sistemas ERP en la actualidad son los del

segmento de Proyectos que contienen las áreas de: administración de proyectos,

presupuestos de proyectos, etc. Para los módulos del segmento de Servicios dan

a las áreas soporte de: contratos de mantenimientos, equipos, registro de

mantenimientos, etc. Por último y por mencionar solo algunos adicionales, los

módulos del segmento de Recursos Humanos abarcan las áreas de: planeación

de recursos humanos, capacitación y desarrollo, administración de la

compensación, relaciones laborales, higiene y seguridad, etc.

A continuación se muestra una tabla con algunas definiciones de sistemas ERP y

sus componentes:

Autores Definición Componentes

(Davenport y Harris, 2007)

“Un sistema ERP es un paquete de software comercial que promete la integración ‘sin costuras’ de toda la información que fluye a través de la compañía: información financiera y contable, información de recursos humanos, información de la cadena de suministro e información de clientes”

Paquete de software.

Intergral.

Módulos financieros, recursos humanos, cadena de suministro.

(Holland y Light, 1999)

“El sistema ERP automatiza las actividades corporativas nucleares – tales como, manufactura, recursos humanos, finanzas y gestión de la cadena de abastecimiento – incorporando las mejores prácticas para la rápida toma de decisiones, las reducciones de costos y el mayor control directivo”.

Automatización de actividades nucleares.

Mejores prácticas.

(Esteves y Pastor, 2001)

“Los sistemas ERP están compuestos de varios módulos – tales como, recursos humanos, ventas, finanzas y producción – que posibilitan la integración de datos a través de procesos de negocios incrustados. Estos paquetes de software pueden ser configurados para responder a las específicas necesidades de cada organización. Estos sistemas proporcionan modelos de referencia o las plantillas de proceso que afirman incorporar las mejores prácticas actuales para apoyar a los procesos de negocio de la organización”.

Modularidad.

Integración.

Configurables.

Mejores prácticas.

Plantillas predefinidas de procesos.

Kumar y Hillergersberg, 2000.

“Los sistemas ERP son paquetes de sistemas de información configurables que integran información y procesos basados en información, dentro y entre las áreas funcionales de una organización”.

Paquetes de sistemas.

Configurables.

Integrales.


IPN UPIICSA 18

Markus y Tanis, 2000.

“Un sistema es un paquete de software comercial que posibilita la integración de datos transaccionales y de los procesos de negocio a través de una organización”. “Basándose en sistemas financieros y de manufactura los ERP pueden, eventualmente, permitir la integración de las cadenas de suministros entre organizaciones”.

Paquete de software comercial.

Integración.

Módulos financieros, producción y cadena de suministro.

Parr y Shanks, 2000b.

“Los sistemas ERP son extensas soluciones empaquetadas de software que integran los procesos de la organización a través de información compartida y flujos de datos.” “El software ERP integra información y procesos de gestión, tales como las finanzas, manufactura, distribución y los recursos humanos, con el fin de permitir la gestión integral de recursos en una empresa”.


Integración.

Módulos de finanzas, manufactura, distribución y recursos humanos.

Lee y Lee, 2000.

“Un ERP es una paquete de software integrado de uso empresarial”. “En el ERP todas las funciones necesarias del negocio, tales como finanzas, manufactura, recursos humanos, distribución y órdenes, se integran firmemente en un solo sistema con una base de datos compartida”


Integración.

Módulos de finanzas, manufactura, recursos humanos, distribución y órdenes.

Base de datos compartida.

O'Leary, 2000. “Los sistemas ERP son sistemas basados en computadores diseñados para procesar las transacciones de una organización y facilitar la integración en tiempo real de la planificación, producción, y respuesta al cliente”.

Sistemas transaccionales.

Módulos de planificación, producción y crm.

Sieber, 1999. “Un ERP es un sistema de software empaquetado de negocios que permite a una compañía manejar el uso eficiente y eficaz de los recursos (materiales, humanos, financieros, etc.), proporcionando una total e integrada solución para las necesidades de procesamiento de información de la organización”.


Integración.

Módulos de inventarios, recursos humanos y financieros.


IPN UPIICSA 19

2.2.2 Características de los sistemas ERP

Las principales características de un sistema ERP que generalmente promueven

proveedores como SAP y Microsoft entre otros, son muy variadas pero

comúnmente tienen coincidencias como son, una base de datos centralizada,

ingreso de datos unificados, sistema modular, adaptable y configurables.

Base de datos centralizada: todo el sistema comparte una única base de datos

en la que se almacena toda la información de la empresa (Microsoft, 2015).

Ingresos de datos unificado: la información se introduce una sola vez en el

sistema, y de forma completa (se introducen todos los datos necesarios), para que

de esta forma quede disponible para el resto de la organización (Microsoft, 2015).

Sistema modular: Por lo general los ERP están compuestos de diferentes

módulos (facturación, contabilidad, recursos humanos, ventas, etc.) que

interactúan entre sí, permitiendo el flujo de información entre ellos (Microsoft,

2015).

Son adaptables: Debido a la complejidad de las empresas debemos considerar a

un ERP como el punto de partida aplicando las modificaciones, personalización

que sean necesarias para reflejar las necesidades reales de la empresa

(Microsoft, 2015).


IPN UPIICSA 20

En la figura 8 se muestran algunos módulos con los que cuentan algunos de los

ERP que existen en el mercado, algunas ocasiones se les ponen nombre de área

y algunas otras de algún proceso especifico contable con el caso de Activos Fijos

y Tesorería por mencionar algunos.

ERP

Cu

en

tas p

or

co

bra

r

Cu

en

tas p

or

pag

ar

Co

sto

de r

ecurs

os

Co

sto

de a

ctivid

ad

es

Co

nta

bili

dad

ge

nera

l

Teso

rerí

a

Activo

s fijo

s

An

ális

is f

inan

cie

ro

Pro

yecto

s

CADI 2007 Si Si No No Si Si Si Si Si

I-ERP2 Si Si Si Si Si Si Si Si Si

JD Edwards Si Si Si Si Si Si Si Si Si

Mapics Si Si Si Si Si Si Si Si Si

Microsoft Dynamics Si Si Si No Si Si Si Si Si

Mincom Ellipse Si Si Si Si Si Si Si Si No

MSAP ERP Si Si Si Si Si Si Si Si Si

Oracle E-bussines Si Si Si Si Si Si Si Si No

Sofinsa Xsylon Si Si Si Si Si Si Si Si Si

Vector Si Si Si Si Si Si No Si Si

Figura 8. Sistemas ERP en el Mercado.


IPN UPIICSA 21

Actualmente se cuenta en el mercado con una gran variedad de productos aunque

algunos tienen cierta especialización en algunos sectores de la industria. En la figura 9 se

listan algunos de los más utilizados y conocidos.

MySQL Oracle Corporation

Advantage Database

dBase: DataBased Intelligence, Inc. (dBI)

FileMaker: FileMaker Inc. (subsidiaria de Apple Inc.)

gsBase

IBM DB2

IBM Informix

Interbase de CodeGear

MAGIC eDeveloper

Microsoft Access

Microsoft SQL Server

NexusDB

Open Access

Oracle Oracle Corporation

Paradox

PervasiveSQL.

Progress (DBMS)

Sybase ASE

Sybase ASA

Sybase IQ

WindowBase

IBM IMS (Information Management System)

CA-IDMS

Figura 9. Gestores de bases de datos en el mercado (Elaboración propia).

Algunas de las metodologías y herramientas más utilizadas para la

implementación de un sistema ERP son el calendario para la implementación de

un proyecto (ACE, 2015), la metodología del PMI (PMI, 2015), la Ingeniería de

Requerimientos (IEEE, 1984) y algunas otras orientadas a productos específicos

en el mercado como las de Microsoft y SAP entre otras.

Podemos decir que de acuerdo a las fases mencionadas, la implementación de un

sistema ERP implica un cambio en los procesos de la empresa; además un


IPN UPIICSA 22

cambio organizacional, lo cual da como resultado una nueva forma de hacer

negocios y de trabajar en conjunto (Laudon & Laudon, 1996).

2.2.3 Flujo estándar de un ERP

Con base a las definiciones aportadas por la literatura, un sistema ERP es un

conjunto de módulos o programas entrelazados que concentran su información de

un solo punto (base de datos) y que al estar interrelacionados permiten que la

información de todas las áreas este estandarizada y sincronizada, de tal forma que

se pueda visualizar la información desde los diferentes departamentos y se

procese para que cada área cumpla con su parte dentro de la organización. Dando

como resultado movimientos contables para su procesamiento en la obtención de

información financiera.

Figura 10. Proceso de un ERP (Elaboración propia).

En la figura 10 se observa el flujo de información a través de las flechas que

interconectan a los módulos, la cual indica la dirección en que se envía la


IPN UPIICSA 23

información hacia los diferentes módulos que a su vez se estarán observando

desde las diferentes áreas de la empresa.

A manera de ejemplo y observando la figura 10 en el módulo de ventas se

registran pedidos que se vuelven facturas, que a su vez pasan como un

documento por cobrar al módulo de cuentas por cobrar, que al mismo tiempo lleva

a cabo una salida en Inventarios, estos dos últimos proporcionan al módulo de

contabilidad una póliza contable, cumpliendo así uno de los ciclos del ERP. Una

vez que llega la información al módulo de contabilidad se podrán crear informes

financieros que podrán dar la posición financiera de la empresa. Obviamente

concentrando la información de las diferentes transacciones de los diferentes

módulos generados desde las diferentes áreas.

Cabe señalar que lo anterior es ejecutado por personal de diferentes áreas de la

empresa.

2.3 Metodologías utilizadas para la implementación de sistemas ERP

El SDLC o ciclo de vida del desarrollo de sistemas (por sus siglas en inglés,

System Development Life Cicle), es de las principales metodologías utilizadas,

formalizadas y documentadas, véase figura 11. Esta metodología guiaba a los

desarrolladores en cada una de las fases, el SDLC constaba de los siguientes

pasos (Oz, 2008):

- Planeación

- Análisis

- Diseño

- Implementación

- Soporte

En estricta teoría no se puede pasar al siguiente paso si no se ha concluido el

anterior. En cuanto a la fase de análisis de sistemas es un proceso de cinco pasos

que son: investigación, estudio de factibilidad técnica, estudio de factibilidad

económica, estudio de factibilidad operativa, definición de requerimientos, así

como algunos temas más específicos que se tengan que analizar detalladamente.

En cuanto al paso de investigación, se debe definir el proceso empresarial al que

el sistema va a dar soporte, además de si lleva o no de la mano alguna


IPN UPIICSA 24

oportunidad empresarial la cual se quiera que aproveche el sistema, otro tema

importante es la definición de qué problemas se quieren resolver o cuál directiva

debe satisfacer.

En el estudio de factibilidad técnica se debe analizar si existe la tecnología para

crear el sistema que se requiere o si existe algo ya desarrollado en el mercado,

este último por lo regular es lo más conveniente para no desarrollar un sistema

desde cero, evitando tener que atravesar por toda una serie de pruebas y ajustes

al sistema, sin olvidar el tiempo que se tendría que invertir a este proceso.

El estudio de factibilidad económica sirve para determinar los recursos que se

necesitan para implementar el sistema, así como saber si los beneficios del

sistema sobrepasan sus costos.

Estudio de factibilidad operativa está enfocado a si el sistema será utilizado en

forma adecuada por los usuarios a quienes está dirigido (empleados, clientes,

proveedores), así también si el sistema a emplear será manejado a toda su

capacidad.

En la definición de los requerimientos, se debe acotar qué características se

pretende que tenga el sistema y si tendrá comunicación con otros sistemas

(interfaces).

Algunas preguntas más específicas que también se pueden observar en esta fase

son si el sistema se adaptará a la cultura de esta organización y si interferirá con

las políticas de la empresa o las leyes vigentes y próximas.


IPN UPIICSA 25

Figura 11. El ciclo de vida del desarrollo de sistemas (Oz, 2008).

En la actualidad existen diversas metodologías, algunas enfocadas a proyectos en

general, otras enfocadas a productos específicos, pero en lo que coinciden

muchos autores es que no importa la metodología que se use pero que se utilice

una, esto disminuirá en alguna medida los riesgos durante la ejecución del

proyecto.

De acuerdo a las características de un sistema ERP y de las expectativas que

tienen los usuarios finales para cubrir las necesidades de la empresa, el proceso

de implementación es complejo y conlleva un riesgo, este último puede ir desde un

costo en tiempo o dinero, hasta colapsar la empresa a nivel financieramente. En

general los administradores no cuentan con guías que los puedan ayudar a

conducir de manera eficiente el proceso de implementación de un sistema ERP, ni

para garantizar la implementación con un buen nivel de probabilidad de éxito, este

último basado en que proporcione los beneficios esperados. En las últimas

décadas diferentes autores han estudiado la importancia y complejidad de la

implementación de un sistema ERP (Deleon y Mclean, 1992; Markus y Tanis,

2000; (Klaus, Rosemann y Gable, 2000; Somers y Nelson, 2001; Zhang, Lee y

Banerjee, 2002; Onur y Eray , 2003), con la finalidad de explicar el involucramiento


IPN UPIICSA 26

de la organización donde se va a implementar el sistema y no participar solo como

espectador.

La mayoría de las metodologías tienen cierta semejanza con la Metodología del

PMI del PMBook (Project Manager Institute con el estándar ANSI, Instituto

Nacional Estadounidense de Estándares).

Es recomendable que la metodología a utilizar la conozcan tanto el cliente como el

proveedor, para que de común acuerdo sepan cuáles serán los pasos del proceso

de implementación, los entregables de cada fase, así como los controles.

2.3.1 Metodología de PMI (Project Management Institute, guía del PMBok)

Las organizaciones realizan trabajos con el fin de lograr un conjunto de objetivos.

Por lo general, los trabajos se clasifican en proyectos y operaciones, aunque en

algunos casos estos se superponen. Algunas de las características de los

proyectos son que pueden ser realizados por personas, los recursos son limitados,

así como su fecha de ejecución, además de que pueden ser planificados,

ejecutados y controlados (PMI, 2015).

Los proyectos y las operaciones difieren primordialmente en que las operaciones

son continuas y repetitivas, mientras que los proyectos son temporales y únicos

(PMI, 2015).

Los objetivos de los proyectos y las operaciones son fundamentalmente

diferentes. La finalidad de un proyecto es alcanzar su objetivo y luego concluirlo

con una solución. Por el contrario, el objetivo de una operación continua es dar

respaldo al negocio en todo momento.

Los proyectos son diferentes porque el proyecto concluye cuando se alcanzan sus

objetivos específicos, mientras que las operaciones adoptan un nuevo conjunto de

objetivos y el trabajo continúa (PMI, 2015).

Los proyectos se llevan a cabo en todos los niveles de la organización y pueden

involucrar a una sola persona o a varios miles. Pueden durar entre unas pocas

semanas y varios años. Los proyectos pueden incluir una o varias unidades

organizativas, como por ejemplo las asociaciones transitorias y los convenios para

un proyecto determinado. Entre los ejemplos de proyectos se incluyen, entre otros,


IPN UPIICSA 27

desarrollar un nuevo producto o servicio, efectuar un cambio en la estructura, en el

personal o en el estilo de una organización, diseñar un nuevo vehículo de

transporte, desarrollar o adquirir un sistema de información nuevo o modificado,

construir un edificio o una planta, construir un sistema de abastecimiento de agua

para una comunidad, realizar una campaña para un partido político, implementar

un nuevo procedimiento o proceso de negocio, responder a una solicitud de

contrato (PMI, 2015).

Los proyectos pueden llegar a ser de muy distinta índole es por eso que el director

de proyectos debe tener cierta especialización y conocimiento del tipo de proyecto,

principalmente para que pueda tener una visión de los riesgos que se podrían

presentar y como evitarlos o mitigarlos.

La dirección de proyectos es la aplicación de conocimientos, habilidades,

herramientas y técnicas a las actividades de un proyecto para satisfacer los

requisitos del proyecto. La dirección de proyectos se logra mediante la aplicación e

integración de los procesos de dirección de proyectos de inicio, planificación,

ejecución, seguimiento y control, y cierre. El director del proyecto es la persona

responsable de alcanzar los objetivos del proyecto (PMI, 2015).

Aunque la persona responsable del proyecto es el director, existe una

corresponsabilidad entre el proveedor y el cliente. Una de las principales funciones

es avisar a todos los involucrados y en especial a los dueños del proyecto del

cumplimiento o no de los objetivos del proyecto.

La dirección de un proyecto incluye, identificar los requisitos, establecer unos

objetivos claros y posibles de realizar, equilibrar las demandas concurrentes de

calidad, alcance, tiempo y costos, así como adaptar las especificaciones, los

planes y el enfoque a las diversas inquietudes y expectativas de los diferentes

interesados (PMI, 2015).

El director es quien debe dar un panorama del avance, posibles retrasos

necesarios o inminentes, e inclusive si es necesario debe proponer detener el

proyecto por conveniencia del proyecto.

Los directores del proyecto a menudo hablan de una “triple restricción” —alcance,

tiempos y costos del proyecto— a la hora de gestionar los requisitos concurrentes

de un proyecto. La calidad del proyecto se ve afectada por el equilibrio de estos

tres factores. Los proyectos de alta calidad entregan el producto, servicio o

resultado requerido con el alcance solicitado, puntualmente y dentro del


IPN UPIICSA 28

presupuesto. La relación entre estos tres factores es tal que si cambia cualquiera

de ellos, se ve afectado por lo menos otro de los factores. Los directores de

proyectos también gestionan los proyectos en respuesta a la incertidumbre. El

riesgo de un proyecto es un evento o condición inciertos que, si ocurre, tiene un

efecto positivo o negativo al menos en uno de los objetivos de dicho proyecto

(PMI, 2015).

En la figura 12 se mencionan las etapas de la gestión de proyectos de acuerdo al

Project Management Institute, así como las tareas y entregables en cada una de

ellas.

Figura 12. Etapas de la gestión de proyectos (PMI, 2015).


IPN UPIICSA 29

2.3.2 Metodología AIP de SAP

La metodología AIP de SAP para la implementación de SAP Business One está

diseñada para llevar a cabo una implementación en alrededor de 50 días,

obviamente pensando en una implementación del sistema directo de caja, es

decir, sin hacer ninguna modificación al sistema, condicionando al cliente a que se

apegue a la funcionalidad que el sistema ofrece.

El tiempo estimado no incluye adaptaciones al sistema pero si garantiza una

rápida implementación apegada según el proveedor a las mejores prácticas de

negocio. En la figura 13 se muestra una gráfica de tiempo de ejecución de cada

una de las etapas de implementación que propone la metodología AIP de SAP.

Figura 13. Ciclo de Implementación de SAP Business One (SAP Partner Edge, 2015).

Es posible instalar e implementar SAP Business One rápida y fácilmente con el

"Programa de Implementación Acelerada de SAP Business" (AIP), dicha

metodología es aplicada y creada por SAP. Ha sido diseñada para servir como

una guía para la configuración del sistema y proceso de implementación. Incluye


IPN UPIICSA 30

un conjunto de plantillas, listas de control, herramientas y otra información de

apoyo que dividen el proceso de implementación en cinco fases. Cada fase cuenta

con tareas específicas que tienen que ser completadas y sugiere roles de cada

participante, responsabilidades y plazos necesarios para completar con éxito la

implementación.

Una de los elementos con los que la literatura sugiere contar para una

implementación de un sistema es, un documento detallado del alcance del

proyecto para posibilitar la finalización clara y oportuna del proyecto. El alcance

inicial del proyecto de implementación de SAP Business One basado en la

metodología de SAP Business One incluye funciones de transacciones y datos

centrales necesarios para las operaciones empresariales.

Después de la entrada en productivo, posiblemente habrá que implementar

características y funciones adicionales como consecuencia del análisis detallado

de los requisitos, esto depende del acuerdo al que hayan llegado el cliente y el

proveedor. En la figura 14 se muestran los hitos que se deben cubrir en cada fase

de la metodología AIP para la implementación de SAP Business One.

Figura 14. Metodología AIP para la implementación de SAP Business One (SAP Partner Edge, 2015).


IPN UPIICSA 31

A continuación se describe cada una de las actividades:

2.3.2.1 Preparación del proyecto

El propósito de esta fase es proporcionar la planificación y preparación inicial para

el proyecto de implementación de SAP Business One. Aunque cada proyecto tiene

sus propios objetivos únicos, el alcance y sus respectivas prioridades; los pasos

de la fase de preparación ayudan a identificar y planificar las áreas principales en

las que deben tener especial atención. Esto incluye cuestiones técnicas, así como

los temas de gestión de proyectos. Además, el software de SAP Business One se

entrega durante esta fase y se lleva a cabo una instalación de prueba.

2.3.2.2 Anteproyecto empresarial

El propósito de esta fase es alcanzar un entendimiento común de cómo el cliente

tiene la intención de ejecutar SAP Business One para apoyar su negocio. Se

llevan a cabo uno o más talleres de recopilación de requisitos durante los cuales

se definen y analizan los procesos de negocio y los requisitos funcionales

individuales del cliente. Además, los talleres sirven para refinar las metas y

objetivos del proyecto original, así como para revisar el cronograma general del

proyecto, si es necesario. El resultado es el Plan de Negocios, que es una

documentación detallada de los resultados obtenidos durante los talleres de

estudio de los requisitos. El Plan de Negocios es una guía técnica y funcional

durante las fases posteriores del proyecto Una aplicación SAP Business.

2.3.2.3 Realización del proyecto

Esta fase representa la más significativa de las fases de la implementación. El

propósito de la realización del proyecto es implementar todos los procesos de

negocio y los requisitos técnicos definidos durante las fases previas y

documentados en el plan de negocios. Durante esta fase, los consultores validan y

actualizan la configuración, y demuestran los procesos en el sistema mientras el

cliente actualiza sus procedimientos de procesos de negocio y lleva a cabo las

pruebas de integración.

2.3.2.4 Preparación final

El propósito de esta fase es preparar el sistema SAP Business One y la

organización del cliente para la puesta en marcha “Go–live”. Las actividades clave


IPN UPIICSA 32

durante esta fase incluyen la formación del administrador y usuarios finales, así

como los últimos ajustes del sistema SAP Business One. Como parte de las

pruebas finales del sistema, se realizan los ajustes necesarios para resolver todas

las cuestiones críticas que hayan quedado pendientes.

2.3.2.5 Puesta en marcha y soporte

Completar esta fase es el objetivo final y la etapa más emocionante del proceso de

implementación. Es cuando se pone en marcha el software SAP Business One en

la empresa y éste empieza a gestionar todas las actividades diarias de forma

independiente. La fase puesta en marcha y soporte consta de dos sub-fases

distintas. El primero se completa con un "Cierre del Proyecto" formal. Durante este

tiempo, el sistema es utilizado productivamente en las operaciones del día a día,

todas las cuestiones y los problemas se resuelven. En esta se lleva a cabo la

transición al equipo de soporte, la transferencia de conocimiento ha completado, y

el proyecto debe ser cerrado formalmente. Posteriormente, la fase de "Mejora

Continua" comienza durante el cual el equipo de apoyo a la producción monitoriza

el sistema y resuelve los problemas de procesos de negocio al momento.

Se establecen procedimientos de gestión de cambios adecuados y se realiza la

formación continua de los usuarios finales. Los planes se efectúan teniendo en

cuenta la revisión continua y la mejora de los procesos empresariales. Se

programa y se lleva a cabo la reunión de revisión y optimización.

SAP provee para la metodología AIP, un conjunto de archivos en formatos de

Office que se debe ir llenando para cumplir los entregables de cada fase, de

manera que va guiando al consultor con la información que debe ir recopilando y

documentando a cada paso (SAP Partner Edge, 2015).


IPN UPIICSA 33

2.3.3 Metodología Sure Step de Microsoft

La metodología Sure Step de Microsoft para la implementación de los sistemas

Microsoft Dynamics, es una secuencia de pasos lógicos relacionados entre sí, que

nos indican cómo empezar y cómo terminar un proyecto de implementación para

cualquiera de los productos de la familia Microsoft Dynamics. En Microsoft

Dynamics existen 4 sistemas ERP llamados AX, NAV, SL y GP, además de contar

productos individuales que se conectan a cualquiera de los ERP como el CRM

entre otros (Microsoft, 2015).

Esta metodología cuenta con un software que sirve como repositorio de la

documentación que se necesita para cada proyecto, almacenándolo de forma

individual. Este se puede obtener de la página de Microsoft y se instala en un

servidor o en una simple computadora personal, de forma que cualquier

participante interesado pueda consultar la documentación del proyecto en todo

momento (Microsoft, 2015).

Microsoft Sure Step provee un conjunto de archivos en formatos de Office que se

deben ir llenando para cumplir los entregables de cada fase, de manera que va

guiando al consultor con la información que debe ir recopilando y documentando a

cada paso. Pero adicional a esto menciona que si es necesario modificar alguno

de los documentos o si no existiera alguno que fuera necesario incluir en el

expediente del proyecto, el software de la metodología permite adicionarlo

(Microsoft, 2015).

Para cada producto de la familia de Microsoft se pueden llevar a cabo tres tipos de

implementación, le primera que es la más rápida denominada ágil donde sugiere

implementar el sistema de caja, es decir, sin adaptaciones al producto, la segunda

es un nivel intermedio con adaptaciones mínimas, y la última sugiere una

implementación con cambios complejos, la cual implica pasos adicionales para el

aseguramiento del cumplimiento de las adaptaciones requeridas. Esto se

especifica en el software de la metodología donde desde un inicio cuando se

crean las plantillas se elige el tipo de producto y el tipo de implementación

(Microsoft, 2015).

El nivel de complejidad que se desea, es algo que se debe acordar desde un inicio

con el cliente, donde esté al tanto del tipo de metodología que se va a utilizar.


IPN UPIICSA 34

En la figura 15 se muestran las fases de manera general de esta metodología,

donde cada una de ellas consta de entregables que permiten a todos los

participantes saber lo que se va a esperar para considerar cerrada cada una de

las fases ya que la teoría dice que no se puede pasar a la siguiente fase sin haber

terminado la inmediata anterior. El cierre de cada fase se debe confirmar y

documentar a través de una carta de cierre, inclusive por si se requiriera parar el

proyecto por alguna razón de cualquiera de las partes, cliente o proveedor.

Figura 15. Metodología Microsoft Dynamics Sure Step (Microsoft, 2015).


IPN UPIICSA 35

Sure Step define 5 fases principales y 2 fases adicionales para la optimización y

actualización. Cubre el ciclo de vida completo, desde el inicio del proyecto,

desarrollo, implementación, optimización y actualización a la nueva versión. Una

fase finaliza con un hito. Un hito es una suma de artefactos creados o refinados en

la fase. Si se logra el hito se puede comenzar la siguiente fase. Al primer vistazo

las fases se ven como un modelo de cascada, la idea principal es no causar

problemas en cascada si alguno de los hitos no se cumple adecuadamente

(Microsoft, 2015).

2.3.3.1 Análisis

La meta de esta fase de análisis es entender los procesos de negocio del cliente y

sus necesidades principales. Se llevan a cabo talleres para hacer una revisión por

área donde cada gerente expone sus procesos, ahí se ven los procesos de

negocio actuales del cliente y los deseables. La idea principal es detectar lo que

se va a poder configurar y lo que no dentro de Dynamics, para acordar con el

cliente lo que se haría en cada caso (Microsoft, 2015).

2.3.3.2 Diseño

El objetivo principal de la fase de diseño es encontrar una manera de cómo los

procesos y necesidades de los clientes se pueden implementar con Dynamics. En

este punto, puede haber más de una solución para un tema. Es necesario

identificar la mejor estrategia para la fase de implementación. Este es el punto en

el que se construye el prototipo y se hacen pruebas de carga sobre la aplicación

prototipo (Microsoft, 2015).

2.3.3.3 Desarrollo

Esta fase tiene como objetivo cumplir con los requisitos de adaptaciones y

modificaciones, la creación y configuración de una base de taos prototipo, y la

planeación y pruebas de migración de datos. Además se debe revisar el prototipo

en cuanto a funcionamiento como en el aspecto de seguridad en los accesos de

los usuarios. Esta fase termina al validarse todas las características que fueron

requeridas en la fase análisis (Microsoft, 2015).


IPN UPIICSA 36

2.3.3.4 Implantación (Despliegue)

Esta fase tiene varios objetivos, como son capacitar al administrador y a los

usuarios finales, preparar la base de datos que se pondrá en producción con los

últimos ajustes derivados de la fase anterior, cargar saldos iniciales de cada una

de las áreas como saldos contables, de clientes, de proveedores, de inventarios,

etc. Y por último la tarea más importante que es la puesta en marcha “Go-live”

(Microsoft, 2015).

2.3.3.5 Operación

Es un proceso de acompañamiento para ayudar en las diferentes áreas en caso

de que al momento del arranque se tengan dudas o se presenten problemas en la

operación, de básicamente un soporte en sitio que generalmente sirve para darles

confianza a los usuarios. Esta fase concluye generalmente con el primer cierre de

operaciones del mes, cierre contable (Microsoft, 2015).

Las fases de Operación, Optimización y Actualización, son pasos que se enfocan

a dar servicio de seguimiento y soporte, una vez terminada la puesta en marcha.

2.3.3.6 Procesos Cruzados

Un proceso en fase cruzada es un punto de monitoreo sobre el proceso para cada

tarea de cada fase. Como el nombre sugiere procesos cruzados, esto se realiza

en las diferentes fases. En general, la mayoría de los procesos en fase cruzada se

realiza desde el inicio del proyecto hasta el final. Los 8 procesos cruzados que

define Sure Step son análisis de procesos de negocio, configuración, migración de

datos, infraestructura, instalación, integración, pruebas y entrenamiento (Microsoft,

2015).

Algunos de los procesos de las fases pueden ser acordados como algún servicio

adicional como el de migración de datos, infraestructura, etc. conforme convenga

al cliente, al proveedor y al proyecto en sí (Microsoft, 2015).

Ésta como todas las metodologías es una propuesta de trabajo aunque esto no

garantiza que no existirán riesgos o problemas durante la implementación.


IPN UPIICSA 37

2.4 Herramientas utilizadas para la implementación de los sistemas ERP.

También se han empleado previo a una implementación, herramientas que ayudan

a establecer los alcances del proyecto, ayudan a discernir los diversos procesos

que se desean cubrir con la implementación de un sistema ERP, aunque la

mayoría de las veces estas herramientas no son utilizadas a menos de que estén

establecidas ya como políticas dentro de la empresa, a continuación se mencionan

dos de las principales.

2.4.1 La Planeación de los Sistemas de Información

Una herramienta que está enfocada a la fase antes de la implementación es “La

planeación de los Sistemas de Información”, la cual abarca desde el objetivo de la

empresa, como son crear una declaración de misión corporativa y del SI, expresar

con claridad la visión para el sistema de información dentro de la organización,

crear planes estratégicos y tácticos para el sistema de información, preparar un

plan para las operaciones que lograrán la misión y la visión, desarrollar un

presupuesto para asegurarse que los recursos estén disponibles con el fin de

lograr la misión y la visión, como se representa en la figura 16.

Figura 16. Pasos para la planeación de los Sistemas de Información. (Oz, 2008).


IPN UPIICSA 38

2.4.2 Calendario para la implementación de un proyecto

Cuando se ha identificado una necesidad específica para adquirir tecnología

nueva o mejorada bajo la estrategia integral de tecnología informativa de la

organización, el siguiente paso consiste en la preparación de una estrategia para

el desarrollo e implementación del proyecto (ACE, 2015).

La estrategia de desarrollo e implementación puede ser delineada utilizando un

calendario o cronograma. Idealmente, el cronograma del proyecto se extenderá

hasta comprender el ciclo de vida estimado de la tecnología. Esto permitirá

identificar todos los costos y actividades previsibles y también indicará aquellos

estimados cuando la tecnología tenga que ser reemplazada o mejorada (ACE,

2015).

En la figura 17 se muestra un calendario para la implementación de un proyecto

que lista un ejemplo de hitos a cumplir como un resumen ejecutivo del proyecto, la

idea es ir llenando con colores verde, amarillo y rojo los avances de cada uno. Los

verdes serían los cumplidos, los amarillos los que están en proceso y los rojos los

que están sin concluirse y retrasados.


IPN UPIICSA 39

24

23

22

21

20

19

18

17

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

Pas

os

del

cal

end

ario

de

imp

lem

en

taci

ón

de

un

pro

yect

o

Ide

ntifica

r la

necesid

ad d

e n

ue

va t

ecn

olo

gía

Dete

rmin

ar

que la t

ecn

olo

gía

pro

puesta

es a

sequib

le

Dete

rmin

ar

que la t

ecn

olo

gía

pro

puesta

es la a

pro

pia

da p

ara

las n

ecesid

ades locale

s

Pre

para

r un p

lan d

e n

eg

ocio

s, in

clu

ye

ndo u

n a

nális

is d

e c

osto

s-b

en

eficio

s y

un e

xam

en d

e las

altern

ativas d

isponib

les

Pre

para

r un p

resu

pu

esto

de

talla

do

Obte

ne

r a

uto

rizació

n d

e los inte

resa

do

s inte

rnos y

exte

rnos

Gara

ntizar

el fina

ncia

mie

nto

ne

cesari

o d

ura

nte

la

vid

a d

el p

royecto

Asegu

rar

las e

nm

iend

as leg

ale

s n

ecesari

as, d

e s

er

el ca

so

Pre

para

r un p

lan d

eta

llad

o d

e a

dm

inis

tració

n d

el p

royecto

Pre

para

r esp

ecific

acio

nes d

eta

lladas p

ara

la t

ecn

olo

gía

de

se

ada

Public

ar

las c

onvo

cato

rias d

e lic

itació

n

Evalu

ar

las lic

ita

cio

nes p

rese

nta

das y

sele

ccio

na

r la

mejo

r

Nego

cia

r y fir

mar

el contr

ato

fin

al

Recib

ir e

l pro

totipo

del sis

tem

a

Pro

bar

y e

valu

ar

el p

roto

tip

o

Busca

r la

ap

robació

n d

el pro

totipo

po

r la

s p

art

es inte

resad

as

Recib

ir la v

ers

ión

fin

al d

el sis

tem

a

Insta

lar

y p

roba

r la

vers

ión

fin

al

Conta

r con

au

ditoria

s in

dep

en

die

nte

s q

ue v

erifiqu

en la inte

grid

ad d

e los c

ódig

os o

rigin

ale

s

Capa

cita

r a

los u

su

ari

os e

n la o

pe

ració

n d

el n

uevo s

iste

ma

Cond

ucir

ca

mp

añ

as d

e info

rmació

n p

úblic

a,

de s

er

el caso

Desple

ga

r el sis

tem

a e

n s

u a

mbie

nte

de o

pera

ció

n

Asegu

rar

que s

e d

isp

on

ga d

e s

iste

ma

s d

e r

eem

pla

zo,

de s

er

ne

cesario

Ope

rar

el sis

tem

a e

n p

rod

ucció

n

Asegu

rar

que s

e c

ue

nte

co

n e

quip

os t

écnic

os y

de m

ante

nim

iento

dura

nte

su o

pe

ració

n p

ara

ase

gura

r la

exitosa c

on

ducció

n d

el eve

nto

Info

rmació

n d

e r

espald

o q

ue

resulte a

pro

pia

da

Conclu

sió

n d

el a

rran

que

en

pro

ducció

n

Evalu

ar

la o

pera

ció

n d

el sis

tem

a e

in

form

ar

a los u

su

ario

s

Pre

para

r pro

pu

esta

s p

ara

mejo

rar

el sis

tem

a p

ara

el p

róxim

o p

roceso e

lecto

ral (y

re

petir

cualq

uie

ra d

e los p

asos p

revio

s p

ara

obte

ner

los f

ondo

s n

ecesari

os p

ara

esas m

ejo

ras)

Darle

el m

ante

nim

iento

necesa

rio a

l sis

tem

a

Intr

od

ucir c

ualq

uie

r m

ejo

ra a

pro

bada

Repe

tir

los p

asos p

revio

s p

ara

la o

pe

ració

n y

evalu

ació

n d

el sis

tem

a e

n la s

iguie

nte

ele

cció

n

Figura 17. Calendario para la implementación de un proyecto (ACE, 2015).


IPN UPIICSA 40

2.4.3 Ingeniería de Requerimientos

La ingeniería de requerimientos establece lo que el sistema debe hacer en cuanto

a procesos, consultas, reportes, alarmas, interfaces, restricciones de seguridad y

algunos otros elementos que la organización necesite, por lo que si no se

identifican de manera correcta, el software no proporcionará al usuario la

funcionalidad esperada; además si no se determinan de manera completa y clara

no se conocerá el alcance ni será posible estimar la dimensión real del proyecto.

Es común que los requerimientos no se expresen de manera clara ni se

documenten de manera apropiada; aunque existen diversas técnicas, notaciones y

métodos, no son utilizados de forma correcta por su complejidad, llegan a ser

incomprensibles para los usuarios, no representan un estándar entre los grupos

involucrados en el desarrollo y algunas veces no reflejan la realidad.

Es un hecho además que los requerimientos cambian, no se actualiza la

documentación relacionada y los cambios no son comunicados a todos los grupos

involucrados en el desarrollo. Los cambios en requerimientos impactan de manera

importante la planeación y arquitectura del proyecto.

De acuerdo con la naturaleza de cada proyecto, existen distintos tipos de

requerimientos que a su vez tienen niveles de detalle. La cantidad de

requerimientos de un proyecto de software puede ser muy grande y difícil de

controlar.

Además como se mencionó anteriormente, se requiere una alta participación del

usuario en el proceso de identificar y validar los requerimientos, para garantizar

que sean los correctos y cubran sus necesidades, participación que muchas veces

no se tiene (Sommerville y Sawyer, 1997).

Son innumerables las opiniones de diversos autores sobre los problemas

relacionados con los requerimientos en el desarrollo de software, a continuación

se mencionan algunos:

“Una de las razones más comunes por las que un sistema falla es una mala

definición de los requerimientos” (Sommerville y Sawyer, 1997).

“El escribir especificaciones de sistema y de software buenas, correctas,

completas y medibles es uno de los problemas más comunes en el desarrollo de

software” (IEEE, 1984).


IPN UPIICSA 41

Para el éxito de un desarrollo de software es esencial una comprensión total de los

requisitos del software. No importa lo bien diseñado o codificado que esté un

programa si no se ha analizado correctamente, pues defraudará al usuario y

frustrará al desarrollador, es verdad que los requisitos del software cambian, pero

el impacto del cambio varía según el momento en que se introduzca. Si se pone

cuidado al dar la definición inicial, los cambios solicitados al principio pueden

acomodarse fácilmente. Cuando se solicitan al final de un proyecto, los cambios

pueden producir un orden de magnitud más caro que el mismo cambio pedido al

principio (Pressman, 1998).

Lo usuarios por lo general saben lo que requieren pero en muchas ocasiones nos

saben cómo solicitarlo, mucho menos como documentarlo, para este proceso es

necesario que por un lado el usuario cuente con su proceso documentado a nivel

manual y a partir de este se lleve a cabo la documentación del requerimiento.

Cuando surgió la Crisis del Software en los años 60, hubo muchos esfuerzos por

encontrar las causas del -ahora familiar- síndrome del problema. Las

investigaciones determinaron que las deficiencias en los requerimientos son una

de las causas más importantes del problema, en la mayoría de los proyectos de

software que no se cumplen los objetivos de realización y costo, los

requerimientos inadecuados juegan un papel principal y costoso en el fracaso del

proyecto, el desarrollo de la especificación de requerimientos en muchos casos

parece trivial pero probablemente es la parte del proceso que conlleva a mayores

fracasos que cualquier otra (IEEE, 1984).

Si bien uno de los puntos principales de los problemas presentados en una

implementación es la mala o nula documentación de los requerimientos, es algo

que ni el cliente ni el proveedor del software se sientan a detallarlo

adecuadamente, el cliente en ocasiones no exige esto con el fin de ahorrarse

tiempo o considerar que sobre la marcha se harán los ajustes necesarios. El

proveedor debería exigir este análisis pero se elevarían los costos del proyecto y

seguramente no se concluiría la venta. Se debe buscar un punto intermedio donde

por lo menos se asegure el alcance.

Por otro lado cabe mencionar que la identificación de requerimientos no es fácil,

debido a que el sistema por desarrollar debe satisfacer las necesidades reales de

los usuarios, las cuales muchas veces no son claras, provienen de diversas

fuentes y son de diversos tipos, por lo que se requieren habilidades y herramientas


IPN UPIICSA 42

tanto técnicas como administrativas por parte de los analistas. Esta es la parte

medular para que el sistema brinde la funcionalidad correcta (IEEE, 1984).

La principal relación de los requerimientos con el retraso de los proyectos radica

en que algunos aspectos están fuera del alcance original, el cual nunca fue

documentado, por lo que se debe implementar un mecanismo formal para

justificarlo. Para que no quede lugar a malos entendidos entre los clientes y el

equipo de desarrollo (IEEE, 1984).

En caso de existir la necesidad de un ajuste al alcance del proyecto lo más

conveniente es que se maneje con un documento llamado “control de cambios” de

manera que se documente el tiempo que pudiera retrasar el proyecto y también si

va a tener algún costo.

Con respecto al número de requerimientos, entre más grande sea el proyecto,

puede ser difícil controlarlos, sobre todo si no se tienen herramientas y

mecanismos establecidos, considerando además que se relacionan unos con

otros y se relacionan con otros artefactos (planes, código, pruebas) del proceso de

ingeniería de software (IEEE, 1984).

Cuando el proyecto es muy grande es cuando más se debe invertir tiempo en el

establecimiento del alcance, entre más detallado menos será el riesgo de un

fracaso.

Es un hecho además que es muy caro hacer cambios a requerimientos después

de que han sido acordados, ya que conllevan a costos relacionados con la re-

especificación, el re-diseño, la re-codificación, el re-probar, la re-implantación, las

acciones correctivas, la responsabilidad civil, los costos de desplazamiento, la

documentación y el mantenimiento constante (IEEE, 1984).

Lo más conveniente es tener una junta de evaluación para determinar si los

cambios que se requieren pueden esperar para una segunda fase o son

necesarios para la puesta en marcha.

2.4.3.1 Concepto

El Instituto de Ingenieros en Electricidad y Electrónica (IEEE), definen a la

Ingeniería de Requerimientos como:


IPN UPIICSA 43

“La ciencia y disciplina relacionada con el análisis y documentación de

requerimientos, incluyendo el análisis de necesidades, el análisis de

requerimientos y la especificación de requerimientos. También proporciona los

mecanismos adecuados para facilitar las actividades de análisis, documentación y

verificación de estos”

Para Ian Sommerville y Pete Sawyer (1997) la Ingeniería de Requerimientos es el

término que engloba todas las actividades relacionadas con descubrir, documentar

y mantener un conjunto de requerimientos para un sistema informático. El término

ingeniería, implica el uso sistemático y repetible de técnicas que son usadas para

asegurar que los requerimientos del sistema sean completos, consistentes y

relevantes.

Recientemente a la Ingeniería de Requerimientos se le denomina también como la

Administración de Requerimientos y se interpretan de forma similar; no obstante

de manera estricta la Administración de Requerimientos es complemento de la

Ingeniería de Requerimientos. La ingeniería es la construcción de éstos; la

administración es la organización y gestión (Sommerville & Sawyer, 1997).

Relación de la Ingeniería de Requerimientos con otras disciplinas

La Ingeniería de Requerimientos puede enfocarse a sistemas o a software. No

obstante, en los sistemas informáticos la relación sistema-software es muy

estrecha, es por ello que este trabajo cubre de cierta manera ambas perspectivas.

En este punto se ubicará a la Ingeniería de Requerimientos -desde nuestra

perspectiva-, con respecto a otras disciplinas reconocidas formalmente por la

IEEE.

En la figura 18 se muestra la relación de las ingenierías involucradas con la

ingeniería de requerimientos, las ingenierías son la Ingeniería de Sistemas que

esta a su vez se apoya en la Ingeniería de Requerimientos de Sistemas, la

Ingeniería de Software que se apoya en la Ingeniería de Requerimientos de

Software y la Ingeniería de Sistemas de Software.


IPN UPIICSA 44

Figura 18. Ingenierías involucradas relacionadas con la Ingeniería de Requerimientos (IEEE, 1984).

La Ingeniería de Sistemas es la aplicación de esfuerzos científicos y de ingeniería

para transformar una necesidad operacional en una descripción de los parámetros

de desempeño del sistema y una configuración del sistema mediante el uso de un

proceso iterativo de definición, síntesis, análisis, diseño, prueba y evaluación;

integrar los parámetros técnicos relacionados y asegurar compatibilidad de todas

las interfaces funcionales y del programa de una manera que optimice la definición

y el diseño del sistema; integrar fiabilidad, facilidad de mantenimiento, seguridad,

facilidad de perdurar, aspectos humanos y otros factores dentro del esfuerzo total

de ingeniería para lograr los objetivos de costo, tiempo y de realización técnica

(IEEE, 1984).

La Ingeniería de Requerimientos tiene como principal dar tanto al cliente como al

proveedor (desarrollador), un mecanismo de aseguramiento para ambas partes, donde

estén de acuerdo con el alcance funcional y técnico.


IPN UPIICSA 45

La ingeniería de sistemas es un proceso iterativo que usa un enfoque sistemático

para asegurar que el sistema, cuando sea desarrollado, satisfaga objetivos

específicos. Debe considerar los elementos de desempeño, costo, riesgo, tiempo y

complejidad operacional para asegurar que se logró un diseño eficaz (IEEE, 1984).

Asegurando los objetivos previamente, permitirá tanto al cliente como al proveedor

evaluar al final si la implementación fue exitosa o no y las razones. Una vez hecha la

evaluación, puede dar paso a una negociación de los ajustes o para una segunda etapa

del proyecto con un nuevo contrato.

La Ingeniería de Software es la aplicación de un enfoque sistemático, disciplinado

y cuantificable hacia el desarrollo, operación y mantenimiento del software; es

decir la aplicación de la ingeniería al software. Ingeniería de Sistemas de Software

es tanto un proceso técnico como administrativo (IEEE, 1984).

El proceso técnico es el esfuerzo analítico necesario para transformar una

necesidad operacional en un diseño de software del tamaño y configuración

apropiados, y su documentación en especificaciones de diseño y requerimientos.

El proceso administrativo implica evaluar el riesgo y el costo, integrar a los

ingenieros especialistas y a los grupos de diseño, mantener el control de la

configuración y auditar continuamente el esfuerzo para asegurar que los objetivos

de costo, de tiempo y de realización técnica son satisfechos para cubrir la

necesidad operacional original (IEEE, 1984).

Se debe contar en todo momento de un seguimiento del cumplimiento de cada objetivo a

través de un plan de entrega y revisiones periódicas. Con lo que debe contar como

mínimo es el objetivo, los responsables de ambas partes tanto del cliente como del

proveedor y las fechas, una vez concluida cada fecha del plan es recomendable tener una

minuta del resultado, si se cumplió o no el objetivo.

La Ingeniería de Requerimientos de Sistema es la ciencia y disciplina relacionada

con el análisis y documentación de los requerimientos del sistema. Comprende la

transformación de una necesidad operacional en una descripción del sistema, los

parámetros de desempeño del sistema y la configuración del sistema mediante el

uso de un proceso iterativo de análisis, diseño, y prototipos (IEEE, 1984).

Debe tener un complejidad que sea claro tanto para el cliente como para el proveedor

(desarrollador), si existiera algo técnico se debe incluir también una explicación para que

el cliente no tenga dudas ya que debe estar firmado por ambas partes.

La Ingeniería de Requerimientos de Software es la ciencia y disciplina relacionada

con el análisis y documentación de los requerimientos de software. Implica la


IPN UPIICSA 46

división de los requerimientos de sistema en varios subsistemas y tareas y la

asignación de estos subsistemas y tareas al software, así como su transformación

en una descripción de requerimientos de software y parámetros de desempeño

mediante el uso de un proceso iterativo de análisis, diseño y prototipos (IEEE,

1984).

En la figura 19 se muestra la principal diferencia entre Ingeniería de

Requerimientos de Sistema y la Ingeniería de Requerimientos de Software es que

el origen de los requerimientos de sistema radica en las necesidades del usuario

mientras que el origen de los requerimientos de software en los requerimientos y/o

especificaciones del sistema.

Figura 19. Proceso de Ingeniería de Requerimientos (IEEE, 1984).

Por lo tanto los ingenieros de requerimientos –o analistas- del sistema trabajan

con los clientes y usuarios, identificando sus necesidades, planes y recursos

disponibles. Deben producir documentos que sean comprensibles por todos

(analistas, gerentes, arquitectos de sistema, usuarios y clientes). Los ingenieros

de requerimientos de software trabajan con los documentos de requerimientos de

sistema y los traducen en requerimientos de software que deben ser

comprendidos tanto por los diseñadores de software como por los ingenieros de

requerimientos.

2.4.3.2 Clasificación de los requerimientos

La mayoría de los autores coinciden en clasificar los requerimientos en funcionales

y no funcionales.


IPN UPIICSA 47

Los requerimientos funcionales describen lo que el sistema debe hacer, es decir

especifican acciones que el sistema debe ser capaz de realizar, sin considerar

restricciones físicas. Los requerimientos funcionales especifican el

comportamiento del sistema.

Los requerimientos no funcionales describen únicamente atributos del sistema o

atributos del ambiente del sistema y pueden ser por ejemplo: requerimientos de

interfaz, de diseño, de implementación, legales, físicos, de costo, de tiempo, de

calidad, de seguridad, de construcción, de operación, entre otros.

De acuerdo al nivel de cumplimiento, los requerimientos pueden ser:

Requerimiento obligatorio.- requerimiento que debe ser implementado.

Requerimiento recomendable.- es deseable que sea implementado.

Requerimiento opcional.- no es crítica su implementación.

En la figura 20 se muestra el alcance del cliente quien es el experto en los

procesos de su negocio, por tanto sabe cuáles son sus necesidades de

información; por otro lado el proveedor quien es experto en los temas de

características de los sistemas y especificaciones del software.

Figura 20. Jerarquía de requerimientos (IEEE, 1984).


IPN UPIICSA 48

2.4.3.3 Responsabilidades de los usuarios

Dentro de las responsabilidades de los usuarios están, instruir a los analistas

sobre el negocio y definir el vocabulario de su área, invertir tiempo en proporcionar

requerimientos y aclarar dudas, también debe ser específico y preciso sobre las

necesidades del negocio y los requerimientos del sistema.

Otros factores que también deben considerar son tomar decisiones a tiempo sobre

los requerimientos, respetando las estimaciones de costo y viabilidad del equipo

de desarrollo, fijando prioridades para requerimientos individuales, características

del sistema o casos de uso. Así también revisar los documentos de requerimientos

y los prototipos, comunicar prontamente los cambios a los requerimientos del

producto (IEEE, 1984).

Un factor importante es seguir el proceso de cambio de los requerimientos,

respetando el proceso de ingeniería de requerimientos que usan los

desarrolladores. (IEEE, 1984).

2.4.3.4 Fases de investigación para la obtención de requerimientos

En cuanto a la obtención de requerimientos es un proceso el cual consta de 7

fases que van desde conocer el porqué de la necesidad, su problemática, los

procesos que involucra, el impacto que tiene en la organización, los usuarios

involucrados, las características esperadas así como las restricciones que se

tienen, por último la infraestructura con la que se cuenta.

En la figura 21 se enlista el orden cronológico con el que se deben seguir las 7

fases generales para la investigación y obtención de requerimientos.


IPN UPIICSA 49

Figura 21. Fases generales para la investigación y obtención de requerimientos (IEEE, 1984).

2.4.3.4.1 Contexto

En cuanto al contexto, se refiere al perfil del usuario y de la organización,

(Nombre, organización, puesto, responsabilidades clave, salidas que produce). Así

como las personas que están detrás de la iniciativa de trabajo, de dónde surgió la

iniciativa, qué áreas intervienen y con qué apoyo se cuenta (IEEE, 1984).

También aquí se deben especificar cuáles son beneficios intangibles y

económicos se esperan de la solución para poder determinar cómo se evaluaría el

éxito de la solución (IEEE, 1984).

El contexto ayuda a tener un antecedente del funcionamiento del área que se verá

beneficiada con la solución, es básicamente la presentación del área con las

personas que harán el levantamiento del requerimiento.

2.4.3.4.2 Problemática

La problemática indica qué problemas existen actualmente, cuál es la raíz del o los

problemas, por qué existe el problema, cómo se está resolviendo actualmente y

cuál es el entorno en que se da la problemática (IEEE, 1984).


IPN UPIICSA 50

En esta fase se especifican los síntomas del problema que está padeciendo y que

impacto tiene en la empresa, inclusive saber cuánto está costando el seguir con el

problema.

2.4.3.4.3 Procesos

Aquí se determinan cuáles de los procesos están relacionados, una descripción

general de los procesos, cuáles de esos procesos son críticos en la organización y

el ambiente en el que se utilizará la solución (IEEE, 1984).

En esta fase se debe platicar de las áreas afectadas y en que procesos se está

teniendo consecuencias. Es importante en este paso ser lo más grafico posible

para un mejor entendimiento, esto debe procurar tenerlo el cliente documentado,

algunas empresas se apoyan el manual de procedimientos de la empresa.

2.4.3.4.4 Volumen y tipo de información

En este punto se hace un análisis del tipo de información se va a procesar, quién

provee dicha información, cómo se encuentra almacenada, representada o

distribuida la información y un punto importante aquí son los volúmenes de

información que se manejan, es decir, cuántas transacciones, cuántos MB, el

número y tipo de archivos (IEEE, 1984).

Se debe contar con un mapa de la estructura de almacenamiento de la

información, tamaño de las bases de datos, ventanas de mantenimiento, inclusive

si es posible contar con una base de datos de la organización para fines de

pruebas.


IPN UPIICSA 51

2.4.3.4.5 Perfil y participación de los usuarios

En cuanto a este punto se debe indicar, quiénes utilizarán la solución, quiénes son

los usuarios, a qué área pertenecen, cuántos usuarios utilizarán la solución, con

qué rol, qué perfil tienen, cuál es su formación profesional, cuáles es su formación

en cuanto al uso de un equipo de cómputo, si tienen experiencia en este tipo de

aplicaciones, así como el tipo de capacitación que será necesaria (IEEE, 1984).

Se necesita contar con una lista de los usuarios responsables de este proceso,

desde usuarios hasta el administrador de cada área, con la información que

podrán visualizar cada uno de ellos, así como las responsabilidades que tiene

cada uno.

2.4.3.4.6 Características deseadas

Se debe especificar las expectativas que se tienen del sistema, cuáles son

características principales que se esperan del sistema, qué funcionalidad debe de

proporcionar, así como cuáles son las expectativas de fiabilidad y desempeño

(IEEE, 1984).

También es importante especificar qué características de calidad se esperan,

quién dará soporte al producto y si se tienen necesidades especiales para el

soporte. Cuáles son sus requerimientos de seguridad y cómo será distribuido el

software (IEEE, 1984).

Aquí se enmarcan los deseables que se requieren cubrir, básicamente es el alcance del

producto terminado que se espera, manejo de la información, consultas, reportes,

alarmas, nivel de seguridad, en sí todo lo que se espera del proceso a cubrir incluyendo

capacitación y documentación.


IPN UPIICSA 52

2.4.3.4.7 Restricciones

Si existen restricciones a considerar y cuáles son, con qué presupuesto se cuenta,

qué limitaciones financieras o de presupuesto son aplicables. Aspectos políticos

internos o externos que afecten las soluciones potenciales, así como restricciones

de la tecnología a utilizar, e inclusive si se tienen prohibiciones algunas

tecnologías en específico (IEEE, 1984).

También es importante dentro de este rubro saber si la solución a construir

interactuará con otros sistemas y si debe mantenerse compatibilidad con

soluciones existentes, así como si existe algún requerimiento de seguridad

especial. Un punto importante aquí es considerar si existen políticas, estándares o

lineamientos que debamos seguir, además de si existe un tiempo definido para su

desarrollo, ya que pudiera existir algún requerimiento legal, regulatorio o de

ambiente, u otros estándares que deban cumplirse (IEEE, 1984).

En esta fase se especifican los límites en cuanto a: presupuesto, tiempos en que

requiere la empresa el sistema, fiscales, operativos, de seguridad y tecnológicos.

Este último delimita hasta donde va a llegar el sistema inclusive en cuanto a

seguridad e interacción con otros sistemas, como pueden ser de facturación,

puntos de venta, así como otros muy particulares que se tengan.

2.4.3.4.8 Infraestructura

Por ultimo qué plataformas usan actualmente y si en un futuro se piensa manejar

algunas otras, con qué recursos de hardware y software cuentan actualmente, si

existen otros sistemas o aplicaciones que sean relevantes para este proyecto y si

se cuenta con licencias de software institucionales (IEEE, 1984).

Adicional a esto se deben considerar los esquemas de respaldo de la información,

los tiempos ejecución de ciertos procesos de interacción con otros sistemas o de

ciertos procesos, la disponibilidad de un ambiente de pruebas, así como definir los

responsables dentro de la organización que podrán apoyar para temas de

infraestructura en el momento que se requiera.


IPN UPIICSA 53

2.5 Factores Críticos de Éxito en la Implementación de Sistemas en las

Empresas (CFS, Critical Factors for Succesful Implementation of

Enterprise Systems)

Podemos definir a los Factores Críticos de Éxito como “el número limitado de

áreas en las que los resultados, si son satisfactorios, asegurarán el éxito en el

desarrollo de la competitividad de la organización”. Holland y Light (1999) definen

en el contexto de los sistemas ERP, como los factores necesarios para asegurar el

éxito en un proyecto de implementación de un sistema ERP.

Las condiciones para el éxito o para el fracaso, en una perspectiva general, de los

sistemas ERP ha sido ampliamente estudiada (Bingi, Sharma y Godla, 1999;

Esteves y Pastor, 2001; Fitzgerald y O’Kane, 1999; Reel, 1999).

De acuerdo a la filosofía de la socio-tecnológica, no puede instalarse una nueva

tecnología o un nuevo sistema sin considerar a las personas que estarán

involucradas en su uso, por lo que la implementación de un ERP implica el

rediseño de la institución (Laudon y Laudon, 1996).

Algunos autores consideran que la implementación de un sistema ERP en una

empresa es un evento de gran relevancia, debe contar con la correcta

planificación y dirigida con eficiencia, el común denominador del éxito de la

implementación de un sistema ERP en las empresas son: directivos involucrados

en el proyecto, equipo de implementación mixto coordinado por un alto directivo,

dedicación suficiente al seguimiento del proceso de implantación, objetivos claros

y medibles, planificación detallada de la formación de los usuarios (Mabert, Soni y

Venkataramanan, 2002).

Las investigaciones hechas hasta el día de hoy acerca de los factores críticos de

éxito en la implantación de los sistemas ERP y su impacto en las empresas son

muy escasas y limitadas, ya que estos sistemas son relativamente nuevos

(Mabert, Soni y Venkataramanan, 2002).

Diferentes autores han identificado factores críticos de éxito en la implementación

de un sistema ERP, incluye: apoyo de la dirección, rediseño de los procesos del

negocio para adecuarlo con el software, inversión en la formación de usuarios,

evitar adaptar el sistema (customizar) y el uso de analistas de negocios con

conocimientos en tecnologías y en organización (Sumner, 1999).


IPN UPIICSA 54

El compromiso desde la alta gerencia, reingeniería de los procesos existentes,

integración del ERP con los otros sistemas de información, la selección y dirección

de los consultores y la formación de los empleados en el nuevos sistema son los

aspectos a considerar para asegurar el éxito en la implantación (Bingi, Sharma y

Golda, 1999).

Algunos autores identificaron con sus estudios 10 factores de éxito en la

implantación de un proyecto, los cuales fueron: misión del proyecto, apoyo de la

alta dirección, plan del proyecto, consulta al cliente, personal competente,

disponer de la técnica necesaria, aceptación del cliente (usuarios), control y

realimentación, comunicación y habilidad para resolver imprevistos (Slevin y Pinto,

1987).

Otros autores desarrollaron un cuadro para agrupar los factores críticos de éxito

del proceso de implantación de ERP en factores (Somers & Nelson, 2001).

Quienes en su propuesta listan 22 factores de éxito los cuales están clasificados

en estratégicos y tácticos, estos factores están asociados con la implantación de

un sistema o proyecto informático, que viene de un proceso de identificación y

síntesis de los requerimientos los cuales han sido recomendados por

investigadores y académicos.

Hay quienes han clasificado los factores críticos en 4 clasificaciones: organizativo,

tecnológico, estratégico y táctico. Los de mayor frecuencia son apoyo continuo de

la dirección, gestión efectiva del cambio organizativo, alcance del proyecto,

dedicación de los consultores y los empleados, comunicación externa e interna,

planificación del proyecto (Esteves y Pastor, 2001).

Otros estudios consideran que el resultado de la implementación está determinado

por los siguientes factores: el papel de los usuarios, el grado de apoyo directivo

para el esfuerzo de implantación, el nivel de riesgo y complejidad del proyecto de

implantación y la calidad de la administración en el proceso de implantación

(Laudon y Laudon, 1996).

La mayoría de autores coinciden en que la implantación de una solución ERP

puede ser un éxito tecnológico pero también un fracaso organizacional. Se debe

prestar suficiente importancia a la participación, liderazgo y compromiso de los

miembros claves de la empresa en cada una de las etapas de la implantación.

Muchos investigadores han señalado que la introducción o alteración de un

sistema de información tiene un poderoso impacto conductual e institucional en la

empresa.


IPN UPIICSA 55

Respecto a los estudios que abordan los factores críticos de éxito en el proceso de

implementación de un sistema ERP, se analizaron los que elaboraron Somers y

Nelson (2001); Al-Mudimigh, Zairi y Al-Mashari (2001); Zhang, Lee y Banerjee

(2002); Akkermans y Helden (2002); Onur y Eray (2003); Nah, Zuckweiler y Lau

(2003).

2.5.1 Clasificación de los beneficios de los sistemas ERP

Operativo, en relación con la reducción de costos, el ciclo reducción del tiempo, la

mejora de la productividad, mejora de la calidad y mejora de servicios al cliente

(Shang y Seddon, 2000).

Gestión, relativa a una mejor gestión de los recursos, mejor toma de decisiones y

la planificación, y la mejora del rendimiento.

Estratégico, relativo a apoyar el crecimiento del negocio, en apoyo a la alianza de

negocios, la construcción de innovaciones de negocio, la construcción de

liderazgo en costos, generando diferenciación de los productos, y la construcción

externa de vínculos de cadena de suministro con clientes y proveedores.

Infraestructura de TI, con la participación de negocios edificio flexibilidad,

reducción de costos y aumento de TI capacidad de infraestructura.

Organizacional, en relación con el apoyo a la organización cambios, lo que facilita

el aprendizaje de negocios, empoderamiento y construcción de visiones comunes.

2.5.2 Comparativo de estudios

En cierto sentido, una estrategia equilibrada tendrá los FCE de carácter

estratégico, organizativo y operativo. En la implementación de sistemas ERP, por

tanto, se llevarán a cabo para servir a ese propósito en particular y para apoyar la

realización de los diversos, FCE multi-nivel. Por otra parte, los sistemas ERP

pueden ceder a muchos beneficios intangibles como la flexibilidad, la integración,

la orientación a procesos y la generación de sinergia. Estos beneficios muy a

menudo inesperadas pueden por lo tanto, proporcionar a las organizaciones una


IPN UPIICSA 56

capacidad adicional y en última instancia, mejorar los últimos esfuerzos de

planificación estratégica que pueden impulsar hacia futuro resultados competitivos.

La taxonomía representada en la figura 22, es un medio para ilustrar por una parte

la interrelación entre los aspectos fundamentales de la estrategia de negocio, y por

el otro, el papel de las TI asociado a los sistemas, pudiendo así soportar la

efectiva implementación de los procesos clave del negocio a través de mejora y

gestión monitoreando los procesos a través del desempeño y revisiones

periódicas.

Figura 22. Taxonomía de los factores críticos para la implementación del sistema ERP (Al-Mudimigh, Zairi & Al-Mashari, 2001).

Una revisión de las implementaciones de sistemas ERP exitosas ha demostrado

que el liderazgo y el compromiso de la alta dirección son los factores más críticos


IPN UPIICSA 57

en las organizaciones, al emprender una implementación de un sistema ERP

(Bingi, Sharma, & Golda, 1999), no sólo es el requisito de establecer la visión y la

dirección para el negocio, también es para aprovechar la energía y la creatividad

de los empleados, que permitir al negocio llevar a cabo la aplicación de conceptos

modernos, tales como BPM o Gestión de proceso de Negocio (por sus siglas en

inglés Business Process Management) y la explotación de la capacidad de la

tecnología de un sistema ERP. Por otra parte, el liderazgo es un enfoque

propagado de individuos y líderes que pueden con eficacia implementar

programas de cambio, tales como los sistemas ERP y que no sean contrarios a las

ideas modernas, el aprendizaje y el crecimiento del negocio a través de la

innovación y la mejores prácticas (Al-Mudimigh, 2001).

Los sistemas ERP son considerados esencialmente como herramientas

informáticas de procesamiento orientadas para mejorar el rendimiento del negocio.

Uno de los elementos fundamentales en el mejoramiento del negocio están siendo

claramente la definición de la visión/misión y la formulación de las

políticas/estrategias que pueden servir como modelo para cualquier organización

(Mitchell y Zmud, 1995). Estas visiones/misiones exitosas son aquellos que se

traducen en metas y objetivos medibles. La etapa de visión y la planificación

puede entonces servir como precursor para permitir el establecimiento de una

estrategia de TI, basado en la cartografía y la determinación de los requisitos clave

que apoyan el despliegue efectivo del negocio (Al-Mudimigh, 2001).

Un proceso visión/misión de TI se desarrolla como un sub-conjunto del proceso de

formulación estratégica de un proceso de negocios (Henderson y Venkatraman,

1993). Se dirige a cuestiones similares que se consideran una técnica, facilitan y

apoyan la perspectiva (Al-Mudimigh, 2001), y se forma a través de un análisis

integral de las deficiencias, así como la captura de prácticas similares

conducentes que forman organizaciones competentes (Al-Mashari y Zairi, 2000).

Después de agrupar los diferentes factores analizados en el contexto general de

estos estudios de acuerdo a la similitud de su descripción, se construyó la tabla

23.


IPN UPIICSA 58

Factores Críticos de Éxito

Som

ers

and N

els

on

2001

Al-M

udim

igh, Z

airi, A

l-

Ma

shari, 2001

Zh

ang,

Lee,

Banerje

e,

2002

Akkerm

ans

Van

Held

en,

2003

Onur

and E

ray,

2003

Nah,

Zuckw

eile

r, L

au,

2003

Para apoyo a la gestión / Top compromiso de la dirección X X X X X X

Presencia de un líder de Proyecto X X X X

Formación de usuarios y de educación / Empleados de formación

X X X

Participación del usuario X

Expectativa de Gestión X X

Consultores de ERP / vendor / asociaciones de clientes X

El uso de herramientas de desarrollo del Vendedor X

ERP paquete de software / selección cuidadosa del paquete apropiado

X X X

El desarrollo de software, pruebas y resolución de problemas

X X

Idoneidad de SW y HW X

Gestión de Proyectos / Gestión Efectiva de Proyectos X X X X X X

Comité Directivo X

El uso de consultores X

personalización mínima X X

Análisis de datos y conversión / Datos Precisión X X

BPR / BPC X X X X X

Definición de la arquitectura X

Recursos dedicados X

La competencia del equipo de proyecto X X

Trabajo en equipo y composición del equipo implementador ERP

X

Cultura y plan de administración del cambio / Administración del cambio.

X X

X

Metas y objetivos claros. X X

Visión y planeación del negocio. X

Educación de los nuevos procesos del negocio X

Comunicación efectiva / Comunicación interdepartamental X X X X

Cooperación interdepartamental. X

Proveedores del ERP / Soporte vigente del proveedor. X

Consultores del ERP. X

Caso de negocio. X

Seguimiento y evaluación del desempeño. X

Legado del sistema de negocio y tecnología de la información apropiado.

X

Infraestructura de IT X

Tabla 23. Comparación de estudios de factores críticos de éxito en la implementación de sistemas ERP (Elaboración propia).


IPN UPIICSA 59

Algunos de los conceptos listados en la tabla 21 se detallan a continuación:

Apoyo de la dirección. Si la alta dirección no está respaldando activamente un

proyecto que todo lo implica como un Implementación de un sistema ERP, hay

poca esperanza para él. Y si la gerencia superior permanentemente delega sus

responsabilidades a los expertos técnicos, la posibilidades de fracaso del proyecto

son altos (Ewushi-Mensah y Przanyski, 1991).

La competencia del equipo de proyecto. En cuanto a la competencia o preparación

del equipo de proyecto, es algo que no se ha estudiado mucho en cuanto a Factor

Crítico de Éxito, como lo mencionaron Argyris y Schön (1978); McGrath (1984);

Senge (1990); Katzenbach y Smith (1993). Es importante contar en las empresas

con un equipo que cuente con Usuarios clave que tengan conocimiento del

proceso en le empresa y de los que son los sistemas ERP. El Líder de Proyecto

deberá contar con conocimientos de los procesos en todas las áreas para así

poder filtrar los requerimientos.

La cooperación interdepartamental. Claramente se observa, que este es uno de

los propósitos de los sistemas ERP, la integración de las diferentes funciones de la

empresa; este es lo que los diferencia de otros sistemas a los sistemas ERP. De

aquí que una estrecha cooperación entre las áreas o departamentos sea un

requisito natural previo. Estudios recientes encontraron que la colaboración

interdepartamental es uno de los principales beneficios posteriores a la

implementación del sistema ERP (Stefanou, 1999).

Metas y objetivos claros. La primera fase de un proyecto de TI debe comenzar con

una conceptualización de los objetivos y las maneras de lograr éstos (Cleland y

King, 1983; Slevin y Pinto, 1987). Metas y objetivos claros parecen formar un FCE

claro, pero puede ser en realidad bastante problemático. Esto es porque, al

comienzo de un proyecto de ERP, a menudo es muy difícil determinar de una

manera clara sus necesidades. De ahí la llamada de Austin y Nolan (1998) para

gestionar iniciativas de ERP como una nueva forma de hacer negocios, y no

simplemente como proyectos de TI.

Gestión de proyectos. La complejidad de un ciclo de vida de un sistema ERP es

muy alto, dada la gran combinación de hardware, software y de los requerimientos

en juego de la empresa (Ryan, 1999). Un enfoque para la superación de este tipo

de complejidad es hacer hincapié en la necesidad de 'una gran cantidad de

planificación metódica y gestión medible (Soliman y Youssef, 1998). Un cierto


IPN UPIICSA 60

grado de improvisación también es necesario como parte del conjunto de

habilidades de los Líderes de Proyecto (Macredie y Sandom, 1999).

La comunicación interdepartamental. La importancia de la comunicación a través

de diferentes funciones de la empresa y los departamentos se conoce en de la

aplicación de la IT o Tecnología de Información (por sus siglas en inglés TI).

Según un autor en la gestión de proyectos de TI, "la comunicación es el aceite que

mantiene todo funcionando correctamente” (Schwalbe, 2000). Como se ha

señalado anteriormente, esta necesidad de comunicación a través de fronteras

funcionales es un tanto el más importante en un contexto de implementación de un

ERP, como el primer objetivo de los sistemas ERP de integrar las funciones de las

empresas (Davenport T.H., 1998).

Gestión de las expectativas. La gestión exitosa de las expectativas de los usuarios

es muy importante para las implementaciones exitosas de sistemas de TI en

general (Ginzberg, 1981). La desalineación de expectativas es común, por ejemplo

a través de sobreventa del proveedor o por la subestimación de la complejidad de

implementación de ERP de la organización. Por lo tanto, la gestión de las

expectativas sigue siendo importante en todas las etapas de la ciclo de vida de

aplicación (Hoffer, George y Valacich, 1998).

Líder de Proyecto. 'El éxito de la tecnología de innovaciones a menudo se ha

relacionado con la presencia de un Líder, que realiza las funciones cruciales de

liderazgo transformacional, facilitación y la comercialización del proyecto para los

usuarios (Somers y Nelson, 2001). Por lo general, este será alguien de la alta

dirección, ésta persona tiene la autoridad para hacer cambios sustanciales en la

organización cuando se requieren (McKersie y Walton, 1991). El papel de Líder de

Proyecto lo pueden llegar a tomar algún usuario experto en los procesos de la

empresa, el CEO o Director de la Empresa (por sus siglas en inglés Chief

Executive Officer) o el encargado de TI en la empresa (Willcocks y Sykes, 2000).

Soporte del proveedor. Un proyecto tan importante como la Implementación de un

sistema ERP no puede ser delegada sólo al proveedor. Se debe tener cuidado ya

que se puede generar una fuerte dependencia de los consultores externos o al

proveedor, demasiada dependencia puede crear un efecto negativo en el éxito del

proyecto de la implementación del MRP (Burns, Turnipseed y Riggs, 1991). Una

empresa normalmente no tiene todas las habilidades técnicas por lo tanto, es

necesario contar con un proveedor que genere confianza a la empresa y que esté


IPN UPIICSA 61

limitado a ciertos servicios contando con soporte de primera mano en las áreas de

IT (Thong, Yap y Raman, 1994; Janson y Subramanian, 1996).

Una cuidadosa selección de sistemas. Proveedores de ERP pueden reclamar que

sus sistemas se superponen en funcionalidad pero no siempre así es, al menos no

en su totalidad. Por ejemplo, algunos sistemas son más adecuados para las

grandes empresas, algunos más para las pequeñas. Algunos paquetes tienen

convertido en una industria de facto, algunos tienen una fuerte presencia en

ciertas regiones. Y luego, una vez hecha la elección para del sistema existe la

decisión a tomar en cuanto a qué versiones o módulos del paquete mejor se

ajustan a la organización. En resumen, si las decisiones tomadas son equivocadas

y fueron improvisadas, la empresa se enfrentará a llevar a cabo una

implementación forzada es muy probable que resulte costoso y arriesgado

(Piturro, 1999; Willcocks y Sykes, 2000).

Constantemente las visiones y misiones implementadas en las empresas son las

que han influido en los factores críticos de éxito que consiguen comunicación a

todos los niveles dentro de la organización.

En ese sentido una condición importante para los sistemas ERP es acceder a los

beneficios deseados. La definición de fracaso o el éxito en Proyectos de TI pueden

verse como “la correspondencia de éxito, donde hay una coincidencia entre los

sistemas de TI y los objetivos previstos específicos, el éxito del proceso, cuando

se termina de proyectos de TI dentro del tiempo y presupuesto, la interacción de

éxito, cuando las actitudes de los usuarios hacia las TI son positivas, expectativa

de éxito, donde coinciden los sistemas de TI expectativas de los usuarios”

(Lyytinen y Hirschheim, 1987).


IPN UPIICSA 62

3 ESTUDIO Y DESARROLLO DEL OBJETO DE INVESTIGACIÓN

Para explicar lo que es la metodología de investigación primero es importante

revisar a grandes rasgos lo que es el método científico, el cual es una herramienta

estratégica que debe ayudar al investigador a llegar a resultados de carácter

científico, este método es un proceso conscientemente dirigido que el investigador

debe seguir, el resultado deberá ser un nuevo conocimiento que amplíe y a su vez

también enriquezca el universo del saber (Albarran y Escobar, 2001).

En cuanto a la metodología de investigación o método de investigación, es el que

sirve para explicar cómo diseñar nuestra investigación, la metodología de

investigación científica es un conjunto de pasos ordenados que generalmente

están enmarcados en 5 pasos generales:

1. Planteamiento del problema.

2. Revisión de bibliografía y estudios realizados al respecto.

3. Obtención de algunas hipótesis que hay que demostrar.

4. Diseñar un procedimiento o un camino de cómo vamos a responder las

preguntas de la investigación.

5. Responder las preguntas de la investigación (Resultados y discusión).

El método es un plan, un procedimiento de cómo vamos a llevar a cabo nuestra

investigación, donde primero se debe identificar el diseño, después se debe

delimitar tanto la población como la muestra a estudiar, así como los instrumentos

que se utilizarán para el estudio, por último se debe definir el procedimiento a

utilizar.

El diseño de la Metodología de investigación debe ir de acuerdo al tipo de tesis

que se desarrolla (Francois Lacouture, 2014).

El proceso de planeación planteado por Galicia (2012) abarca 6 etapas las cuales

se muestran en la figura 24, el autor primero da varias definiciones basadas en el

diccionario de la lengua española donde define al proceso: como la acción de ir

hacia adelante, el transcurso del tiempo y por ultimo conjunto de fases sucesivas

de un fenómeno natural o de una operación artificial.


IPN UPIICSA 63

Figura 24. Esquema general del Proceso de Investigación (Arias Galicia, 2012).

El esquema general del proceso de investigación no es un proceso lineal, hay

avances y retrocesos en las etapas.


IPN UPIICSA 64

3.1 Diseño de investigación

Para la elaboración de esta tesis se aplicó un método de investigación documental

y de campo, es un estudio transversal y descriptivo ya que no está enfocada a

fines probabilísticos sino a encontrar factores que influyen en el éxito de la

implementación exitosa de sistemas ERP en PYMES de la Zona Metropolitana del

Valle de México.

Como parte de la investigación debemos consultar documentos, entendiendo por

esto los registros realizados sobre papel, audio, película, video, etc. Las fuentes

para esto son: bibliotecas, hemerotecas, archivos, pinacotecas, internet, etc. (Arias

Galicia, 2012).

En la etapa 1, se consultaron fuentes existentes con el fin de evitar duplicidad de

trabajos hechos con anterioridad. El trabajo se inició recopilando información

acerca de investigaciones realizadas en torno al objeto de estudio, hallazgos,

teorías comprobadas, clasificando la información que pudiera servir como contexto

y teoría.

En la etapa 2 se llevó a cabo una investigación de campo recopilando datos por

medio de un cuestionario previamente diseñado, el cual se diseñó con base a los

factores críticos de éxito encontrados en otros estudios, pero dejando las

preguntas clave abiertas para evitar cualquier sesgo. El cuestionario se aplicó

tanto a personas que fueron líderes de proyecto en implementaciones de sistemas

ERP en diferentes empresas como a consultores de empresas implementadoras

de SAP Business One, lo anterior con la finalidad de conocer su experiencia en

este proceso, sus puntos de vista tanto de los resultados de la implementación y

de lo que consideran hicieron falta para que fuera una implementación exitosa.

Para la etapa 3, la información que resultó de ambas investigaciones tanto la

documental como la de campo, se clasificó, analizó y comparó para encontrar

coincidencias u otros hallazgos importantes. Por último con base a lo anterior se

desarrollaron las conclusiones.

En la figura 25 se muestra gráficamente el proceso de investigación que se llevó a

cabo incluyendo los componentes de cada fase.


IPN UPIICSA 65

Figura 25. Diagrama general del Proceso de Investigación (Elaboración propia).

3.1.1 Diseño específico de la investigación

A continuación en la tabla 26 se listan las actividades apegadas a las necesidades

del diseño la investigación. Las actividades son secuenciales por lo que se deben

ir cubriendo en el orden especificado, no es recomendable continuar si alguna de

las actividades no se termina de ejecutar.

Actividad Técnicas Herramientas Metas

¿Qué hacer? ¿Cómo hacer? ¿Con qué hacer? ¿Qué obtener en

particular?

Actividad 1

Planteamiento del

problema.

Técnicas de investigación

documental o

bibliográfica.

Internet.

Publicaciones

científicas.

Fichas bibliográficas.

Identificar el concepto

general a estudiar.


IPN UPIICSA 66

Entrevistas con

expertos.

Actividad 2

Diseño, planeación

de la investigación.


documental o

bibliográfica.

Internet.

Publicaciones

científicas.


Entrevistas con

expertos.

¿Qué recursos se

requieren?

¿Qué actividades son

necesarias?

Actividad 3

Recopilación de

información

existente.


documental o

bibliográfica.

Internet.

Publicaciones

científicas.


Entrevistas con

expertos.

¿El tema se ha

estudiado antes?

¿Qué otros estudios

se han hecho?

Actividad 4

Análisis de la

información

existente.


documental o

bibliográfica.

Elaboración de gráficas

de los estudios actuales.

Internet.

Publicaciones

científicas.


¿Objetivos

anteriormente

logrados?

¿Cómo se recabaron

los datos?

Actividad 5

Diseño del Método

de Investigación.

Identificación del diseño.

Identificación de la

población y la muestra.

Descripción de los

instrumentos.

Descripción del

procedimiento.

Internet

Publicaciones

científicas.

Fichas bibliográficas

Evaluación de

resultados y

diagnóstico

correspondiente.

Actividad 6

Recopilación de

datos mediante el

método planteado


documental o

bibliográfica.

Estudio de campo.

Internet

Publicaciones

científicas.

Fichas bibliográficas

¿Qué problemas han

tenido en empresas

del área metropolitana

del valle de México

con la implementación


IPN UPIICSA 67

en la actividad 5. de sistemas ERP?

Actividad 7

Análisis,

explicación e

interpretación.

Análisis sistémico. Hojas de cálculos.

Entrevistas con

expertos.

¿Qué significan los

resultados?

Actividad 8

Comparación de

resultados de otros

estudios vs datos

recabados en las

encuestas.

Elaboración de gráficas. Procesador de textos.

Hojas de cálculos.

Entrevistas con

expertos.

¿Hay similitudes?

¿Cuáles son las

similitudes?

¿Cuáles de los puntos

encontrados son

responsabilidad del

cliente y cuáles del

proveedor?

Actividad 9

Elaboración de

diagnóstico y

conclusiones.

Recopilar y analizar

diversas metodologías.

Internet.

Publicaciones

científicas.


Entrevistas con

expertos.

Evaluación de

resultados y

diagnostico

correspondiente.

Conclusiones.

Actividad 10

Revisión general

de la tesis.

Lectura general a nivel

personal.

Lectura general de

personas de apoyo para

la evaluación del

entendimiento.

Procesador de textos. Entrega de documento

escrito y presentación

de grado.

Tabla 26. Diseño de la Investigación (Elaboración propia).


IPN UPIICSA 68

3.1.2 Limitaciones de la investigación

En la investigación de campo se encuestaron 500 empresas que implementaron

SAP Business One, las cuales están catalogadas como pequeñas y medianas

empresas (PYMES), según la clasificación del INEGI clasifica en PYMES a las

empresas que cuentan con un rango de entre 15 y 250 usuarios considerados

como operarios del sistema.

Las empresas encuestadas se encuentran ubicadas en la Zona Metropolitana del

Valle de México. Según el INEGI la Zona Metropolitana del Valle de México o por

sus siglas ZMVM, es el área conformada por el Distrito Federal y 60 municipios

aglomerados, uno de ellos en el Estado de Hidalgo, los restantes del Estado de

México, lo anterior según los resultados del censo elaborado en el año 2010 esta

zona contaba con una población de alrededor de 20 millones de habitantes (tan

solo en el Distrito Federal son 8 851 080 habitantes), según datos de la ONU en el

año 2012 fue la 3ª aglomeración humana más poblada del mundo.

3.2 Población y unidad de análisis de datos

Se tiene registro según SAP de alrededor 500 empresas PYMES que

implementaron o están en la fase final de implementación de la Zona

Metropolitana del Valle de México.

De cada una de estas empresas se consideraron líderes de proyecto o usuarios

clave (usuarios champion) que estuvieron durante la implementación. En caso de

ya no laborar en la empresa se solicitó al Administrador de la empresa a quien se

le hizo llegar la encuesta, que se apoyara con el consultor que estuvo como líder

de proyecto por parte del proveedor en la implementación.

3.2.1 Distribución de las empresas por tamaño

Según la clasificación de SAP en cuanto al tamaño de empresas en México, el

10.5% de las empresas muestra son pequeñas (1 a 100 empleados); 25.3%

medianas (100 a 500 empleados) y 63.2 grandes (más de 500 empleados).


IPN UPIICSA 69

3.2.2 Áreas o procesos del negocio en los que utiliza SAP

De acuerdo a información de SAP, los módulos de SAP más utilizados a nivel

mundial, implementados en más del 75% de las empresas, como se muestra en la

figura 27, son los que se refieren a procesos transaccionales y de control:

finanzas, compras, inventarios, gestión de activos y ventas; mientras que los

menos utilizados son: gestión de ciclo de vida del producto, comercio electrónico,

marketing y otros como gestión de mantenimiento, proyectos y recursos humanos.

Figura 27. Áreas o procesos del negocio en los que se utiliza SAP (Elaboración propia).

3.2.3 Definición de la población objetivo

La población considerada son 500 empresas que implementaron SAP Business

One en la Zona Metropolitana del Valle de México, según registros de SAP.

El estudio de campo abarca empresas con experiencia en la implementación de

un sistema ERP SAP Business One.

9 11

19 23 23

37

45 46 52 52

67

76 78 84

89 90

18

0

10

20

30

40

50

60

70

80

90

100


IPN UPIICSA 70

Para el diseño de las preguntas de la encuesta, se hizo una revisión de los

estudios actuales acerca de los factores críticos de éxito en Implementaciones de

sistemas ERP, con esto se formularon preguntas abiertas y cerradas que pudieran

proporcionar información en torno al objeto de estudio procurando no tener ningún

sesgo. La encuesta se dirigió principalmente a líderes de proyecto y usuarios clave

que participaron en el proceso de implantación del sistema ERP en la empresa,

así como consultores que participaron como líderes de proyecto del lado del

proveedor.

3.3 Muestra de estudio

El estudio estará basado en la obtención de información cualitativa que son

opiniones de un grupo de personas, eventos, sucesos, comunidades, etc., sobre el

cual o cuales se habrán de recolectar los datos, sin que necesariamente sea

representativo del universo o población que se estudia (Arias Galicia, 2012);

(Hernández, 2008).

En cuanto a los estudios cualitativos el tamaño de muestra no es importante desde

un punto de vista probabilístico, ya que el interés del estudio no es generalizar los

resultados a una población más amplia. Lo que se busca en una investigación de

enfoque cualitativo, es profundidad, motivo por el cual se pretende calidad en los

datos más que propiamente cantidad, en donde lo fundamental es la aportación de

personas, participantes, organizaciones, eventos, hechos etc., que nos ayuden a

entender el fenómeno de estudio y a responder las preguntas de investigación

planteadas.

La composición y tamaño de la muestra cualitativa depende del desarrollo del

proceso inductivo de investigación a desarrollar, el cual existe una gran diversidad

de estudios que varían con los tamaños de la muestra a investigar. Dentro de esta

investigación, se utilizara el método de muestreo por conveniencia intencional y

premeditada, siguiendo un criterio estratégico, seleccionando a quienes más

conocimientos tienen del tema.


IPN UPIICSA 71

3.3.1 Determinación del tamaño de la muestra

Al ser un estudio que está basado en obtención de información cualitativa, la

población considerada es de 500 empresas que según información de SAP tienen

instalado el sistema ERP SAP Business One en la Zona Metropolitana del Valle de

México, de las cuales se tomó una muestra de 217 empresas.

El mecanismo para la obtención de la información fue a través de correos

electrónicos, se les envió el cuestionario a las 500 empresas.

Se les dio un lapso máximo de un mes para enviar la encuesta respondida.

Se tomaron las primeras 217 encuestas que se recibieron en la cuenta de correo

que se les indicó a los participantes con las preguntas debidamente respondidas,

esto además ayudó a darle aleatoriedad a la recopilación de la información.

Las encuestas que lleguen después de las 217, ya no fueron incluidas en el

estudio.

3.3.2 Limitaciones de la muestra

En cuanto a las limitaciones del estudio de campo, la investigación está dirigida

únicamente a PYMES.

PYMES que geográficamente se encuentran en la Zona Metropolitana del Valle de

México.

Las personas a las que está dirigida la encuesta son personas que participaron en

la implementación del sistema ERP, dejando a su criterio responder en caso de

que la implementación no hubiera sido exitosa, cuáles cree que fueron los factores

que influyeron.

No se conoció en persona a los participantes, ni se hizo una discriminación de

género, nivel de estudio, ni capacidades de liderazgo.


IPN UPIICSA 72

3.4 Selección de instrumentos

La selección de instrumentos se refiere al mecanismo con el cual se obtuvieron los

datos que proveen de información. Buscando la disminución de subjetividad y

dando calidad a la información se buscó tener un procedimiento que no obligue al

encuestado inclinarse hacia alguna respuesta inducida, para lo cual se elaboró un

cuestionario en su mayoría de respuestas abiertas. “La objetividad está

relacionada con la posibilidad de que cualquier persona (sin importar sus

inclinaciones o gustos individuales) arribe a resultados semejantes al seguir los

mismos procedimientos y tomando como base el mismo marco teórico” (Arias

Galicia, 2012).

El instrumento debe contar con dos aspectos fundamentales que son confiabilidad

y validez, para el primero se refiere a la consistencia y permanencia del

instrumento y los procedimientos de aplicación ya que es necesario obtener en

cada ocasión mediciones del fenómeno estudiado, sin que se vea afectado por

otros factores. En cuanto a la Validez se refiere a la obtención de mediciones o

clasificaciones del asunto en estudio, eliminando otras posibles variables (Arias

Galicia, 2012).

3.4.1 Recopilación de datos

A través de la aplicación de un cuestionario de preguntas abiertas y cerradas que

se envió vía correo electrónico a PYMES de la Zona Metropolitana del Valle de

México, quienes están registradas en una base de datos de SAP México.

Se envió a 500 empresas donde los primeros 217 que llegaron primero y

estuvieron debidamente contestados los cuestionarios, son lo que se tomaron en

cuenta para ser analizados.

La investigación de campo se llevó a cabo a través de la aplicación de un

cuestionario que se envió vía email a administradores de empresas, solicitándoles

que lo contestaran Líderes de Proyecto o Usuarios Clave que estuvieron en el

proceso de implementación de SAP Business One, en caso de que no existiera

ninguno de los dos ya laborando se le sugirió al Administrador que lo canalizara al


IPN UPIICSA 73

consultor que implementó en la empresa (Líder de Proyecto por parte del

proveedor).

En la preparación del cuestionario se llevó 15 días. Los encuestados contaron con

un tiempo máximo de un mes para responder el cuestionario y una vez recibidos

los datos se llevó otro mes para ordenar y clasificar los datos. Una vez agrupada

la información se generaron gráficas para su estudio las cuales se llevaron 15

días. Total 3 meses.

Se aplicó una regla para resumir al máximo la información de las encuestas, por

ejemplo en la pregunta de Razones de no cubrir en tiempo y costo la

implementación del sistema ERP, se debían de acumular por lo menos 5

incidencias para considerarla como una razón, se determinó que hasta ese

momento formaría parte de la lista, así se evitó tener una dispersión que pudiera

resultar poco manejable.


IPN UPIICSA 74

3.4.2 Cuestionario aplicado en campo

En cuanto a las preguntas que se manejaron en el cuestionario se incluyeron

preguntas abiertas y de elección forzosa acotadas a Falso o Verdadero, aunque

estas últimas fueron muy pocas para evitar algún sesgo en la investigación (Arias,

2012), como se muestra en la figura 28.

Figura 28. Cuestionario aplicado a las organizaciones (Elaboración propia).

Arias (2012) menciona que todas las herramientas pueden tener un margen de

error, en el caso de los cuestionarios existen ciertas limitaciones como pueden ser,

la falta de profundidad, problema por bajo o diferente grado de escolaridad de los

encuestados, estado de ánimo, carencia de anonimato, tiempo que se tome el

encuestado en responder los cuestionarios, lo cual puede mermar la confianza en

los datos.


IPN UPIICSA 75

A pesar de estas limitaciones se considera que el cuestionario puede ser una

herramienta útil, siempre y cuando se establezca claramente la manera en que se

recopilaron los datos y posteriormente como fueron analizados. (Arias, 2012).


IPN UPIICSA 76

4 HALLAZGOS Y RESULTADOS

Una vez obtenidos los datos de la encuesta realizada, se procedió a ordenarlos,

clasificarlos y agruparlos, de manera que proporcionaran información concreta,

incidente y relevante.

Al analizar los datos y se llegó a la encuesta número 183, empezaron a disminuir

las variaciones en cuanto a la pregunta “¿Cuáles consideras que fueron los

factores críticos que ocasionaron que no se tuviera una implementación exitosa?”,

se presentó un punto de saturación teórica, ya no se estaban presentando datos

diferentes.

Posteriormente la información se resumió y graficó, para compararla con los

estudios que han hecho algunos investigadores. Se buscaron coincidencias, así

como algunos otros hallazgos adicionales relevantes. Por último con base a lo

anterior se realizaron las conclusiones.

A continuación se muestra la información clasificada y analizada de los

cuestionarios aplicados a las PYMES de la Zona Metropolitana del Valle de

México, la cual se representó a través de tablas y gráficas.


IPN UPIICSA 77

4.1 Análisis de la información obtenida

Como se observa en la tabla 29, la mayoría de los encuestados fueron líderes de

proyecto y usuarios clave (ambos de parte cliente), sumando 203 contra solo 14

consultores participantes (de parte del proveedor). Esto le da un valor importante a

la encuesta ya que la mayoría de las opiniones están del lado del cliente, quien en

una introspección aportó los factores que en su opinión hicieron falta para poder

lograr una implementación exitosa.

Rol desempeñado durante la implementación

No. De empresas

Líderes de proyecto del cliente. 172

Usuarios clave del cliente. 31

Consultores. 14

TOTAL 217

Tabla 29. Rol desempeñado durante la implementación (Elaboración propia).

4.1.1 Giros de las empresas

En cuanto a la información de los giros de las empresas como se muestra en la

gráfica 30, se obtuvo que la mayoría fueron Comercializadoras, seguidas por las

de Servicios y si las agrupamos con las Retaileras que son empresas mayoristas

suman un 60% del total, en estas empresas en teoría es relativamente sencillo

implementar un sistema ERP, a diferencia de las empresas Textileras y

Manufactureras que juntas suman un 29% y donde siempre es más compleja una

implementación.

La complejidad en las empresas Textileras y Manufactureras radica en que

requieren de incluir en su plan de implementación los módulos de Producción y

MRP, además de que generalmente manejan un mayor volumen artículos, listas

de materiales y transacciones mensuales. Inclusive necesitan una mayor precisión

en cálculos de ensamble de los productos fabricados y un mayor análisis en sus

procesos, por ende aumenta el tiempo y riesgo de implementación.


IPN UPIICSA 78

Por lo anterior en teoría deberían ser más las empresas que logren una

implementación exitosa, lo cual no se ve reflejado en las encuestas que más

adelante se muestran.

Gráfica 30. Giros de las empresas entrevistadas (Elaboración propia).

Textileras 17%

Manufaturera 12%

Restaurantera 4%

Comercializadora 28%

Servicios 23%

Financieras 2%

Automotrices 4%

Retaileras 9%

Otros 1%


IPN UPIICSA 79

4.1.2 Número de usuarios que utilizan el ERP

La gráfica 31 refleja que la mayoría de las empresas contaban con un rango de

entre 15 y 50 usuarios con un 43%, lo que en teoría debería permitirles contar una

organización bien estructurada para la implementación de un sistema ERP, al ser

menos las personas que se tendrían que poner de acuerdo en sus procedimientos

internos. Si sumamos el porcentaje de las empresas de entre 15 y 50 más las de

entre 51 y 100, estamos hablando de un 81% de empresas con 100 usuarios o

menos.

En muchas ocasiones al ser empresas con un número menor a 100 usuarios los

administradores piensan en que no se necesita tener procedimientos antes de la

implementación de un ERP, mucho menos pensar en documentarlos, darles

mantenimiento y seguimiento continuo. De hecho tener sus procedimientos

documentados lo ven como un gasto innecesario.

Algunos administradores siguen pensando que con implementar un sistema ERP y

apegarse a sus mejores prácticas estarán cubiertas sus necesidades organizativas

y adoptarlos como procedimientos.

Gráfica 31. Usuarios que usan el ERP en la empresa (Elaboración propia).

Entre 15 y 50 43%

De 51 a 100 38%

Mas de 100 19%


IPN UPIICSA 80

4.1.3 Motivos de la implementación del ERP

En la gráfica 32 se visualiza, que el motivo principal de la implementación de un

sistema ERP fue por un requerimiento de sus clientes. En la actualidad es muy

común que algunos clientes requieran que sus proveedores cuenten con una

herramienta como un sistema ERP para que tengan cierta garantía de no

provocarles problemas de desabasto, pasando a ser el ERP parte del curriculum

de cualquier empresa.

La moda también juega un papel importante, inclusive muchas empresas utilizan

el tener implementado un ERP como herramienta de venta. En este aspecto son

muy comunes las recomendaciones inter-compañías de ciertas marcas de

sistemas, en algunos círculos llega a darles cierto estatus, dependiendo de la

marca del ERP con el que cuenten.

Un cambio en la dirección también fue el disparador de la implementación de un

ERP, cuando en la nueva administración se cuenta con una persona que ya ha

tenido la experiencia de implementar un ERP en empresas en las que laboró

anteriormente, es muy probable que ayude a lograr una implementación exitosa,

reduciendo los riesgos e impulsando la implementación con objetivos más claros.

Gráfica 32. Motivos de la implementación del ERP (Elaboración propia).

Moda 21%

Necesidad interna

12%

Requerimiento fiscal 17%

Requerimiento de clientes

31%

Nueva administración

19%


IPN UPIICSA 81

4.1.4 Razones por las que seleccionó el ERP

La mayor parte de los sistemas ERP implementados fueron seleccionados por el

precio, inclusive se pudo haber dado el caso de que ni siquiera cubriera todas sus

necesidades pero por el acuerdo comercial se logró la negociación, tal como se

observa en la gráfica 33.

La moda fue el segundo factor importante al momento de seleccionar un sistema

ERP, aquí las marcas también juegan un papel importante en conjunto con las

recomendaciones de otras empresas que con algún sistema lograron cubrir sus

necesidades.

La parte preocupante es que solo el 12% de las empresas seleccionaron un

sistema ERP porque cubría sus necesidades. Esto refleja el poco interés de las

empresas en hacer un análisis exhaustivo en el proceso de selección.

Gráfica 33. Razones por las que se seleccionó el ERP (Elaboración propia).

Por precio 37%

Por moda 29%

Por recomendación

22%

Cubria las necesidades

12%


IPN UPIICSA 82

4.1.5 Implementaciones hechas en tiempo

De acuerdo con la gráfica 34, muy pocas empresas lograron implementar el

sistema ERP en el tiempo originalmente acordado con 22% contra un 78% que

tuvo variaciones.

Es muy común que las empresas no manejen o no negocien un esquema de

penalización por retraso del proyecto, inclusive en muchos casos ni siquiera se

estipuló en el contrato el tiempo de implementación pactado, limitando que se

pueda llevar a cabo alguna negociación al momento de presentarse retrasos.

La gráfica 34 tiene cierta similitud respecto a la gráfica 3 de esta tesis, presentada

por Standish Group en el 2001, acerca del porcentaje de proyectos exitosos, donde

dice que el 22% de los proyectos de implementación de sistemas ERP son exitosos

contra el 22% que no lo son.

Gráfica 34. Implementaciones hechas en tiempo (Elaboración propia).

No 78%

Si 22%


IPN UPIICSA 83

4.1.6 Porcentaje de variación del tiempo de implementación respecto al

planteado en un inicio

Las empresas que variaron más de un 200% respecto al tiempo originalmente

estimado fue de un 38%, mientras que las que variaron de un 101% a un 200%

fueron de un 31%, en suma las empresas que variaron más de un 100% fueron un

69% de las empresas, véase la gráfica 35.

Se implementaron un 69% de las empresas en más del doble de tiempo esperado,

casi 3 de cada 4 empresas, lo cual es alarmante y de tomar en cuenta para el

momento de negociar la adquisición se considere alguna penalización en caso de

algún retraso.

El 22% de las empresas que estuvieron en el rango de 0 a 10% de variación,

consideraron este rango perfectamente manejable e inclusive algunas de ellas

terminaron antes del tiempo acordado.

Gráfica 35. Porcentaje de variación del tiempo de implementación respecto al planteado en un inicio (Elaboración propia).

0% a 10% 22%

11% a 100% 9%

101% a 200% 31%

mas de 200% 38%


IPN UPIICSA 84

4.1.7 Porcentaje de variación del costo de implementación respecto al

planteado en un inicio

En cuanto a la variación del costo la mayoría estuvieron entre el 1% y 100%

respecto al costo original de la implementación del sistema ERP, comentaron que

esto había sido respecto a lo que la empresa había tenido que pagar al proveedor

acerca de funcionalidades adicionales no contempladas o solicitadas desde un

inicio, tal como se observa en la gráfica 36.

Es importante mencionar que en este cálculo no están contemplados los costos

ocasionados por problemas como: costo por entregas canceladas impuntuales,

desabasto de inventarios, sueldos adicionales por trabajos re-trabajos fuera de

horario laboral y otros gastos imputables al retraso de la implementación.

Gráfica 36. Porcentaje de variación del costo de implementación respecto al planteado en un inicio (Elaboración propia).

1 a 100 55% 100 a 200

27%

mas de 200 18%


IPN UPIICSA 85

4.1.8 Porcentaje de las empresas que cubrieron sus necesidades

Las empresas que no cubrieron sus necesidades o expectativas fueron un 61%,

contra un 39% que sí. La mayoría por un tema de reportes, procesos y controles

que tenían que llevar por fuera del sistema. Véase la gráfica 37.

Al final de la implementación muchas de las empresas ya no quisieron invertir en

mejoras, dado que ya se habían salido del presupuesto original.

Gráfica 37. Porcentaje de las empresas que cubrieron sus necesidades (Elaboración propia).

Si 39%

No 61%


IPN UPIICSA 86

4.1.9 Factores críticos por lo que no se tuvo una implementación exitosa

Los factores críticos por los que no se tuvieron implementaciones exitosas, fueron

muy diversos, la mayoría de los encuestados coincidieron en Metas y Objetivos

Claros con un 14%, seguido por Renuencia al cambio con un Compromiso de la

Dirección (poco involucramiento), no se tenían, véase la gráfica 38.

Gráfica 38. Factores críticos por lo que no se tuvo una implementación exitosa (Elaboración propia).

Para apoyo a la gestión / Top compromiso de la

dirección 11%

Formación de usuarios y de educación /

Empleados de formación 7%

El desarrollo de software, pruebas y resolución de

problemas 6%

Personalización mínima / Implementación de caja

5%

Metas y objetivos claros. 14%

Cooperación interdepartamental.

4% Tiempo de

implementación. 3%

Rigides del sistema 5%

La mayor parte de los usuarios no sabian lo que

implicaba el proyecto 3%

No se involucro a personal operativo en las revisiones, solo gerentes

4%

Rotacion de personal durante la

implementación 5%

Renuencia al cambio 10%

Pretender organizar la empresa con el sistema

8%

No se contaba con procesos documentados

desde un inicio 6%

Falta de conocimiento de los consultores del producto o de los

procesos del giro de la empresa

5%

Falta de documentación de lo implementado (configuración del

sistema, manuales, guías de capacitación).

4%


IPN UPIICSA 87

4.2 Comparación de información obtenida vs estudios realizados por otros

investigadores

En cuanto a los resultados obtenidos a través de la encuesta se encontraron

puntos que coincidieron no solo entre los entrevistados sino también con los

autores que fueron analizados y que llevaron a cabo estudios similares al

respecto, los factores críticos de éxito coincidentes se muestran en la tabla 39.

No. Factores críticos de éxito del estudio en campo,

“coincidentes” con otros estudios de la literatura

Responsable

1 Para apoyo a la gestión / alto compromiso de la dirección.

Cliente

2 Formación de usuarios y de educación / empleados de formación.

Cliente

3 El desarrollo de software, pruebas y resolución de problemas.

Proveedor

4 Personalización mínima. Cliente

5 Metas y objetivos claros. Cliente

6 Cooperación interdepartamental. Cliente

7 Tiempo de implementación. Cliente

Tabla 39 Factores críticos de éxito coincidentes con otros estudios (Elaboración propia).

También se detectaron algunos factores adicionales que más de 5 empresas

mencionaron y que no necesariamente coincidieron con los resultados de los

autores analizados. En la tabla 40 se listan los puntos donde más de 5

encuestados mencionaron alguno o varios de ellos.

No. Factores críticos de éxito del estudio en campo,

“no coincidentes” con otros estudios de la literatura

Responsable

8 Rigidez del sistema. Cliente

9 Implementación de caja. Cliente

10 No se revisó ni aprobó un prototipo. Cliente y

proveedor


IPN UPIICSA 88

11 La mayor parte de los usuarios no sabían lo que implicaba el proyecto.

Cliente

12 No se involucró a personal operativo en las revisiones, solo gerentes.

Cliente

13 No se evaluó al personal que participaría y utilizaría el sistema.

Cliente

14 No existieron laboratorios de pruebas. Cliente y

proveedor

15 Rotación de personal durante la implementación. Cliente y

proveedor

16 Renuencia al cambio. Cliente

17 Pretender organizar la empresa con el sistema. Cliente

18 No se contaba con procesos documentados desde un inicio.

Cliente

19 Falta de conocimiento de los consultores del producto o de los procesos del giro de la empresa.

Proveedor

20 Cambio de los consultores que inicialmente iniciaron el proyecto (rotación).

Proveedor

21 Capacitación deficiente. Proveedor

22 Falta de documentación de la implementación (configuración del sistema, manuales, guías de capacitación).

Proveedor

Tabla 40 Factores críticos de éxito detectados adicionalmente (Elaboración propia).

4.3 Resultado de la comprobación de la problemática

Al observar detenidamente cada uno de los elementos de las tablas 39 y 40 se

observa que la gran mayoría dependen del cliente con un 64%, un 23% son

imputables el proveedor y un 14% a ambos.

Por lo tanto en la mayoría de los casos el cliente es directamente responsable o es

corresponsable, dando como resultado que el cliente sea el responsable en

prácticamente tres cuartas partes de los factores encontrados.

Existe un primer grupo de factores que prácticamente desde un inicio el cliente

decidió que fueran así, como son los de personalización mínima, implementación


IPN UPIICSA 89

de caja, pretender organizar la empresa con el sistema, poca o nula evaluación y

no involucrar a usuarios operativos para ciertas actividades.

En un segundo grupo están los factores que podrían no ser tan controlables como

la rotación de personal, la resistencia al cambio y cooperación interdepartamental,

aunque se pudo hacer un trabajo de prevención para cubrirlos, éste último podría

ser un tema para otro estudio.

Un tercer grupo de factores, por desconocimiento no los exigió el cliente a su

proveedor desde un inicio, como un buen método de capacitación, documentación

del proyecto, laboratorios de pruebas, manuales o guías de capacitación, entre

otras.

Y un cuarto grupo de factores son los que el cliente pudo haber preparado desde

antes de empezar la implementación como los procesos documentados y los

objetivos claramente establecidos y documentados (alcance).

Por lo anterior todo esto nos da como resultado que el desconocimiento e

imprecisión de los requerimientos en las organizaciones, da como consecuencia,

incrementos en tiempo y costo del proyecto de implementación de un sistema ERP

en las PyMEs de la Zona Metropolitana del Valle de México, así como considerar

que una implementación no fue exitosa.

Con base a la información de las tablas 39 y 40, donde se obtuvieron tanto

elementos coincidentes como adicionales y en respuesta a la pregunta original

que plantea esta tesis de, si ¿es necesario contar con ciertos elementos mínimos

para que se logre llevar a cabo una implementación de un sistema ERP en

PYMES de la Zona Metropolitana del Valle de México de forma exitosa o es

suficiente con contratar a un proveedor con buenas referencias para dicho fin?, se

observa que no todos los elementos dependen del proveedor, sino que, hay

aspectos con los que las organizaciones deben de contar cuando van a llevar a

cabo una implementación de un sistema ERP.


IPN UPIICSA 90

CONCLUSIONES

Esta tesis lo que buscó comprobar es si las organizaciones deben contar con

ciertos elementos, previo a la implementación de un ERP o pueden confiar en que

un proveedor experto les implemente sin ninguna preparación previa, el resultado

fue que la mayoría de los factores críticos de éxito son responsabilidad del cliente,

por lo tanto deben tener muy claros sus objetivos y estar informados de lo que

implica la implementación de un sistema ERP, las metodologías de

implementación y las herramientas que existen en el mercado para documentar

sus requerimientos, estos últimos se recomienda tenerlos antes de llevar a cabo

una implementación.

Un proceso de implementación de un sistema ERP está dividido en 3 grandes

fases: el antes, el durante y el posterior al arranque o puesta en marcha (Go-live).

La primera fase “el antes de la implementación” debe cubrirse adecuadamente con

el máximo de aseguramiento para que las fases durante y posterior a la

implementación no sean costosos, desgastantes y decepcionantes.

Las palabras clave en todo momento es “aseguramiento y documentación”,

asegurarse de que las cosas primero estén debidamente requeridas, planteadas y

posteriormente documentadas, para que no se pierdan en el camino y se vigile

que se cumplan como parte de la implementación.

Si al momento de seleccionar el sistema ERP, éste no cuenta con lo necesario

para cubrir todos los requerimientos, se debe decidir si, se esperan a contar con

todo lo necesario para la implementación, se desarrollan en una segunda etapa o

se emprende la búsqueda de otro sistema ERP. Otro punto a negociar es si los

desarrollos tendrán costo para el cliente o los absorberá el proveedor. Dando con

esto claridad desde un inicio del alcance del proyecto.

Las metodologías de implementación generalmente están enfocadas a la segunda

y tercera fase, la primera fase la tratan como un proceso meramente comercial

donde a lo más que llegan es a hacer un diagnóstico de manera general. Mientras

no exista un compromiso comercial en ésta primera fase es responsabilidad del

cliente todo lo que ocurra en adelante, el cliente es quién debe tener muy claro el

objetivo del proyecto, con qué recursos cuenta y en qué tiempo necesita concluir

la implementación.


IPN UPIICSA 91

La implementación de un sistema ERP es una actividad de corresponsabilidad

entre dos entes el cliente y el proveedor, por lo tanto en cualquier contingencia

alguno de los dos o ambos tendrán que absorber los costos que esto implique, es

por eso que se deben tomar todas las precauciones de aseguramiento desde un

inicio.

La correcta ejecución de la fase 1 permitirá dar durante la segunda fase

seguimiento puntual al proceso de implementación, con todo debidamente

controlado y documentado, además contar con un mapa de comunicación

organizativamente establecido entre el cliente y el proveedor para la correcta

información de avances en todo momento -estatus del proyecto-, para que al final

se tengan elementos para determinar si fue una implementación exitosa y si no

tener clara la razón.

La implementación de un sistema ERP en cualquier empresa nunca termina, una

vez que se empieza a utilizar el sistema, comienza un proceso de mantenimiento,

mejoras y actualizaciones, una vez operando nos daremos cuenta si en realidad

nuestros cálculos de mejoras se ven cumplidas y seguramente se encontrarán lo

que algunos denominan áreas de oportunidad, que pudieran cubrirse con algunas

adaptaciones adicionales, inclusive no debemos descartar una re-implementación

completa de ser necesario o hasta un cambio de producto, obviamente con todo el

proceso de justificación que esto amerita, evaluando el costo-beneficio.

Una vez que se terminó de llevar a cabo una implementación se puede hacer una

revisión post-mortem, para analizar lo que se hizo bien y mal del proyecto, así

como la viabilidad de mejorar algunos puntos en una segunda etapa.

Un gran error es pensar que el sistema va a corregir todas las deficiencias

funcionales de la empresa, la empresa debe estar preparada para el cambio, debe

ser flexible y tener una fuerte cultura organizacional preparada para afrontarlo,

debe estar dispuesta a cambios organizacionales.

Existe un vínculo entre los beneficios de ERP y las metas estratégicas, por lo

tanto, los objetivos o los factores críticos de éxito son relativos no absolutos, en

términos de lo que específicamente se puede esperar.

Si se considera tener el conocimiento mínimo para emprender una

implementación, si se tienen en cuenta los factores críticos de éxito listados en el

capítulo 2 así como los factores adicionales detectados en esta tesis, se tiene una


IPN UPIICSA 92

alta probabilidad de acercarse más a una “implementación exitosa de un sistema

ERP en empresas PyME de la Zona Metropolitana del Valle de México”.

Las limitaciones de esta tesis estriban en que no abarca un estudio de porqué en

algunas organizaciones se toman algunas decisiones contundentes y en

ocasiones arriesgadas, como por ejemplo el forzar a la organización a que se

adapte al sistema ERP en lugar de hacer que el sistema de adapte a la

organización.

Otra limitante de este estudio son que sería algo difícil hacer pruebas de lo aquí

comentado, es decir, hacer una implementación sin preparación y otra con

preparación para medir el impacto de una y otra, sería complejo y costos, por lo

tanto debemos basarnos en la historia de las malas experiencias que han tenido

algunas organizaciones para darnos cuenta de lo que podríamos mejorar y

asegurarnos en todo momento de lo más posible.

Una limitante más que también tiene este estudio es que en proyectos de

implementación se trabaja con gente y cada persona es diferente en todos los

aspectos, por ende tienen diferentes capacidades, planes y necesidades. Es un

tema que también sería difícil medir al momento de implementar y que también

puede influir en una implementación.

Los estudios que se sugieren derivados de esta tesis son, acerca del

comportamiento del ser humano durante un implementación de un sistema ERP,

la medición y análisis en organizaciones que hayan aplicado lo indicado en este

estudio en un lapso de tiempo, el porqué de la toma de decisiones abruptas y

contundentes a costa de muchos factores que pudieran afectar las organizaciones

y lo beneficioso que pudieran resultar en un futuro.


IPN UPIICSA 93

GLOSARIO DE TÉRMINOS, ABREVIATURAS Y ACRÓNIMOS

Término Significado

ERP Los sistemas de planificación de recursos empresariales (por sus siglas

en inglés, Enterprise Resource Planning).

CRM Administración basada en la relación con los clientes (por sus siglas en

inglés, Customer Relationship Management).

CSF Factores críticos de éxito (por sus siglas en inglés, Critical Success

Factors).

Implementación

(Implantación)

Una implementación es la instalación de una aplicación informática,

realización o la ejecución de un plan, idea, modelo científico, diseño,

especificación, estándar, algoritmo o política.

(Distíngase siempre el término implementación de implantación,

puesto que una implantación se realiza de forma impuesta u

obligatoria al usuario sin importar su opinión; en cambio en la

implementación se involucra al usuario en el desarrollo de lo que se

está realizando).

Requerimiento Algo que se le pide o solicita a alguien.

Proceso Conjunto de actividades mutuamente relacionadas o que al interactuar

juntas en los elementos de entrada y los convierten en resultados.

Procedimiento Conjunto de acciones u operaciones que tienen que realizarse de la misma

forma, para obtener siempre el mismo resultado bajo las mismas

circunstancias (por ejemplo, procedimiento de emergencia).

Software Equipamiento lógico o soporte lógico de un sistema informático, que

comprende el conjunto de los componentes lógicos necesarios que hacen

posible la realización de tareas específicas, en contraposición a los

componentes físicos que son llamados hardware.

Hardware Se refiere a todas las partes físicas de un sistema informático; sus

componentes son: eléctricos, electrónicos, electromecánicos y mecánicos.

Son cables, gabinetes o cajas, periféricos de todo tipo y cualquier otro

elemento físico involucrado; contrariamente, el soporte lógico es

intangible y es llamado software. El término es propio del idioma inglés


IPN UPIICSA 94

(literalmente traducido: partes duras).

Paquete de software Un paquete de software es una serie de programas que se distribuyen

conjuntamente. Algunas de las razones suelen ser que el funcionamiento

de cada uno complementa a o requiere de otros, además de que sus

objetivos están relacionados como estrategia de mercadotecnia.

Metodología Conjunto de procedimientos racionales utilizados para alcanzar una gama

de objetivos que rigen una investigación científica, una exposición

doctrinal o tareas que requieran habilidades, conocimientos o cuidados

específicos. Alternativamente puede definirse la metodología como el

estudio o elección de un método pertinente para un determinado

objetivo.

Adaptaciones al sistema Modificaciones o adecuaciones que se pueden hacer a un ERP a través de

alguna, también conocidas como personalizaciones.

MB Un megabyte (MB) o megaocteto (Mo) es una cantidad de datos

informáticos. Es un múltiplo del byte u octeto, que equivale a 106 B (un

millón de bytes).

GB Un gigabyte es una unidad de almacenamiento de información cuyo

símbolo es el GB, equivalente a 109 (mil millones) bytes. Muchas veces se

confunde con 230 bytes, igual a un gibibyte de acuerdo con las normativas

IEC 60027-2 y la IEC 80000-13:2008 publicadas por la Comisión

Electrotécnica Internacional.

PMBok Libro sobre el cual está basada la metodología de implementación del

Instituto de Administración de Proyectos (PMI).

PMI Instituto de Administración de Proyectos (por sus siglas en inglés, Project

Management Institute).

TI Tecnología de Información.

SI Sistemas de Información

FCE Factores Críticos de Éxito.

AIP Programa de Implementación Acelerada (por sus siglas en inglés,

Accelerated Implementation Program)

Retail Venta al detalle (en inglés retail) es un sector económico que engloba a

las empresas especializadas en la comercialización masiva de


IPN UPIICSA 95

productos o servicios uniformes a grandes cantidades de clientes. Es el

sector industrial que entrega productos al consumidor final.

Retaileras Empresas comercializadoras que venden productos a empresas

detallistas (retail).

Microsoft Dynamics Familia de productos de Microsoft que engloban 4 sistemas ERP para

diferentes industrias: AX, NAV, SL y GP.

Go-live Puesta en marcha, arranque del proyecto.

BMP Gestión de proceso de Negocio (por sus siglas en inglés Business

Process Management).

CEO Director de la Empresa (por sus siglas en inglés Chief Executive Officer).

SDLC Ciclo de Vida del Desarrollo de Sistemas (por sus siglas en inglés,

System Development Life Cicle).


IPN UPIICSA 96

BIBLIOGRAFÍA

ACE. (01 de 01 de 2015). Calendario para la implementación de un proyecto. Recuperado el 01 de

01 de 2015, de The Electoral Knowledge Network:

http://aceproject.org/main/espanol/et/default

Akkermans, H. A. (2002). Vicious And Virtuous Cycles In ERP Implementation; A Case Study Of

Interrelations Between Critical Success Factors. European Journal Of Information Systems,

35-46.

Akkermans, H., & Van Helden, K. (2002). Vicious and virtuous cycles in ERP implementation: a case

study of interrelations between critical success factors. European Journal of Information

Systems, June, 35-46.

Albarran, M., & Escobar, G. (2001). Método de Investigación. México: Grupo Editorial Patria, (134-

142).

Allen, D. (1997). Multisite implementation: Special strategies. APICS 1997 International Conference

Proceedings, Falls Church, VA, 551–555.

Al-Mashari, M., & Zairi, M. (2000). Supply-chain re-engineering using enterprise resource planning

(ERP) systems: An analysis of a SAP R/3 implementation case. International Journal of

Physical Distribution & Logistics Management., 30, 296–313.

Al-Mudimigh, A. Z.-M. ( 2001). ERP Software Implementation: An Integrative Framework,.

European Journal Of Information Systems.

Angeles, M. e. (2000). Modelo de Referencia de Procesos y Capacidades, Modelo de Evaluación de

Procesos y Guía de Indicadores Según ISO 15504 (SPICE). Asociación Mexicana para la

Calidad en Ingeniería de Software (AMCIS).

Angerosa, A. (1999). The future looks bright for ERP. APICS––The Performance Advantage,

October, 5-6.

Argyris, C., & Schön, D. (1978). Organizational Learning: A Theory of Action Perspective. Reading,

MA.: Addison Wesley.

Arias Galicia, L. F. (2012). Metodología de la Investigación. México (Reimpresión): Ed. Trillas.

Austin, R., & Nolan, R. (1998). Manage ERP initiatives as new ventures, not IT projects. Harvard

Business School Working Paper, 99–024.

Avnet. (1999). ERP not living up to promise. Global Supply Chain 2, 7.


IPN UPIICSA 97

Bajwa, D., Garcia, J., & Mooney, T. (2004). An integrative framework for the assimilation of

enterprise resource planning systems: Phases, antecedents, and outcomes. Journal of

Computer Information Systems. Spring, 81-90.

Bingi, P., Sharma, M., & Golda, J. (1999). Critical issues affecting an ERP implementation.

Information Systems Management, 7-14.

Buckhout, S., Frey, J., & Nemec, J. (Abril de 1999). Making ERP succeed;turning fear into promise.

Recuperado el 01 de Diciembre de 2014, de Strategy and Business, Booz-Allen and

Hamilton: http://www.strategy-business.com

Burns, O., Turnipseed, D., & Riggs, W. (1991). Critical success factors in manufacturing resource

planning implementation. International Journal of Operations and Production

Management 11, 5–19.

CIO, I. C. (2002). Factores de Éxito en la Implantación de ERP en las Organizaciones. Factores de

Éxito en la Implantación de ERP en las Organizaciones (págs. 831-840). Vigo: CIO 2002.

Clancy, T. (1991 ). The Sum of All Fears. United States, (1st Edition): Putnam.

Davenport, T. (1998). Putting the enterprise into the enterprise system. Harvard Business Review,

July-August, 121-131.

Davenport, T. (2000). Mission Critical: Realizing the Promise of Enterprise Systems. Boston,

Massachusetts: HBS Press.

Davenport, T. H., & Harris, J. G. (2007). Competing on Analytics: The New Science of Winning.

United States of America: Harvard Business School Press.

David, F. R. (2003). Conceptos de Administración Estratégica. México: Pearson/Prentice Hall.

Davis, G. B. (s.f.). Sistemas de Información Gerencial. México: Ed. Mc Graw Hill.

Davis, M. (s.f.). Software Requirements: Analysis and Specification. Editorial Prentice Hall.

Davis., A. M. (1993). Software Requirements: objects, functions, and states. Editorial Prentice Hall

(1ª Edición).

De Bodinat, H. (s.f.). Como Razona un Estratega. Paris: Harvard l´expansion, Groupe l´expansion.

Dean Leffingwell, D. W. (1999). Managing Software Requirements: A Unified Approach. Addison-

Wesley.


IPN UPIICSA 98

Deleon, W., & Mclean, E. (1992). Information Systems Success: The Quest For The Dependent

Variables. Information Systems Research, Vol.3, No.1, March, 60-95.

Dillon, C. (1999). Stretching toward enterprise flexibility with ERP. APICS––The Performance

Advantage, October, 38–43.

Estandar. (1984). IEEE Guide to Software Requirements Specifications. Instituto de ingenieros en

eléctrica y electrónica (IEEE), ANSI/IEEE 830-1984.

Esteves, J., & Pastor, J. (2001). Enterprise Resource Planning Systems Research: An Annotated

Bibliography. Communications of the Association for Information Systems (CAIS), 7 (8),

August.

Everdingen, Y., Hillergersberg, J., & Waarts, E. (2000). ERP adoption by European midsize

companies. Communications of the ACM, 43 (3), April, 27-31.

Ewushi-Mensah, K., & Przanyski, Z. (1991). On information systems project abandonment: an

exploratory study of organizational practices. practices. MIS Quarterly, 15, 67–85.

Fitzgerald, B. A. (1999). A Longitudinal Study Of Software Process Improvement. IEEE Software,

Vol. 16, No. 3, 37-45.

Francois Lacouture, J. (2014). Seminario de Ingeniería Eléctrica-Electrónica. FI-UNAM, Tema 2.

Garelli, S. (2008). Competitiveness 20 Years Later. IMD World Competitiveness Yearbook.

Ginzberg, M. (1981). Early diagnosis of MIS implementation failure: promising results and

unanswered questions. Management Science, 27, 459–476.

Gremillion, L., & Pyburn, P. (1983). Breaking the system development bottleneck. Harvard Business

Review, 61 (2), March-April, 130-137.

Griffith, T., Zammuto, R., & Aiman-Smith, L. (1999). Why new technologies fail? Industrial

Management, May-June, 29-34.

Gruia-Catalin, R. (01 de 01 de 2015). UNM Computer Scientist. Recuperado el 01 de 01 de 2015, de

UNM Computer Scientist: http://www.cs.unm.edu/directory/faculty-profiles/gruia-catalin-

roman.html

Hammer, M., & Stanton, S. (1999). How processes enterprise really work. Harvard Business

Review, November-December, 108-118.

Henderson, J., & Venkatraman, N. (1993). Strategic alignment: leveraging information technology

for transforming organizations. IBM Systems Journal, 32 (1), 4-16.


IPN UPIICSA 99

Henderson, R. (1989). Bruce “The Origin of Strategy”. Harvard Business Review.

Hoffer, J., George, J., & Valacich, J. (1998). Modern Systems Analysis and Design (2nd edn).

Reading, MA.: Addison-Wesley.

Holland, C., & Light, B. (1999). A critical success factors model for ERP implementation. IEEE

Software, Mayo-Junio, 30-36.

Hong, K., & Kim, J. (2002). The critical success factors for ERP implementation: an organizational fit

perspective. Information & Management, 25-40.

Hopp, W., & Spearman, M. (1996). Factory physics: foundations of manufacturing management, .

Irwin.

IEEE. (1984). IEEE Guide to Software Requirements Specifications. ANSI-IEEE 830.

INEGI. (2009). Censos Económicos (2009), Micro, Pequeña, Mediana y Gran Empresa:

Estratificacion de los Establecimientos. México: INEGI.

Intelligenia. (14 de 03 de 2013). Intelligenia. Recuperado el 26 de 04 de 2015, de Ingenieria

Inteligente: http://blog.intelligenia.com/2013/03/de-una-idea-una-realidad.html

Ivar Jacobson, G. B. (2000). El Proceso Unificado de Desarrollo de Software. Addison Wesley.

Jackson, M. (1995). Software Requirements & Specifications: A Lexicon of Practice, Principles and

Prejudices. Editorial Addison-Wesley (1a ed).

Janson, M., & Subramanian, A. (1996). Packaged software: selection and implementation policies.

INFOR, 34, 133–151.

Jarrar, Y. A.-M. (2000). ERP Implementation Critical Success Factors–The Role And Impact Of

Business Process Management. Icmit.

Jarvenpaa, S., & Ives, B. (1991). Executive involvement and participation in the management of

information technology. MIS Quarterly, 15, 205–227.

Jeffrey, B. (1980). The Historical Development of The Strategic Management Concept (vol 5).

Academy of Managemet Review.

Katzenbach, J., & Smith, D. (1993). The Wisdom of Teams. Creating the High-Performance

Organization. Cambridge, MA.: Harvard Business School Press.

Klaus, H., Rosemann, M., & Gable, G. (2000). What Is ERP? Information Systems Frontiers, August,

141-157.


IPN UPIICSA 100

Kumar, K., & Hillergersberg, J. (2000). ERP Experiences and Evolution. Communication of the ACM,

Vol 43, 23-26.

Laudon, K., & Laudon, J. (1996). Management Information Systems: Organization and Technology.

Prentice Hall.

Lee, Z., & Lee, J. (2000). An ERP Implementation Case Study from a Knowledge Transfer

Perspective. Journal of Information Technology, vol. 15, n. 4, 281-288.

Leonard-Barton, D. (1988). Implementation as mutual adaptation of technology and organization.

Research Policy, 251-267.

Loizos, C. (1998). ERP: Is it the ultimate software solution. Industry Week 7, 33.

Lyytinen, K., & Hirschheim, R. (1987). Information Systems Failure: A Survey and Classification of

The Empirical Literature’, in P.I. Zorkoczy (ed.), Oxford Surveys in Information Technology,

vol. 4. Oxford: Oxford University Press.

Mabert, V., Soni, A., & Venkataramanan, M. (2002). Sistemas ERP: mitos comunes versus realidad

evolutiva. Harvard Deusto Business Review, 106, 74-82.

Macredie, R., & Sandom, C. (1999). IT-enabled change: evaluating an improvisational perspective.

European Journal of Information Systems, 8, 247–259.

Marble, R. (2000). Operationalising the implementation puzzle: an argument for eclecticism in

research and in practice. European Journal of Information Systems, 9, 132–147.

Markus, M., & Robey, D. (1988). Information technology and organizational change: causal

structure in theory and research. Management Science, 34 (5), May, 583-598.

Markus, M., & Tanis, C. (2000). The enterprise systems experience – from adoption to success, in

R.W. Zmud, Framing the Domains of IT Research: Glimpsing the Future Through the Past.

Cincinnati, OH: Pinnaflex Educational Resources, Inc.

McGrath, J. (1984). Groups: Interaction and Performance. Englewood Cliffs, NJ: Prentice-Hall.

McKersie, R., & Walton, R. (1991). Organizational Change. In The Corporation of the 1990s:

Information Technology and Organizational Transformation. Oxford University Press, New

York.: Scott Morton MS, 244–277.

McKersie, R., & Walton, R. (1991). Organizational Change. In The Corporation of the 1990s:

Information Technology and Organizational Transformation. Oxford University Press, New

York: Scott Morton MS.


IPN UPIICSA 101

Microsoft. (01 de 01 de 2015). Metodología de Implementacion Sure Step. Recuperado el 01 de 01

de 2015, de Sure Step: http://msdn.microsoft.com/en-

us/library/dd979122%28v=crm.6%29.aspx;

http://www.axaptapedia.com/Sure_Step_Methodology

Mitchell, V., & Zmud, R. (1995). Strategy congruence and BPR rollout. In V. Grover & W. Kettinger

(Eds.), Business process change: Reengineering concepts, methods and technologies.

London: Idea Group (428–452).

Mumford, E. (1983). Designing Human Systems for New T. Manchester Business School,

Manchester.

Murdick, R. G. (1988). Sistemas de Información Administrativa. México: Ed. Prentice Hall

Hispanoamericana (2 ed.), Florida Atlantic University.

Network, A. T. (01 de 01 de 2015). ACE The Electoral Knowledge Network. Recuperado el 01 de 01

de 2015, de ACE The Electoral Knowledge Network:

http://aceproject.org/main/espanol/et/default

Oden, H., Langenwalter, G., & Lucier, R. (1993). Handbook of Material and Capacity Requirements

Planning. New York: McGraw-Hill.

O'Leary, D. (2000). Game Playing Behavior in Requirements Analysis, Evaluation, and System

Choice for Enterprise Resource Planning Systems. International Conference on Information

Systems ICIS, Brisbane, Australia.

Onur, K., & Eray , U. (2003). Critical Success Factors Affecting The Success Of An ERP Systems

Implementation. Department Of Management Information Systems, Istanbul, Turkey.

Oz, E. (2008). Administración de los Sistemas de Información. México: Thomson (5ª ed.).

Parr, A., & Shanks, G. (2000a). A Taxonomy Of ERP Implementation Approaches. IEEE Proceedings

Of The 33rd Hawaii International Conference On System Science, 1-10.

Parr, A., & Shanks, G. (2000b). A Model of ERP Project Implementation. Journal of Information

Technology, 289-304.

Partsch, H. A. (1990). Specification and Transformation of Programs. A Formal Approach to

Software. New York: Springer-Verlag Berlin Heidelberg (1ª. Edición).

Piturro, M. (1999). How midsize companies are buying ERP. Journal of Accountancy 188, 41–48.

PMI. (01 de 01 de 2015). La metodología del PM (basada en la guía del PMBok). Recuperado el 01

de 01 de 2015, de Project Management Institute: http://www.pmi.org


IPN UPIICSA 102

Pressman, R. S. (1998). Ingeniería de Software. Editorial Mc Graw Hill (4ª Edición).

Ptak, C., & Schragenheim, E. (2000). ERP: Tools, Techniques, and Applications for Integrating the

Supply Chain. Boca Raton, FL: St. Lucie Press.

Recopiladores: Thayer, D. (1990). System and Software Requirements Engineering. IEEE.

Reel, J. (1999). Critical success factors in software projects. IEEE Software, 16, 18–23.

Richmond, B. (1993). Systems thinking: critical thinking skills for the 1990s and beyond. System

Dynamics Review, 9, 113–133.

Ryan, H. (1999). Managing development in the era of large complex systems. Information Systems

Management, 16, 89–91.

Sallenave, J. P. (1994). Gerencia Integral y Planeación Estratégica. Bogotá: Ed. Norma.

SAP Partner Edge. (01 de 05 de 2015). SAP Partner Edge. Recuperado el 01 de 05 de 2015, de SAP

Partner Edge: https://websmp110.sap-ag.de/smb/sbo/aip

Schwalbe, K. (2000). Information Technology Project Management. Course Technology.

Senge. (1990). The Fifth Discipline. New York: Doubleday Currency.

Shang, S., & Seddon, P. (2000). A Comprehensive framework for classifying the benefits of ERP

systems. Proceedings of the Sixth Americas Conference on Information Systems, Long

Beach, Ca. August., 10–13.

Shankarnarayanan, S. (Marzo de 2000). ERP systems––using IT to gain a competitive advantage.

Recuperado el 1 de 12 de 2014, de Indian Express:

http://www.expressindia.com/newads/bsl/ advant

Sieber, M. N. (1999). A Recurring Improvisational Methodology for Change Management in ERP

Implementation. Americas Conference on Information Systems, AMCIS, Milwaukee, USA.

Slevin, D., & Pinto, J. (1987). Balancing Strategy and Tactics in Project Implementation. Sloan

Management Review, 29, 1, 33-41.

Soliman, F., & Youssef, M. (1998). The role of SAP software in business process reengineering.

International Journal of Production and Operations Management, 19, 886–895.

Somers, T., & Nelson, K. (2001). The impact of critical success factors across the stages of

enterprise resource planning implementations. Proceedings of the 34th Hawaii

International Conference on Systems Sciences (págs. Proceedings of the 34th Hawaii


IPN UPIICSA 103

International Conference on Systems Sciences (HICSS-3), January 3–6 Maui, Hawaii (CD-

ROM). Maui, Hawaii, January 3–6: HICSS-3.

Sommerville, I., & Sawyer, P. (1997). Requirements Engineering (Ingeniería de Requerimientos).

Biblioteca de la DGSCA, UNAM. Clasificación: QA76.6 S6453. ISBN 0-471-974444-7:

Editorial John Wiley & Sons, 1ª Edición.

Stallaert, M., & Whinston, A. (2000). The adoption and design methodologies of component-based

enterprise systems. European Journal of Information Systems, 25-35.

Standish Group. (2001). Chaos. Standish Group, www.standishgroup.com.

Standish Group. (2006). Chaos. Standish Group, www.standishgroup.com.

Stefanou, C. (1999). Supply Chain Management (SCM) and organizational key factors for successful

implementation of Enterprise Resource Planning (ERP) systems. Proceedings of the

Americas Conference on Information Systems, Milwaukee, WI., 800–802.

Sumner, M. (1999). Critical success factors in enterprise wide information management systems.

Proceedings of the Americas Conference on Information Systems, Milwaukee WI, 232-234.

Thong, J. (1999). An integrated model for information systems adoption in smes. Journal of

Management Information Systems, No. 15, 187-214.

Thong, J., Yap, C., & Raman, K. (1994). Engagement of external expertise in information systems

implementation. Journal of Management Information Systems, 11, 209–231.

Turban, E., Mclean, E., & Wetherbe, J. (2003). Information Technology For Management, Wiley,

USA. Wiley, USA.

Umble, E., Haft, R., & Umble, M. (2003). Enterprise resource planning: Implementation procedures

and critical success factors. European Journal of Operational Research, 241-257.

Volkoff, O. (1999). Enterprise system implementation: a process of individual metamorphosis.

American Conference on Information Systems.

Willcocks, L., & Sykes, R. (2000). The role of the CIO and IT function in ERP. Communications of the

ACM, 43, 33-38.

Zhang, L., Lee, M., & Banerjee, P. (2002). Critical Success Factors Of Enterprise Resource Planning

Systems Implementation Success In China. IEEE Proceedings of the 36th Hawaii

International Conference on System Sciences, 1-10.


IPN UPIICSA 104


IPN UPIICSA 105

ANEXOS

1. Cuestionario aplicado para el levantamiento de información en las

organizaciones.

T E S I S - 148.204.210.201148.204.210.201/tesis/1443798581687TesisCarlosI.pdf · instituto...

Documents

Transcript of T E S I S - 148.204.210.201148.204.210.201/tesis/1443798581687TesisCarlosI.pdf · instituto...