Metodología de integración de las Tecnologías de Información a las micro empresas

DEDICATORIA
Dedico esta tesis a mi escuela FUNIBER,
a mi esposa Susana,
y a todas las micro-empresas de México.
César Prieto.
“Lo importante en la ciencia no es tanto obtener nuevos datos, sino
descubrir nuevas formas de pensar sobre ellos.”
(William Lawrence Bragg)

AGRADECIMIENTOS
Gracias a dios por darme la fuerza de vivir y pensar.
Agradezco enormemente a todos mis profesores del máster, a mi escuela Fundación
Universitaria Iberoamericana (FUNIBER), y a mi tutor Saúl Domingo Soriano por haberme
guiado en esta meta que he emprendido y me ha alentado a terminar.
Agradezco a todos los autores referenciados en la bibliografía de este documento porque
en sus trabajos me he apoyado para lograr mi objetivo.
Agradezco a mi esposa Susana por haberme tenido la paciencia y el apoyo incondicional,
que sin estos hubiera sido imposible lograr mi meta.
Agradezco a todas las empresas que he conocido en el entorno laboral por haberme
dado la oportunidad de colaborar con ellos y aplicar mis conocimientos.
Agradezco a todas las personas que he conocido en la vida porque de ellos he aprendido
siempre un poco.
“Hay ciertas cosas que, para saberlas bien, no basta haberlas aprendido”
(Lucio Anneo Séneca)
César Prieto.

COMPROMISO DE AUTOR
Yo, César Jacobo Prieto Barrientos con cédula de identidad MEMDEISW900023 y
alumno del programa académico Maestría en Dirección Estratégica en Ingeniería de
Software, declaro que:
El contenido del presente documento es un reflejo de mi trabajo personal y manifiesto
que ante cualquier notificación de plagio, copia o falta a la fuente original, soy
responsable directo legal, económico y administrativo sin afectar al Director del trabajo, a
la Universidad y a cuantas instituciones hayan colaborado en dicho trabajo, asumiendo
las consecuencias derivadas de tales prácticas.
Firma: ___________________________

Mazatlán Sinaloa, México, 11 de julio de 2018
Att: Dirección Académica
Por este medio autorizo la publicación electrónica de la versión aprobada de
mi Proyecto Final bajo el título Metodología (ligera) para la integración de TI a la
cadena de valor empresarial. Caso: Micro-empresas en Mazatlán, Sinaloa, México
en el campus virtual y en otros espacios de divulgación electrónica de esta
Institución.
Informo los datos para la descripción del trabajo:
Título
Metodología (ligera) para la Integración de TI a la Cadena de
Valor Empresarial. Caso: Micro-empresas en Mazatlán, Sinaloa,
México.
Autor César Jacobo Prieto Barrientos
Resumen
Desarrollo de una “Metodología ligera para la Integración de las
TI a la Cadena de Valor Empresarial” tomando como base las
ventajas que ofrecen los modelos y metodologías actuales para
la integración de TI, adaptando sus principios para poder ser
utilizada solo con los recursos que cuentan las micro-empresas
para incrementar su competitividad.
Programa - Maestría en Dirección Estratégica en Ingeniería de Software.
Palabras
clave
TI, MLITICVE, micro-empresa, Competitividad, Metodología
Contacto cesarjprieto@hotmail.com
Atentamente,
Firma: ___________________________

ii
ÍNDICE GENERAL
1. INTRODUCCIÓN......................................................................... 1
1.1. Motivación y enfoque............................................................................ 1
1.2. El problema general de la competitividad de las micro-empresas en
México............................................................................................................. 1
1.3. Estructura del trabajo ........................................................................... 3
2. OBJETIVOS, HIPOTESIS, ALCANCE........................................ 4
2.1. Objetivo General.................................................................................... 4
2.2. Objetivos Específicos ........................................................................... 4
2.3. Hipótesis (Descripción) ........................................................................ 4
2.4. Alcance................................................................................................... 5
3. MARCO TEÓRICO...................................................................... 6
3.1. Modelos y Metodologías de integración de TI a los procesos
empresariales................................................................................................. 6
3.1.1. Modelo ITIL ................................................................................................. 6
3.1.2. Modelo CMMI............................................................................................ 12
3.1.3. BPM ........................................................................................................... 14
3.1.4. SOA ........................................................................................................... 17
3.2. Conceptos teóricos de apoyo ............................................................ 23
3.2.1. Control estadístico de procesos ............................................................ 23
3.2.2. Ciclo de mejora continua ........................................................................ 24
3.2.3. Arquitectura Empresarial ó Arquitectura de Negocio .......................... 26
3.2.4. Cadena de valor ....................................................................................... 29
3.2.5. Proceso de Negocio................................................................................. 30
3.2.6. ROI............................................................................................................. 31
3.2.7. Investigación y Desarrollo ...................................................................... 33
3.3. Paradigmas de construcción y desarrollo TI.................................... 34
3.3.1. RAD (Diseño Rápido de Aplicaciones) .................................................. 34
3.3.2. Construcción de Prototipos.................................................................... 35
3.3.3. Espiral ....................................................................................................... 36
3.3.4. Programación extrema (XP).................................................................... 37
3.3.5. SCRUM...................................................................................................... 38
3.3.6. DAS (Desarrollo Adaptativo de Software) ............................................. 39
3.4. Competitividad..................................................................................... 41
3.4.1. Definición.................................................................................................. 41
3.4.2. Factores que afectan la competitividad empresarial............................ 41
4. SOLUCION PROPUESTA......................................................... 44
4.1. Descripción de la solución................................................................. 44
4.2. Alcance................................................................................................. 44
4.3. Acotando el Marco Teórico en base a los objetivos del proyecto.. 45
4.4. Diseño de la Metodología Ligera para la Integración de TI a la
cadena de Valor Empresarial (MLITICVE).................................................. 46

iii
4.4.1. Revisar y ajustar la arquitectura de negocio......................................... 46
4.4.2. Definir y asignar los procesos de valor................................................. 49
4.4.3. Gestión del proceso................................................................................. 50
4.4.4. Gestión por procesos............................................................................. 51
4.4.5. Gestión de proyectos de TI.................................................................... 52
5. METODOLOGIA DE INVESTIGACION .................................... 56
5.1. Hipótesis .............................................................................................. 56
5.2. Nivel y tipo de investigación .............................................................. 56
5.3. Procedimiento de indagación ............................................................ 56
5.4. Técnicas e instrumentos de recolección de datos .......................... 57
5.5. Variables............................................................................................... 57
5.6. Población y muestra ........................................................................... 59
5.7. Técnicas de procesamiento y análisis de datos .............................. 61
6. ANALISIS DE RESULTADOS .................................................. 62
6.1. Uso de las TI en las micro-empresas de Mazatlán Sinaloa México.62
6.2. Competitividad..................................................................................... 62
6.3. Incremento de la Competitividad con la ayuda de las TI................. 63
6.4. Plan de explotación de la MLITICVE.................................................. 66
6.5. Casos prácticos de la aplicación de la MLITICVE............................ 67
7. CONCLUSIONES...................................................................... 70
7.1. Cumplimiento de los objetivos .......................................................... 70
7.2. Limitaciones del Proyecto.................................................................. 71
7.3. Líneas de mejora ................................................................................. 71
8. RECOMENDACIONES.............................................................. 72
BIBLIOGRAFIA .............................................................................. 73

iv
ÍNDICE DE FIGURAS
Figura 1. 1: Probabilidad de muerte y esperanza de vida de las micro-empresas............................ 2
Figura 3. 1: Publicaciones que conforman ITIL ................................................................................. 6
Figura 3. 2: Proceso de Gestión de la Capacidad de acuerdo a ITIL.............................................. 11
Figura 3. 3: Vista de la Red de Valor de ITIL................................................................................... 11
Figura 3. 4: Dimensiones de la vista de Procesos del CMMI .......................................................... 12
Figura 3. 5: Histórico del desarrollo de CMMs................................................................................. 13
Figura 3. 6: Evolución de la Ingeniería de Procesos hacia el BPM................................................. 15
Figura 3. 7: Separación de la lógica de negocio y la lógica de TI ................................................... 20
Figura 3. 8: Evolución de los esquemas de integración empresarial soportada por las TI (SOA) .. 22
Figura 3. 9: Ciclo de Deming ........................................................................................................... 24
Figura 3. 10: Vista del Ciclo de desarrollo de la Arquitectura Empresarial (TOGAF)...................... 28
Figura 3. 11: Esquema de la Cadena de Valor de Michael Porter .................................................. 29
Figura 3. 12: Vista de procesos de la cadena de valor de Porter.................................................... 30
Figura 3. 13: Formula para el calculo del ROI................................................................................. 31
Figura 3. 14: Etapas del modelo RAD ............................................................................................. 35
Figura 3. 15: Modelo de construcción de prototipos........................................................................ 35
Figura 3. 16: Ciclos del modelo en espiral....................................................................................... 37
Figura 3. 17: Mapa de Programación Extrema................................................................................ 37
Figura 3. 18: Etapas del paradigma SCRUM .................................................................................. 38
Figura 3. 19: Ciclo de vida del modelo DAS.................................................................................... 40
Figura 4. 1: Vista de la Capacidad de la Arquitectura Empresarial para MLITICVE ....................... 47
Figura 4. 2: Vista de la arquitectura de negocio de la MLITICVE.................................................... 48
Figura 4. 3: Vista del Proceso.......................................................................................................... 50
Figura 4. 4: Gestión por procesos ................................................................................................... 51
Figura 4. 5: Gestión de Proyectos de TI en la MLITICVE................................................................ 55
Figura 5. 1: Numero de empresas por tamaño en el año 2014-2015.............................................. 59
Figura 5. 2: Formula para calcular el tamaño de la muestra en base al valor poblacional.............. 60
Figura 6. 1: Penetración de las TI por tamaño de empresa ............................................................ 63
Figura 6. 2: Visión Global de la Competitividad y TI........................................................................ 64
Figura 6. 3: Ejemplos del impacto de las TI en los 10 factores de competitividad .......................... 65
Figura 6. 4: Ubicación Geográfica de Mazatlán, Sinaloa, México ................................................... 66
Figura 7. 1: Diagrama de MLITICVE ............................................................................................... 70

v
ÍNDICE DE TABLAS
Tabla 1. 1: Estructura del Proyecto. .................................................................................................. 3
Tabla 2. 1: Objetivos específicos de la MLITICVE ............................................................................ 4
Tabla 3. 1: Características Principales del Modelo ITIL-V3.............................................................. 7
Tabla 3. 2: Objetivos de la librería del modelo ITIL .......................................................................... 8
Tabla 3. 3: Características principales de los servicios en SOA ..................................................... 21
Tabla 3. 4: Los ocho pasos para la solución de un problema vía PHVA......................................... 26
Tabla 3. 5: Etapas del modelo RAD ................................................................................................ 34
Tabla 3. 6: Etapas del modelo Construcción de Prototipos............................................................. 35
Tabla 3. 7: Etapas del modelo en espiral ........................................................................................ 36
Tabla 3. 8: Características y Factores de decisión de XP............................................................... 38
Tabla 3. 9: Características y factores del modelo SCRUM ............................................................. 39
Tabla 3. 10: Características y factores de decisión del modelo DAS.............................................. 40
Tabla 3. 11: Relación entre los factores internos y la competitividad.............................................. 43
Tabla 4. 1: Aplicación de los principios de modelos y metodologías a los objetivos de la MLITICVE
......................................................................................................................................................... 45
Tabla 4. 2: Análisis de paradigmas de desarrollo por criterio.......................................................... 53
Tabla 4. 3: Actividades de la MLITCVE........................................................................................... 55
Tabla 5. 1: Variables principales de interés en la MLITICVE .......................................................... 58
Tabla 5. 2: Descomposición de variables complejas en simples..................................................... 58
Tabla 5. 3: Definición de valores para calcular el tamaño de la muestra ........................................ 60
Tabla 6. 1: Uso de las TI en las micro-empresas del Caso............................................................. 62
Tabla 6. 2: Factores de competitividad en relación con las TI para las micro-empresas del Caso. 62
Tabla 6. 3: Casos prácticos de la aplicación de la MLITICVE......................................................... 68
Tabla 7. 1: Cumplimiento de los objetivos específicos.................................................................... 70

vi
RESUMEN
El deterioro competitivo es uno de los principales problemas de la corta vida de las micro-
empresas en México, menos de 2 años, una de las causas de este problema se debe a la
falta de procesos de valor bien definidos o bien gestionados.
El presente trabajo aporta una “Metodología Ligera para la Integración de Tecnologías de
Información a la Cadena de Valor Empresarial (MLITICVE)” que servirá para apalancar
los procesos empresariales y revertir el deterioro competitivo.
La metodología “MLITICVE” basa su procedimiento en los principios de los modelos
internacionales ITIL, CMMI, BPM, SOA y los paradigmas de construcción y desarrollo
de productos de TI.
Para dar una justificación formal a la propuesta de solución para el incremento de
competitividad mediante la integración de TI a los procesos empresariales, se desarrolla
una metodología de investigación científica de tipo explicativa de las causas del
deterioro competitivo en las micro-empresas Mexicanas, en la cual, se busca el por qué
de los hechos mediante el establecimiento de relaciones de causa y efecto entre la
competitividad de una micro-empresa y el apalancamiento de las TI a los procesos de
valor, tomando como caso de estudio a las micro-empresas de Mazatlán, Sinaloa,
México para evidenciar la relación de estas variables.
En base a los datos obtenidos de la metodología de investigación y aplicados al análisis
de resultados del uso de las TI, y a las acciones tomadas para el incremento de la
competitividad documentadas que se dan en las micro-empresas del caso, se harán
algunas recomendaciones de como la aplicación de una metodología como la
“MLITICVE” ayuda a revertir el deterioro competitivo para poder prevalecer en el entorno
cambiante en que están inmersas las micro-empresas.
Palabras clave
TI / TIC, MLITICVE, micro-empresa, Competitividad, Metodología.

vii
ABSTRACT
Competitive deterioration is one of the main problems of the short life of micro-enterprises
in Mexico, less than 2 years, this problem is due to the lack of well-defined or well-
managed value processes.
The present work provides a "Light Methodology for the Integration of Information
Technologies to the Enterprise Value Chain (LMIITEVC)", which will serve to leverage
business processes and reverse the competitive deterioration.
The methodology "LMIITEVC" bases its procedure on the principles of the international
ITIL, CMMI, BPM, SOA and paradigms of construction and development of IT
products.
In order to give a formal justification to the proposed solution to the increase of
competitiveness through the integration of IT to the business processes, a methodology of
scientific investigation of the type of explanatory of the causes of the competitive
deterioration in the Mexican micro-enterprises will be developed, in which, the search for
the facts through the establishment of cause and effect relationships between the
competitiveness of a micro-enterprise and the leverage of IT to value processes, taking
as a case study the micro-enterprises of Mazatlán , Sinaloa, Mexico to show the
relationship of these variables.
Based on the data obtained from the research methodology and applied to the analysis of
the results of the use of IT, and the actions taken to increase the competitiveness
documented in the micro-enterprises of the case, some recommendations will be done as
to how The application of a methodology such as "LMIITEVC" help to reverse the
competitive deterioration in order to prevail in the changing environment in which micro-
enterprises are immersed.
Keywords
IT / ICT, LMIITEVC, micro-enterprise, Competitive, Methodology

1
1. INTRODUCCIÓN
En México el sector comercial más rezagado en el ámbito de las TI son las micro-
empresas, pero, por otro lado es el que engloba al mayor número de empresas y
personas ocupadas, este sector constituye el principal andamiaje económico porque
representa el mayor porcentaje del total de las empresas, sin embargo, es el sector en el
que las empresas tienen el ciclo de vida más corto.
El presente trabajo aborda la problemática de competitividad que tienen las micro-
empresas Mexicanas por la falta de integración de las TI a sus procesos de valor.
1.1. Motivación y enfoque
En Mazatlán Sinaloa así como en las demás ciudades de la republica Mexicana la falta
de competitividad en el sector de las micro-empresas es un problema generalizado que
podemos aprovechar como nicho de mercado para comercializar la metodología
desarrollada en este documento (MLITICVE), como asesoría y consultoría comercial para
el incremento de la competitividad, por otro lado, si alguna de estas micro-empresas logra
mantenerse en el mercado y puede crecer por la aplicación de la metodología, entonces
estaremos contribuyendo con la economía de la región.
1.2. El problema general de la competitividad de las micro-empresas en
México
Las micro-empresas necesitan ser más competitivas en su sector comercial. Para la
mayoría de las empresas mexicanas en este sector la toma de decisiones en su gobierno
corporativo esta basado en análisis apresurado, llegando hasta la intuición, trayendo
como consecuencia el deterioro de la competitividad a corto y mediano plazo.
En un estudio realizado en la UANL (Universidad Autónoma de Nuevo León) sobre el
Modelo probabilístico de quiebra para pequeñas y medianas empresas mexicanas por
Juvencio Jaramillo Garza y Jesús Fernando García (Garza & García, 2013) dice:
No dudamos de la capacidad de los administradores de las mipyme, que muchos
tienen años haciendo lo mismo y otros nuevos emprendedores se suman a la
competencia y lucha por la preferencia de los clientes cada vez más desleales.
Sin embargo, lamentablemente ya no es suficiente con la experiencia o con la
intuición que se debe competir, esto pasa a segundo termino sin que dejen de ser
útiles. A estas herramientas del siglo pasado para gestionar empresas hay que
agregar la técnica y los conocimientos avanzados para ser exitosos en el
mantenimiento de la empresa a flote ante esta competencia cada vez más voraz.
(párr. 3)

2
En el boletín 087/15 del INEGI sobre la esperanza de vida de los negocios (INEGI:
Esperanza de vida de los negocios, 2015, p. 2) dice que: En México la probabilidad de que
una micro-empresa logre pasar el primer año de vida es de entre el “62% al 83%
dependiendo del numero de trabajadores, y de sobrevivir, su periodo de vida va de los
6.9 a los 15 años para empresas que tienen de 2 a 10 empleados” como lo muestra la
tabla de la figura 1.1.
Figura 1. 1: Probabilidad de muerte y esperanza de vida de las micro-empresas.
Fuente: (INEGI: Esperanza de vida de los negocios, 2015, p. 2).
En el mismo boletín 08/15 del INEGI (INEGI: Esperanza de vida de los negocios, 2015, p. 5)
detalla que: En México una empresa para alcanzar la madurez necesita 20 años, y el
porcentaje para las micro-empresas que logran llegar a esta edad es de entre 11% y 25%
dependiendo del numero de empleados.

3
1.3. Estructura del trabajo
La tabla 1.1 detalla la estructura del proyecto resumiendo el contenido de cada capitulo y
la relación entre ellos.
Tabla 1. 1: Estructura del Proyecto.
Capitulo Contenido Relación entre contenidos
1. INTRODUCCION
Se establece el problema general de
la competitividad en las micro-
empresas Mexicanas, así como la
motivación y enfoque de la
metodología propuesta “MLITICVE”
para la solución a este problema.
Sirve de base para el desarrollo de
todos los capitulos del Proyecto.
2.
OBJETIVOS, HIPOTESIS Y
ALCANCE
Se plantean los objetivos del
proyecto, se propone la hipótesis y se
limita el alcance del proyecto.
En este capitulo se define la
solución a la problemática planteada
en la “INTRODUCCION”.
3.
MARCO TEORICO
Se establecen las bases, principios y
conceptos teóricos en que están
sustentadas las metodologías y
modelos de integración de TI a los
procesos empresariales, que servirán
para el desarrollo de la “MLITICVE”.
Se enmarcan las bases teóricas en
las que se soporta la solución a los
objetivos planteados en el capitulo
“2.”, y que sirven para desarrollar la
MLITICVE como “SOLUCION” en el
capitulo “4.”.
4.
SOLUCION PROPUESTA
Presenta la Metodología Ligera para
la Integración de las TI a la Cadena
de Valor Empresarial (MLITICVE)
como solución a la problemática de
competitividad.
Se detalla la solución al problema
planteado en la INTRODUCCIÓN
aplicando los principios listados en el
MARCO TEORICO, abarcando las
variables y la muestra detalladas en
la METODOLOGIA DE
INVESTIGACION del capitulo “5.”.
5. METODOLOGIA DE
INVESTIGACION
- Se establece de manera formal la
hipótesis, el tipo de investigación,
las variables utilizadas, las
técnicas y los procedimientos de
indagación.
- Se define la muestra para el caso
de estudio.
- Se desarrolla la metodología
para el caso de estudio,
justificando la hipótesis
establecida en el capitulo “2.”.
- Se acotan las variables y la
muestra planteados en la
INTRODUCCIÓN y OBJETIVOS
de los capitulos “1. y 2.”.
6.
ANALISIS DE
RESULTADOS
- Se justifica la hipótesis de cómo
las TI integradas mediante una
metodologÍa incrementan la
competitividad de una empresa.
- Se presenta el plan de
explotación de la metodologÍa.
- Se exponen los casos practicos.
- Se comprueba la hipótesis
planteada en el capitulo “2. y 5.”.
- Se justifica en base a resultados
la relación entre el MARCO
TEORICO y el MARCO
METODOLOGICO de los
capitulos “3. y 5.”.
7.
CONCLUSIONES
- Se valora el cumplimiento de los
objetivos.
- Se enfatizan los resultados más
significativos derivados del
estudio del caso.
- Se detallan las limitaciones de la
metodologia “MLITICVE”.
- Se enmarcan las lineas de
mejora teórica, práctica y
metodologica de la solución.
- Se proponen nuevas lineas de
investigación.
Es la conclusión del desarrollo del PF
donde se hace un examen de
cumplimiento de todos los capitulos
del proyecto.
8. RECOMENDACIONES
- Se describen los factores de
competitividad que no cubre la
metodologia propuesta y que hay
que tener en cuenta.
- Se hacen recomendaciones
sobre la integración de TI a los
procesos de valor.
Se relaciona con todos los capitulos
del proyecto para hacer
recomendaciones sobre los aspectos
no cubiertos por la MLITICVE.
Fuente: Propia (2018)

4
2. OBJETIVOS, HIPOTESIS, ALCANCE
2.1. Objetivo General
Establecer la “MLITICVE: Metodología Ligera para la Integración de las TI a la Cadena de
Valor Empresarial” tomando como base los principios en que están soportados los
modelos y metodologías actuales para la integración de las TI a los procesos
empresariales, y poder ser utilizados solo con los recursos que cuentan las micro-
empresas para incrementar su competitividad.
2.2. Objetivos Específicos
Para preparar el terreno y poder cubrir los objetivos específicos de la tabla 2.1 fue
necesario realizar las siguientes tareas de apoyo:
• Se estableció el marco teórico con los principios de los modelos y metodologías
de integración de TI a los procesos empresariales en la sección “3.1.”.
• Se establecieron los conceptos teóricos de apoyo en que se sustentan los
modelos y metodologías de integración a los procesos empresariales en la
sección “3.2.”.
• Se establecieron los principios de los paradigmas ó modelos de construcción
y desarrollo de productos de TI en la sección “3.3.”.
• Se estableció la relación que hay entre el incremento de la competitividad y la
integración de las TI a los procesos de valor con la ayuda de una metodología en
la secciones “3.1. y 3.4.2.”, y los capítulos “5. y 6.”.
Una vez realizadas las tareas de apoyo, se estableció el procedimiento de la
Metodología Ligera para la Integración de TI a la Cadena de Valor Empresarial
(MLITICVE) en el capitulo “4.”, en donde se acotaron y adaptaron los principios y
conceptos teóricos para cubrir los objetivos de la tabla 2.1.
Tabla 2. 1: Objetivos específicos de la MLITICVE
Clave Objetivo
OB01 Caracterizar los procesos de valor en base a una arquitectura de negocio.
OB02 Establecer que hacer para gestionar los procesos de valor.
OB03
Establecer que hacer para gestionar la Integración de TI para apoyar los procesos de
valor.
Fuente: Propia (2017)
2.3. Hipótesis (Descripción)
En la sección “5.1.” de la Metodología de Investigación se ha establecido de manera
formal la hipótesis de que existe una relación entre el apalancamiento que dan las TI a
los procesos de valor y el incremento de la competitividad.

5
2.4. Alcance
El alcance de la MLITICVE es responder a las preguntas “por que” y “que hacer” para
integrar las TI a los procesos de valor en una micro-empresa.
Por lo que se hacen recomendaciones para:
• Definir o ajustar la arquitectura de negocio.
• Alinear los procesos de valor con la arquitectura de negocio.
• Definir los procesos de valor en una micro-empresa.
• La búsqueda de TI para el apoyo de los procesos de valor.
• La integración de las TI a los procesos de valor cuidando de mantener los
estándares y el incremento de calidad de los productos o servicios ofrecidos al
cliente.
• Establecer un ciclo de mejora continua de nuestra arquitectura de negocio para
que tenga la capacidad requerida de calidad, tiempo y costos competitivos.
Para las preguntas “el como y el “con que”, no se desarrollan en este documento por
las razones siguientes:
• La gestión de integración de TI representa un planteamiento de gestión diferente
para cada caso particular de micro-empresa.
• Las herramientas de gestión de integración pueden ser diferentes en cada caso
particular de micro-empresa.
• La motivación y enfoque de este trabajo es explotar la MLITICVE como asesoría
comercial donde se responderán estas preguntas de manera particular aplicando
la metodología a una micro-empresa específica.

6
3. MARCO TEÓRICO
En este capítulo se han establecido las bases, principios y conceptos teóricos en que
están sustentadas las metodologías y modelos de integración de TI a los procesos
empresariales, y que han servido para el desarrollo de la “MLITICVE” como solución al
problema de competitividad.
Para aclarar estos principios fue necesario adicionar los apartados “3.2.”, “3.3.” y “3.4.”
como soporte a los conceptos fundamentales de estas metodologías y modelos.
También se detallaron los factores que afectan la competitividad empresarial y la
proporción que tienen las TI sobre esta.
3.1.Modelos y Metodologías de integración de TI a los procesos
empresariales
Los modelos y metodologías de interés para el desarrollo de la MLITICVE son ITIL,
CMMI, BPM y SOA.
3.1.1. Modelo ITIL
ITIL (Information Technology Infraestructure Library o Biblioteca de Infraestructura de
Tecnologías de la Información) es un conjunto de publicaciones o librería basado en
buenas prácticas para la gestión de servicios de Información, la última versión al
momento de escribir este documento es la ITIL 2011, sin embargo para el desarrollo de
este documento nos basamos en la versión “3”.
Figura 3. 1: Publicaciones que conforman ITIL
Fuente: (Huércano, 2014, p. 5).

7
3.1.1.1. Antecedentes
En el manual de ITIL V3 de Sergio Ríos Huércano (Huércano, 2014, p. 4) detalla la historia
de ITIL como:
ITIL nació en la década de 1980, a través de la Agencia Central de
Telecomunicaciones y Computación del Gobierno Británico (Central Computer
and Telecomunications Agency - CCTA), que ideó y desarrollo una guía para que
las oficinas del sector público británico fueran más eficientes en su trabajo y por
tanto se redujeran los costes derivados de los recursos TI. Sin embargo esta guía
demostró ser útil para cualquier organización, pudiendo adaptarse según sus
circunstancias y necesidades. De hecho resultó ser tan útil que actualmente ITIL
recoge la gestión de los servicios TI como uno de sus apartados, habiéndose
ampliado el conjunto de “buenas practicas” a gestión de la seguridad de la
información, gestión de niveles de servicio, perspectiva de negocio, gestión de
activos software y gestión de aplicaciones. Estas buenas prácticas provienen de
las mejores soluciones posibles que diversos expertos han puesto en marcha en
sus organizaciones a la hora de entregar servicios de TI, por lo que en ocasiones
el modelo puede carecer de coherencia.
En la actualidad ITIL pertenece al Oficina de Comercio Británico (Office of
Government Commerce - OGC), pero puede ser utilizado para su aplicación
libremente.
3.1.1.2. Características
Las características principales del modelo se muestran en la tabla 3.1.
Tabla 3. 1: Características Principales del Modelo ITIL-V3
Característica Descripción
No desarrollada con derechos
de propiedad
- El modelo de aplicación es independiente de
proveedores asociados a su aplicación.
- Las mejores prácticas están basadas en procesos
puestos en marcha y recopilados en estos volúmenes.
- No tienen derechos de uso por prácticas personales o
empresariales únicas.
De dominio público
- Transición de conocimiento libre.
- Es de libre utilización, incluso únicamente las partes
que le apliquen.
Compendio de mejores
prácticas
- Se puede aplicar y obtener beneficios adaptando el
modelo a las características de cada necesidad.
- Estas mejores prácticas son el resultado obtenido del
trabajo diario de expertos y profesionales del mundo de
las TI desde hace casi tres décadas.
Estándar Internacional
- En conceptos, lenguaje, terminología, formas de trabajo
de las TI y documentación que se utiliza en servicios,
procesos, estrategia, objetivos, responsabilidades y
recursos.
Compatibilidad
- Existe un nexo de la gestión de TI con otras normas
internacionales como ISO, EFQM y CMMI.
Requiere Certificación - Para su aplicación es necesario estar certificado.
Fuente: Propia (2016) a partir del manual de ITIL-V3 (Huércano, 2014)
Para tener más clara y resumida las áreas y objetivos de cada librería se detallan en la
tabla “3.2.”.

8
Tabla 3. 2: Objetivos de la librería del modelo ITIL
Biblioteca Nombre Descripción Objetivos
SE
Service Strategy -
Estrategia de
Servicios (SE)
Diseña el plan de acción
que permitirá desarrollar
una estrategia en la
Organización en cuanto a
las Tecnologías de la
Información para alinearlas
con el negocio.
• Competitividad
• Mercado
• Proveedores
• Servicios
• Procesos
SD
Service Desing -
Diseño de servicios
(SD)
Se desarrollan los
conceptos relativos al
diseño de Servicios TI.
• Capacidad
• Continuidad
• Proveedores
• Diseño
SO
Operaciones de
Servicios (SO)
Ofrece un nivel de servicio
de la Organización acorde a
los requisitos y necesidades
de los Clientes en base al
establecimiento de los SLA
(Service Level Agreement o
Acuerdo de Nivel de
Servicio).
• Productividad y
Beneficios
• Gestión de
eventos,
incidencias y
aplicaciones
• Help Desk
• Cumplimiento de
servicios
• Responsabilidades
del personal de
servicios
ST
Service Transition
Transición de
Servicios (ST)
Definen los temas
relacionados a la transición
de servicios como los
cambios que se han de
producir en la prestación de
servicios.
• Gestión de
Configuración
• Servicio de
activos
• Gestión de
despliegue de
servicios de TI
• Gestión del
cambio
• Gestión del
conocimiento
Fuente: Propia (2016), en base al manual de ITIL-V3 (Huércano, 2014)
En el manual de ITIL-V3 (Huércano, 2014, p. 10) referente a la estrategia de servicio
detalla que:
El objetivo de la Estrategia de Servicio es el de incluir las TI en la Estrategia
Empresarial de manera que podamos calibrar nuestros objetivos según nuestra
infraestructura TI y adaptar cada uno a las necesidades del otro.
Las modificaciones de estructura que ha sufrido la librería ITIL han situado
finalmente a la estrategia empresarial relacionada con el servicio de las TI como
parte principal y como eje en el Ciclo de Vida ITIL. Sin embargo, a pesar de este
modulo de conocimiento, ITIL no indica como comenzar a definir la Estrategia
de Servicio, ni por donde comenzar a implantar estas mejoras.
La Estrategia de Servicio en ITIL se encamina hacia el mismo sentido que la
estrategia empresarial, pero ahora incluyendo en esta la componente TI. Integra
pues a su análisis nuevos objetivos y la evolución futura de las TI en la
Organización. ITIL busca alinear e integrar la tecnología con el Negocio, que los

9
servicios tecnológicos que se implementan y se ofertan desde los departamentos
de TI estén diseñados para apoyar al negocio.
La idea que se trata de aportar a las organizaciones es que es necesario plantear
objetivos pero teniendo en cuenta qué tenemos, como lo tenemos y a donde
podemos llegar con lo que tenemos, es decir, planear el futuro sabiendo que
puede ser necesario invertir para mejorar nuestra infraestructura TI, o planificar el
futuro de la empresa dependiendo de nuestra capacidad actual en TI, y/o abrir
nuevas líneas de negocio debido a que nos diferenciamos del resto de empresas
en las características que ofrece nuestra infraestructura TI. Con el fin de
comenzar a integrar las TI en nuestra estrategia hemos de tener en cuenta que
uno de los principales defectos de toda organización (en todo el mundo) es que
una vez tomada la decisión de comenzar a gestionarse y planificar su futuro, lo
normal es que nunca se hayan definido exactamente qué tipo de servicios
relacionados con la TI ofrece la empresa y a quien y como dirigir los esfuerzos
comerciales para ponerlos en el mercado.
Los pasos que ITIL establece en la definición e implantación de medidas para la
puesta en marcha de la estrategia de servicios se desarrollan a lo largo de una
serie de apartados que proponen una estructura para el diseño y definición de
nuestra estrategia.
Existen muchas metodologías que acercan la idea de ITIL a la persona, empresa,
organización o entidad que se plantee comenzar con la definición de una
Estrategia de Servicio, ya que, como se comentó anteriormente, ITIL no pone
las herramientas, solo la idea y la estructura o contenido que ha de tener
nuestro plan.
2.1. Creación de Valor a través del Servicio
El objetivo de la Creación de Valor a través del Servicio es disponer del
conocimiento de la red que interacciona entre nosotros y los clientes/usuarios.
Cuando se constituye una empresa, ésta ha de tener muy claro de su
producto/servicio si quiere venderlo. Es decir da valor a su solución, producto
o servicio ofertándolo de una manera concreta, ofreciendo información detallada
porque conoce perfectamente qué es, cómo es y de donde viene y por tanto nos
hace ver el valor que ese producto/servicio nos va a aportar si lo adquirimos. Esto
es exactamente lo que propone ITIL. Hemos de poner en valor nuestro
servicio IT para integrarlo en nuestra estrategia empresarial, ya sea como
bien, como soporte, como apoyo o como futuro elemento diferenciador.
A esto se le llama Valor. Pero para crear valor, primero debemos conocer nuestro
servicio. El valor de un servicio tiene componentes tanto objetivas como
subjetivas, es decir, medibles y no medibles, cuantitativas y cualitativas. La
dificultad estriba en saber qué es lo que puedo ofrecer con respecto a qué es lo
que demandan nuestros clientes actuales y potenciales. Es necesario dar un
valor real que corresponda a la percepción que los clientes y/o usuarios tienen de
éste. Por tanto, existen multitud de factores que debemos contrastar y detectar.
Estos no sólo tendrán que ver con la capacidad, las funcionalidades y la utilidad,
sino que habrá que incluir términos como la fiabilidad del servicio, su continuidad,
su seguridad, la rapidez en la entrega de servicios, la resolución de incidencias,
etcétera, dependiendo, como se comentó anteriormente de las necesidades de
los usuarios.

10
2.1.2. CREAR VALOR
La manera tradicional de crear valor se estimaba a través de la cadena de
valores, modelo adoptado de la gestión industrial tradicional. Ha resultado muy
útil en la gestión empresarial; pero ITIL mejora este concepto aportando una
nueva visión, la Red de Valor. Nos propone que identifiquemos qué podemos
hacer con nuestro servicio de manera que estamos creando valor, porque con el
mismo esfuerzo de conocimiento, estamos detectando oportunidades de
crecimiento sobre nuestra infraestructura TI. Esas oportunidades de crecimiento
(ver Capítulo 6, Mejora Continua) se refieren tanto a la propia infraestructura,
como a necesidades formativas para potenciar servicios anteriormente
considerados residuales. Es decir, se refiere a los activos de los que dispone la
organización para ofrecer un servicio.
Estas oportunidades pueden ser suplidas por proveedores, por lo que en el
proceso de análisis estableceremos contacto con estos proveedores que nos
aportarán las soluciones que harán de nuestra identificación del valor del servicio
un proceso completo que definirá la Red de Valor.
Esta red comienza en el usuario, que tiene sus necesidades suplidas a través de
nuestros servicios, soportados por una infraestructura TI, que ha sido mejorada
por proveedores y que puede tener servicios externalizados en estos
proveedores, como garante de fiabilidad, seguridad u otros conceptos
demandados, pudiendo ofrecer un servicio de alta calidad a los usuarios a través
de una red, donde el valor principal es la calidad del servicio ofrecido al cliente
final. En definitiva, estamos identificando los grupos de interés que rodean a
nuestro servicio (ver Capitulo 7, Relación de ITIL con otros modelos - EFQM).
3.6. Gestión de la capacidad
El objetivo de La gestión de la capacidad es procurar que el servicio disponga
la capacidad de recursos (almacenamiento, rendimiento y eficiencia) necesaria y
en el momento en el que se demande. Además debe velar para que esta gestión
proporcione una contención del gasto por ineficiencias en la capacidad y sobre
todo que esta capacidad esté alineada tanto con los requisitos actuales y futuros
del cliente, como con la estrategia de la organización).
Para que se cumpla este objetivo la Gestión de la Capacidad debe velar por:
§ Monitorizar el Rendimiento de la Infraestructura.
§ Controlar y analizar el Alcance de la Infraestructura actual, para
determinar qué soporte puede ofrecer a nuevos servicios o
modificaciones de software.
§ Modelado o simulación para la determinación de los requisitos y
necesidades de capacidad.
§ Planificar a través de un Plan de Capacidad las condiciones futuras.
Sin una gestión de la capacidad correctamente puesta en marcha, pueden
realizarse compras indebidas, que conlleven un gasto mayor del necesario;
puede ocurrir una sobreestimación del alcance de la infraestructura actual, por lo
que el Servicio puede verse afectado, y por tanto ocurrir un incumplimiento de
contrato.
Los beneficios de disponer de una Gestión de la Capacidad para la organización
serán, entre otros, los siguientes:
§ Reducir riesgos de disminución de la calidad del servicio gracias a un
control de los recursos y un seguimiento del rendimiento.

11
§ Eficacia en la respuesta y flexibilidad para responder a nuevas
necesidades.
§ Reducción de costes y control del gasto.
Para realizar un control y seguimiento de todas las actuaciones que han de
realizarse comúnmente en cuanto a la Capacidad, la siguiente figura, 3.6.1.
ilustra las entradas de información y datos necesarias para poner en marcha una
gestión de la capacidad bien fundamentada y las salidas que toda esta
información debe generar para la gestión del servicio con respecto a la
capacidad:
Figura 3. 2: Proceso de Gestión de la Capacidad de acuerdo a ITIL
Fuente: (Huércano, 2014, p. 44)
Se puede decir que el objetivo principal del modelo ITIL-V3 es crear valor a través del
servicio.
3.1.1.3. Principios
Figura 3. 3: Vista de la Red de Valor de ITIL
Fuente: (Huércano, 2014, p. 13)

12
En base a la descripción de características y objetivos de ITIL podemos destacar los
siguientes principios que nos han servido para el desarrollo de la MLITICVE:
• Reduce costos en TI.
• Hace más eficiente el trabajo de procesos.
• Mejora continua de los procesos.
• Gestiona el cambio.
• Gestiona las TI.
• Gestiona la capacidad de los procesos.
• Crea valor a través del servicio.
• Cuida el cumplimiento de estándares, normas y calidad.
• Define un marco de trabajo.
• Ve el servicio como estrategia.
3.1.2. Modelo CMMI
CMMI (Capability Maturity Model Integration) es un modelo de madurez de mejora de los
procesos para el desarrollo de productos y servicios. Describe las mejores prácticas a
aplicar en el ciclo de vida de los productos (figura 3.4), abarcando desde la elaboración,
la entrega y el mantenimiento.
Figura 3. 4: Dimensiones de la vista de Procesos del CMMI
Fuente: (Software Engineering Institute, 2010, p. 4)
En el documento CMMI para el Desarrollo, Versión 1.3, de Software Engineering Institute
(Software Engineering Institute, 2010, p. 5) detalla que:

13
Un modelo de madurez y de capacidad (Capability Maturity Model®, CMM®),
incluyendo CMMI, es una representación simplificada del mundo. Los CMMs
contienen los elementos esenciales de los procesos eficaces. Estos elementos se
basan en los conceptos desarrollados por Crosby, Deming, Juran y Humphrey.
En la década de los 30, Walter Shewhart comenzó a trabajar en la mejora de
procesos introduciendo los principios del control estadístico de la calidad
[Shewhart 1931]. Estos principios fueron refinados por W. Edwards Deming
[Deming 1986], Phillip Crosby [Crosby 1979] y Joseph Juran [Juran 1988]. Watts
Humphrey, Ron Radice y otros los ampliaron y comenzaron a aplicarlos al
software en su trabajo en IBM y en el SEI [Humphrey 1989]. El libro de Humphrey,
Managing the Software Process, describe los principios y conceptos básicos en
los cuales se basan muchos de los modelos de madurez y de capacidad (CMMs).
El SEI ha tomado la premisa de la gestión de procesos, “la calidad de un sistema
o producto está muy influenciada por la calidad del proceso empleado para
desarrollarlo y mantenerlo” y ha definido CMMs que recogen esta premisa. La
adhesión a esta premisa se encuentra en los movimientos de calidad de todo el
mundo, como lo muestra la International Organization for
Standardization/International Electro-technical Commission (ISO/IEC) en su
conjunto de estándares.
Los CMMs se centran en mejorar los procesos de una organización. Contienen
los elementos esenciales de los procesos eficaces de una o más disciplinas y
describen un camino evolutivo de mejora desde procesos ad hoc e inmaduros a
procesos disciplinados y maduros con calidad y eficacia mejoradas.
Figura 3. 5: Histórico del desarrollo de CMMs
Fuente: (Software Engineering Institute, 2010, p. 6)
En el mismo documento CMMI para el Desarrollo, Versión 1.3, de Software Engineering
Institute (Software Engineering Institute, 2010, p. 7) define el marco CMMI como sigue.
El marco CMMI proporciona la estructura necesaria para crear los modelos la
formación y los componentes de evaluación de CMMI. Para permitir el uso de
múltiples modelos dentro del marco CMMI, los componentes de los modelos se

14
clasifican como comunes a todos los modelos CMMI o aplicables a un modelo
especifico. El material común se denomina “CMMI Model Foundation” o “CMF.”
Los componentes del CMF son parte de todos los modelos generados a partir del
marco CMMI. Esos componentes se combinan con el material aplicable a un área
de interés (p. ej., adquisición, desarrollo, servicios) para crear un modelo.
Una “constelación” se define como una colección de componentes CMMI que se
usan para construir modelos, materiales de formación y documentos relativos a la
evaluación para un área de interés (p. ej., adquisición, desarrollo, servicios). El
modelo de la constelación de desarrollo se denomina “CMMI para Desarrollo” o
“CMMI-DEV.”
CMMI para Desarrollo es un modelo de referencia que cubre las actividades para
desarrollar tanto productos como servicios. Las organizaciones de numerosos
sectores, incluyendo aeroespacial, banca, hardware, software, defensa,
automoción y telecomunicaciones, utilizan el CMMI para Desarrollo.
CMMI para Desarrollo contiene practicas que cubren la gestión de proyectos, la
gestión de procesos, la ingeniería de sistemas, la ingeniería de hardware, la
ingeniería de software y otros procesos de soporte utilizados en el desarrollo y
mantenimiento.
En lo que se refiere al “área de procesos” el documento de Software Engineering
Institute lo define como: Un grupo de prácticas relacionadas en un área que, cuando se
implementan de forma conjunta, satisface un conjunto de metas consideradas
importantes para realizar mejoras en esa área (Software Engineering Institute, 2010, p.
449).
3.1.2.3. Principios
En base a la descripción de características y objetivos del CMMI podemos destacar los
siguientes principios que nos han servido para el desarrollo de la MLITICVE:
• Caracterización de los procesos.
• Mejora Continua de los procesos.
• Control estadístico de calidad de procesos.
• Cuida el cumplimiento de estándares y normas.
• Crea modelos de trabajo.
• Crea valor con el servicio.
3.1.3. BPM
BPM “(Business Process Management) Es una disciplina integradora que engloba
técnicas y disciplinas que abarca las capas de estrategia, negocio y tecnología, que se
comprende como un todo integrado en gestión a través de los procesos” (Hitpass, 2017,
p. 5).

15
De acuerdo con Jeston & Nelis (Jeston & Nelis, 2014, p. XXIII) sobre la historia de BPM
detalla:
La idea de trabajar con procesos y el mejoramiento de estos es relativamente
nueva, a principios del siglo XX Frederick Taylor y sus colegas desarrollaron la
idea del mejoramiento de los procesos mediante la restricción de las labores
manuales en el proceso de producción.
El siguiente gran paso en la gestión de procesos se dio cuando esta idea fue
apoyada por el control estadístico de procesos de W. Edwards Deming,
Walter Shewhart y Joseph Juran donde uno de sus pilares es la mejora
continua de la calidad de productos y servicios. Otro paso importante en el
desarrollo del BPM fue integrar la reingeniería de procesos donde de manera
radical se genera una nueva forma de trabajar para mejorar el desempeño de la
organización con la ayuda de las TI, otro componente importante es la integración
de la metodología Six Sigma que alude a la mejora de los procesos analizando
su variabilidad.
Según Bernhard Hitpass (Hitpass, 2017, p. 5) detalla que a partir de 2002 aparece por
primera vez el acrónimo BPM explicándolo como sigue:
A partir de principios de los años 90 nace la idea en los países industrializados de
integrar las diferentes disciplinas de gestión corporativas directamente con la
operación de los procesos. En una publicación de Smith and Fingar en el año
2002 con el titulo BPM Third Wave[SmithFingar02], aparece por primera vez el
acrónimo BPM. Académicos, profesionales y proveedores de TI captan
rápidamente la importancia y el interés por BPM. La tendencia ha ido creciendo
día a día y se han hecho grandes inversiones en el desarrollo de técnicas,
metodologías y soluciones para BPM.
Figura 3. 6: Evolución de la Ingeniería de Procesos hacia el BPM
Fuente: (Hitpass, 2017, p. 9)
En el Libro Business Process Management Fundamentos y Conceptos de
Implementación de Berhard Hitpass (Hitpass, 2017, p. 3) dice que:

16
Actualmente los modelos de excelencia basados en los conceptos de gestión por
calidad total se utilizan para introducir la mejora continua y la innovación, para
mejorar el desempeño de la organización y en especial los resultados
económicos, a través de sus procesos.
Introducir procesos en las organizaciones que les permita entrar en un circulo
virtuoso de mejora continua para dar cumplimiento a estas exigencia a través del
tiempo, son los desafíos actuales a las que se encuentran sometidas las
organizaciones [Hitpass09]. A pesar de que los objetivos son claros, lograrlos y
dar cumplimiento a ellos no es materia sencilla. El concepto de creación de valor
para el cliente esta relacionado con los atributos calidad, tiempo y costos. ¿Los
productos y servicios tienen la calidad exigida por el cliente?, ¿cumplen con los
tiempos esperados?, ¿el costo es razonable?, ¿cumplen con las regulaciones
exigidas? La mayoría de las organizaciones hoy en día no se esfuerzan en dar
algún grado de cumplimiento a estas altas exigencias que demandan los
ciudadanos y mercados globalizados.
Mucha gente se confunde con que es realmente BPM y no es sorprendente si
consideramos que la comunidad de BPN no logra ponerse de acuerdo en una
definición común[Hitpass08]. Actualmente existen muchas definiciones de BPM.
Aunque todas ellas tienen algo en común también existen diferencias, sobre todo
en el alcance. Algunos autores y expertos, en especial en Europa, restringen el
BPM a una disciplina de gestión sin incluir explícitamente el apoyo de TI. Otros
autores, específicamente en Norteamérica, definen BPN como el proceso hacia la
automatización y operación de los procesos implícitamente con TI ¿Podemos
entonces concluir que no existe un entendimiento común sobre BPM?
El concepto de BPM es incluso mas amplio que ambas visiones descritas recién,
pero el entendimiento común se puede lograr a través de los objetivos que se
persiguen con BPM, que por lo general todas las escuelas los comparten. Por lo
general las diferencias de las escuelas se encuentra en el concepto de cómo
enfrentar el proceso hacia el logro de los objetivos y cada concepto parte por una
definición, razón por la cual algunas definiciones se diferencian de otras. La
definición de los objetivos es clara y bien definida:
• Lograr o mejorar la <<agilidad del negocio>> en una organización. El
concepto de agilidad de negocio se entiende como la capacidad que
tiene una organización para adaptarse a los cambios del entorno a través
de los cambios en sus procesos integrados.
• Lograr mayor <<eficacia>>. El concepto de eficacia se entiende como la
capacidad que tiene una organización para lograr en mayor o menor
medida los objetivos estratégicos o de negocio.
• Mejora los niveles de <<eficiencia>>. Eficiencia es la relación entre los
resultados obtenidos y los recursos utilizados, es decir el grado de
productividad de un resultado. El termino eficiencia esta relacionado con
todos los indicadores de productividad en cuanto a calidad.
Hoy en día, no basta que una organización sea solo eficiente, como lo podría
haber sido en el pasado, porque si no es capaz de adaptarse ante los frecuentes
cambios impulsados por la globalización no es eficaz, dicho de otro forma no
logra cumplir los objetivos en el tiempo y calidad exigidos por los mercados.
Sobre todo la agilidad de negocio ha cobrado mayor importancia en nuestros
tiempos de la globalización. La empresa que pueda adaptarse más rápido a
los constantes cambios en el mercado, que son cada vez mas frecuentes, tendrá

17
mayores ventajas competitivas que aquellas que no logran adaptarse al ritmo
que la globalización exige.
La pregunta crucial es entonces: Que instrumentos están utilizando las
empresas para lograr mayor agilidad, eficacia y eficiencia? La respuesta es
mayor control y eficiencia en la capacidad de cambio en sus procesos de
negocio, porque a través de los procesos se crea valor para los clientes.
3.1.3.3. Principios
En base a la descripción de características del BPM podemos destacar los siguientes
principios que nos han servido para el desarrollo de la MLITICVE:
• Caracterización de los procesos.
• Mejora Continua de los procesos.
• Control de calidad de procesos.
• Adaptación al cambio.
• Enfasis al valor agregado como servicio.
• Enfasis al apoyo de las TI a los procesos.
3.1.4. SOA
Según el documento de IBM DeveloperWorks define a SOA como:
SOA “(Service Oriented Architecture)” Arquitectura Orientada a Servicios es un
estilo arquitectónico de TI que soporta la transformación de la empresa en un
conjunto de servicios vinculados o tareas empresariales repetibles a las cuales se
puede acceder en una red cuando sea necesario (IBM DeveloperWorks, 2017, p.
parrafo 2).
SOA tiene sus antecedentes en la evolución de la Arquitectura de software, en un artículo
publicado en la biblioteca de la Comunidad educativa Mundiali del sitio de Ilustrados,
Yanet Espinol Martín (Martín, 2008), detalla esta evolución diciendo:
Cada vez que se narra la historia de la arquitectura de software o de la ingeniería
de software, se reconoce que en un principio, hacia 1968, Edsger Dijkstra,
propuso que se estableciera una estructuración correcta de los sistemas de
software antes de lanzarse a programar, escribiendo código de cualquier
manera (Dijkstra Enero de 1983). Dijkstra, quien sostenía que las ciencias de la
computación eran una rama aplicada de las matemáticas y sugería seguir pasos
formales para descomponer problemas mayores, fue uno de los introductores de
la noción de sistemas operativos organizados en capas que se comunican sólo
con las capas adyacentes y que se superponen “como capas de cebolla”. Inventó
o ayudó a precisar además docenas de conceptos: el algoritmo de camino más
corto, los stacks, los vectores, los semáforos, los abrazos mortales. De sus
ensayos arranca la tradición de hacer referencia a “niveles de abstracción” que ha
sido tan común en la arquitectura subsiguiente.

18
Aunque Dijkstra no utiliza el término arquitectura para describir el diseño
conceptual del software, sus conceptos sientan las bases para lo que luego
expresarían Niklaus Wirth (Wirth Abril de 1971) como stepwise refinement y
DeRemer y Kron (Kron 1976) como programming-in-the large o programación en
grande, ideas que poco a poco irían decantando entre los ingenieros primero y los
arquitectos después.
En la conferencia de la NATO de 1969, un año después de la sesión en que se
fundara la ingeniería de software, P. I. Sharp formuló estas sorprendentes
apreciaciones comentando las ideas de Dijkstra:
“Pienso que tenemos algo, aparte de la ingeniería de software, algo de lo que
hemos hablado muy poco pero que deberíamos poner sobre el tapete y
concentrar la atención en ello, es la cuestión de la arquitectura de software. La
arquitectura es diferente de la ingeniería, ejemplo de lo que quiero decir,
echemos una mirada a OS/360. Partes de OS, si vamos al detalle, han utilizado
técnicas que hemos acordado constituyen buena práctica de programación. La
razón de que OS sea un amontonamiento amorfo de programas es que no tuvo
arquitecto. Su diseño fue delegado a series de grupos de ingenieros, cada uno de
los cuales inventó su propia arquitectura. Y cuando esos pedazos se clavaron
todos juntos no produjeron una tersa y bella pieza de software (Sharp 27 al 31 de
Octubre de 1969).”
Una novedad importante en la década de 1970 fue el advenimiento del diseño
estructurado y de los primeros modelos explícitos de desarrollo de software. Estos
modelos comenzaron a basarse en una estrategia más orgánica, evolutiva,
cíclica, dejando atrás las metáforas del desarrollo en cascada que se inspiraban
más bien en la línea de montaje de la ingeniería del hardware y la manufactura.
Poco a poco el diseño se fue independizando de la implementación, y se forjaron
herramientas, técnicas y lenguajes de modelado específicos.
En la misma época, otro precursor importante, David Parnas, demostró que los
criterios seleccionados en la descomposición de un sistema impactan en la
estructura de los programas y propuso diversos principios de diseño que debían
seguirse a fin de obtener una estructura adecuada. Parnas desarrolló temas tales
como módulos con ocultamiento de información, estructuras de software y familias
de programas (Parnas Diciembre de 1972), enfatizando siempre la búsqueda de
calidad del software.
En 1972, Parnas publicó un ensayo en el que discutía la forma en que la
modularidad en el diseño de sistemas podía mejorar la flexibilidad y el control
conceptual del sistema, acortando los tiempos de desarrollo. Introdujo entonces el
concepto de ocultamiento de información (information hiding), uno de los
principios de diseño fundamentales en diseño de software aún en la actualidad.
En la segunda de las descomposiciones que propone Parnas comienza a
utilizarse el ocultamiento de información como criterio. Cada módulo deviene
entonces una caja negra para los demás módulos del sistema, los cuales podrán
acceder a aquél a través de interfaces bien definidas, en gran medida invariables.
En 1975, Brooks, diseñador del sistema operativo OS/360 y Premio Turing 2000,
utilizaba el concepto de arquitectura del sistema para designar “la especificación
completa y detallada de la interfaz de usuario” y consideraba que el arquitecto es
un agente del usuario (Jr. 1975). También distinguía entre arquitectura e
implementación; mientras aquella decía qué hacer, la implementación se ocupa
de cómo.

19
Como escriben Clements y Northrop en esta época (Northrop Febrero de 1996)
en todo el desenvolvimiento ulterior de la disciplina permanecería en primer plano
esta misma idea: la estructura es primordial (structure matters), y la elección de la
estructura correcta ha de ser crítica para el éxito del desarrollo de una solución.
“La elección de la estructura correcta sintetiza, como ninguna otra expresión, el
programa y la razón de ser de la AS”.En la década de 1980, fue surgiendo nuevo
paradigma, el de la programación orientada a objetos. Paralelamente, hacia fines
de la década de 1980 y comienzos de la siguiente, la expresión arquitectura de
software comienza a aparecer nuevamente en la literatura para hacer referencia a
la configuración morfológica de una aplicación.
El primer estudio en que aparece la expresión “arquitectura de software” en el
sentido en que hoy lo conocemos es sin duda el de Perry y Wolf; ocurrió en 1992,
aunque el trabajo se fue gestando desde 1989. En él, los autores proponen
concebir la AS por analogía con la arquitectura de edificios, una analogía de la
que luego algunos abusaron (WWISA 1999), otros encontraron útil y para unos
pocos ha devenido inaceptable (Reed 2001).
“La década de 1990, fue la década de la “arquitectura de software”, dando
cumplimiento a las profecías de Perry y Wolf, fue sin duda la década de
consolidación y diseminación de la AS en una escala sin precedentes. Las
contribuciones más importantes surgieron en torno del instituto de ingeniería de la
información de la Universidad Carnegie Mellon (CMU SEI). En la misma década,
demasiado pródiga en acontecimientos, surge también la programación basada
en componentes, que en su momento de mayor impacto impulsó a algunos
arquitectos mayores, como Paul Clements (Clements Enero de 1996.), a afirmar
que la AS promovía un modelo que debía ser más de integración de componentes
pre-programados que de programación.
En el documento de Garner Service-Oriented Architecture Scenario (Gartner, 2003, p.
G00114358) dice que: SOA fue descrita por primera vez por Garner en 1996 en los
documentos (SSA Reserch Note SPA-401-068, 12 Abril 1996, “Service Oriented
Architectures, Part 1” and SSA Reserch Note SPA-401-069 Service Oriented
Architectures, Part 2”.
En base a lo descrito anteriormente por Yanet Espinol Martín y los documentos de
Gartner, SOA surge como una alternativa de solución a la complejidad de integración de
sistemas en una empresa, que la integración sea ágil y con calidad de estándares
internacionales en un tiempo óptimo para responder a los cambios del entorno
globalizado, donde SOA se puede ver como un nivel de abstracción del uso de los
componentes de sistemas lógicos como servicios utilizables, esto se logra
homogenizando la capa de utilización con reglas bien establecidas donde no importa el
lenguaje o plataforma tecnológica en que estén soportados los sistemas (figura 3.7).

20
Figura 3. 7: Separación de la lógica de negocio y la lógica de TI
Fuente: (Erl, 2009, p. 23)
Es necesario hacer notar que el concepto de servicios es el núcleo principal de la
arquitectura SOA, por lo que el definirlo se hace indispensable para poder entenderlo y
aplicarlo a las soluciones de negocios de las micro-empresas en la MLITICVE.
En el documento Arquitectura orientada a servicios en el contexto de la arquitectura
empresarial de (Arango Serna, Londoño Salazar, & Zapata Cortes, 2010, p. 79) detalla que: un
servicio es una unidad de trabajo que se ejecuta por un proveedor del mismo para
obtener un resultado final, el cual es requerido o utilizado por un consumidor.
En el mismo articulo dice que:
Los servicios corresponden a funciones de negocio que, cuando son invocadas,
ejecutan una tarea especifica. Si todos estos servicios, entre muchos otros, son
comunes para casi todas las organizaciones, y que por lo general pueden ser
adquiridos como paquetes de industria o ser construidos internamente, la
diferencia o ventaja competitiva reside en la forma en que cada organización
ensambla y reutiliza dichos servicios, ajustándolos a la estrategia y necesidades
especificas del negocio.

21
La tabla 3.3 detalla las características principales que incorporan la implementación de un
servicio.
Tabla 3. 3: Características principales de los servicios en SOA
Característica Cumplimiento
Interface Bien definida soportada en estándares.
Implementación Ocultamiento de los detalles.
Invocación
Se hace mediante mecanismos basados en estándares abiertos
de la industria.
Granularidad
Puede ser gruesa o fina. Los de granularidad gruesa exponen
una función de alto nivel de negocio, que a su vez invoca a otros
servicios internos que pueden ser de granularidad fina. Un
servicio de granularidad fina es aquel que implementa una
función muy especifica.
Publicado
Por el proveedor del mismo y que sea consumido por uno o más
clientes (aplicaciones, flujos y procesos).
Desacoplado Modulares, autónomos e independientes.
Reutilizable Puede ser invocado por diferentes aplicaciones.
Fuente: Propia, basado en (Arango Serna, Londoño Salazar, & Zapata Cortes, 2010)
Referente a la relación que existe entre SOA y la Arquitectura Empresarial (AE) es que
estas presentan una marcada similitud y superposición en varios de sus principios,
(Arango Serna, Londoño Salazar, & Zapata Cortes, 2010, p. 77) detallan que:
La relación que existe entre una arquitectura orientada a servicios y una
arquitectura empresarial, presenta una alta similitud y superposición en varios de
sus conceptos, procesos, actividades y resultados que se presentan en cada una
de ellas. Adicionalmente ambos modelos están determinados por el
direccionamiento que se hacen a nivel de la organización (estrategia y planeación
y arquitectura de referencia); al mismo tiempo, ambos modelos manejan
esquemas de gobernabilidad similares.
En el desarrollo de un modelo de AE, se parte de un estado actual de la
arquitectura (línea base), además sirve como insumo para conducir el
planteamiento de las acciones y planes a desarrollar para llevar la arquitectura a
un estado mas evolucionado acorde a las necesidades del negocio. Lo importante
es que al conocer este estado, se dispone de información valiosa para definir el
plan de acción para evolucionar a un nivel de arquitectura superior u objetivo
donde se quiere llegar, al cual se le denomina “TO-BE” que significa “Estado
deseado”. El camino a recorrer se va a soportar en SOA como vehículo de
transformación [10].
El proceso para transitar de un estado actual hacia un estado deseado, se
denomina “GAP” que significa “BRECHA”. El cubrimiento de la brecha permite que
se vaya realizando acercamiento hacia el modelo objetivo, el cual se puede
representar en un plano de tiempo vs. el nivel de maduración que se va
alcanzando.

22
La figura 3.8 nos muestra gráficamente estos procesos de acercamiento.
Figura 3. 8: Evolución de los esquemas de integración empresarial soportada por las TI (SOA)
Fuente: (Arango Serna, Londoño Salazar, & Zapata Cortes, 2010, p. 77)
3.1.4.3. Principios
En base a la descripción de los antecedentes y características de SOA podemos destacar
los siguientes principios que nos han servido para el desarrollo de la MLITICVE:
• La arquitectura se antepone al desarrollo, esta nos dice el que hacer pero no el
como.
• Aprovecha los activos existentes.
• Flexibiliza las empresas con la ayuda de las TI.
• Las necesidades de los clientes son satisfechas en base a servicios.
• Descubrimiento y Reutilización de componentes como servicios.
• Implementaciones rápidas con costos bajos.
• Separa la arquitectura de la ingeniería.
• Aplica la Mejora continua de los procesos.

23
3.2. Conceptos teóricos de apoyo
A continuación se presentan algunos conceptos teóricos que las metodologías y modelos
vistos en la sección “3.1.” aluden, y que han servido para presentar la MLITICVE en el
capitulo “4.”.
3.2.1. Control estadístico de procesos
Según Gutiérrez Pulido y De la Vara Salazar en su libro Control Estadístico de Calidad y
Seis Sigma (Gutíerrez Pulido & De La Vara Salazar, 2009, p. 5) define los términos de
calidad, competitividad, productividad, eficiencia, eficacia, variables de entrada y salida
del proceso, y variabilidad, como:
Calidad: Es el juicio que el cliente tiene sobre un producto o servicio, resultado
del grado con el cual un conjunto de características inherentes al producto cumple
con sus requerimientos.
Competitividad: Es la capacidad de una empresa para generar valor para el
cliente y sus proveedores de mejor manera que sus competidores.
Productividad: Es la capacidad de generar resultados utilizando ciertos recursos.
Se incrementa maximizando resultados y/u optimizando recursos.
Eficiencia: Relación entre los resultados logrados y los recursos empleados. Se
mejora optimizando recursos y reduciendo tiempos desperdiciados por paros de
equipo, falta de material y retrasos.
Eficacia: Grado con el cual las actividades planeadas son realizadas y los
resultados previstos son logrados. Se atiende maximizando resultados.
Variables de entrada del proceso: Son las que definen las condiciones de
operación del proceso e incluyen las variables de control y las que aunque no son
controladas, influyen en el desempeño del mismo.
Variables de salida del proceso: Son las características de calidad en las que
se reflejan los resultados obtenidos en un proceso.
Variabilidad: Se refiere a la diversidad de resultados de una variable o de un
proceso.
Variabilidad y pensamiento estadístico: La estadística está formada por un
conjunto de técnicas y conceptos orientados a la recolección y análisis de datos
tomando en cuenta la variación en los mismos. Por su parte, el control estadístico
de la calidad es la aplicación de técnicas estadísticas al control de calidad.
Capacidad de un proceso: Consiste en conocer la amplitud de la variación del
proceso para una característica de calidad dada; esto permitirá saber en qué
medida tal característica de calidad es satisfactoria (cumple especificaciones).
La herramientas tradicionales básicas para llevar a cabo el control estadístico de
procesos son:
• Diagrama de Pareto.

24
• Estratificación.
• Hoja de verificación.
• Diagrama causa-efecto (diagrama de Ishikawa).
• Lluvia de ideas.
• Diagrama de dispersión.
El uso de estas herramientas cuando se aplica la MLITICVE a una micro-empresa se da
principalmente en el establecimiento de la capacidad empresarial, la gestión de proceso y
la gestión por procesos detallados en las secciones “4.4.1.1., 4.4.3. y 4.4.4.”.
3.2.2. Ciclo de mejora continua
Uno de los principios de la gestión de calidad total que impacta a la competitividad es el
mejoramiento continuo del desempeño de la organización.
Las metodologías y modelos de integración de TI expuestas en la sección “3.1.” aluden a
este principio, mismo que se ha utilizado para elaborar la MLITICVE por lo que es
necesario detallarlo.
A partir de los años cincuenta el Dr. Edwards Deming presento por primera vez este
principio a industriales japoneses con el ciclo PHVA, donde P significa “planificar”, H
“hacer”, V “verificar” y A “actuar” como lo muestra la figura 3.9, posteriormente este ciclo
fue desarrollado por Shewhart en su control estadístico de procesos.
Figura 3. 9: Ciclo de Deming
Fuente: (García P., Quispe A., & Ráez G, 2003)
En el documento Mejora continua de calidad en los procesos García, Quispe y Ráez
(García P., Quispe A., & Ráez G, 2003) detalla que:
Se admite, estadísticamente, que en las organizaciones sin " Gestión de mejora
Continua" el volumen de la ineficiencia puede estar entre un 15 y 25 % de sus
ventas. Las que si la hacen, oscila entre 4 y 6%. Un rápido calculo nos har á́
descubrir la magnitud de la respectiva "Mina de Oro" y el efecto que tiene sobre

25
los resultados y la competitividad. La mayoría de los fallos o ineficiencias que
configuran el despilfarro son desconocidos, considerados como normales,
ignorados y con frecuencia ocultados. Actitudes que impiden buscar soluciones y
evitar su repetición.
La gestión de mejora continua en una organización requiere:
• El liderazgo de la dirección
• Un comité de mejora continua
• Formación y motivación especificas
• Un sistema de gestión documentado
• Asesoramiento externo
Según la NTP-ISO 9000:2001, Mejora continua es una "actividad recurrente
para aumentar la capacidad para cumplir los requisitos" siendo los requisitos la
"necesidad o expectativa establecida, generalmente implícita u obligatoria".
• Análisis y evaluación de la situación existente.
• Objetivos para la mejora.
• Implementación de posible solución.
• Medición, verificación, análisis y evaluación de los resultados de la
implementación.
• Formalización de los cambios.
Los resultados se revisan para detectar oportunidades de mejora. La mejora es
una actividad continua, y parte de la información recibida del propio sistema y de
los clientes.
Dentro del contexto de un sistema de gestión de la calidad, el ciclo PHVA es un
ciclo que esta en pleno movimiento. Que se puede desarrollar en cada uno de los
procesos. Está ligado a la planificación, implementación, control y mejora
continua, tanto para los productos como para los procesos del sistema de gestión
de la calidad.
El ciclo PHVA se explica de la siguiente forma:
Planificar:
• Involucrar a la gente correcta
• Recopilar los datos disponibles
• Comprender las necesidades de los clientes
• Estudiar exhaustivamente el/los procesos involucrados
• ¿Es el proceso capaz de cumplir las necesidades?
• Desarrollar el plan/entrenar al personal
Hacer:
• Implementar la mejora/verificar las causas de los problemas
• Recopilar los datos apropiados
Verificar:
• Analizar y desplegar los datos
• ¿Se han alcanzado los resultados deseados?
• Comprender y documentar las diferencias
• Revisar los problemas y errores
• ¿Qué se aprendió?
• ¿Qué queda aún por resolver?

26
Actuar:
• Incorporar la mejora al proceso
• Comunicar la mejora a todos los integrantes de la empresa
• Identificar nuevos proyectos/problemas
A continuación se detallan los ocho pasos de aplicación del ciclo de la calidad en base al
ciclo PHVA.
Tabla 3. 4: Los ocho pasos para la solución de un problema vía PHVA
Etapa Paso Nombre y descripción del paso
Planear
1
Seleccionar y caracterizar un problema: elegir un problema
realmente importante, delimitarlo y describirlo, estudiar antecedente e
importancia, y cuantificar su magnitud actual.
2
Buscar todas las posibles causas: Lluvia de ideas, diagrama de
Ishikawa. Participan los involucrados.
3
Investigar cuáles de las causas son mas importantes: recurrir a
datos, análisis y conocimiento del problema.
4
Elaborar un plan de medidas enfocado a remediar las causas mas
importantes: para cada acción, detallar en qué consiste, su objetivo y
cómo implementarla; responsables, fechas y costos.
Hacer 5
Ejecutar las medidas remedio: seguir el plan y empezar a pequeña
escala.
Verificar 6
Revisar los resultados obtenidos: comparar el problema antes y
después.
Actuar
7 Prevenir la recurrencia: si las acciones dieron resultado, estas deben
generalizarse y estandarizar su aplicación. Establecer medidas para
evitar recurrencia.
8 Conclusión y evaluación de lo hecho: evaluar todo lo hecho
anteriormente y documentarlo.
Fuente: (Gutíerrez Pulido & De La Vara Salazar, 2009, p. 14)
Para llevar a cabo estos pasos es necesario apoyarse en las herramientas estadísticas
mencionadas en la sección “3.2.1.”.
Dentro de la MLITICVE la mejora continua esta aplicada en el ciclo de revisión de la
arquitectura empresarial y la capacidad de esta para el ajuste de la competitividad
detallada en la sección “4.4.1.”.
3.2.3. Arquitectura Empresarial ó Arquitectura de Negocio
En el articulo de Carlos García sobre que es la Arquitectura Empresarial (Garcia , 2013)
dice que:
Podemos definir AE (Arquitectura Empresarial) como la representación de todos
los componentes, procesos y políticas de la empresa.
Según Gartner, Arquitectura Empresarial es el proceso de trasladar una visión y
estrategia de negocio en un cambio efectivo, comunicando las capacidades
actuales y repensando los principios y los modelos que describen el estado futuro
de la empresa y facilitan su evolución.

27
Hoy en día las empresas cuentan con una gran variedad de Software, hardware,
componentes y elementos que se han implementado para ayudar a las diferentes
áreas de las empresas o para mejorar el área de TI; ERP, CRM, Nomina, SOA,
BI, sistemas legados, aplicaciones móviles, etc., etc. Alinear estos componentes
es un reto fundamental, pero alinearlos con la estrategia de negocios es un reto
aún mayor.
AE es una práctica estratégica, que permite conectar las relaciones entre las
iniciativas de negocio y la tecnología que la apalanca, permite evaluar las
fortalezas y debilidades, y trazar estrategias de transformación, desde la
Arquitectura actual hacia un modelo Arquitectónico que represente una visión
futura.
Las empresas tienen una AE, la tengan definida y clara o no, el representarla
desde los diferentes aspectos le permitirá a la empresa entender el impacto de
cada estrategia de negocio en la tecnología y como la tecnología tiene que
adecuarse, modificarse, mejorarse para lograr
La AE nos permite observar como las estrategias, metas, componentes y
tecnologías están relacionadas y mostrar la interdependencia entre ellas, al final
de cuentas los proyectos de tecnología deben existir exclusivamente como parte
de las estrategias de negocio de la empresa.
EA permite enfocar los problemas de una forma integrada y coherente, al mismo
tiempo que ofrece un medio para alcanzar un entendimiento y conceptualización
entre todos los involucrados en las decisiones de la empresa.
Los programas de AE son un apoyo para que las empresas que desean iniciar
proyectos de Innovación Organizacional, Restructuración Administrativa o
Gestión de Procesos de Negocios (BPM).
Una muy buena practica al implementar una AE es usar un modelo de referencia
para lo cual TOGAF (The Open Group Architecture Framework) es una excelente
alternativa, es un marco de trabajo de Arquitectura Empresarial que proporciona
un enfoque para el diseño, planificación, implementación y gobierno de una
arquitectura empresarial de información.
En el documento Q091 del marco de trabajo (framework) de TOGAF (TOGAF, 2014, pp.
Q091-1) detalla que: Es una dimensión o fase “B” de la Arquitectura Empresarial del
Método de Desarrollo de la Arquitectura (ADM) la cual define la estrategia de negocios,
la gobernabilidad, la estructura y los procesos clave de la organización.

28
Figura 3. 10: Vista del Ciclo de desarrollo de la Arquitectura Empresarial (TOGAF)
Fuente: (TOGAF, 2014, pp. Q091-1)
De acuerdo a Andrew Josey (et al.) en su libro TOGAF versión 9.1 (Josey, et al., 2014, p.
34) establece que en la fase “B” del framework se analiza:
• Sus procesos.
• Su gente.
• La relación que hay entre procesos, gente y ambiente.
• Los principios que gobiernan su diseño y evolución.
• La manera en que la organización alcanzara sus metas de negocios.
También en esta fase se definen:
• Estructura de la organización.
• Objetivos de negocio y metas.
• Funciones de Negocio.
• Servicios que ofrece el negocio.
• Procesos.
• Roles en el Negocio.
• Correlación entre la organización y sus funciones.

29
3.2.4. Cadena de valor
En un documento de la web, de la enciclopedia virtual Eumed, Juan Carlos Chávez
Martínez, referente a la “CADENA DE VALOR, ESTRATEGIAS GENÉRICAS Y
COMPETITIVIDAD: EL CASO DE LOS PRODUCTORES DE CAFÉ ORGÁNICO DEL
MUNICIPIO DE TANETZE DE ZARAGOZA, OAXACA” (Chávez Martínez, 2013). Detalla
en su marco teórico algunos conceptos referente a lo que es la cadena de valor que nos
han servido de soporte para el desarrollo de MLITICVE:
Según Arce (2008:4), la cadena de valor tiene como objetivo maximizar la
creación de valor mientras se minimizan los costos. Como instrumento de
decisión proporciona información al categorizar las actividades que producen
valor añadido en una organización e identificar las actividades que le generan una
ventaja competitiva sustentable.
El SIE (2004:4), coincide en que es una herramienta para examinar las
actividades que una empresa desempeña y cómo interactúan entre sí, para poder
analizar las fuentes de ventaja competitiva.
De acuerdo con Donovan (2006:2), la cadena de valor representa la articulación
de todos los actores involucrados en la producción, transformación y
comercialización de un producto, desde la producción primaria, pasando por
diferentes niveles de transformación e intermediación, hasta el consumo final,
acompañado por los proveedores de servicios (técnicos, empresariales y
financieros) de la cadena.
Sin embargo, a pesar de los múltiples conceptos, se considera a Michael E. Porter
como el padre de la cadena de valor por ser el primero en hacer planteamientos
teóricos congruentes y novedosos en torno a este concepto.
Para Porter (2006: 33 y 34), la cadena de valor es una herramienta o medio
sistemático que permite analizar las fuentes de la ventaja competitiva, es decir, la
cadena de valor permite dividir a la empresa en sus actividades estratégicamente
relevantes a fin de comprender su comportamiento en costos, así como las
fuentes actuales y potenciales de diferenciación.
Figura 3. 11: Esquema de la Cadena de Valor de Michael Porter
Fuente: (Robben, 2016, p. 7)

30
De acuerdo con Bernhard Hitpass (Hitpass, 2017, p. 20) la vista de la cadena de valor de
Porter integrada por procesos se vería como sigue:
Figura 3. 12: Vista de procesos de la cadena de valor de Porter
Fuente: (Hitpass, 2017, p. 20)
3.2.5. Proceso de Negocio
Según Hitpass dice que un proceso corresponde a la representación de un conjunto de
acciones (actividades) que se hacen, bajo ciertas condiciones (reglas) y que puede
gatillar o ejecutar cosas (eventos). (Hitpass, 2017, p. 16)
La definición de proceso que se aplicó para la MLITICVE en el capitulo “4.” es la que
expone Hitpass (Hitpass, 2017, p. 17) como sigue:
Es una concatenación lógica de actividades que cumplen un determinado fin, a
través del tiempo y lugar, impulsadas por eventos.
Esta definición contiene los principales elementos que describen un proceso:
• Los eventos son ocurrencias externas que inician un proceso, es decir, un
proceso no se inicia por sí sólo, algo tiene que ocurrir y el proceso
reacciona ante el suceso.
• El proceso debe cumplir un determinado fin, en las ciencias
económicas, destinado a producir bienes y servicios.
• A diferencia de los eventos, las actividades en un proceso consumen
tiempo y recursos. Una actividad se puede definir como una <<acción
sobre un objeto>>, es decir, el proceso de transformación ocurre a través
de las actividades en un proceso.
• Las actividades en un proceso están encadenadas a través de una
secuencia lógica que determinan en su conjunto las condiciones del
negocio.

31
Estos elementos básicos describen en su conjunto los procesos y están
contenidos en la mayoría de las notaciones para modelarlos. La definición es
pura, no dice nada respecto para qué objetivos se levantan y modelan procesos
en una organización.
Un proceso de negocios es un conjunto de actividades que impulsadas por eventos y
ejecutándolas en una cierta secuencia crean valor para un cliente (interno o externo).
(Hitpass, 2017, p. 18)
De acuerdo a Hitpass (Hitpass, 2017, p. 17) un proceso de negocio se reconoce por:
El tipo de evento que lo detona. Una de las principales características de un
proceso de negocio es que es detonado por el cliente y los resultados de la
ejecución del proceso tienen que volver al cliente, entendiéndose en el sentido
más amplio que el cliente también puede ser interno, por ejemplo, un área de
negocio o externo un proveedor.
3.2.6. ROI
El Retorno sobre la Inversión, ROI: Es una razón que relaciona el ingreso generado por
un centro de inversión a los recursos (o base de activos) usados para generar ese
ingreso (Villegas, 2001) . La fórmula usada es:
Figura 3. 13: Formula para el calculo del ROI
Fuente: (Villegas, 2001, p. 14)
Para aplicar esta formula es indispensable definir los siguientes términos:
• El ingreso se debe definir como segmento en lugar de operación.
• Los activos utilizados deberán tomarse como activos disponibles para el uso.
• Los activos de planta deben incluirse al valor corriente.
• Deberá usarse al comienzo del periodo un valor promedio de los activos.
Sin embargo del conocido análisis de Du Pont (Villegas, 2001, p. 18) sabemos que:
El ROI es afectado por la rotación de los activos y por el margen de utilidad. La
rotación de activos mide la productividad de los activos para generar ventas y
muestra del número de pesos de ventas generado por cada peso invertido en
activos. El margen de utilidad es la razón de utilidades a ventas e indica qué
proporción de cada peso vendido al no usarse para cubrir gastos se convierte en
utilidad.
En resumen, la expresión en el modelo Dupont es:
ROI = Rotación de Activos x Margen de Utilidad = [Ventas ÷ Activos] x
[Utilidad ÷ Ventas]

32
En otras palabras el ROI es un indicador financiero que mide la rentabilidad de una
inversión, es decir, la relación que existe entre la utilidad neta o la ganancia obtenida, y la
inversión, y que también se puede expresar como (Arturo, 2012):
ROI = (Utilidad neta o Ganancia / Inversión) x 100
Por ejemplo, si el total de una inversión (capital invertido) es de 4000 y las utilidades
netas obtenidas en el periodo fueron de 1000, aplicando la fórmula del ROI:
ROI = (1000 / 4000) x 100
Nos da un ROI de 25%, con lo que podemos afirmar que la inversión tuvo una
rentabilidad del 25%. (Arturo, 2012)
Para nuestro caso el ROI lo podemos utilizar para evaluar un proyecto de inversión,
como los proyectos de integración de TI, si el ROI es positivo significa que nuestra
integración de TI es rentable, y mientras mayor sea el ROI la inversión se va a recuperar
mas rápido. Por otro lado si el ROI es menor o igual a cero significa que nuestro proyecto
de TI no es rentable y perderemos dinero.
También el ROI nos puede servir para evaluar diferentes proyectos en la fase de
planeación y poder decidir cual es el mas viable desde el punto de vista económico.
Es importante recalcar que debido a su simplicidad el ROI es un indicador que no toma
en cuenta el valor del dinero en el tiempo, por lo que es recomendable al momento de
evaluar un proyecto utilizarlo con otros indicadores como el VAN y el TIR.
El VPN (Valor Presente Neto) es el excedente que queda para el (los) inversionistas
después de haber recuperado la inversión y el costo de oportunidad de los recursos
destinados.
El VPN también llamado VAN (valor actual neto) es un indicador que toma en cuenta el
valor del dinero a través del tiempo. Es decir, que al comparar flujos de efectivo en
diferentes periodos de tiempo, los compara en un solo periodo, llevando todos los valores
al presente, actualizándolos o descontándolos a través de una tasa de interés
(Betancourt Milan, 2001, p. 93)
El TIR (Tasa Interna de Retorno) según Brealey & Myers es el tipo de descuento al cual
él VAN de un proyecto, sería igual a 0 (Brealey, Myers, & Allen, 2010).

33
3.2.7. Investigación y Desarrollo
Algunas definiciones sobre lo que significa investigación las podemos encontrar en el
libro “Proyecto de investigación” de Fidas G. Arias (Arias, 2006, p. 21) que nos parece
adecuado enumerarlas antes de acotar el sentido de esta palabra para la MLITICVE:
“Una investigación puede definirse como un esfuerzo que se emprende para
resolver un problema, claro está, un problema de conocimiento.” (Sabino, 2002,
p. 34).
“Se define la investigación como una actividad encaminada a la solución de
problemas. Su objetivo consiste en hallar respuestas a preguntas mediante el
empleo de procesos científicos.” (Cervo y Bervian, 1989, p. 41).
En la definición de alguna TI a integrar a los procesos empresariales siempre existe un
antecedente de investigación y desarrollo para esta definición, por este motivo es
necesario detallar lo que significa el investigar y desarrollar para la MLITICVE.
Para investigar algo es necesario definir un tema de investigación, para nuestro caso es
establecer alguna TI que aumente la eficiencia y eficacia de los procesos de valor para
que se incremente la competitividad de nuestra micro-empresa.
En el desarrollo del proceso de investigación existen elementos que responden a como
hacer la investigación, entre ellos están:
• Identificación de fuentes.
• Recolección de información.
• Análisis de la información obtenida.
• Presentación de resultados.
El investigar nos conduce a tener conocimiento de la solución al problema que
queremos abordar.
Este conocimiento nos servirá para desarrollar o adaptar una TI que incremente nuestra
competitividad empresarial.
El tipo de investigación para la MLITICVE es la aplicación practica de las TI que
puedan explotarse para resolver el problema de competitividad empresarial.

34
3.3. Paradigmas de construcción y desarrollo TI
Dentro de la ingeniería de software existen varios paradigmas ó modelos de construcción
y desarrollo de productos de TI, sus principios de construcción se han adaptado para su
aplicación de la MLITICVE en el ciclo de gestión de proyectos TI (sección “4.4.5.”).
Estos modelos son:
• Paradigma RAD (Diseño Rápido de Aplicaciones).
• Paradigma de Construcción de Prototipos.
• Paradigma en Espiral.
• Paradigma de desarrollo adaptativos
o Programación extrema (XP).
o SCRUM.
o DAS (Desarrollo Adaptativo de Software).
3.3.1. RAD (Diseño Rápido de Aplicaciones)
Es un modelo de proceso de desarrollo de software relativamente corto, de acuerdo a
(Arvelaez Salazar, Medina Aguirre, & Chaves Osorio, 2011, p. 255) detalla que:
Dura entre 60 y 90 días, este modelo es una adaptación a alta velocidad del
modelo lineal secuencial, para lograr un desarrollo rápido se utiliza la construcción
de software basada en componentes, utilizando herramientas de software que
permitan de forma ágil y efectiva realizar una aplicación con altos estándares de
calidad.
El Modelo RAD comprende las siguientes etapas:
Tabla 3. 5: Etapas del modelo RAD
Etapa Descripción
Modelado de gestión
Este modelo se basa en dar respuesta a las siguientes preguntas:
• ¿Qué información conduce el proceso de gestión?
• ¿Qué información genera?
• ¿A dónde va la información?
• ¿Quién la procesa?
Modelado de datos En este modelo se definen los almacenes de datos y cómo se relacionan los
almacenes entre si.
Modelado del proceso Se utiliza para añadir, modificar, suprimir o recuperar un objeto de datos.
Generación de
aplicaciones
Para esto se utiliza una herramienta de cuarta generación que permite crear el
software y facilitar la construcción del programa.
Pruebas y entrega
El proceso de desarrollo finaliza realizando pruebas de calidad del software
diseñado con la herramienta RAD, posteriormente se realiza la implementación de
la aplicación.
Fuente: Propia basado en (Arvelaez Salazar, Medina Aguirre, & Chaves Osorio, 2011, p. 255)

35
De manera grafica el modelo se ve como en la figura 3.14
Figura 3. 14: Etapas del modelo RAD
Fuente: (Arvelaez Salazar, Medina Aguirre, & Chaves Osorio, 2011, p. 255)
3.3.2. Construcción de Prototipos
Este modelo inicia con la recolección de requerimientos del cliente, con base en estos se
define el conjunto de objetivos para el software, se identifican los requisitos conocidos y
con base en estos se desarrolla rápidamente un prototipo o maqueta que posteriormente
evalúa el cliente utilizándolo y ayudando a refinar de nuevo los requisitos del software a
desarrollar; este proceso se seguirá repitiendo hasta que el cliente quede satisfecho con
el desarrollo del software.
Figura 3. 15: Modelo de construcción de prototipos
Fuente: (Arvelaez Salazar, Medina Aguirre, & Chaves Osorio, 2011, p. 255)
El Modelo de Construcción de Prototipos comprende las siguientes etapas:
Tabla 3. 6: Etapas del modelo Construcción de Prototipos
Etapa Descripción
Requerimientos Análisis de requisitos del sistema y análisis de requisitos del software.
Diseño Desarrollo e implementación del prototipo.
Codificación y test
unitario
Evaluación del prototipo por el cliente, refinamiento iterativo del prototipo
y refinamiento de las especificaciones del prototipo.
Integración final Satisfacción final del prototipo por el cliente, implementación final.
Fuente: Propia basado en (Arvelaez Salazar, Medina Aguirre, & Chaves Osorio, 2011, p. 255)

36
3.3.3. Espiral
Este ciclo puede considerarse una variación del modelo de construcción de prototipos,
fue diseñado por Boehm en el año 1988. El modelo se basa en una serie de ciclos
repetitivos para ir ganando madurez en el producto final. Toma los beneficios de los ciclos
de vida incremental y por prototipos, pero se tiene más en cuenta el concepto de riesgo
(Pressman, 2010, p. 39), que aparece debido a las incertidumbres e ignorancias de los
requerimientos proporcionados al principio del proyecto o que surgirán durante el
desarrollo. A medida que el ciclo se cumple (el avance de la espiral), se van obteniendo
prototipos sucesivos que van ganando la satisfacción del cliente o usuario. A menudo, la
fuente de incertidumbres es el propio cliente o usuario, que en la mayoría de las
oportunidades no sabe con perfección todas las funcionalidades que debe tener el
producto.
En este modelo hay cuatro etapas.
Tabla 3. 7: Etapas del modelo en espiral
Etapa Descripción
Planificación
Levantamiento y revisión de requerimientos iniciales o luego de una
iteración.
Modelado
Análisis de riesgo
De acuerdo con el levantamiento y revisión de requerimientos decidimos
si continuamos con el desarrollo.
Implementación Se desarrolla un prototipo basado en los requerimientos.
Evaluación
El cliente evalúa el prototipo, si da su conformidad, termina el
proyecto. En caso contrario, incluimos los nuevos requerimientos
solicitados por el cliente en la siguiente iteración.
Fuente: Propia basado en (Chubasco, 2009, p. 31)

37
De manera grafica el modelo en espiral se ve como en la figura 3.16
Figura 3. 16: Ciclos del modelo en espiral
Fuente: (Chubasco, 2009, p. 31)
3.3.4. Programación extrema (XP)
En el documento sobre metodologías ágiles de Letelier y Penadés del Departamento de
Sistemas Informáticos de la Universidad Politécnica de Valencia (Letelier & Penadés, 2006)
la define como:
XP es una metodología ágil centrada en potenciar las relaciones interpersonales
como clave para el éxito en desarrollo de software, promoviendo el trabajo en
equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando
un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y
el equipo de desarrollo, comunicación fluida entre todos los participantes,
simplicidad en las soluciones implementadas y coraje para enfrentar los cambios.
XP se define como especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.
El éxito de la programación extrema radica en que enfatiza la implicación del cliente
final y el trabajo en equipo. Es el resultado de la adopción de las mejores metodologías
de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de
manera dinámica durante el ciclo de vida del software.
Figura 3. 17: Mapa de Programación Extrema
Fuente: (Letelier & Penadés, 2006, p. parr. 10)

38
La tabla 3.8 detalla las características y factores del paradigma de Programación
Extrema.
Tabla 3. 8: Características y Factores de decisión de XP
Características Factores de decisión
• Pruebas unitarias continuas,
frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresión.
• Desarrollo iterativo e incremental: pequeñas
mejoras, unas tras otras.
• Frecuente integración del equipo de
programación con el cliente o usuario.
• Corrección de todos los errores antes de
añadir nueva.
• Programación en parejas: se recomienda
que las tareas de desarrollo se lleven acabo
por dos personas en un mismo puesto.
• Se recomienda que un representante del
cliente trabaje junto al equipo de desarrollo.
• La simplicidad y la comunicación son
extraordinariamente complementarias. Con
más comunicación resulta más fácil
identificar qué se debe y qué no se debe
hacer.
Fuente: (FUNIBER, 2017)
1
3.3.5. SCRUM
En el documento sobre metodologías ágiles de Letelier y Penadés del Departamento de
Sistemas Informáticos de la Universidad Politécnica de Valencia (Letelier & Penadés, 2006,
p. 7), detalla que:
SCRUM fue desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle.
Define un marco para la gestión de proyectos, que se ha utilizado con éxito
durante los últimos 10 anos. Está especialmente indicada para proyectos con un
rápido cambio de requisitos. Sus principales características se pueden resumir en
dos. El desarrollo de software se realiza mediante iteraciones, denominadas
sprint, con una duración de 30 días. El resultado de cada sprint es un incremento
ejecutable que se muestra al cliente. La segunda característica importante son las
reuniones a lo largo proyecto, entre ellas destaca la reunión diaria de 15 minutos
del equipo de desarrollo para coordinación e integración.
Figura 3. 18: Etapas del paradigma SCRUM
Fuente: (Schwaber, 2004)
1
Del contenido del documento de la asignatura TI037 de MDEISW
2
Del contenido del documento de la asignatura TI037 de MDEISW, FUNIBER
3
Del contenido del documento de la asignatura TI037 de MDEISW

Metodología de integración de las Tecnologías de Información a las micro empresas

Metodología de integración de las Tecnologías de Información a las micro empresas

Recomendados

Recomendados

Más contenido relacionado

Similar a Metodología de integración de las Tecnologías de Información a las micro empresas

Similar a Metodología de integración de las Tecnologías de Información a las micro empresas (20)

Último

Último (20)

Metodología de integración de las Tecnologías de Información a las micro empresas