capítulo i marco metodológico
TRANSCRIPT
INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y
ADMINISTRATIVAS
“REINGENIERÍA Y AUTOMATIZACIÓN DE PROCESOS DE LA EMPRESA
RELACIONES JURÍDICAS”
T E S I N A
Q U E P A R A O B T E N E R E L T Í T U L O D E :
I N G E N I E R O E N I N F O R M Á T I C A
P R E S E N T A :
C H R I S T I A N C Á R D E N A S O L I V A R E S
Q U E P A R A O B T E N E R E L T Í T U L O D E :
I N G E N I E R O I N D U S T R I A L
P R E S E N T A :
L A U R A R A M Ó N G U T I É R R E Z
MÉXICO D. F. 2009
ÍNDICE
RESUMEN ............................................................................................................................................ i
INTRODUCCIÓN................................................................................................................................. ii
CAPÍTULO I MARCO METODOLÓGICO .......................................................................................... 1
1.1 PLANTEAMIENTO DEL PROBLEMA ........................................................................................... 1 1.2 OBJETIVO (S) ........................................................................................................................ 1
1.2.1 Objetivo General .......................................................................................................... 1
1.2.2 Objetivos específicos .................................................................................................. 1
1.3 TÉCNICAS E INSTRUMENTOS DE MEDICIÓN ............................................................................... 2 1.4 UNIVERSO Y/O MUESTRA ........................................................................................................ 4 1.5 JUSTIFICACIÓN ...................................................................................................................... 4
CAPÍTULO II MARCO TEÓRICO PARA LA REINGENIERÍA DE PROCESOS. ............................. 5
2.1 REINGENIERÍA DE PROCESOS ................................................................................................. 5 2.1.1 ¿Qué es la reingeniería de procesos? .................................................................... 5
2.1.2 Pasos para el Rediseño de un Proceso (Reingeniería) ....................................... 23
2.1.3 Reingeniería ............................................................................................................. 26
2.1.4 Objetivo de la Reingeniería de Procesos .............................................................. 27
2.1.5 Herramientas para la reingeniería de procesos ................................................... 28
2.1.6 Metodología ............................................................................................................. 45
2.2 SUSTENTABILIDAD ............................................................................................................... 48 2.2.1 ¿Qué es la sustentabilidad? ................................................................................... 48
2.2.2 La sustentabilidad: más allá del medio ambiente ................................................ 49
2.2.3 ¿Qué significa el desarrollo sustentable y qué significa la sustentabilidad? .. 50
2.3 CONCLUSIÓN .................................................................................................................. 51
CAPÍTULO III MARCO TEÓRICO PARA LA AUTOMATIZACIÓN DE PROCESOS Y REFERENCIAL ................................................................................................................................. 52
3.1 WEB 2.0 ............................................................................................................................ 52 3.1.1 Definición ................................................................................................................. 52
3.1.2 Orígenes del término............................................................................................... 52
3.1.3 Características principales de la WEB 2.0 ............................................................ 53
3.2 LA SOCIEDAD DEL CONOCIMIENTO EN LA AUTOMATIZACIÓN DE PROCESOS ............................. 53 3.2.1 Sociedad del conocimiento .................................................................................... 53
3.2.2 Adam Smith y Peter Drucker y la "Sociedad del Conocimiento" ....................... 54
3.3 SOCIEDAD DEL CONOCIMIENTO Y NUEVAS TECNOLOGÍAS ..................................................... 54 3.4 LA INTERNET EN LA SOCIEDAD DEL CONOCIMIENTO ............................................................... 55 3.5 AUTOMATIZACIÓN ................................................................................................................ 56
3.5.1 ¿Qué es la automatización? ................................................................................... 56
3.6 TECNOLOGÍAS DE LA INFORMACIÓN ...................................................................................... 58 3.6.1 Definición ................................................................................................................. 58
3.7 METODOLOGÍAS DE DESARROLLO DE SOFTWARE .................................................................. 58 3.7.1 Definición de metodologías ................................................................................... 58
3.7.2 Metodologías existentes para el desarrollo de software .................................... 59
3.8 PROGRAMACIÓN ORIENTADA A OBJETOS ............................................................................. 69 3.8.1 Origen ....................................................................................................................... 69
3.8.2 Conceptos Básicos ................................................................................................. 70
3.8.3 Características ......................................................................................................... 71
3.9 BASE DE DATOS .................................................................................................................. 72 3.9.1 Definición ................................................................................................................. 72
3.9.2 Tipos de bases de datos ......................................................................................... 72
3.9.3 Modelos de base de datos ...................................................................................... 73
3.9.4 Sistema de gestión de base de datos ................................................................... 75
3.10 UML ................................................................................................................................... 77 3.10.1 Definición ............................................................................................................. 77
3.10.2 Diagramas ............................................................................................................ 79
3.10.3 Software para modelado en UML ....................................................................... 81
3.11 LENGUAJES DE PROGRAMACIÓN .......................................................................................... 83 3.11.1 Historia de los lenguajes de programación ...................................................... 83
3.11.2 Lenguaje maquina ............................................................................................... 83
3.11.3 Lenguajes ensambladores ................................................................................. 83
3.11.4 Lenguajes ensambladores ................................................................................. 84
3.12 WEB CLIENT SOFTWARE FACTORY ...................................................................................... 84 3.12.1 Definición ............................................................................................................. 84
3.12.2 Principales Patrones y practicas de la Web Client Software Factory ............ 84
3.13 AJAX CONTROL TOOLKIT ................................................................................................... 87 3.14 RELACIONES JURÍDICAS ...................................................................................................... 87
3.14.1 ¿Qué es la empresa Relaciones Jurídicas? ..................................................... 87
3.14.2 Estructura organizacional .................................................................................. 87
3.14.3 Misión ................................................................................................................... 88
3.14.4 Visión .................................................................................................................... 88
3.14.5 Objetivo ................................................................................................................ 88
3.14.6 Marco jurídico ...................................................................................................... 88
3.15 CONCLUSIÓN .................................................................................................................. 89
CAPÍTULO IV. PROCESAMIENTO Y ANÁLISIS DE LA INFORMACIÓN DE CAMPO ................. 90
4.1 ANÁLISIS DE SITUACIÓN ACTUAL DEL ÁREA JURÍDICA DE LA EMPRESA RELACIONES
JURÍDICAS ....................................................................................................................................... 90 4.1.1 Micro-escenario ....................................................................................................... 90
4.1.2 Desarrollo de Diagramas de Actividades.............................................................. 94
4.1.3 Proceso del Área de Asuntos Jurídicos ............................................................... 98
4.1.4 Análisis de Normatividad de Procesos ................................................................ 99
4.1.5 Identificación de Vulnerabilidades MATRIZ FODA ............................................ 100
4.1.6 Matriz (MAFE) ......................................................................................................... 102
4.1.7 Matriz de Evaluación de Factores Externos (MEFE) ......................................... 103
4.1.8 Matriz de Evaluación de Factores Internos (MEFI) ............................................ 104
4.1.9 Tabla de Acciones FODA ..................................................................................... 106
4.2 TABLA DE DIAGNOSTICO ( CAUSA, PROBLEMA, CONSECUENCIA) ............................. 107 4.2.1 Diagrama Causa – Efecto ..................................................................................... 108
4.3 DIAGNOSTICO DE SITUACIÓN ACTUAL DEL ÁREA JURÍDICA DE LA EMPRESA RELACIONES
JURÍDICAS ..................................................................................................................................... 110 4.3.1 Tabla de Análisis Diagnostico del Mes de Noviembre 2008 ............................. 110
4.3.2 Tabla de Análisis Diagnostico ............................................................................. 111
4.3.3 Diagrama de PARETO .......................................................................................... 112
4.4 RESULTADOS DE SITUACIÓN ACTUAL ................................................................................. 113 4.5 CONCLUSIÓN ................................................................................................................ 114
CAPÍTULO V DESARROLLO DE LA REINGENIERÍA DE PROCESO ....................................... 115
5.1 REINGENIERÍA DEL PROCESO ............................................................................................. 115 5.1.1 Proceso actual del Área de Asuntos Jurídicos .................................................. 116
5.1.2 Representación de Análisis de Procesos en Asuntos Jurídicos ..................... 117
5.2 MAPEO DE PROCESOS ....................................................................................................... 118 5.3 DISEÑO DE LA PROPUESTA PARA REINGENIERÍA DE PROCESOS ........................................... 121
5.3.1 Propuesta ............................................................................................................... 121
5.3.2 Proceso Rediseñado del Área de Asuntos Jurídicos ........................................ 122
5.3.3 Recomendaciones para llevar a cabo la reingeniería de procesos ................. 123
5.4 RECICLAJE ........................................................................................................................ 123 5.4.1 Objetivo .................................................................................................................. 124
5.4.2 Alcance ................................................................................................................... 124
5.4.3 Terminología y definiciones ................................................................................. 124
5.4.4 Responsabilidades ................................................................................................ 125
5.4.5 Descripción del procedimiento ............................................................................ 125
5.4.6 Análisis costo beneficio ....................................................................................... 126
5.4.7 Presentación del procedimiento .......................................................................... 127
5.5 CONCLUSIÓN ................................................................................................................ 129
CAPÍTULO VI PROPUESTA DE AUTOMATIZACIÓN DE PROCESOS ....................................... 130
6.1 IDENTIFICACIÓN DE SERVICIOS A AUTOMATIZAR ................................................................... 130 6.2 ETAPA DE INICIO ................................................................................................................ 133
6.2.1 Definición de alcance de automatización ........................................................... 133
6.3 ELABORACIÓN ................................................................................................................... 137 6.3.1 Especificación de requerimientos ....................................................................... 137
6.3.2 Desarrollo de casos de uso .................................................................................. 143
6.3.3 Desarrollo de arquitectura .................................................................................... 171
6.3.4 Diagrama entidad relación ................................................................................... 175
6.3.5 Interfaz gráfica ....................................................................................................... 176
6.4 CONSTRUCCIÓN................................................................................................................. 178 6.5 TRANSICIÓN ...................................................................................................................... 179 6.6 CONCLUSIÓN ................................................................................................................ 180
CONCLUSIONES............................................................................................................................ 181
BIBLIOGRAFÍA............................................................................................................................... 183
GLOSARIO ..................................................................................................................................... 185
ANEXO ............................................................................................................................................ 190
i
RESUMEN
La empresa Relaciones Jurídicas se dedica a la atención y la defensa de asuntos jurídicos
desprendidos de faltas en lo establecido en algún documento oficial como lo son leyes federales,
permisos y reglamentos. Actualmente la cantidad de asuntos ingresados ha ido en aumento, de tal
manera que se ha rebasado la capacidad operativa del área jurídica, provocando que no se
puedan atender de manera oportuna los asuntos turnados a la misma. El no atender de manera
oportuna los asuntos de índole jurídica trae como consecuencias la imposición de sanciones
administrativas a las autoridades responsables de los asuntos, que se deje de atender la orden
directa de un superior jerárquico o que se pierdan los asuntos ante un Juzgado o Tribunal. En la
actualidad en las empresas existe una gran diversidad de problemas o mas bien preferimos
llamarlas oportunidades de crecimiento y desarrollo. Es labor de nosotros como profesionales
tomar esas oportunidades y transformarlas en algo productivo e innovador para las organizaciones.
La intención de esta tesina es presentar la solución a la problemática que existe en la
empresa ―Relaciones Jurídicas‖. Este trabajo consta fundamentalmente de 2 partes que son: la
Reingeniería y la Automatización de los procesos. Dentro de la primera etapa nos enfocamos a
determinar las causas del problema discutiéndose y analizando de manera tal que se pudieran
desarrollar soluciones a cada una de las partes del problema y descartar todas aquellas partes que
no fueran parte del mismo, para esto se utilizaron técnicas y herramientas de reingeniería que nos
llevan a ver los problemas reales y poder atacarlos de forma eficaz. Como resultado de la
reingeniería de procesos se determino automatizar los procesos que se consideraron críticos para
el funcionamiento óptimo de la empresa, de esta manera nace SISJUR (Sistema Jurídico).
SISJUR, es una herramienta desarrollada sobre plataforma WEB que permite atender y aumentar
la velocidad de respuesta así como el control sobre la operación critica de la empresa Relaciones
Jurídicas.
Por otro lado y no menos importante, durante este seminario nos hemos creado una nueva
visión de los problemas que atacan a las empresas y al mundo en general, Al inicio de este
proyecto nos enfocábamos en resolver una problemática de una empresa sin detenernos a pensar
en como esta solución afectaría al entorno. Pero al final hemos creado una solución que procura
transformar una empresa social y ecológicamente responsable. Esto lo queremos lograr mediante
la implementación de procesos de reciclaje además de contar con un sistema informático que
permitirá optimizar y reducir el consumo de papel dentro de la empresa.
ii
INTRODUCCIÓN
Actualmente el desarrollo de las sociedades del conocimiento abren cada día más brechas
hacia el desarrollo sustentable, por tal motivo para este proyecto nos basamos en algunos de estos
conceptos, para generar una propuesta que no solo permita cubrir las necesidades actuales de
operación y que asegure el optimo funcionamiento de los procesos en la empresa ―Relaciones
Jurídicas‖, si no que también contribuya a transformar a esta empresa en una empresa sustentable
así como responsable ecológicamente. Para esto nos basamos en el uso de metodologías de
mejora continua y desarrollo de software que nos permitirá tener un mejor control de la información
recopilada y tomar mejores decisiones a partir de ella.
Durante el desarrollo de este proyecto se podrá apreciar como a partir de una problemática
planteada se va generando una solución de una forma ordenada y como esta misma solución, que
comúnmente se hubiera desarrollado bajo el esquema antiguo ahora es una solución con nuevos
enfoques y nuevos conceptos que nos permiten acercarnos a la sociedad del conocimiento y a la
sustentabilidad empresarial.
Para el desarrollo de esta tesina, desarrollamos un total de 6 capítulos, en cada uno de los
capítulos se manejan temas que de manera progresiva ayudan a entender y se observar como va
madurando el proyecto hasta resolver la problemática plateada.
Capítulo I Marco Metodológico: Se plantea la problemática a tratar dentro de la empresa
―Relaciones Jurídicas―.
Capítulo II Marco teórico para la reingeniería de procesos: Se establecen las teorías y
conceptos y técnicas sobre las cuales se desarrollara la tesis en cuanto a lo que se refiere a la
reingeniería de procesos.
Capítulo III Marco teórico para la Automatización de procesos y Referencial: Se
establecen las teorías y conceptos sobre las cuales se desarrollara la tesis en cuanto a lo que se
refiere a la automatización de procesos.
Capítulo IV Procesamiento y análisis de la información de campo: Se realiza todo el
levantamiento de la información para determinar la situación actual mediante el uso y aplicación de
una metodología así como de distintas herramientas.
iii
Capítulo V Desarrollo de la reingeniería de proceso: Se realiza el rediseño o reingeniería
de los procesos basándose en la información obtenida del análisis de la situación actual, así mismo
las propuestas para que este proceso funcione correctamente con la ayuda de la técnica de mapeo
de procesos. A demás se desarrolla el proceso de reciclaje como aportación para contribuir a tener
una empresa sustentable.
Capítulo VI Propuesta de Automatización de procesos: Se realiza el diseño y construcción
de la aplicación basándonos en las necesidades de la empresa así como en el resultado de la
reingeniería de procesos.
Al final de estos 6 capítulos hemos obtenido una solución que satisface la problemática
planteada de manera muy exitosa y que además contribuye con la sustentabilidad de la empresa
con la creación de un proceso de reciclaje de papel que nos permitirá reducir considerablemente el
uso del mismo y que con la ayuda del sistema desarrollado se complementa para ayudar en esta
labor de reciclaje además de optimizar la operación de la empresa ―Relaciones Jurídicas‖.
1
Capítulo I Marco Metodológico
1.1 Planteamiento del problema
La atención de asuntos jurídicos para muchas empresas en distintos sectores, forma parte
de las actividades cotidianas. En muchos de los casos y específicamente en el sector gobierno
existen diversos trámites burocráticos que por su propia naturaleza impiden la contestación
oportuna de los asuntos desencadenando diversas consecuencias. Para algunos tipos de asuntos
estas consecuencias son mayores ya que existe un incumplimiento directo con lo establecido en la
ley.
Hoy en día en la empresa “Relaciones Jurídicas”, los procedimientos establecidos en el
manual de procesos ya no cubren las necesidades actuales del área de asuntos jurídicos, ya que
estos fueron definidos en el año 2004 sin haber sufrido revisiones y actualizaciones de acuerdo a
los cambios de operación del área.
Actualmente el retrazo en el tiempo de respuesta derivado por el ineficiente proceso de
recepción, contestación y seguimiento de los asuntos jurídicos ingresados en la empresa
Relaciones Jurídicas, provoca que se impongan sanciones administrativas a las autoridades
responsables, que se incumpla una orden de un superior jerárquico, que se incumpla lo
establecido en las leyes correspondientes al tipo de asunto o se pierda el caso ante un Tribunal o
Juzgado.
1.2 Objetivo (s)
1.2.1 Objetivo General
Optimizar y automatizar los procesos para disminuir el retraso en el tiempo de respuesta en
la recepción, contestación y seguimiento de los asuntos jurídicos ingresados en la empresa
Relaciones Jurídicas.
1.2.2 Objetivos específicos
Realizar análisis de situación actual.
Identificar los procesos actuales para la recepción, contestación y seguimiento de asuntos
jurídicos ingresados en la empresa Relaciones Jurídicas.
2
Analizar normatividad de procesos por área.
Analizar e Identificar vulnerabilidades de procesos identificados.
Establecer metodologías de mejora continua y desarrollo de sistema de información.
Atacar causas del problema.
Generar propuestas integrales de solución al problema.
Evaluar TI (Plataforma de desarrollo, Base de Datos) para generación de propuestas de
automatización de procesos.
Realizar levantamiento de análisis detallado para automatización de procesos
(Requerimientos de usuario, sistema y negocio).
1.3 Técnicas e instrumentos de medición
Los instrumentos de medición que utilizaremos para obtener la información requerida en
este proyecto son:
Entrevistas.
Para un primer acercamiento utilizaremos la entrevista informal, mediante esta
obtendremos un panorama general de la realidad de los problemas que presenta el área jurídica.
Como segundo paso realizaremos entrevistas focalizadas, con el propósito de conseguir la
mayor información sobre puntos específicos de los problemas detectados en las entrevistas
informales. Así mismo utilizaremos entrevistas por pautas o guías para obtener información más
especializada acerca de un tema específico de la problemática.
Para esto utilizaremos la investigación Tecnológica, de campo y documental ya que este
tipo de investigaciones se apoyan en información derivadas de entrevistas siguiendo los siguientes
pasos:
3
Pasos de una investigación
Planteo del problema.
Etapa exploratoria. - Lecturas. - Visitas al terreno. - Conversaciones con colegas. -
Entrevistas a personas que conocen el problema por experiencia personal o debido a sus
estudios.
Delimitaciones operativas del problema. Unidades de análisis, variables, indicadores,
muestra.
Redacción de un plan tentativo de procesamiento y análisis de los datos.
Recolección de los datos.
Importancia de utilizar la investigación
La investigación nos ayuda a mejorar el estudio porque nos permite establecer contacto
con la realidad a fin de que la conozcamos mejor, así mismo nos ayuda a desarrollar la solución de
problemas más confiables y exactos.
Metodología: para toda investigación es de importancia fundamental que los hechos y
relaciones que establece, los resultados obtenidos o nuevos conocimientos y tengan el grado
máximo de exactitud y confiabilidad. Para ello planea una metodología o procedimiento ordenado
que se sigue para establecer lo significativo de los hechos y fenómenos hacia los cuales está
encaminado el significado de la investigación.
Una vez recopilado los datos por los instrumentos diseñados para este fin es necesario
procesarlos, es decir, elaborarlos matemáticamente, ya que la cuantificación y su tratamiento
estadístico nos permitirán llegar a construcciones en relación con la hipótesis planteada. El
procesamiento de datos, antes dispendioso mediante métodos manuales, es hoy realizado por
computadoras electrónicas las cuales han eliminado, por así decirlo, gran parte del trabajo
matemático y estadístico que antes se realizaba.
El Informe: la estructura del informe de investigación es sencilla y sigue fielmente los
pasos fundamentales del diseño de la investigación; en ningún momento debe ser contraria al
diseño, ya que el informe debe ser la respuesta de lo planteado al diseño de la investigación.
4
Para la presentación del informe debe seguirse las normas de la metodología formal de
presentación de trabajos cinéticos, los cuales se han considerado en diversas obras por los
tratadistas de la metodología formal.
1.4 Universo y/o muestra
Por la naturaleza del proyecto de tesis, el universo será el personal de la empresa
Relaciones Jurídicas, asignada a la atención de los asuntos jurídicos. El personal es el siguiente:
1. Subdirector de área jurídica.
2. Dos abogados.
3. Auxiliar administrativo.
4. Notificador.
1.5 Justificación
Actualmente el área de recepción, encargada del ingreso de documentos por parte de
Relaciones Jurídicas, por la gran cantidad de documentos recibidos y por el ineficiente proceso de
recepción y turno de documentos, turna de manera tardía los documentos relacionados con el área
jurídica, generando desde este momento un retardo en la contestación y seguimiento de los
asuntos Jurídicos. El correcto funcionamiento del área de recepción permitirá un mejor control de
la documentación recibida y mayor velocidad en el proceso de turno de los asuntos Jurídicos. Para
lograr el óptimo funcionamiento del área de recepción será necesario realizar una revisión a los
procedimientos actuales y en su caso hacer una reingeniería de los mismos así como contar con
una herramienta automatizada que permita tener mas velocidad y control sobre la documentación
recibida.
Por otro lado, contar con procedimientos eficientes y un sistema de información integral,
permitirá al área jurídica tener mejor control sobre los asuntos que le son turnados; agilizar el
proceso de análisis, asignación de prioridades, contestación y notificación de asunto. Permitiendo
con esto reducir considerablemente el tiempo de respuesta de un asunto y monitorear en cualquier
momento la fecha máxima de entrega, estatus jurídico y de proceso de los asuntos atendidos.
Adicionalmente la implementación de este sistema de información, permitirá reducir
considerablemente el uso del papel, ya que se manejarán documentos electrónicos, digitalizados
así como revisiones electrónicas.
5
Capítulo II Marco teórico para la Reingeniería de Procesos.
2.1 Reingeniería de procesos
2.1.1 ¿Qué es la reingeniería de procesos?
2.1.1.1 Definición formal de reingeniería
Estamos entrando en el nuevo siglo, con compañías que funcionaron en el XX con diseños
administrativos del siglo XIX. Necesitamos algo enteramente distinto. Ante un nuevo contexto,
surgen nuevas modalidades de administración, entre ellas está la reingeniería, fundamentada en la
premisa de que no son los productos, sino los procesos que los crean los que llevan a las
empresas al éxito a la larga. Los buenos productos no hacen ganadores; los ganadores hacen
buenos productos. Lo que tienen que hacer las compañías es organizarse en torno al proceso. 1
Las operaciones fragmentadas situadas en departamentos especializados, hacen que
nadie esté en situación de darse cuenta de un cambio significativo, o si se da cuenta, no puede
hacer nada al respecto, porque sale de su radio de acción, de su jurisdicción o de su
responsabilidad. Esto es consecuencia de un concepto equivocado de administración
organizacional.
Un proceso de negocios es un conjunto de actividades que reciben uno o más insumos
para crear un producto de valor para el cliente.
Reingeniería significa volver a empezar arrancando de nuevo; reingeniería no es hacer
más con menos, es con menos dar más al cliente. El objetivo es hacer lo que ya estamos
haciendo, pero hacerlo mejor, trabajar más inteligentemente.
Es rediseñar los procesos de manera que estos no estén fragmentados. Entonces la
compañía se las podrá arreglar sin burocracias e ineficiencias.
Propiamente hablando: "reingeniería es la revisión fundamental y el rediseño radical de
procesos para alcanzar mejoras espectaculares en medidas críticas y actuales de rendimiento,
tales como costos, calidad, servicio y rapidez‖.
1 Joiner, Brian. Gerencia de la cuarta generación, McGraw-Hill, México.1995, pp23, 24.
6
Hacia la reingeniería
Detrás de la palabra reingeniería, existe un nuevo modelo de negocios y un conjunto
correspondiente de técnicas que los ejecutivos y los gerentes tendrán que emplear para reinventar
sus compañías.
Bajo el pensamiento tradicional de la administración muchas de las tareas que realizaban
los empleados nada tenía que ver con satisfacer las necesidades de los clientes. Muchas de esas
tareas se ejecutaban para satisfacer exigencias internas de la propia organización de la empresa.
En el ambiente de hoy nada es constante ni previsible, ni crecimiento del mercado, ni
demanda de los clientes, ni ciclo de vida de los productos. Tres fuerzas, por separado y en
combinación, están impulsando a las compañías a penetrar cada vez más profundamente en un
territorio que para la mayoría de los ejecutivos y administradores es desconocido. Estas fuerzas
son: clientes, competencia y cambio.
Clientes
Los clientes asumen el mando, ya no tiene vigencia el concepto de él cliente, ahora es este
cliente, debido a que el mercado masivo hoy está dividido en segmentos, algunos tan pequeños
como un solo cliente. Los clientes ya no se conforman con lo que encuentran, ya que actualmente
tienen múltiples opciones para satisfacer sus necesidades.
Esto es igualmente aplicable en la relación cliente-proveedor entre las propias empresas, y
los reclamos muchas veces se expresan en: "O lo hace usted como yo quiero o lo hago yo mismo".
Los clientes se han colocado en posición ventajosa, en parte por el acceso a mayor información.
Para las empresas que crecieron con la mentalidad de mercado masivo, la realidad es más
difícil de aceptar acerca de los clientes, en cuanto a que cada uno cuenta. Si se pierde un cliente
hoy, no se aparece otro para reemplazarlo.2
Competencia
Antes era sencilla: la compañía que lograba salir al mercado con un producto o servicio
aceptable y al mejor precio realizaba una venta. Ahora hay mucho más competencia.
2 Idem.
7
La globalización trae consigo la caída de las barreras comerciales y ninguna compañía
tiene su territorio protegido de la competencia extranjera. Empresas americanas, japonesas,
europeas tienen experiencia en mercados fuertemente competitivos y están muy ansiosas de ganar
una porción de nuestro mercado. Ser grande ya no es ser invulnerable, y todas las compañías
existentes tienen que tener la agudeza para descubrir las nuevas compañías del mercado.
Las compañías nuevas no siguen las reglas conocidas y hacen nuevas reglas para
manejar sus negocios.
El cambio
El cambio se vuelve una constante, la naturaleza del cambio también es diferente. La
rapidez del cambio tecnológico también promueve la innovación Los ciclos de vida de los
productos han pasado de años a meses. Ha disminuido el tiempo disponible para desarrollar
nuevos productos e introducirlos. Hoy las empresas tienen que moverse más rápidamente, o
pronto quedarán totalmente paralizadas.
Los ejecutivos creen que sus compañías están equipadas con radares eficientes para
detectar el cambio, pero la mayor parte de ellas no lo está, lo que detectan son lo cambio que ellas
mismas esperan. Los cambios que pueden hacer fracasar a una compañía son lo que ocurren
fuera de sus expectativas.
¿Qué se va a rediseñar?
Recordemos que son los procesos y no las organizaciones los sujetos a reingeniería. Es
una parte difícil dado que normalmente podemos identificar todos los elementos dentro de una
organización pero no así los procesos, podemos hablar del departamento de compras y sus
procedimientos, pero pocas veces hablamos de un proceso de compras que involucra a varios
departamentos y que por definición debería tener un solo encargado.
Para identificar y entender mejor los procesos, se les pueden poner nombres que indiquen
su estado inicial y final: 3
Manufactura: proceso de aprovisionamiento a despacho.
Desarrollo de producto: de concepto a prototipo.
3 Idem.
8
Ventas: de comprador potencial a pedido.
Despacho de pedidos: de pedido a pago.
Servicio: de indagación a resolución.
Para seleccionar un proceso a rediseñar podemos considerar los siguientes aspectos:
Procesos quebrantados
Tienen dificultades en tener un producto final. Formas de identificarlos son:
Extenso intercambio de información, redundancia de datos, tecleo repetido. Es causado
por la fragmentación arbitraria de un proceso natural. El flujo de información debe reducirse
a productos terminados, y no reprocesarse la información en cada unidad a partir de la
información recibida.
Inventarios, reservas y otros activos. Existen debido a incertidumbres en los procesos
internos y externos. Estas reservas no solo suelen ser de materiales, también son de
personal o recursos financieros. Es necesario planear junto con proveedores y clientes las
necesidades para no contar con recursos ociosos.
Alta relación de comprobación y control con valor agregado. Fragmentación. Existen
procesos internos que no dan valor agregado al producto pero si afectan su costo y calidad
final.
Repetición de trabajo. Retroinformación inadecuada a lo largo de las cadenas. A menudo
el problema se corrige al final del proceso regresando el producto al inicio sin indicar
incluso cual fue el problema encontrado y cuando se detectó.
Complejidad, excepciones y casos especiales. Acumulación a una base sencilla. A un
proceso sencillo inicial le creamos excepciones y casos especiales a medida que surgen
otros problemas, en reingeniería es necesario rescatar el proceso inicial y crear otro
proceso para cada caso especial que surja. 4
4 Idem.
9
Procesos importantes
Son los que causan un impacto directo a los clientes, y es el segundo en importancia al
seleccionar procesos de reingeniería. En este caso es necesario estar en contacto con los clientes
de cada proceso para identificar sus necesidades, aunque este no conoce el proceso si le da
importancia a algunas características resultantes de él como son precio, entregas oportunas,
características del producto, etc. Mismas que nos pueden dar una idea de que parte del proceso se
está hablando.
Procesos factibles
Otro concepto es el de factibilidad y se basa en el radio de influencia en cuanto a la
cantidad de unidades organizacionales que intervienen en él, mientras más sean, mayor será el
radio de influencia. Antes de seguir con la reingeniería, es necesario entender al proceso y no irse
a los detalles, entendiendo el proceso es posible crear nuevos detalles.
El análisis tradicional toma los insumos y productos de un proceso como supuestos y mira
dentro del proceso para medir y examinar lo que ocurre. En cambio entender el proceso no da
nada por sentado, al entender un proceso no se acepta el producto como un supuesto, pero en
parte si es entender que hace el cliente con ese producto. Esto implica entender al cliente mejor
que lo que el se entiende.
2.1.1.2 Reconstrucción de los procesos
A continuación se presentan algunas características comunes de procesos renovados
mediante reingeniería.
Varios oficios se combinan en uno
La característica más común y básica de los procesos rediseñados es que desaparece el
trabajo en serie. Es decir, muchos oficios o tareas que antes eran distintos se integran y
comprimen en uno solo. Sin embargo, no siempre es posible comprimir todos los pasos de un
proceso en un solo oficio ejecutado por una sola persona. En otros casos, puede no resultar
práctico enseñarle a una sola persona todas las destrezas que necesitaría para ejecutar la totalidad
del proceso. 5
5 Idem.
10
Los beneficios de los procesos integrados eliminan pases laterales, lo que significa acabar
con errores, demoras y repeticiones. Asimismo, reducen costos indirectos de administración dado
que los empleados encargados del proceso asumen la responsabilidad de ver que los requisitos
del cliente se satisfagan a tiempo y sin defectos. Adicionalmente, la compañía estimula a estos
empleados para que encuentren formas innovadoras y creativas de reducir continuamente el
tiempo del ciclo y los costos, y producir al mismo tiempo un producto o servicio libre de defectos.
Otro beneficio es un mejor control, pues como los procesos integrados necesitan menos personas,
se facilita la asignación de responsabilidad y el seguimiento del desempeño.
Los trabajadores toman decisiones
En lugar de separar la toma de decisiones del trabajo real, la toma de decisiones se
convierte en parte del trabajo. Ello implica comprimir verticalmente la organización, de manera que
los trabajadores ya no tengan que acudir al nivel jerárquico superior y tomen sus propias
decisiones.
Entre los beneficios de comprimir el trabajo tanto vertical como horizontalmente se cuentan:
Menos demoras, costos indirectos más bajos, mejor reacción de la clientela y más facultades para
los trabajadores.
Los pasos del proceso se ejecutan en orden natural
Los procesos rediseñados están libres de la tiranía de secuencias rectilíneas: se puede
explotar la ejecución simultánea de tareas por sobre secuencias artificiales impuestas por la
linealidad en los procesos. En los procesos rediseñados, el trabajo es secuenciado en función de lo
que realmente es necesario hacerse antes o después.
La "deslinearización" de los procesos los acelera en dos formas: Primera: Muchas tareas se
hacen simultáneamente. Segunda: Reduciendo el tiempo que transcurre entre los primeros pasos y
los últimos pasos de un proceso se reduce el esquema de cambios mayores que podrían volver
obsoleto el trabajo anterior o hacer el trabajo posterior incompatible con el anterior. Las
organizaciones logran con ello menos repeticiones de trabajo, que es otra fuente de demoras.
Los trabajos tienen múltiples versiones
Esto se conoce como el fin de la estandarización. Significa terminar con los tradicionales
procesos únicos para todas las situaciones, los cuales son generalmente muy complejos, pues
tienen que incorporar procedimientos especiales y excepciones para tomar en cuenta una gran
11
variedad de situaciones. En cambio, un proceso de múltiples versiones es claro y sencillo porque
cada versión sólo necesita aplicarse a los casos para los cuales es apropiada. No hay casos
especiales ni excepciones. 6
El trabajo se realiza en el sitio razonable
Gran parte del trabajo que se hace en las empresas, consiste en integrar partes del trabajo
relacionadas entre sí y realizadas por unidades independientes. El cliente de un proceso puede
ejecutar parte del proceso o todo el proceso, a fin de eliminar los pases laterales y los costos
indirectos.
Después de la reingeniería, la correspondencia entre los procesos y organizaciones puede
parecer muy distinta a lo que era antes, al reubicarse el trabajo en unidades organizacionales, para
mejorar el desempeño global del proceso.
Se reducen las verificaciones y los controles
Los procesos rediseñados hacen uso de controles solamente hasta donde se justifican
económicamente. Los procesos tradicionales están repletos de pasos de verificación y control que
no agregan valor, pero que se incluyen para asegurar que nadie abuse del proceso. Los procesos
rediseñados muestran un enfoque más equilibrado. En lugar de verificar estrictamente el trabajo a
medida que se realiza, se tienen controles globales o diferidos. Estos sistemas están diseñados
para tolerar abusos moderados o limitados, demorando el punto en el que el abuso se detecta o
examinando patrones colectivos en lugar de casos individuales. Sin embargo, los sistemas
rediseñados de control compensan con creces cualquier posible aumento de abusos con la
dramática disminución de costos y otras trabas relacionadas con el control mismo.
La conciliación se minimiza
Se disminuyen los puntos de contacto externo que tiene un proceso, y con ello se reducen
las posibilidades de que se reciba información incompatible que requiere de conciliación.
Un gerente de caso ofrece un solo punto de contacto
Este personaje aparece frecuentemente en procesos rediseñados, cuando los pasos del
proceso son tan complejos o están tan dispersos que es imposible integrarlos en una sola persona
6 Idem.
12
o incluso en un pequeño grupo. El gerente de caso funge como un "defensor de oficio" del cliente,
responde a las preguntas y dudas del cliente y resuelve sus problemas. Por tanto, el gerente de
caso, cuenta con acceso a todos los sistemas de información que utilizan las personas que realizan
el trabajo y tiene la capacidad para ponerse en contacto con ellas, hacerles preguntas y solicitarles
ayuda cuando sea necesario.7
Prevalecen operaciones hibridas centralizadas-descentralizadas
Las empresas que han rediseñado sus procesos tienen la capacidad de combinar las
ventajas de la centralización con las de la descentralización en un mismo proceso. Apoyadas por la
informática, estas empresas pueden funcionar como si las distintas unidades fueran
completamente autónomas, y, al mismo tiempo, la organización disfruta de las economías de
escala que crea la centralización.
2.1.1.3 Tipos de cambios que ocurren al rediseñar los procesos
Cambian las unidades de trabajo: de departamentos funcionales a equipos de proceso
En cierto modo lo que se hace es volver a reunir a un grupo de trabajadores que habían sido
separados artificialmente por la organización. Cuando se vuelven a juntar se llaman equipos de
proceso. En síntesis, un equipo de procesos es una unidad que se reúne naturalmente para
completar todo un trabajo -un proceso.
Los oficios cambian: de tareas simples a trabajo multidimensional
Los trabajadores de equipos de proceso que son responsables colectivamente de los
resultados del proceso, más bien que individualmente responsables de una tarea, tienen un oficio
distinto. Comparten con sus colegas de equipo, la responsabilidad conjunta del rendimiento del
proceso total, no sólo de una pequeña parte de él.
Aunque no todos los miembros del equipo realizan exactamente el mismo trabajo, la línea
divisoria entre ellos se desdibuja. Todos los miembros del equipo tienen por lo menos algún
conocimiento básico de todos los pasos del proceso, y probablemente realizan varios de ellos.
Además todo lo que hace el individuo lleva el sello de una apreciación del proceso en forma global.
Cuando el trabajo se vuelve multidimensional, también se vuelve más sustantivo. La
7 Idem.
13
reingeniería no sólo elimina el desperdicio sino también el trabajo que no agrega valor. La mayor
parte de la verificación, la espera, la conciliación, el control y el seguimiento -trabajo improductivo
que existe por causa de las fronteras que hay en una empresa y para compensar la fragmentación
de un proceso- se eliminan con la reingeniería, lo cual significa que la gente destinará más tiempo
a hacer su trabajo real. 8
Después de la reingeniería, no hay eso de "dominar un oficio"; el oficio crece a medida que
crecen la pericia y la experiencia del trabajador.
El papel del trabajador cambia: de controlado a facultado
Cuando la administración confía en los equipos la responsabilidad de completar un proceso
total, necesariamente tiene que otorgarles también la autoridad para tomar las medidas
conducentes. Los equipos, sean de una persona o de varias, que realizan trabajo orientado al
proceso, tienen que dirigirse a sí mismos. Dentro de los límites de sus obligaciones -fechas límite
convenido, metas de productividad, normas de calidad, etc.- deciden cómo y cuándo se ha de
hacer el trabajo. Si tienen que esperar la dirección de un supervisor de sus tareas, entonces no son
equipos de proceso. La reingeniería y la consecuente autoridad impactan en la clase de personas
que las empresas deben contratar.
La preparación para el oficio cambia: de entrenamiento a educación
En un ambiente de cambio y flexibilidad, es claramente imposible contratar personas que ya
sepan absolutamente todo lo que va a necesitar conocer, de modo que la educación continua
durante toda la vida del oficio pasa a ser la norma de una empresa rediseñada.
El enfoque de medias de desempeño y compensación se desplaza: de actividad a
resultados.
La remuneración de los trabajadores en las empresas tradicionales es relativamente
sencilla: se les paga a las personas por su tiempo. En una operación tradicional -trátese de una
línea de montaje con máquinas de manufactura o de una oficina donde se tramitan papeles-, el
trabajo de un empleado individual no tiene valor cuantificable. ¿Cuál es por ejemplo, el valor
monetario de una soldadura? ¿O de los datos verificados de empleo en una solicitud de seguro?
Ninguna de éstas tiene valor por sí misma. Sólo el automóvil terminado o la póliza de seguro
expedida tienen valor para la compañía.
8 Idem.
14
Cuando el trabajo se fragmenta en tareas simples, las compañías no tienen más remedio
que medir a los trabajadores por la eficiencia con que desempeñan trabajo estrechamente definido.
Lo malo es que esa eficiencia aumentada de tareas estrechamente definidas no se traduce
necesariamente en mejor desempeño del proceso. 9
Cuando los empleados realizan trabajo de proceso, las empresas pueden medir su
desempeño y pagarles con base en el valor que crean. En las compañías que se han rediseñado,
la contribución y el rendimiento son las bases principales de la remuneración.
Cambian los criterios de ascenso: de rendimiento a habilidad
Una bonificación es la recompensa adecuada por un trabajo bien hecho. El ascenso a un
nuevo empleo no lo es. Al rediseñar, la distinción entre ascenso y desempeño se traza firmemente.
El ascenso a un nuevo puesto dentro de una empresa es una función de habilidad, no de
desempeño. Es un cambio, no una recompensa.
Los valores cambian: de proteccionistas a productivos
La reingeniería conlleva un importante cambio en la cultura de la organización, exige que
los empleados asuman el compromiso de trabajar para sus clientes, no para sus jefes. Cambiar los
valores es parte tan importante de la reingeniería como cambiar los procesos.
Los gerentes cambian: de supervisores a entrenadores
Cuando una compañía se rediseña, procesos que eran complejos se vuelven simples, pero
puestos que eran simples se vuelven complejos. La reingeniería al transformar los procesos, libera
tiempos de los gerentes para que éstos ayuden a los empleados a realizar un trabajo más valioso y
más exigente.
Los gerentes en una compañía rediseñada necesitan fuertes destrezas interpersonales y
tienen que enorgullecerse de las realizaciones de otros. Un gerente así es un asesor que está
donde está para suministrar recursos, contestar preguntas y ver por el desarrollo profesional del
individuo a largo plazo. Éste es un papel distinto del que han desempeñado tradicionalmente la
mayoría de los gerentes. 10
9 Idem.
10 Idem.
15
Estructuras organizacionales cambian: de jerarquía a planas
Cuando todo un proceso se convierte en el trabajo de un equipo, la administración del
proceso se convierte en parte del oficio del equipo. Decisiones y cuestiones Inter departamentales
que antes requerían juntas de gerentes y gerentes de gerentes, ahora las toman y las resuelven los
equipos en el curso de su trabajo normal. Las compañías ya no necesitan tanto "pegamento"
gerencial como necesitaban antes para mantener unido el trabajo.
Después de la reingeniería ya no se necesita tanta gente para volver a reunir procesos
fragmentados. Con menos gerentes hay menos niveles administrativos y consecuentemente,
predominan las estructuras planas.
Los ejecutivos cambian: de anotadores de tantos a líderes
Las organizaciones más planas acercan a los ejecutivos a los clientes y a las personas que
realizan el trabajo que agrega valor. En un ambiente rediseñado, el cabal desempeño del trabajo
depende mucho más de las actitudes y los esfuerzos de los trabajadores facultados que de actos
de gerentes funcionales orientados a tareas. Por consiguiente, los ejecutivos tienen que ser líderes
capaces de influir y reforzar los valores y las creencias de los empleados con sus palabras y sus
hechos.
2.1.1.4 Roles de la reingeniería
Para llevar a cabo la reingeniería de procesos se han identificado los siguientes roles:
Líder.
Dueño o responsable del proceso.
Equipo de reingeniería.
Comité directivo.
"Zar" de reingeniería.
El líder
Es un alto ejecutivo que respalda, autoriza y motiva el esfuerzo total de reingeniería. Debe
tener la autoridad suficiente para que persuada a la gente de aceptar los cambios radicales que
implica la reingeniería. Sin este líder el proceso de reingeniería queda en buenos propósitos sin
llegar a culminarse como se espera.
16
Debe mantener el objetivo final del proceso, necesita la visión para reinventar la empresa
bajo nuevos esquemas competitivos, mantiene comunicados a empleados y directivos de los
propósitos a lograr, así como los avances logrados. 11
Designa a quienes serán los dueños de los procesos y asigna la responsabilidad de los
avances en el rendimiento.
Dueños del proceso
Gerente de área responsable de un proceso específico y del esfuerzo de ingeniería
correspondiente.
En las empresas tradicionales no se piensa en función de procesos, se departamentalizan
las funciones, con lo que se ponen fronteras organizacionales a los procesos.
Los procesos deben de identificarse lo más pronto posible, asignar un líder y este a los
dueños de los procesos.
Es importante que los dueños de procesos tengan aceptación de los compañeros con los
que van a trabajar, aceptar los procesos de cambio que trae la reingeniería, y su función principal
es vigilar y motivar la realización de la reingeniería. El oficio de los dueños no termina cuándo se
completa el proyecto de reingeniería, cuándo se tiene el compromiso de estar orientado a
procesos, cada proceso sigue ocupando de un dueño que se responsabilice de su ejecución.
Equipo de reingeniería.
Formado por un grupo de individuos dedicados a rediseñar un proceso específico, con
capacidad de diagnosticar el proceso actual, supervisar su reingeniería y su ejecución. Es el
encargado de realizar el trabajo pesado de producir ideas, planes y convertirlos en realidades.
Cabe mencionar que un equipo solo puede trabajar con un proceso a la vez, de tal manera que se
debe formar un equipo por cada proceso que se está trabajando. El equipo debe tener entre 5 y 10
integrantes, máximo, de los cuales una parte debe de conocer el proceso a fondo, pero por poco
tiempo para que no lo acepten como algo normal, y otra parte debe ser formada con personal ajeno
al proceso, pudiendo ser gente de fuera de la empresa, que lo pueda cuestionar y proponer
alternativas. 12
11
Idem. 12
Idem.
17
Comité directivo.
Cuerpo formulador de políticas, compuesto de altos administradores que desarrollan la
estrategia global de la organización y supervisan su progreso, normalmente incluye a los dueños
de proceso.
Puede estar o no presente en el proceso, da orden de prioridad, opinan sobre cuestiones
que van más allá de los procesos y proyectos en particular.
“Zar” de la reingeniería
Es el responsable de desarrollar técnicas e instrumentos de reingeniería y de lograr sinergia
entre los distintos proyectos en la empresa. Se encarga de la administración directa coordinando
todas las actividades de reingeniería que se encuentren en marcha; apoya y capacita a los dueños
de proceso y equipos de reingeniería.
2.1.1.5 Éxito en la reingeniería
Lamentablemente, a pesar de los muchos casos de éxito presentados, muchas compañías
que inician la reingeniería no logran nada. Terminan sus esfuerzos precisamente en donde
comenzaron, sin haber hecho ningún cambio significativo, sin haber alcanzado ninguna mejora
importante en rendimiento y fomentando más bien el escepticismo de los empleados con otro
programa ineficaz de mejoramiento del negocio.
A continuación se presenta la mayor parte de los errores comunes que llevan a las
empresas a fracasar en reingeniería:
Tratar de corregir un proceso en lugar de cambiarlo
Aunque los procesos existentes sean la causa de los problemas de una empresa, son
familiares; la organización se siente cómoda con ellos. La infraestructura en que se sustentan ya
esta instalada. Parece mucho más fácil y sensato tratar de mejorarlos que descartarlos del todo y
empezar otra vez. El mejoramiento incremental es el camino de menor resistencia en la mayoría de
las organizaciones. También es la manera más segura de fracasar en la reingeniería de las
empresas. 13
13
Idem.
18
No concentrarse en los procesos
Innovar es también el resultado de procesos bien diseñados, no una cosa en sí misma.
La falla esta en no adoptar una perspectiva orientada a los procesos en el negocio.
No olvidarse de todo lo que no sea ingeniería de procesos
Un esfuerzo de reingeniería, genera cambio de muchas clases. Hay que rediseñar las
definiciones de oficios, las estructuras organizacionales, los sistemas administrativos, es decir todo
lo que se relaciona con procesos. Hasta los gerentes que ansían una radical reingeniería de
procesos se asustan ante la magnitud de los cambios que para ello se requiere. Precisamente lo
que significa rediseñar es rehacer la compañía.
No hacer caso de los valores y las creencias de los empleados
La gente necesita alguna razón para dar buen rendimiento dentro de los procesos
rediseñados. La administración tiene que motivar a los empleados para que se pongan a la altura
de las circunstancias apoyando los nuevos valores y creencias que los procesos exigen.
Se tiene que poner atención a lo que está pasando en la mente del personal al igual que lo que
ocurre en sus escritorios. Los cambios que requieren modificaciones de actitudes no son
aceptados con facilidad se tienen que cultivar los valores requeridos recompensando la conducta
que los demuestra. Los altos administradores tienen que dar charlas a cerca de estos nuevos
valores y al mismo tiempo demostrar su dedicación a ellos mediante su comportamiento personal.
Conformarse con resultados de poca importancia14
Para lograr grandes resultados se requieren grandes aspiraciones. Es grande la tentación
de seguir el sendero más fácil y contentarse con la mejora marginal, ésta a la larga es más bien un
perjuicio. Lo más nocivo es que las medidas marginales refuerzan una cultura de incrementalismo
y hacen de la compañía una entidad poco valerosa.
Abandonar el esfuerzo antes de tiempo
No puede sorprendernos que algunas compañías abandonen la reingeniería o reduzcan
sus metas originales al primer síntoma de problemas. Pero también hay compañías que suspenden
su esfuerzo de reingeniería a la primera señal de éxito. El éxito inicial se convierte en una excusa
14
Idem.
19
para volver a la vida fácil del negocio de costumbre. En ambos casos la falta de perseverancia
priva a la compañía de los grandes beneficios que podría cosechar más adelante.
Limitar de ante mano la definición del problema y el alcance del esfuerzo de reingeniería
Un esfuerzo de reingeniería está condenado de ante mano al fracaso cuando, antes de
empezar, la administración define de una manera estrecha el problema por resolver o limita su
alcance. Definir el problema y fijar su alcance son pasos del esfuerzo mismo de reingeniería. Este
empieza con el planteamiento de los objetivos que se persiguen, no con la manera como dichos
objetivos se van a alcanzar.
La reingeniería tiene que romper fronteras, no reforzarlas. Tiene que sentirse destructiva
no cómoda. Insistir en que la reingeniería es fácil es insistir en que no es ingeniería.
Dejar que las culturas y las actitudes corporativas existentes impidan que empiece la
reingeniería.
Las características culturales dominantes en una compañía pueden inhibir o frustrar un
esfuerzo de ingeniería antes de que comience. Las compañías cuya orientación a corto plazo las
mantiene enfocadas exclusivamente en los resultados trimestrales encontrarán difícil extender su
visión a los más amplios horizontes de la reingeniería. Los ejecutivos tienen la obligación de
superar esas barreras.
Tratar de que la reingeniería se haga de abajo para arriba
Hay dos razones para que los empleados de primera línea y los mandos medios no estén
en capacidad de iniciar y ejecutar un esfuerzo de reingeniería que tenga éxito.
La primera es que los que están cerca de las líneas del frente carecen de la amplía
perspectiva que exige la reingeniería.
La segunda razón es que todo proceso comercial
necesariamente cruza fronteras organizacionales.
Si un cambio radical surge desde abajo, puede que le pongan resistencia y lo ahoguen.
Solo un liderazgo vigoroso y que venga de arriba inducirá a aceptar las transformaciones que la
reingeniería produce. 15
15
Idem.
20
Confiar el liderazgo a una persona que no entiende de reingeniería
El liderazgo de la alta administración es un indispensable requisito previo del éxito pero no
cualquier alto administrador sirve para el caso. El líder tiene que ser alguien que entienda la
reingeniería y este plenamente comprometida con ella debe además, orientarse a las operaciones
y apreciar la relación que hay entre el desempeño operativo y los resultados finales. La antigüedad
y la autoridad no son suficientes; igualmente críticas son la comprensión y una actitud mental
adecuada.
Escatimar los recursos destinados a la reingeniería
Una compañía no puede alcanzar las enormes ventajas de rendimiento que promete la
reingeniería sin invertir en su programa, y los componentes más importantes son el tiempo y la
atención de los mejores de la empresa. La reingeniería no se les puede confiar a los
semicompetentes. Asignar recursos insuficientes también les indica a los empleados que la
administración no les concede mucha importancia al esfuerzo de reingeniería, y los incita a no
hacer caso de ella o a oponerle resistencia, esperando que no haya de pasar mucho tiempo sin
que pierda impulso y desaparezca.
Enterrar la reingeniería en medio de la agenda corporativa
Si las compañías no ponen la reingeniería a la cabeza de su agenda, es preferible que
prescindan del todo de ella. Faltando el interés constante de la administración, la resistencia y la
inercia harán que el proyecto se pare. El personal solo se reconcilia con la inevitabilidad de la
reingeniería cuando reconoce que la administración está comprometida a fondo, que se concentra
en ella y le presta atención regular y constante. 16
Disipar la energía en un gran número de proyecto
La reingeniería exige un enfoque preciso y enorme disciplina, lo que equivale a decir que
las compañías tienen que concentrar sus esfuerzos en un número pequeño de procesos a la vez.
Puede que muchos procesos (servicios a los clientes, investigación y desarrollo y de ventas)
necesiten una reingeniería radical, pero para lograr el éxito no se deberán atender a todos
simultáneamente. El tiempo y la atención de la administración son limitados, y la reingeniería no
recibirá el apoyo que es necesario si los administradores están pensando en una cosa y otra.
16
Idem.
21
Tratar de rediseñar cuando el director ejecutivo le falta pocos años para jubilarse
Hacer cambios radicales en los procesos de una compañía traerá inevitablemente
consecuencias serias para la estructura de ésta y para sus sistemas administrativos, y una persona
que está a punto de retirarse sencillamente no querrá intervenir en tan complejas cuestiones o
adquirir compromisos que limiten la libertad de acción de su sucesor. En las organizaciones
jerárquicas, sobre todo, los aspirantes al alto cargo que va a quedar vacante quizá se sientan
vigilados y juzgados, en tal caso se interesarán más en el desempeño individual que en ser parte
de un gran esfuerzo colectivo de reingeniería.
No distinguir la reingeniería de otros programas de mejora
Un peligro de la reingeniería es que los empleados lo vean como solo otro programa del
mes. Este peligro, ciertamente, se convertirá en realidad si la reingeniería se le confía un grupo
impotente. Para evitar esa posibilidad la administración tiene que confiarles la reingeniería a
gerentes de línea, no a especialistas del personal ejecutivo. Además si se ha emprendido otro
programa de mejora, entonces hay que tener mucho cuidado de lo contrario habrá confusión, y se
desperdiciará una energía enorme para ver cual de los dos es superior.
Concentrarse exclusivamente en diseño
La reingeniería no solo es rediseñar. También hay que convertir los nuevos diseños en
realidad. La diferencia entre los ganadores y los perdedores no suele estar en la calidad de sus
respectivas ideas sino en lo que hacen con ellas. Para los perdedores, la reingeniería nunca pasa
de la fase ideológica a la ejecución.
Tratar de hacer la reingeniería sin volver a alguien desdichado
No se puede hacer una tortilla sin romper los huevos. Sería grato decir que la reingeniería
es un programa en que sólo se gana, pero sería una mentira. La reingeniería no les reporta ventaja
a todos. Algunos empleados perderán sus empleos y otros no quedarán contentos con sus nuevos
oficios. Tratar de complacer a todos es una empresa imposible, que sólo aplazará la ejecución de
la reingeniería para el futuro. 17
17
Idem.
22
Dar marcha atrás cuando se encuentra resistencia
Los empleados siempre opondrán resistencia, es una reacción inevitable cuando se
emprende un cambio de grandes proporciones. El primer paso para hacerle frente y esperarla y no
dejar que entorpezca el esfuerzo.
La verdadera razón de que la reingeniería no tenga éxito es la falta de previsión de la
administración que no planifica de antemano para hacer frente a la inevitable resistencia que la
reingeniería encontrara.
Prolongar demasiado el esfuerzo
La reingeniería produce tensiones en toda la compañía y prolongarla durante mucho
tiempo aumenta la incomodidad para todos. Un tiempo justo de 12 meses deben ser suficientes
para pasar de la proacción a la entrega de un proceso rediseñado. Si se tarda más, la gente se
impacienta, se confunde y se distrae. Llegará a la conclusión de que se trata de otro programa
fraudulento y el esfuerzo fracasará. Por todo lo enunciado anteriormente hay más motivos de
fracaso porque la gente tiene una gran habilidad para encontrar nuevas maneras de abandonar un
proyecto, pero en todos los motivos vistos, hemos encontrado un factor común y es el papel que
desempeña la alta administración. Si la reingeniería fracasa sea cualquiera la causa inmediata, los
altos administradores no entendieron bien la reingeniería ó padecen la falta de liderazgo.
2.1.1.6 Consideraciones adicionales
¿A qué área de la empresa se ataca primero cuando se emprende la reingeniería?
Hay dos áreas importantes: una es la relacionada con los clientes, sobre todo en la forma
de llenar los pedidos en el sector de servicio al cliente, y la otra es atacar el área que está
funcionando peor, que a veces es la financiera y a veces es la manufactura. De todas formas, más
de la mitad de las organizaciones empieza por la atención al cliente. 18
¿Se puede aplicar la reingeniería más de una vez?
Por supuesto. Hay toda una nueva generación de reingeniería que está comenzando
ahora. Incluso las compañías que cumplieron el proceso en los últimos cinco o diez años están
comenzando otra vez. Y la fuerza detrás de esta generación es Internet. Porque aunque trabajen
18
Idem.
23
muy bien, las empresas no están listas para que los clientes accedan a ellas por la Red. Las
compañías todavía no están en condiciones de proveer precios, disponibilidad y posibilidad de
ordenar por Internet. Todo lo que se hizo hasta ahora no es suficiente y hay que empezar de
nuevo.
¿Cómo se traduce la tecnología a la reingeniería?
Una compañía que no pueda cambiar su modelo de pensar acerca de la informática y otras
tecnologías no se puede rediseñar. El error fundamental que muchas compañías cometen al
pensar en tecnología es verla a través del lente de sus procesos existentes. Se preguntan: ¿Cómo
podemos usar estas nuevas capacidades tecnológicas para realzar o dinamizar o mejorar lo que ya
estamos haciendo? Por el contrario, debieran preguntarse: ¿Cómo podemos aprovechar la
tecnología para hacer cosas que no estamos haciendo? La reingeniería, a diferencia de la
automatización, es innovación. Es explorar las más nuevas capacidades de la tecnología para
alcanzar metas enteramente nuevas. Uno de los aspectos más difíciles de la reingeniería es
reconocer las nuevas capacidades no familiares de la tecnología en lugar de las familiares.
¿La reingeniería tiene que ver con la reducción de personal?
La gente confunde estas dos cosas, sobre todo porque la mayoría de las reducciones no
funciona, deja ir a la gente y luego toma más. La reingeniería no implica, ni prevé reducción de
personal, no fue enunciada con ese objetivo, lamentablemente los recursos humanos son la
variable más fácil de reducir y la más notoria al reconstruir y rediseñar los procesos.
2.1.2 Pasos para el Rediseño de un Proceso (Reingeniería)
Diez pasos para la Reingeniería por Ing. Raúl A. Pérez Verzini19
1. Elegir el proceso a rediseñar.
Para ello tener en cuenta los Factores Críticos de Éxito de la Organización o Área a la
que pertenece el proceso. Es decir, se trata de identificar aquel proceso cuya mejora (debido
a su desempeño actual) afectará de manera significativa la performance del área o de la
compañía.
19
Ing. Pérez Verzini Raúl A.. "Como entender reingeniería de procesos", primera edición en español, Editorial McGraw Hill. México,1996., pp.66,67
24
2. Identificar los Resultados Deseados (requeridos) para ese proceso.
El grupo que trabaje en la reingeniería del proceso debe responder la siguiente pregunta:
¿Qué debería suceder para que estemos de acuerdo en que el proceso está funcionando
de manera óptima?
Se trata de hacerse una imagen mental del resultado que se pretende alcanzar: ¿Es este el
resultado que queremos crear?
Siempre que pueda, asigne números reales a los objetivos. Es más fácil organizar las
acciones cuando sabe que el resultado deseado es $2 millones que cuando es ―mejorar las
ventas‖. ¿Ha cuantificado el objetivo lo más posible?
Consensuar con los directamente involucrados, tanto ―proveedores‖ como ―clientes‖
internos (y/o externos) del proceso, será clave para el éxito de la reingeniería.
3. Relevar Situación Actual
Recolectar la mayor cantidad de evidencia objetiva (datos) e indicadores que proporcionen
una imagen clara del desempeño actual del proceso.
4. Escribir un Diagrama de flujo del Proceso Actual
Paso a paso, sin omitir nada importante, hacer el flujograma de cómo funciona el proceso
actual. Para ello conviene tener presente algunas preguntas claves, entre ellas:
¿Qué es lo primero que ocurre?
¿Qué es lo siguiente que ocurre?
¿Qué es lo último que ocurre?
¿De dónde viene el (Servicio, Material)?
¿Cómo él (Servicio, Material, Información) llega al proceso?
¿Quién toma las decisiones (si se necesita)?
¿Qué pasa si la decisión es ―Sí‖?
¿Qué pasa si la decisión es ―No‖?
¿A dónde va el (Producto, Servicio, Información) de esta operación?
¿Qué revisiones / verificaciones se realizan en el ―producto‖ en cada parte del
25
¿proceso?
¿Qué pasa si la revisión / verificación no cumple con los requisitos?
5. Rediseñar el Proceso20
Una vez que se tiene la foto actual de cómo opera el proceso (situación actual), se trata de
contrastarla con la condición requerida a fin de identificar los GAPS (brechas) que pudieran
presentarse.
Es en esta etapa donde conviene preguntarse por qué las cosas se hacen de esa forma y
si existe alguna forma más efectiva de hacerlas. Aquí también conviene responderse algunas
preguntas disparadoras de la reflexión, entre las más importantes:
¿Para qué se hace realmente esta tarea?
¿Por qué la actividad es necesaria?
¿Qué otra cosa se podría o se debería hacer?
¿Dónde se lleva a cabo?
¿Por qué se lleva a cabo en ese lugar en particular?
¿Cuándo se hace?
¿Por qué se hace en ese momento en particular?
¿Cuándo se podría o debería hacer?
¿Quién lo hace?
¿Por qué lo hace esa persona?
¿Quién más podría o debería hacerlo?
¿Cómo se hace?
¿De qué otra forma se podría o debería hacer?
6. Identificar las Variables Críticas de Proceso y los Puntos de Control.
Rediseñado el proceso se trata de identificar aquellos ―pocos vitales‖ que son el alma del
proceso y se sabe que, si están bajo control, hay muchas probabilidades de que todo salga bien.
Nota: Se puede invertir el paso haciendo primero este y luego el rediseño. Dependerá del grado de
claridad que exista en el grupo con relación a la condición requerida y a las características propias
del proceso.
20
Idem.
26
7. Asignar Responsabilidades
Si aun no se hizo, este es el momento de clarificar explícitamente las responsabilidades en
torno a la ejecución (implementación) correcta del proceso. Se trata de poner por escrito Quién es
responsable de Qué y Cuándo.
8. Elegir Indicadores de Gestión
Seguramente aparecieron varios puntos de control asociados con variables críticas del
proceso. De entre ellos conviene elegir alguno que sirva como Indicador de Gestión para alimentar
el Tablero de Comando de la Gerencia y mediante el cual se chequeará regularmente la
performance del sector en estudio.
9. Escribir Procedimiento
En caso de ser necesario y a los fines no de burocratizar sino de clarificar la
implementación y facilitar la transmisión horizontal de conocimientos, convendrá poner por escrito
un procedimiento que refleje la forma en la que el proceso comenzará a desarrollarse. Una vez
escrito, y siguiendo lo sugerido por la norma ISO 9001, se procede a informar a los directamente
involucrados. 21
10. Implementar y Evaluar
Una vez completado los pasos anteriores es el momento de poner en marcha la nueva
forma de trabajo. Pero ese no es el último paso. El grupo debe acordar un plazo adecuado de
seguimiento para volver a evaluar la efectividad de las decisiones tomadas respecto al proceso. Un
plazo adecuado puede ser de 30 días para que se junte suficiente evidencia del desempeño del
proceso como para poder chequear su efectividad.
2.1.3 Reingeniería
Reingeniería es el re-diseño rápido y radical de los procesos estratégicos de valor
agregado y de los sistemas, las políticas y las estructuras organizacionales que los sustentan.
Estudia todos los procesos para ver si contribuyen o no a satisfacer un valor percibido por el
cliente. Los procesos que agregan valor se mejoran, los que no, se eliminan.
21
Idem.
27
El objetivo es mejorar drásticamente la productividad y preparar a la organización para
competir en entornos turbulentos. 22
Las características principales de la reingeniería de procesos son las siguientes:
No se mejorará aquello que ni siquiera deba hacerse.
Rápido link entre lo que la empresa hace y lo que el entorno espera que haga.
Fuerte cuestionamiento a todo aquello que no evidencie aporte de valor agregado al núcleo
del negocio.
Es el cliente (interno o externo) quien determina lo que se hace y cómo se hace.
Fuerte orientación a lo que debe hacerse y no a quién lo hace o dónde lo hace.
Se acortarán las distancias entre quien decide y quien ejecuta lo que contribuirá a la
efectividad buscada.
Se promoverá la necesidad de desaprender.
Se hará énfasis en el abandono de paradigmas inadecuados.
Con la reingeniería de procesos se logra un adecuado proceso que contribuirá a uno o más
de los siguientes resultados:
Aumento de la Rentabilidad.
Aumento de la Satisfacción de Clientes.
Disminución de Costos.
Aumento de Ingresos.
Mejora de la Calidad.
Mejora de la Productividad.
Aumento de Participación de Mercado.
Aumento de Precisión.
Aumento de Rapidez.23
2.1.4 Objetivo de la Reingeniería de Procesos
El objetivo de la reingeniería de procesos es que los métodos actuales se lleven a cabo
con fundamentos y de manera lógica, es por ello que los procesos son de suma importancia
tenerlos documentados ya que cuando se tienen dudas se dirigen al manual de procedimientos del
22
Hammer Michell. Reingeniería. Editorial Norma, México, 1994, pp.32-36 23
Idem.
28
área correspondiente, no se pueden tener procesos sin actualizar ya que siempre se realiza una
mejora a los mismos para el buen funcionamiento de nuestra área laboral. 24
2.1.5 Herramientas para la reingeniería de procesos
2.1.5.1 Mapeo de Proceso
Mapeo (Rediseño) de Procesos25
Principales Motivos para Mapear y Rediseñar Procesos
Reducir costos
Mejorar la calidad
Incrementar velocidad (throuhgput)
Cambiar la cultura organizacional
Otros
Beneficios generales del Rediseño de Procesos Incrementar la calidad y la creación de
valor, a través de:
Aplicación de mejores prácticas
Simplificación y estandarización de operaciones
Integración de procesos independientes
Dar visibilidad a la operación total
Compartir visión de negocios
Fomentar la co-operación y trabajo en equipo
Objetivos del Rediseño de Procesos
Mejorar la Calidad de los Procesos del SGC
Aumentar la asertividad de la demanda
Mejorar la sincronización de la producción
Optimizar los niveles de inventarios
Reducir los ciclos de pedido-facturación-entrega-cobranza
Mejorar el nivel de servicio al cliente
Evitar perder ventas por falta de producto
24
Sherkenbach William w., McGraw Hill, México,1999, pp. 21-26. 25
Mapeo de procesos. http://www.google.com.mx/search?hl=es&q=mapeo+de+procesos&meta. Día 11 enero del 2009.
29
Optimizar el costo de fletes foráneos y locales
Mejorar el nivel de la cobranza
Reducir gastos de administración
Evitar reprocesos de administración (devoluciones y rechazos)
Optimizar los niveles de la plantilla de personal
Herramientas para el Mapeo de Procesos
Las herramientas para el mapeo de procesos se pueden dividir en 4 categorías
Diagramas de flujo simples
IDEF (Integrated computer aided DEFinition)
Software para el mapeo26
2.1.5.2 Diagrama de flujo
Definición : El Diagrama de Flujo es una representación gráfica de la secuencia de pasos que se
realizan para obtener un cierto resultado. Este puede ser un producto, un servicio, o bien una
combinación de ambos.27
Características principales: A continuación se comentan una serie de características que ayudan
a comprender la naturaleza de la herramienta.
Capacidad de Comunicación: Permite la puesta en común de conocimientos individuales sobre
un proceso, y facilita la mejor comprensión global del mismo.
Claridad: Proporciona información sobre los procesos de forma clara, ordenada y concisa.
SÍMBOLO
Definición: Imagen o figura con la que se representa un concepto.
Diagrama de flujo de procesos.28
26
Idem.
27 Diagrama de Flujo.www.fundibeq.org/metodologias/herramientas/diagrama_de_flujo.pdf .Día 11 de enero del 2009.
28 Idem.
30
Figura 1. Diagrama de flujo de procesos.
31
Secuencia de actividades que forman el proceso29
Símbolos fáciles para representar operaciones.
Trazar el diagrama de flujo del proceso, indicando los pasos que éste sigue actualmente.
Trazar un diagrama de flujo del proceso, indicando los pasos que debería seguir si todo
trabaja correctamente.
Comparar los diagramas para encontrar diferencias, ya que ahí es donde radica el
problema.
Para realizar un diagrama de flujos deben seguirse los siguientes pasos:
Definir el propósito del diagrama que quiere representarse y para quién va dirigido
Concretar el nivel de detalle
Establecer los límites del proceso
Utilizar los símbolos apropiados
Para cada paso, preguntarse cuáles son los inputs y outputs
Documentar cada paso
Completar y relacionar todos los pasos del proceso
Revisar y verificar que el diagrama refleja de forma exacta el proceso
Preparación de la construcción del diagrama
Paso 1: Establecer quiénes deben participar en su construcción.
El grupo de trabajo, o la persona responsable del estudio identificará los organismos
implicados en el proceso, o parte del mismo, que debe ser analizado.
29
Idem.
Inicio
Pasos del Proceso
Decisión
Final
Inicio
Pasos del Proceso
Decisión
Final
Figura 2 Secuencia de actividades que forman el proceso
32
Se invitará a un representante de dichos organismos a participar en la construcción del
Diagrama de Flujo.
El número de participantes en la sesión de construcción del Diagrama no será superior a
10 para que el grupo sea operativo y eficaz.
Paso 2: Preparar la logística de la sesión de trabajo.
Con objeto de que el ritmo de la sesión de trabajo sea el adecuado se debe prever:30
Dar la información necesaria a los participantes en la reunión sobre el objeto de la misma y
sobre este procedimiento.
Preparar superficies y material de escritura que permitan tener a la vista continuamente el
trabajo desarrollado.
Símbolos para Diagramar Flujos
Figura 3. Símbolos para Diagramar Flujos.
30
Idem.
33
El uso de diagramas de flujo simples es un buen comienzo para analizar procesos y
comunicar el proceso al equipo (no detallado). A mano: Brownpaper, Post-its ; Software:
Micrografx’s, ABC Snapgraphics, SW VISIO.
2.1.5.3 Mejora Continua
Mejorar continuamente la efectividad del SGC a través de: 31
La Política de Calidad;
Los Objetivos Específicos de Calidad;
El Análisis de Datos;
Los Resultados de Auditorías;
Las Acciones Correctivas y Preventivas;
Las Revisiones por la Dirección;
La Calidad de la Gestión y
Los Resultados Totales de la Empresa.
Requisitos de la Norma ISO-9000 Sistema de Gestión de la Calidad32
31
Idem. 32
Harrington, H.James, Administración Total del mejoramiento continuo, McGraw Hill, México, 1997, pp.19-23
Figura 4 Cuadro del sistema de Gestión de Calidad.
34
El mapeo de procesos facilita mejorar la calidad de las gestiones de la empresa así
como sus resultados financieros.
Mapear es la base del Rediseño de Procesos: Reorganización de las actividades que hoy
realizamos para:
1. Fortalecer las que generan valor
2. Reducir las que no agregan valor pero son necesarias
3. Eliminar las que no generan valor (desperdicio)
Objetivos del Mapeo de Procesos: Mejorar los procesos del Sistema de Gestión de la Calidad
para lograr resultados espectaculares en las medidas de desempeño críticas, tales como:
1. Mejorar Ingresos
2. Reducir Costos y Gastos
3. Optimizar el uso del Capital de Trabajo
4. Administrar Integralmente los Riesgos
5. Incrementar la Calidad Percibida vs. Precio
6. Subir el Nivel de Servicio al Cliente
7. Aumentar el Nivel de Satisfacción de los Colaboradores
8. Destacar en la Calidad Total de la Empresa33
El Mapeo de Procesos es una herramienta que facilita el entendimiento completo, de todo
el personal de la empresa, por su aportación al SGC.
Diagrama General del Sistema de Gestión de la Calidad
Definición de procesos que incluye
Manual de Calidad con los procesos del SGC
o Objetivos específicos
o Definición de KPI´s y metas
o Mapa actual
o Mapa rediseñado
o Flujo de actividades
o Responsables y fechas
o Políticas y puntos de control
Identificación de necesidades y requerimientos de:
33
Idem.
35
o Capacitación
o Tecnología (hardware, accesorios, software y reportes operativos)
o Equipo y herramientas
o Inversiones adicionales
o Cambios organizacionales
Management Book34
Cliente
Comercial
Sist. Abon. Asign.
Mesa de pruebas
Participantes Salidas
Registra y
emite O.T.
Pedido cambio
de domicilio
Cumplimiento
O. T.
Cumplimiento
O. T.
Informe de
cumplimiento
Pedido
satisfecho
C.F ROtros destinos de salida
Proveedores externos
al proceso
Flujo del proceso
LíneasCumplimiento
O. T.
Conmutación
5
Figura 5 Diagrama de Flujo de un proceso.
2.1.5.4 Diagrama (CAUSA-EFECTO) Ishikawa
Figura 6 Diagrama de causa - efecto
34
Idem
36
Diagrama de causa efecto o de espina de pez ideado por el ingeniero Ishikawa35
El Diagrama de Ishikawa, también llamado diagrama de causa-efecto, es una de las
diversas herramientas surgidas a lo largo del siglo XX en ámbitos de la industria y posteriormente
en el de los servicios, para facilitar el análisis de problemas y sus soluciones en esferas como es la
calidad de los procesos, los productos y servicios. Fue concebido por el ingeniero japonés
Dr.Kaoru Ishikawa en el año 1953. Se trata de un diagrama que por su estructura ha venido a
llamarse también: diagrama de espina de pescado, que consiste en una representación gráfica
sencilla en la que puede verse de manera relacional una especie de espina central, que es una
línea en el plano horizontal, representando el problema a analizar, que se escribe a su derecha.
El problema analizado puede provenir de diversos ámbitos como la salud, calidad de
productos y servicios, fenómenos sociales, organización, etc. A este eje horizontal van llegando
líneas oblicuas -como las espinas de un pez- que representan las causas valoradas como tales por
las personas participantes en el análisis del problema. A su vez, cada una de estas líneas que
representa una posible causa, recibe otras líneas perpendiculares que representan las causas
secundarias. Cada grupo formado por una posible causa primaria y las causas secundarias que se
le relacionan forman un grupo de causas con naturaleza común. Este tipo de herramienta permite
un análisis participativo mediante grupos de mejora o grupos de análisis, que mediante técnicas
como por ejemplo la lluvia de ideas, sesiones de creatividad, y otras, facilita un resultado óptimo en
el entendimiento de las causas que originan un problema, con lo que puede ser posible la solución
del mismo.
La primera parte de este Diagrama muestra todas aquellos posibles factores que puedan
estar originando alguno de los problemas que tenemos, la segunda fase luego de la tormenta de
ideas es la ponderación o valoración de estos factores a fin de centralizarse específicamente sobre
los problemas principales, esta ponderación puede realizarse ya sea por la experiencia de quienes
participan o por investigaciones in situ que sustenten el valor asignado.
¿Cómo hacerlo?
Para empezar, decide cual característica de calidad, salida o efecto quieres examinar y
continúa con los siguientes pasos:36
35 Diagrama causa-efecto. www.monografias.com/trabajos42/diagrama-causa-efecto/diagrama-causa-efecto.shtml - 34k
.Día 13 de enero del 2009.
36 Idem.
37
Dibuja un diagrama en blanco.
Escribe de forma breve el problema o efecto.
Escribe las categorías que consideres apropiadas a tu problema: maquina, mano de obra,
materiales, métodos, son los más comunes y aplican en muchos procesos.
Realiza una lluvia de ideas (brainstorming) de posibles causas y relaciónalas a cada
categoría.
Figura 7 Ejemplo de un diagrama de Ishikawa.
Pregúntale ¿por que? a cada causa, no más de dos o tres veces.
Empieza por enfocar tus variaciones en las causas seleccionadas como fácil de
implementar y de alto impacto.37
Figura 8 Representación de cómo hacer un diagrama Ishikawa.
37
Idem.
38
2.1.5.5 Diagrama de PARETO
¿Qué es?
Una forma especial de gráfico de barras verticales que separa los problemas muy
importantes de los menos importantes, estableciendo un orden de prioridades. 38
Fue creado sobre la base del principio de Pareto, según el cual, el 80% de los problemas
son provenientes de apenas el 20% de las causas.
Se usa para:
Identificar y dar prioridad a los problemas más significativos de un proceso.
Evaluar el comportamiento de un problema, comparando los datos entre el "antes" y el
"después".
¿Cómo construirlo?
Trece dos ejes verticales de la misma longitud, en un eje horizontal.
En el eje vertical izquierdo, haga una escala de 0 hasta el número correspondiente al total
de la Lista de verificación.
En el eje vertical derecho haga una escala de 0 a 100%. El 100% corresponderá al total de
la Lista de Verificación.
Divida el eje horizontal en intervalos iguales, de acuerdo con la cantidad de categorías de
la Lista de Verificación.
38 Pareto, por el Dr. Juran www.elprisma.com/apuntes/ingenieria_industrial/diagramadepareto/ .Día 13 de enero del 2009.
39
Diagrama de Pareto
22% 21% 18%12% 11%
6% 5% 5%22%
43%
61%
73%
84%90%
95%100%
0%
20%
40%
60%
80%
100%
Participaci
ón de p
erso
nal
Rela
ciones
con p
rove
edores
Org
anizaci
ón orie
ntada
al c
liente
Toma d
e deci
siones
Enfoque
basa
do e
n pro
ceso
s
Lidera
zgo
Siste
ma p
ara la
gest
ión
Mejo
ra c
ontin
ua
Fre
cu
en
cia
s
Figura 9 Representación del Diagrama de Pareto
2.1.5.6 Matriz FODA
Es una herramienta que tiene por objeto identificar los factores internos y externos de la
organización que condicionan su situación actual y permiten definir planes estratégicos futuros. La
aplicación de esta herramienta exige la participación de todo el personal de la organización para la
localización de los puntos fuertes y débiles de la misma, de entre los que se seleccionarán,
posteriormente, los más relevantes. 39
2.1.5.7 Matriz de Evaluación de Factores Externos (MEFE)
Vamos a pasar por alto la Matriz FODA, bajo el entendido que ya es una herramienta de
todos conocida. Nos ocuparemos de la Matriz de Evaluación de los Factores Externos identificada
también como la Matriz EFE.40
El objetivo de esta matriz es ―permitir a los estrategas resumir y evaluar información
39
Fred, R. David Conceptos de administración estratégica, Quinta Edición, Prentice Hall Hispano Americano, México,
1997, pp.145.
40 Matriz de Evaluación de los Factores Externos (MEFE) www.eumed.net/ce/2006/hpt-FODA.htm .Día 11 de enero del
2009.
40
económica, social, cultural, demográfica, ambiental, política, gubernamental, jurídica, tecnológica y
competitiva‖
La elaboración de una Matriz EFE consta de cinco pasos:
Haga una lista de los factores críticos o determinantes para el éxito identificados en el
proceso de la auditoria externa. Abarque un total entre diez y veinte factores, incluyendo
tanto oportunidades como amenazas que afectan a la empresa y su industria. En esta lista
primero anote las oportunidades y después las amenazas. Sea lo más específico posible.
Asigne un peso relativo a cada factor, de 0.0 (no es importante), a 1.0 (muy importante). El
peso indica la importancia relativa que tiene ese factor para alcanzar el éxito. Las
oportunidades suelen tener pesos más altos que las amenazas, pero éstas, a su vez,
pueden tener pesos altos si son especialmente graves o amenazadoras. La suma de
todos los pesos asignados a los factores debe sumar 1.0.
Asigne una calificación de 1 a 4 a cada uno de los factores determinantes para el éxito con
el objeto de indicar si las estrategias presentes de la empresa están respondiendo con
eficacia al factor, donde 4 = una respuesta superior, 3 = una respuesta superior a la media,
2 = una respuesta media y 1 = una respuesta mala. Las calificaciones se basan en la
eficacia de las estrategias de la empresa.
Multiplique el peso de cada factor por su calificación para obtener una calificación
ponderada.
Sume las calificaciones ponderadas de cada una de las variables para determinar el total
ponderado de la organización.
No debemos pasar por alto que es más importante entender a fondo los factores que se
usan en la matriz EFE, que asignarles los pesos y las calificaciones.
2.1.5.8 Matriz de Evaluación de Factores Internos (MEFI)
También denominada Matriz EFI, este instrumento resume y evalúa las fuerzas y
debilidades más importantes dentro de las áreas funcionales de un negocio y además ofrece una
base para identificar y evaluar las relaciones entre dichas áreas.41
La matriz EFI es similar a la matriz EFE que se desarrolló en el capitulo anterior. Se
desarrolla siguiendo cinco pasos:
41
Idem.
41
Haga una lista de los factores críticos o determinantes para el éxito identificados en el
proceso de la auditoria interna. Abarque un total entre diez y veinte factores,
incluyendo tanto fortalezas como debilidades que afectan a la empresa y su industria.
En esta lista primero anote las fortalezas y después las debilidades. Sea lo más
específico posible
Asigne un peso relativo a cada factor, de 0.0 (no es importante), a 1.0 (muy
importante). El peso indica la importancia relativa que tiene ese factor para alcanzar el
éxito. Las fortalezas suelen tener pesos más altos que las debilidades. La suma de
todos los pesos asignados a los factores debe sumar 1.0.
Asigne una calificación de 1 a 4 a cada uno de los factores determinantes para el
éxito con el objeto de indicar si las estrategias presentes de la empresa están
respondiendo con eficacia al factor, donde 4 = una respuesta superior, 3 = una
respuesta superior a la media, 2 = una respuesta media y 1 = una respuesta mala. Las
calificaciones se basan en la eficacia de las estrategias de la empresa.
Multiplique el peso de cada factor por su calificación para obtener una calificación
ponderada.
Sume las calificaciones ponderadas de cada una de las variables para determinar el
total ponderado de la organización.
Independientemente de la cantidad de fortalezas y debilidades clave incluidas en la Matriz
EFI, el total ponderado más alto que puede obtener la organización es 4.0 y el total ponderado más
bajo posible es 1.0. El valor del promedio ponderado es 2.5.
No debemos pasar por alto que es más importante entender a fondo los factores que se
usan en la matriz EFI, que asignarles los pesos y las calificaciones.
En síntesis, el análisis de la matriz pretende FODA ser un marco de referencia operativo,
que permita establecer las líneas de actuación futuras.42
2.1.5.9 Análisis FODA
Proviene del acrónimo en inglés SWOT, en español las siglas son FODA (Fortalezas,
Oportunidades, Debilidades y Amenazas). 43
42
Idem. 43 Porter, M. Técnicas para el análisis de los sectores industriales y de la competencia, capítulo 3, Marco de referencia para
el análisis de la competencia, Editorial CECSA, México, 2005 pp. 71, 84 y 85.
42
El análisis FODA consiste en realizar una evaluación de los factores fuertes y débiles que
en su conjunto diagnostican la situación interna de una organización, así como su evaluación
externa; es decir, las oportunidades y amenazas. También es una herramienta que puede
considerarse sencilla y permite obtener una perspectiva general de la situación estratégica de una
organización determinada.
Thompson (1998) establece que el análisis FODA estima el hecho que una estrategia
tiene que lograr un equilibrio o ajuste entre la capacidad interna de la organización y su situación
de carácter externo; es decir, las oportunidades y amenazas.
¿Cómo identificar las fortalezas y debilidades?
Una fortaleza de la organización es alguna función que ésta realiza de manera correcta,
como son ciertas habilidades y capacidades del personal con atributos psicológicos y su evidencia
de competencias. Otro aspecto identificado como una fortaleza son los recursos considerados
valiosos y la misma capacidad competitiva de la organización, como un logro que brinda la
organización y una situación favorable en el medio social. Una debilidad de una organización se
define como un factor considerado vulnerable en cuanto a su organización o simplemente una
actividad que la empresa realiza en forma deficiente, colocándola en una situación considerada
débil.
Para Porter, las fortalezas y oportunidades son, en su conjunto, las capacidades, es decir,
el estudio tanto de los aspectos fuertes como débiles de las organizaciones o empresas
competidoras (productos, distribución, comercialización y ventas, operaciones, investigación e
ingeniería, costos generales, estructura financiera, organización, habilidad directiva, etc.)
Estos talones de Aquiles de situaciones pueden generar en la organización una posición
competitiva vulnerable.
Es posible destacar que acerca del procedimiento para el análisis FODA, que una vez
identificados los aspectos fuertes y débiles de una organización se debe proceder a la evaluación
de ambos, es decir, de las fortalezas y las debilidades. 44
Es importante destacar que algunos factores tienen mayor preponderancia que otros,
como lo plantea Strickland, al denominar el análisis FODA como la construcción de un balance
estratégico, mientras que los aspectos considerados fuertes de una organización son los activos
44
Idem.
43
competitivos, y los débiles son los pasivos también competitivos. Pero se comete un error si se
trata de equilibrar la balanza. Lo importante radica en que los activos competitivos o aspectos
fuertes superen a los pasivos competitivos o situaciones débiles; es decir, lo trascendente es darle
mayor ponderación a los activos.
Identificar oportunidades y amenazas.45
Las oportunidades constituyen aquellas fuerzas ambientales de carácter externo no
controlables por la organización, pero que representan elementos potenciales de crecimiento o
mejoría. La oportunidad en el medio es un factor de gran importancia que permite de alguna
manera moldear las estrategias de las organizaciones. Las amenazas son lo contrario de lo
anterior, y representan la suma de las fuerzas ambientales no controlables por la organización,
pero representan fuerzas o aspectos negativos y problemas potenciales. Permite resolver dos
preguntas: ¿qué tenemos? ¿En dónde estamos?
Figura 10 Matriz de FODA
Fuente: Thompson (1998), Dirección y administración estratégicas, conceptos, casos y lecturas, "Análisis SWOT. Qué es
necesario buscar para medir los puntos fuertes, débiles, las oportunidades y las amenazas de una compañía", Editorial
McGraw Hill, primera edición en español, México, p. 98
La Matriz FODA propuesta por Thompson anteriormente, constituye la base o el punto de
partida para la formulación o elaboración de estrategias, de la Matriz FODA se pueden realizar
nuevas matrices, de esta forma de la Matriz FODA (Fortalezas, Oportunidades, Debilidades y
Amenazas), se pueden desarrollar el marco analítico y las estrategias a través de
las etapas siguientes (figura-)46
45
Thompson (1ra edición en español) "Análisis SWOT. Qué es necesario buscar para medir los puntos fuertes, débiles, las
oportunidades y las amenazas de una compañía", Editorial McGraw Hill, México, 1998 .pp. 98.
46
Idem.
44
Figura 11 Representación de la Matriz FODA
MARCO ANALÍTICO PARA FORMULAR ESTRATEGIAS47
Etapa 1: Etapa de los insumos
1. Matriz de Evaluación de los Factores
Internos (MEFI).
2. Matriz del Perfil Competitivo (MPC).
3. Matriz de Evaluación de los Factores
Externos (MEFE)
Etapa 2: La Etapa de la adecuación
1. Matriz de las Amenazas, Oportunidades,
Debilidades, Fortalezas (MAFE).
2. Matriz de la Posición Estratégica y la
Evaluación de la Acción (MEPE).
3. Matriz del Boston Consulting Group
(MBCG)
47 Fred, R. David. Quinta Edición, Conceptos de administración estratégica, "El marco analítico para formular estrategias",
Prentice Hall Hispano Americano, México. 1997, pp. 185.
45
4. Matriz Interna -- Externa (MIE)
5. Matriz de la Gran Estrategia (MGE)
Etapa de la decisión
1. Matriz Cuantitativa de la Planeación
Estratégica (MCPE)
Figura 12 Marco Analítico para formular estrategias.
Fuente: Fred, R. David Conceptos de administración estratégica, "El marco analítico para formular estrategias", Capítulo 6,
Análisis y elección de la estrategia, Quinta Edición, Prentice Hall Hispano Americano, México, 1997, pp. 185.
2.1.5.10 Tormenta de Ideas
La tormenta de ideas (brainstorming) es una herramienta de trabajo en equipo para
conseguir, de forma rápida, que el grupo de personas reunidas genere, aclare y evalúe una lista
considerable de ideas, problemas, temas, procesos, etc.
Esta actividad permitirá implicar a todos los miembros, que aportarán soluciones y se
identificarán en el proyecto de mejora continua de la calidad del servicio. Es importante combinar
esta herramienta con la de trabajo en equipo, identificando los roles que debe desempeñar cada
uno de sus integrantes. 48
Este proceso consta de tres fases:
Fase de generación: Se define con claridad la finalidad que se persigue. Cada persona interviene
por turno, en orden secuencial, presentando una idea por turno. No se critican ni se discuten las
ideas, aunque pueden construirse ideas sobre otras ya planteadas. Todas las ideas se anotan de
forma visible para todos, y esta fase acabará cuando se hayan agotado todas las ideas.
Fase de aclaración: El equipo repasa la lista, aclarando y debatiendo todas las ideas.
Fase de evaluación: El equipo repasa la lista para eliminar duplicidades o combinar elementos,
según sea necesario.
2.1.6 Metodología
Simplificando la metodología un proyecto de reingeniería digno de este nombre debe
comportar cinco fases:
48
Idem.
46
descubrir las necesidades de los clientes,
identificar los problemas de los procesos,
concebir nuevos procesos y una nueva organización,
recorrer a los sistemas informáticos más apropiados,
crear sistemas de evaluación, promociones y sistemas de remuneración diferentes.
La metodología consiste en establecer los "process maps", esquemas exhaustivos de
análisis de los flujos de trabajo existentes. Estos esquemas permiten ver dentro del proceso lo que
es inútil y lo que no aporta nada al cliente. Partiendo del principio de que un proceso es un
producto/servicio y que un producto/servicio es un proceso, buscamos todas las vías de mejora
posible de los procesos que permitirán servir mejor al consumidor final, respetando todas las
obligaciones internas y los objetivos de la dirección.
El equipo de reingeniería típico está dirigido por un alto directivo -senior- para planificar el
programa de reingeniería y se compone por especialistas de procesos dedicados al reingeniería,
de empleados especializados en tecnología, en finanzas y en recursos humanos y si es posible de
clientes internos o externos afectados por el proceso.
El equipo de reingeniería visita todas las unidades implicadas en el proceso e identifica los
problemas de los procesos con los equipos naturales de trabajo o los transversales ya existentes si
se da el caso. Los miembros del equipo deben comprender las exigencias administrativas de este
proceso así como las opciones tecnológicas y organizacionales necesarias para aplicarlo. Deberán
innovar y preconcebir lo que podría ser el proceso óptimo. Esta es la razón por la que la
composición del equipo de reingeniería es esencial y debe comportar especialistas al corriente de
las tecnologías más avanzadas.
Hace falta crear un entorno que favorezca la creatividad, los replanteamientos y el
"business as usual", es decir, la manera de operar tradicional y los procedimientos habituales que
no han evolucionado al mismo ritmo que la tecnología y que raramente tienen en cuenta sus
posibilidades.
Puesta en práctica
La aproximación habitual de los equipos de reingeniería es el PDCA en cuatro fases: Plan -
Do - Check – Act (Planificar - Hacer - Controlar – Actuar).
47
2.1.6.1 Mejora Continua del Proceso Plan-Do- Check – Act
La fase de planificación, PLAN, define el proceso a reconcebir, establece la finalidad
buscada, el lapso de tiempo concedido (generalmente de 6 meses a 1 año para las cuatro fases) y
determina los objetivos medibles: satisfacción de los clientes, productividad, pertinencia, reducción
de retrasos, control de costes.49
El equipo de reingeniería analiza los PGI: process - goals - impacts (procesos - objetivos -
impactos). Trata de definir un esquema ideal y un nuevo proceso y emite recomendaciones sobre
los cambios a realizar, los responsables de estos cambios y las medidas a llevar a cabo.50
La eficacia del reingeniería, de la innovación de procesos, está ligada a la noción de
"función universal". Muchas funciones son idénticas sea cual sea el sector de actividad. Un pedido
es idéntico, se trate de la compra de un bien, de un servicio. Una factura, un recibo, también. De
aquí la posibilidad a través de una búsqueda de benchmarking de identificar las prácticas más
eficaces existentes en la industria recorriendo a las tecnologías más evolucionadas para poner en
práctica estas funciones.
La fase de planificación se descompone en cuatro etapas:
49
Idem. 50
Idem.
Figura 13 Mejora Continúa
48
comprender los procesos en curso a través del análisis detallado de los flujos
organizacionales de trabajo,
identificar la esencia de las funciones buscando las funciones universales a que
conciernen,
aplicar los estándares identificados a través del benchmarking para esta función,
modificar el proceso y automatizar.
La segunda fase del reingeniería, - DO- , hacer, es la de la puesta en práctica de las
recomendaciones del equipo de reingeniería: introducción de cambios, creación de un nuevo
proceso, establecimiento de los instrumentos de medida del progreso.
La tercera fase del reingeniería, "CHECK", es la del control de los resultados. ¿Las
mejoras esperadas han sido obtenidas y todos los objetivos de mejora de servicio y de reducción
de costes conseguidos? ¿Han aparecido nuevos riesgos de errores o estrangulamientos/cuellos de
botella? ¿Es necesario efectuar modificaciones? ¿Si se debe hacer, van seguidas de efectos
positivos? Nueva evaluación de resultados.
La cuarta fase del reingeniería, "ACT", actuar, consiste en estandarizar, generalizar las
recomendaciones del plan al conjunto de la empresa y establecer las herramientas de mejora
continua a través de revisiones permanentes de resultados.
La diferencia entre un Management tradicional y el Management de procesos reside en la
asignación del tiempo: 5% para la planificación y 75% para la puesta en práctica en la
aproximación tradicional, contra 75% dedicado a la planificación y 5% a la puesta en práctica en
esta nueva aproximación, 10% dedicado respectivamente en las dos aproximaciones a las fases de
control y de acción final.51
2.2 Sustentabilidad
2.2.1 ¿Qué es la sustentabilidad?
52
La sustentabilidad es un concepto que desde hace varias décadas ha llamado la atención
a estudiosos de diferentes disciplinas. Biólogos, sociólogos, antropólogos, geógrafos, urbanistas,
arquitectos, entre otros, han intentado definir cada vez con mayor precisión su significado.
51
Idem. 52
CECADESU, Prever el Futuro: El Desarrollo Sustentable,
http://cecadesu.semarnat.gob.mx/biblioteca_digital/desarrollo_sustentable/desarrollo_sustentable02.shtml consulta: 7 Abril 2009.
49
Su historia se inicia en la década de los años setenta cuando la defensa del medio
ambiente se convirtió en uno de los temas más importantes de las campañas y agendas políticas
en distintos países. Fue precisamente en junio de 1972, durante la Conferencia de las Naciones
Unidas sobre el Medio Ambiente Humano celebrada en Estocolmo, Suecia, cuando creció la
convicción de que se estaba atravesando por una crisis ambiental a nivel mundial. A partir de esta
conferencia, en donde se reunieron 103 estados miembros de las Naciones Unidas y más de 400
organizaciones gubernamentales, se reconoció que el medio ambiente es un elemento
fundamental para el desarrollo humano. Con esta perspectiva se iniciaron programas y proyectos
que trabajarían para construir nuevas vías y alternativas con el objetivo de enfrentar los problemas
ambientales y, al mismo tiempo, mejorar el aprovechamiento de los recursos naturales para las
generaciones presentes y futuras. Años más tarde, en 1987, la Comisión de Medio Ambiente de la
ONU emitió un documento titulado Nuestro futuro común, también conocido con el nombre de
Informe Brundtland, por el apellido de la doctora que encabezó la investigación. En este estudio se
advertía que la humanidad debía cambiar sus modalidades de vida y de interacción comercial, si
no deseaba el advenimiento de una era con inaceptables niveles de sufrimiento humano y
degradación ecológica. En este texto, el desarrollo sustentable se definió como "aquel que
satisface las necesidades actuales sin poner en peligro la capacidad de las generaciones futuras
para satisfacer sus propias necesidades".
2.2.2 La sustentabilidad: más allá del medio ambiente
Desde esta definición, expuesta en 1987, la percepción de la sustentabilidad se ha
transformado. De una visión centrada en el deterioro del medio ambiente se ha transitado hacia
una definición más integral que incluye muchos otros aspectos vinculados con la calidad de vida
del ser humano.
Así las nociones de sustentabilidad desarrolladas en los años posteriores al Informe
Brundtland incluyeron menciones a un cúmulo de procesos socioeconómicos, políticos, técnicos,
productivos, institucionales y culturales que están relacionados con la satisfacción de las
necesidades humanas. Acerquémonos, por ejemplo, a la definición de un grupo de ambientalistas
latinoamericanos.
El concepto de sustentabilidad se funda en el reconocimiento de los límites y de las
potencialidades de la naturaleza, así como en la complejidad ambiental, inspirando una nueva
comprensión del mundo para enfrentar los desafíos de la humanidad en el tercer milenio. El
concepto de sustentabilidad promueve una nueva alianza naturaleza-cultura fundando una nueva
economía, reorientando los potenciales de la ciencia y de la tecnología, y construyendo una nueva
50
cultura política fundada en una ética de la sustentabilidad —en valores, en creencias, en
sentimientos y en saberes — que renueva los sentidos existenciales, los mundos de vida y las
formas de habitar el planeta Tierra.
Como puede verse, con el paso del tiempo la sustentabilidad ha llegado a constituir un
concepto que evoca una multiplicidad de procesos que la componen. Sin embargo, hay que decir
que se trata de algo más que un término. La sustentabilidad es una nueva forma de pensar para la
cual los seres humanos, la cultura y la naturaleza son inseparables.
2.2.3 ¿Qué significa el desarrollo sustentable y qué significa la sustentabilidad?
53―… de entrada una discusión inútil a la cual le doy un minuto: si sustentable o sostenible.
Sostenible viene del inglés es un anglicismo; sustentable existe en castellano. Prefiero usar el
término sustentable que existe en castellano y justamente ¿qué dice el diccionario sobre
sustentable? Es aquello que se puede mantener a través del tiempo. Yo creo que lo esencial de la
sustentabilidad, del concepto de desarrollo sustentable, es incluirle una dimensión de tiempo.
Cuánto tiempo más nos va a durar el agua usándola como la estamos usando, cuánto tiempo mas
nos van a durar los bosques usándolos como los estamos usando.
Entonces, la esencia de la sustentabilidad es esa dimensión de largo plazo, una dimensión
que rebasa evidentemente los límites del capital. Si yo voy a la Sierra de Tapalpa, donde tenemos
trabajo fuerte desde hace tiempo, y compro una hectárea de bosque y la tumbo, hacerlo me
llevaría 4 meses y sería un exitoso empresario, pero ¿cuánto le lleva a la naturaleza volver a hacer
una hectárea de bosque? ... 30 años por lo menos.
Entonces, los ciclos de recuperación del capital están peleados con los ciclos de
recuperación de la naturaleza. Sustentar el bosque es aprovecharlo, de tal modo que siempre
podamos seguir aprovechándolo. …‖
53
Dr. Morales Hernández Jaime, QUE ES SUSTENTABILIDAD, Participación en el programa de radio institucional
―Frecuencia Verde‖ 22 de Agosto de 2002.
51
2.3 CONCLUSIÓN
En este capítulo mencionamos las referencias que tomaremos en cuenta para el desarrollo
de nuestro proyecto tomando sólo lo referente a la reingeniería de procesos, es por ello que nos
enfocaremos en los pasos para la reingeniería y mapeo de procesos y posterior a esto seguiremos
con la automatización de nuestros procesos ya que sabemos que aunque obtendremos ventajas
con nuestra reingeniería de procesos y que el proceso será más rápido, esto no es suficiente para
las necesidades actuales de la empresa Relaciones Jurídicas por lo tanto para cubrir éstas
realizaremos la automatización con la ayuda de la metodología mencionada en el siguiente
capítulo.
52
Capítulo III Marco teórico para la Automatización de procesos y
Referencial
3.1 WEB 2.0
3.1.1 Definición
―La Web dos (punto) cero podría definirse como la promesa de una visión realizada: la Red
–la Internet, con mayúscula o minúscula, que se confunde popularmente con la propia Web
convertida en un espacio social, con cabida para todos los agentes sociales, capaz de dar soporte
a y formar parte de una verdadera sociedad de la información, la comunicación y/o el conocimiento.
Con minúsculas porque nace de la propia acción social en interacción con un contexto tecnológico
nuevo‖54
.
3.1.2 Orígenes del término
55El término fue acuñado por Dale Dougherty de O'Reilly Media en una lluvia de ideas con
Craig Cline de MediaLive para desarrollar ideas para una conferencia. Dougherty sugirió que la
Web estaba en un renacimiento, con reglas que cambiaban y modelos de negocio que
evolucionaban. Dougherty puso ejemplos — "DoubleClick era la Web 1.0; Google AdSense es la
Web 2.0. Ofoto es Web 1.0; Flickr es Web 2.0." — en vez de definiciones, y reclutó a John Battelle
para dar una perspectiva empresarial, y O'Reilly Media, Battelle, y MediaLive lanzó su primera
conferencia sobre la Web 2.0 en Octubre del 2004. La segunda conferencia se celebró en octubre
de 2005.
En su conferencia, O'Reilly y Battelle resumieron los principios clave que creen que
caracterizan a las aplicaciones web 2.0: la Web como plataforma; datos como el "Intel Inside";
efectos de red conducidos por una "arquitectura de participación"; innovación y desarrolladores
independientes; pequeños modelos de negocio capaces de redifundir servicios y contenidos; el
perpetuo beta; software por encima de un solo aparato.
En general, cuando mencionamos el término Web 2.0 nos referimos a una serie de
aplicaciones y páginas de Internet que utilizan la inteligencia colectiva para proporcionar servicios
interactivos en red dando al usuario el control de sus datos.
54
Fumero Antonio y Roca Genis Con la Colaboración de Sáez Vacas Fernando. Web 2.0, Fundación Orange. España
2007, pp. 15 – 30. 55
Web 2.0 http://es.wikipedia.org/wiki/Web_2.0, consulta: 5 Febrero Marzo 2009.
53
3.1.3 Características principales de la WEB 2.0
Orientada a la Interacción y redes sociales.
Sitios Web 2.0 actúan más como puntos de encuentro, o webs dependientes de usuarios.
Uso de técnicas como:
o CSS.
o AJAX.
o Soporte para postear en un blog.
o JSON.
Uso de patrones de diseño.
3.2 La sociedad del conocimiento en la automatización de procesos
3.2.1 Sociedad del conocimiento
56La noción de sociedad del conocimiento fue utilizada por primera vez en 1969 por un
autor austriaco de literatura relacionada con el "management" o gestión, llamado Peter Drucker, y
en el decenio de 1990 fue profundizada en una serie de estudios detallados publicados por
investigadores como Robin Mansel o Nico Stehr. Las sociedades de la información surgen con el
uso e innovaciones intensivas de las tecnologías de la información y las comunicaciones, donde el
incremento en la transferencia de información, modificó en muchos sentidos la forma en que se
desarrollan muchas actividades en la sociedad moderna. Sin embargo, la información no es lo
mismo que el conocimiento, ya que la información es efectivamente un instrumento del
conocimiento, pero no es el conocimiento en sí, el conocimiento obedece a aquellos elementos que
pueden ser comprendidos por cualquier mente humana razonable, mientras que la información son
aquellos elementos que a la fecha obedecen principalmente a intereses comerciales, retrasando lo
que para muchos en un futuro será la sociedad del conocimiento. Cabe destacar que la sociedad
del conocimiento no es algo que exista actualmente, es más bien un ideal o una etapa evolutiva
hacia la que se dirige la humanidad, una etapa posterior a la actual era de la información, y hacia la
que se llegará por medio de las oportunidades que representan los medios y la humanización de
las sociedades actuales. Mientras la información sólo siga siendo una masa de datos
indiferenciados (hasta que todos los habitantes del mundo no gocen de una igualdad de
oportunidades en el ámbito de la educación para tratar la información disponible con discernimiento
y espíritu crítico, analizarla, seleccionar sus distintos elementos e incorporar los que estimen más
interesantes a una base de conocimientos), entonces seguiremos estando en una sociedad de la
información, y no habremos evolucionado hacia lo que serán las sociedades del conocimiento.
56
Crovi Delia. Sociedad de la Información y el Conocimiento: Entre lo falaz y lo posible", Mc Graw Hill ,Buenos Aires, 2004, pp 10 – 20..
54
3.2.2 Adam Smith y Peter Drucker y la "Sociedad del Conocimiento"
57En 1974, Peter Drucker escribió su libro ―La sociedad post-capitalista‖, en el que
destacaba la necesidad de generar una teoría económica que colocara al conocimiento en el
centro de la producción de riqueza. Al mismo tiempo, señalaba que lo más importante no era la
cantidad de conocimiento, sino su productividad. En este sentido, reclamaba para una futura
sociedad, para una sociedad de la información en la que el recurso básico sería el saber, que la
voluntad de aplicar conocimiento para generar más conocimiento debía basarse en un elevado
esfuerzo de sistematización y organización. A finales de los años 60's, Drucker, el nuevo teórico
del management, con relación a la Sociedad del Conocimiento afirmaba que sería una sociedad en
la que la gestión empresarial cambiaría radicalmente su relación con los trabajadores del
conocimiento empleados, pues éstos últimos estarían mucho menos necesitados de instituciones
empresariales e incluso de la tradicional gestión del conocimiento que las primeras lo estarían de
ellos. Así pues, el discurso de Peter Drucker cuando mezcla ―sociedad del conocimiento‖ y Global
Shopping Center (el "centro comercial global"), se refiere al desarrollo de las empresas de talla
mundial y al auge de las industrias, las redes de información, liberando del peso de las fronteras a
los gestores de la producción, consumidores y productos, interconectándolos en un mercado único
que se autorregularía de per se , en la tradición de la "mano invisible" de Adam Smith.
3.3 Sociedad del Conocimiento y Nuevas Tecnologías
58"Con la invención de los ordenadores, la humanidad por primera vez estuvo en
condiciones de fabricar un portador de información interactivo. Hasta ese momento, el ser humano
era el único portador de información interactivo, porque era capaz de aplicar la información
almacenada para contestar preguntas y resolver problemas. Apoyándose en la más moderna
tecnología, ahora se pueden producir industrialmente máquinas que también van a disponer de
semejante capacidad interactiva. Justamente por esta razón, la informática y la tecnología de las
comunicaciones constituyen pilares básicos de la sociedad de la información"59
57
Idem. 58
Zapata López Fernando. Sociedad del Conocimiento y Nuevas Tecnologías. http://www.oei.es/salactsi/zapata.htm,
consulta: 10 Febrero 2009. 59
Gómez Segade, José A., "Propuesta de Directiva sobre determinados aspectos de los derechos de autor y los derechos
afines en la sociedad de la información", en "Propiedad Intelectual y Nuevas Tecnologías", Editorial Reus S.A., Madrid (España), 1999 pp. 47 - 100.
55
3.4 La Internet en la sociedad del conocimiento
Si bien la Internet forma parte del desarrollo natural de un proyecto más ambicioso como
son las grandes autopistas de información, no es menos cierto que en su campo (medio objetivo),
ya están aflorando todas las preocupaciones y cuestionamientos a nivel social.
La red de redes, como hoy se conoce a la Internet, surgió en diciembre de 1969 como una
red experimental (ARPANET), que conectaba entre sí los centros de información de tres
universidades norteamericanas y el Instituto de Investigaciones de Stanford.
A finales de la década de los 80 la Fundación Americana de la Ciencia (NSF), puso en
funcionamiento la red denominada NSFnet, con el propósito de permitir que las universidades y
centros de investigación pudieran hacer uso de sus grandes computadoras. Estas conexiones
comenzaron a utilizarse para el envío de correo electrónico, transferencia de datos y archivos,
constituyéndose, de esta forma, en la columna vertebral de Internet, que como sabemos es hoy el
fundamento de la Infraestructura Global de Información.
Soslayando lo que pueda significar la Internet desde el punto de vista físico, podemos decir
que la Internet es un protocolo (TCP/IP); esto es, el lenguaje común que permite la
interconectividad de las redes de computadoras y por ende el intercambio de información. De igual
manera, la Internet provee otro lenguaje común denominado hipertexto (HTML).
Ahora bien, en la Internet es donde adquiere connotación práctica toda la problemática que
generan las categorías conceptuales "información", "conocimiento" y "cultura" dentro de un entorno
digital.
"Internet no sólo es un nuevo medio de información y comunicación, sino que, junto con
otros sistemas tecnológicos periféricos (multimedia, infojuegos, realidad virtual, etc.), configura un
nuevo espacio social, electrónico, telemático, digital, informacional y reticular, al que cabe
denominar "tercer entorno". El tercer entorno se superpone a los otros dos, el campo y la ciudad
(physis y polis), y genera profundas transformaciones en la vida humana y social, debido a que
tiene una estructura matemática, física, etc., muy distinta a la de los entornos naturales y urbanos.
La emergencia del tercer entorno modifica casi todas las acciones humanas (la guerra, las
finanzas, la ciencia, el comercio, el ocio, la cultura, el arte, la medicina, la enseñanza, la
delincuencia, etc.)".60
60
Echeverría, Javier, "El futuro de las lenguas en Internet", en comentario sobre la obra "Los señores del aire: Telépolis y
el tercer entorno", Editorial Destino, Barcelona 1999, pp. 34.
56
Desde el punto de vista técnico en la Internet la información y todo tipo de contenidos, se
convierten en datos electrónicos mediante su digitalización; los datos son descompuestos en
"paquetes" digitales que escapan al simple conocimiento sensorial del hombre. Durante el proceso
de transporte y comunicación los "paquetes" son desmontados y vueltos a ensamblar; proceso en
el cual están involucradas múltiples organizaciones, múltiples dispositivos y múltiples
jurisdicciones.
Alguien dijo que el mundo se está encogiendo, pues la Internet, obrando como un sistema
nervioso central, nos proporciona nuevos "ojos" y nuevos "oídos" para alcanzar con facilidad sitios
distantes haciendo uso de la "virtualidad"; término empleado para connotar la simulación y
visualización de todo tipo de procesos, en los cuales el usuario puede participar y percibir
sensorialmente los resultados.
3.5 Automatización
3.5.1 ¿Qué es la automatización?
61La palabra automatización nace automatización del griego antiguo: guiado por uno
mismo y según la real academia de la lengua española es:
Convertir ciertos movimientos corporales en movimientos automáticos o indeliberados.
Aplicar la automática a un proceso, aun dispositivo.
Automática: Perteneciente o relativo al autómata.
Autómata: Instrumento o aparato que encierra dentro de sí el mecanismo que le imprime
determinados movimientos.
Según la Real Academia de Ciencias Exactas Física y Naturales define la Automática
como el estudio de los métodos y procedimientos cuya finalidad es la sustitución del operador
humano por el operador artificial en la generación de una tarea física o mental previamente
programada.
La Automatización es el estudio y aplicación de la Automática al control de los procesos
industriales y de gestión de la producción.
61
Automatización industrial, http://es.wikipedia.org/wiki/Automatización, consulta: 5 Marzo2009.
57
Historia de la automatización
Los orígenes son muy remotos, cuando el hombre primitivo desplazaba sus cargas por
medio de troncos de madera o bien cuando se daban a conocer medios como el tornillo sin fin, el
plano inclinado o la palanca, se efectuaba en cada caso una nueva aportación en el continuo
progreso técnico de la humanidad; estas aportaciones que nos parecen ahora sencillas frente a los
conocimientos de la ciencia fueron en su día tan fundamentales para este progreso técnico como la
idea de Arquímedes de utilizar las presiones de los fluidos en trabajos mecánicos (250 años a.c.).
En un principio la Automatización se identifico con mecanización, perteneciente a la evolución
industrial del maquinismo, nacida en Inglaterra.
En 1947, por un lado D.S. Harder Vicepresidente ejecutivo de Ford Motor Company de
Cleveland, y de otro John Diebol profesor de la Universidad de Harvard, forjaron la automatización
independientemente pero simultáneamente en el tiempo. D.S. Harder, utiliza la palabra
automatización para describir la maquinaria que estaba comenzando a desarrollar la salida de
bloques de los motores de automóvil, ford en al año 1947 crea el departamento de ingenieros de
automatización. Posteriormente John Diebold en ―Automatión‖ define la palabra como toda
actividad en que se desarrolla un esfuerzo en forma automática, así como procesos en los que se
hacen piezas automáticamente. Uno de los factores que ayudaron a la automatización como la
conocemos hoy en día fue la aparición de la computadora y con la evolución de esta, la
automatización ha tenido un crecimiento muy acelerado.
El técnico americano Claude E. Shanon puede ser llamado el padre de la Teoría de la
Información. Esta teoría sirve para explicar de manera más precisa los conceptos de entrada y
salida, de codificación, memorización y transmisión de información medible, ya sea entre dos
sistemas o en el interior de un mismo sistema. A todos los sistemas de este tipo se les denominó
sistemas cibernéticos. Aquí la palabra cibernética se utiliza en su sentido mas amplio = Mate
matización del tratamiento de la información. De la expresión maquinas cibernéticas, han derivado
expresiones como: Autómatas para el tratamiento de la información, Cerebros electrónicos,
Computadoras.
En la industria al día de hoy son pocos los procesos que no están automatizados, incluso
aquellos procesos que se consideran administrativos se han automatizado por la necesidad de
tener un mejor control, más seguridad y reducir el error humano. Para esto se han usado lenguajes
de programación, bases de datos y metodologías de software permitiendo crear sistemas
administrativos automatizados.
58
3.6 Tecnologías de la información
3.6.1 Definición
62El concepto de tecnología de información se define según por la asociación de la
tecnología de información de América (ITAA): Es el estudio, diseño, desarrollo de sistemas
computacionales de software y hardware que se encargar de trasmitir y guardar información. El
término de información se reduce a datos. El primer término de Tecnología de Información se
definió por primera ve en los años 70,
Al concepto de tecnología informativa actual se le da una nueva definición y es más
reconocido, su concepto es muy grande ya que abarca muchos campos, como son; diseño de
redes, bases de datos complejas, continuamente se diseñan software. Actualmente se conocen
como TIC (Tecnologías de la Información y las Comunicaciones) y se define como ―conjunto de
tecnologías que permiten la adquisición, producción, almacenamiento, tratamiento, comunicación,
registro y presentación de informaciones, en forma de voz, imágenes y datos contenidos en
señales de naturaleza acústica, óptica o electromagnética. Las TIC incluyen la electrónica como
tecnología base que soporta el desarrollo de las telecomunicaciones, la informática y el
audiovisual.
3.7 Metodologías de desarrollo de software
3.7.1 Definición de metodologías
63Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas
y ayudas a la documentación para el desarrollo de productos de software.
Según Alistair Cockburn, una metodología se compone de partes interconectadas:
Roles: Arquitecto, Programador, Analista Tester.
Habilidades.
Técnicas (De programación, Análisis, Pruebas).
Equipos.
Herramientas (Para una técnica determinada o realizar un entregable que cumpla
el estándar)
Entregables (casos de uso, diagramas de clases, etc.)
62
Tecnología de la información, http://es.wikipedia.org/wiki/Tecnolog%C3%ADa_de_la_informaci%C3%B3n, consulta: 5
Marzo2009. 63
Pressman Roger S., ―Ingeniería del Software: Un enfoque práctico‖, Segunda edición, Editorial McGraw Hill, E.U. 1990,
pp.- 12.
59
Estándares (normativas de notación, codificación, convenciones.)
Actividades
Calidad (aspectos a gestionar y tener en cuenta en los entregables).
Desde otra perspectiva, Graham, Brian Henderson-Sellers, y Houman Younessi, exponen
en su The OPEN Process Specification que toda metodología tiene que cubrir el ciclo de vida
completo y proporcionar como mínimo:
Un proceso de ciclo de vida completo.
Un conjunto de conceptos y modelos.
Un conjunto completo de técnicas (reglas, guías de estilo.).
Un conjunto delimitado de entregables.
Un lenguaje de modelado de notación intuitiva.
Un conjunto de métricas.
Un conjunto de técnicas para asegurar la calidad.
Estándares de codificación.
Guías para la gestión de los proyectos.
Un conjunto de herramientas de soporte.
3.7.2 Metodologías existentes para el desarrollo de software
En la actualidad existen diversas metodologías para el desarrollo de software, pero para
fines de esta tesina nos enfocaremos solo en RUP y XP.
3.7.2.1 Rational Unified Process (RUP)
64Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken
Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la investigación. En
1995 Rational Software compró una compañía sueca llamada Objectory AB, fundada por Ivar
Jacobson, famoso por haber incorporado los casos de uso a los métodos de desarrollo orientados
a objetos. El Rational Unified Process fue el resultado de una convergencia de Rational Approach y
Objectory (el proceso de la empresa Objectory AB). El primer resultado de esta fusión fue el
Rational Objectory Process, la primera versión de RUP, fue puesta en el mercado en 1998, siendo
el arquitecto en jefe Philippe Kruchten.
64
Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, 2000, Addison Wesley, E.U.
1999 pp 43 – 81.
60
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en
fases e iteraciones. El proceso RUP se repite en una serie de ciclos. Cada ciclo concluye con una
versión del producto (release) y cada ciclo está dividido en 4 fases: concepción, elaboración,
construcción y transición. Cada una de las fases está a su vez dividida en iteraciones, y en cada
iteración se realizan 5 procesos o etapas principales: requerimientos, análisis, diseño,
implementación, pruebas y entrega o preparación del release (versión).
RUP define por lo tanto el proceso mediante dos dimensiones:
Dinámica o en el tiempo. Se expresa en términos de ciclos, fases, iteraciones y fechas
límite o hitos (milestones).
Estática. Se describe en términos de actividades, entregables, roles y workflows.
La metodología RUP, llamada así por sus siglas en inglés Rational Unified Process, divide
en 4 fases el desarrollo del software:
Concepción.
Elaboración.
Construcción.
Transmisión.
Figura 1 Fases de RUP65
65
Instituto Tecnológico de sonora, www.itson.mx/dii/itapia/Conceptos%20de%20RUP.doc, consulta: 15 Marzo 2009.
61
Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste
en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteración se
establecen en función de la evaluación de las iteraciones precedentes. Para sistemas nuevos en su
primera versión. El total del esfuerzo aplicado se distribuye de la siguiente manera:
10% para la fase de Concepción.
20% para la fase de Elaboración.
50% para la fase de Construcción.
10% para la fase de Transición.
Fase de Concepción (Inception)
En la fase de Concepción se establece el 'business case', los objetivos del cual son:
Identificar las entidades externas que interaccionarán con el sistema y la
naturaleza de estas interacciones mediante la definición de los casos de uso y la
descripción de los más prioritarios.
Estudiar los riesgos que puede tener el proyecto.
Estimar los recursos necesarios.
Realizar una planificación global de las fases a realizar con sus fechas límite.
En esta fase obtenemos los siguientes resultados:
Un documento general con los requerimientos funcionales del proyecto,
características clave y principales restricciones.
Un modelo de casos de uso inicial (un 10-20%-20 del total).
Un glosario inicial o vocabulario.
Costes económicos.
Una planificación de las fases del proyecto.
Opcionalmente uno o diversos prototipos gráficos (no tenemos todavía la
arquitectura).
Los criterios de evaluación de la fase que determinarán si se sigue con la siguiente fase o
que no son:
Estimaciones del coste y planificación (coste actual versus coste planificado).
Comprobar que los casos de uso expresan los requerimientos.
Credibilidad de las estimaciones de coste/planificación, prioridades, riesgos y
62
proceso de desarrollo.
Estudio del prototipo.
Preparación del entorno al proyecto.
En este punto el proyecto puede ser cancelado o reevaluado si no cumple los
requisitos la fase.
Fase de Elaboración
En esta fase se planifica en detalle el proyecto, se especifican los requerimientos en detalle
(casos de uso en detalle, con escenarios y clases), y se implementa la base de la arquitectura. Los
objetivos son:
Análisis y Diseño del dominio del problema.
Establecimiento de la arquitectura: ámbito, requerimientos funcionales y no
funcionales.
Detallar la planificación.
Eliminar los riesgos del proyecto.
Construir un prototipo ejecutable de la arquitectura (dirigido a los casos de uso más
prioritarios y más problemáticos, ya que son los que exponen el riesgo del
proyecto).
Se obtienen los siguientes resultados:
Modelo de Casos de Uso (a un 80% como a mínimo): todos los casos de uso y
actores han sido definidos y la mayoría de los casos de uso han sido detallados
(escenarios, flujo principal, diagrama de actividades, etc.).
Requerimientos no funcionales genéricos (no asociados a un caso de uso
específico).
Descripción de la arquitectura.
Prototipo ejecutable de la arquitectura.
Lista de riesgos revisados y casos de uso revisados.
Documentación legal asociada al uso de software de terceros (se determina a la
arquitectura)
Un plan de desarrollo para todo el proyecto, con detalle, mostrando las iteraciones
y el criterio de evaluación para cada iteración.
Los criterios de evaluación para abortar o replantear el paso a la siguiente fase son:
63
¿Tenemos la visión general que el producto es establo?
¿Es estable la arquitectura?
¿Demuestra el prototipo ejecutable que los elementos de mayor riesgo han sido
resueltos?
¿La planificación de la siguiente fase (Fase de Construcción) se encuentra lo
bastante detallada? ¿Es creíble en comparación con las estimaciones?
¿Están todos los integrantes del equipo de desarrollo de acuerdo que con la
arquitectura actual y la planificación actual se puede desarrollar por completo el
sistema?
¿Es aceptable el coste actual versus el coste planificado?
Por lo menos el 80 % de los casos de uso terminados.
Fase de Construcción
En esta fase tiene lugar la implementación del sistema (codificación) y se finalizan aquellos
aspectos del análisis y diseño que hubieran quedado por finalizar en la anterior fase. Como
resultado de la fase obtenemos el producto y los manuales de usuario, así como la documentación
del modelo de la aplicación.
El criterio de evaluación de la fase es determinar si el producto es lo bastante maduro
como para ser usado por los usuarios finales. El producto al finalizar esta fase se considera que se
encuentra en una versión "beta" (ya que pueden surgir incidencias que se resolverán en la
siguiente fase).
Fase de Transición
El propósito de esta fase es que el producto sea probado por los usuarios finales o beta-
usuarios para comprobar la estabilidad del sistema y la satisfacción que ofrece. También puede ser
necesario realizar nuevas versiones, arreglar errores o finalizar aspectos que habían sido
pospuestos.
Los objetivos de la fase son por lo tanto:
"Beta testing" para validar el nuevo sistema.
En caso de migración de un anterior sistema, paralelismo con el sistema que está
reemplazando el nuevo sistema.
Conversión de las bases de datos operativas (en caso de necesidad).
Formación de usuarios y administradores.
64
Visión Estática del Proceso
En la visión estática del proceso podemos diferenciar 4 conceptos:
Roles. Responsabilidades de una persona o equipo (quién).
Actividades. Tareas reales que se tienen que realizar en el proceso (cómo).
Entregables. Son el resultado de las actividades e incluyen documentos y modelos
(qué).
Workflow. Definen la secuencia de actividades que se tienen que realizar en un
punto del proceso (cuándo).
RUP organiza las actividades del proceso en 9 disciplinas totales que se dividen entre 2
grupos: 6 disciplinas básicas y 3 disciplinas de soporte:
Disciplinas básicas: Modelo del Negocio, Requerimientos, Análisis y Diseño,
Implementación, Pruebas y Deployment (o Entrega).
Disciplinas de soporte: Configuración y Gestión de Cambios, Gestión de Proyectos
y Entorno.
Modelo de Negocio
El objetivo del modelo de negocio es entender la forma de funcionar de la organización del
cliente, tanto en estructura como en dinámica de sus procesos. Su objetivo no es modelar por lo
tanto el sistema software a implantar, sino las funciones y roles que realiza la organización para
poder realizar más fácilmente la reingeniería de procesos o la implantación del nuevo sistema. En
la mayoría de casos este modelo no es necesario o no se realiza.
Requerimientos
El objetivo de esta disciplina es describir lo que el sistema tendría que hacer y permitir que
los desarrolladores y el cliente estén de acuerdo con esta descripción. Para eso se realizarán las
siguientes tareas:
Describir los requerimientos funcionales y no funcionales (rendimiento esperado,
plataformas soportadas, integración con sistemas externos, etc.).
Capturar un glosario o vocabulario del sistema o proyecto (mediante documento y
clases conceptuales).
Encontrar actores y casos de uso.
65
Describir los casos de uso mediante su flujo principal, flujos alternos y
excepciones.
Asignar prioridades a los casos de uso encontrados para poder planificar la
iteración en forma de análisis, diseño e implementación.
Análisis y Diseño
A partir de la especificación de los casos de uso se detallan sus escenarios, las clases de
análisis necesarias y se define la arquitectura de diseño adecuada para la plataforma seleccionada.
Implementación
En la implementación se realiza el código del sistema, la integración entre los
componentes y las pruebas unitarias de cada uno de los componentes.
Pruebas
Durante las pruebas se realiza la descripción de los casos de prueba (qué comprobaciones
hay que realizar), se implementan las pruebas y se ejecutan. Estas pruebas pueden ser tanto de
integración, como funcionales, como de rendimiento.
Deployment
Durante el Deployment se realiza el empaquetamiento del sistema, su distribución e
instalación. Asimismo si se ha amado se proporciona de la formación y ayuda adecuada a los
usuarios.
3.7.2.2 Extreme Programing (XP)
66Extreme Programming (XP) es un enfoque de la ingeniería de software formulado por
Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace
Change (1999).
Es una de las metodologías de desarrollo de software más exitosas en la actualidad
utilizada para proyectos de corto plazo, cortó equipo y cuyo plazo de entrega era ayer. La
metodología consiste en una programación rápida o extrema, cuya particularidad es tener como
66
Programación extrema, http://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema, consulta: 15 Marzo 2009.
66
parte del equipo, al usuario final, pues es uno de los requisitos para llegar al éxito del proyecto.
Figura 2 Fases de XP 67
XP tiene como objetivo principal la codificación, por lo cual esta tarea es considerada de
forma especial en todo el ciclo de vida del proyecto. XP se define principalmente por 4 valores:
Comunicación
La comunicación se consigue mediante la programación por parejas (pair programming), la
estimación de las tareas e iteraciones, etc. El objetivo es que el equipo pueda discutir de manera
libre cualquier aspecto del proyecto sin temor a represalias.
Simplicidad
Es muy común a la industria del software complicar demasiado los proyectos de desarrollo.
La intención es producir entregables que sean de valor para el cliente y olvidar los modelos de
diseño demasiado complejos.
Feedback
El feedback se obtiene mediante las pruebas de código, iteraciones con entregables
frecuentes, o revisiones continuas del código.
Coraje
XP tiene como misión principal la revisión continua del código y la realización de pruebas
67
Idem.
67
de forma frecuente. Asimismo se basa en la filosofía de la refactorización continua, tanto de
arquitectura como del código basado en ella.
Además de los 4 valores anteriormente mencionados, XP define 13 prácticas:
Equipo Completo
Todos los integrantes del proyecto forman parte de un equipo, en el cual hay una persona
del cliente que proporciona los requerimientos, asigna las prioridades y realiza un seguimiento del
proyecto.
Los testers ayudan al cliente a definir las pruebas de aceptación, los analistas ayudan a
definir los requerimientos al cliente, etc. En estos equipos no hay especialistas, solo habilidades
generales repartidas.
El Juego del Planning
El objetivo es determinar el alcance de la próxima iteración o entrega (release) según las
prioridades del negocio y las estimaciones técnicas realizadas por los programadores. Existe un
feedback continuo entre el cliente y los desarrolladores que permite realizar los ajustes necesarios.
Pequeños releases
Instalar en producción un sistema inicial simple e ir liberando nuevas versiones en
iteraciones muy cortas.
Pruebas del Cliente
El cliente, además de definir las características deseadas del sistema, define sus pruebas
de aceptación. El equipo construirá estas pruebas por demostrar que las características están
correctamente implementadas.
Propiedad Colectiva del Código
El código realizado puede ser modificado por cualquier integrante del equipo. El equipo
debe tener conocimiento de todas las partes implementadas en el sistema.
68
Estándares de codificación
Todos los integrantes del equipo siguen un estándar de codificación, por el que todo el
código del sistema parece haber sido escrito por un solo individuo.
Ritmo aceptable
Los equipos trabajan duramente y a un ritmo aceptable, de forma que solo se debe trabajar
más de la cuenta si es efectivo. Se debe trabajar para conseguir un software de calidad, para lo
cual los equipos deben trabajar de gusto para ganar, no para morir".
Metáfora
El desarrollo debe ser guiado por una historia simple y compartida de cómo funciona el
sistema, mediante el uso de un vocabulario común.
Integración Continua
Integrar y realizar builds diversas veces al día, cada vez que se completa una parte del
sistema. Cuando el proceso de build se realiza cada semana o más tarde, el proceso de
integración se vuelve caótico y el sistema en general deja de funcionar (características que no
funcionan, correctamente, clases que no compilan por algunas dependencias cambiadas, etc.).
Mediante integraciones continuas se comprueba la estabilidad del sistema y se evitan estos
problemas.
Desarrollo conducido por pruebas
Mediante el uso de pruebas se comprueba de forma continua el sistema. Los
programadores escriben continuamente pruebas unitarias, que se han de ejecutar de forma
correcta para que el desarrollo siga adelante.
Refactoring
Los programadores reestructuran su código sin cambiar su comportamiento para borrar
partes del código duplicadas, simplificar el diseño o añadir flexibilidad.
69
Diseño simple
El sistema debe ser diseñado el más simple posible de forma que puedan comprenderse
aquellos aspectos más relevantes, y dejar de lado características de menor importancia.
Programación a pares
El código es escrito por 2 programadores en una misma máquina de forma alternada. Esto
garantiza que el código es revisado por el otro programador y existe un feedback mejor que
permite mejores pruebas, mejor diseño y mejor código.
Para fines de esta tesis utilizaremos RUP como metodología para el desarrollo del sistema,
se generaran entregables que se ajusten a la naturaleza del proyecto. La decisión sobre el uso de
esta metodología se basa en la naturaleza del proyecto ya que se detecto un gran número de
servicios a automatizar y teniendo en cuenta que el sistema crecerá en el mediano plazo RUP
maneja la aumentación e información necesaria para la continuación del proyecto.
3.8 Programación Orientada a Objetos
68La Programación Orientada a Objetos también conocida como POO, es una forma de
programación que utiliza objetos, ligados mediante mensajes, para la solución de problemas.
Puede considerarse como una extensión natural de la programación estructurada en un intento por
potenciar los conceptos de modularidad y reutilización del código.
3.8.1 Origen
Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un
lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del
Centro de Cómputo Noruego en Oslo. Al parecer, en este centro, trabajaban en simulaciones de
naves, y fueron confundidos por la explosión combinatoria de cómo las diversas cualidades de
diversas naves podían afectar unas a las otras. La idea ocurrió para agrupar los diversos tipos de
naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus
propios datos y comportamiento. Fueron refinados más tarde en Smalltalk, que fue desarrollado en
Simula en Xerox PARC (y cuya primera versión fue escrita sobre Basic) pero diseñado para ser un
68
Ceballos Francisco Javier, POO Visual Basic Curso de programación, RA – MA, México 2004. pp. 14 – 18.
70
sistema completamente dinámico en el cual los objetos se podrían crear y modificar "en marcha"
en lugar de tener un sistema basado en programas estáticos.
La programación orientada a objetos tomó posición como el estilo de programación
dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++, una
extensión del lenguaje de programación C. Su dominación fue consolidada gracias al auge de las
Interfaces gráficas de usuario, para las cuales la programación orientada a objetos está
particularmente bien adaptada. En este caso, se habla también de programación dirigida por
eventos. Las características de orientación a objetos fueron agregadas a muchos lenguajes
existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, entre otros. La adición de
estas características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a
menudo a problemas de compatibilidad y a la capacidad de mantenimiento del código. Los
lenguajes orientados a objetos "puros", por otra parte, carecían de las características de las cuales
muchos programadores habían venido a depender. Para saltar este obstáculo, se hicieron muchas
tentativas para crear nuevos lenguajes basados en métodos orientados a objetos, pero permitiendo
algunas características imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un
temprano y moderadamente acertado lenguaje con esos objetivos pero ahora ha sido
esencialmente reemplazado por Java, en gran parte debido a la aparición de Internet, y a la
implementación de la máquina virtual de Java en la mayoría de navegadores.
3.8.2 Conceptos Básicos
Objeto
Un programa tradicional se compone de procedimientos y datos. Un programa orientado a
objetos consiste solamente en objetos. Un objeto es una encapsulación genérica de datos y de los
procedimientos para manipularlos. Dicho de otra forma, un objeto es una entidad que tiene
atributos particulares, las propiedades, y unas formas para operar sobre ellos, los métodos. Por lo
tanto, un objeto contiene, por una parte, operaciones que definen su comportamiento, y por otra,
variables manipuladas por esas operaciones que definen su estado.
Mensajes
Cuando se ejecuta un programa orientado a objetos, los objetos están recibiendo,
interpretando y respondiendo a mensajes de otros objetos. Esto marca una clara diferencia con
respecto a los elementos de datos pasivos de los sistemas tradicionales.
71
Métodos
Un método se implementa en una clase de objetos y determina como tiene que actuar el
objeto cuando recibe un mensaje. En adición, las propiedades permitirán almacenar información
para dicho objeto. Un método también puede enviar mensajes a otros objetos solicitando una
acción o información. La estructura más interna de un objeto esta oculta para otros usuarios y la
única conexión que tiene con el exterior son los mensajes. Los datos que están dentro de un objeto
solamente pueden ser manipulados por los métodos asociados al propio objeto.
Clases
Una clase es un tipo de objeto definido por el usuario. Una clase equivale a la
generalización de un tipo específico de objetos.
3.8.3 Características
Abstracción
Denota las características esenciales de un objeto, donde se capturan sus
comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que
puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el
sistema sin revelar cómo se implementan estas características.
Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo
están, una variedad de técnicas son requeridas para ampliar una abstracción.
Encapsulamiento
Significa reunir a todos los elementos que pueden considerarse pertenecientes a una
misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los
componentes del sistema. Algunos autores confunden este concepto con el principio de
ocultación, principalmente porque se suelen emplear conjuntamente.
Herencia
Es el mecanismo para compartir automáticamente métodos y datos entre clases y
subclases de objetos.
72
Polimorfismo
Esta característica permite implementar múltiples formas de un mismo método,
dependiendo cada una de ellas de la clase sobre la que se realice la implementación. Esto hace
que se pueda acceder a una variedad de métodos distintos (todos con el mismo nombre) utilizando
exactamente el mismo medio de acceso.
3.9 Base de Datos
3.9.1 Definición
69Un conjunto de información almacenada en memoria auxiliar que permite acceso directo y
un conjunto de programas que manipulan esos datos.
Base de Datos es un conjunto exhaustivo no redundante de datos estructurados
organizados independientemente de su utilización y su implementación en máquina accesibles en
tiempo real y compatibles con usuarios concurrentes con necesidad de información diferente y no
predicable en tiempo.
3.9.2 Tipos de bases de datos
Según la variabilidad de los datos almacenados
Bases de datos estáticas
Éstas son bases de datos de sólo lectura, utilizadas primordialmente para almacenar datos
históricos que posteriormente se pueden utilizar para estudiar el comportamiento de un conjunto de
datos a través del tiempo, realizar proyecciones y tomar decisiones.
Bases de datos dinámicas
Éstas son bases de datos donde la información almacenada se modifica con el tiempo,
permitiendo operaciones como actualización y adición de datos, además de las operaciones
fundamentales de consulta. Un ejemplo de esto puede ser la base de datos utilizada en un sistema
de información de una tienda de abarrotes, una farmacia, un videoclub, etc.
69
Martín Martínez Francisco Javier. Operaciones con bases de datos ofimáticas y corporativas. México 2004. RA – MA.
pp. 22 – 41.
73
Según el contenido
Bases de datos bibliográficas
Solo contienen un representante de la fuente primaria, que permite localizarla. Un registro
típico de una base de datos bibliográfica contiene información sobre el autor, fecha de publicación,
editorial, título, edición, de una determinada publicación, etc. Puede contener un resumen o
extracto de la publicación original, pero nunca el texto completo, porque sino estaríamos en
presencia de una base de datos a texto completo (o de fuentes primarias—ver más abajo). Como
su nombre lo indica, el contenido son cifras o números. Por ejemplo, una colección de resultados
de análisis de laboratorio, entre otras.
Bases de datos de texto completo
Almacenan las fuentes primarias, como por ejemplo, todo el contenido de todas las
ediciones de una colección de revistas científicas.
Directorios
Un ejemplo son las guías telefónicas en formato electrónico.
Bases de datos o "bibliotecas" de información Biológica
Son bases de datos que almacenan diferentes tipos de información proveniente de las
ciencias de la vida o médicas. Se pueden considerar en varios subtipos:
Aquellas que almacenan secuencias de nucleótidos o proteínas.
Las bases de datos de rutas metabólicas.
Bases de datos de estructura, comprende los registros de datos experimentales
sobre estructuras 3D de biomoléculas.
Bases de datos clínicas.
3.9.3 Modelos de base de datos
70Además de la clasificación por la función de las bases de datos, éstas también se pueden
clasificar de acuerdo a su modelo de administración de datos.
70
Pons Capote Olga, Marín Ruiz Nicolás. (1ª Edición). Introducción a los sistemas de bases de datos, Editorial Thomson, México, 2005. pp. 23 – 60.
74
Bases de datos jerárquicas
Como su nombre indica, almacenan su información en una estructura jerárquica. En este
modelo los datos se organizan en una forma similar a un árbol (visto al revés), en donde un nodo
padre de información puede tener varios hijos. El nodo que no tiene padres es llamado raíz, y a los
nodos que no tienen hijos se los conoce como hojas.
Las bases de datos jerárquicas son especialmente útiles en el caso de aplicaciones que
manejan un gran volumen de información y datos muy compartidos permitiendo crear estructuras
estables y de gran rendimiento.
Una de las principales limitaciones de este modelo es su incapacidad de representar
eficientemente la redundancia de datos.
Base de datos de red
Éste es un modelo ligeramente distinto del jerárquico; su diferencia fundamental es la
modificación del concepto de nodo: se permite que un mismo nodo tenga varios padres (posibilidad
no permitida en el modelo jerárquico).
Fue una gran mejora con respecto al modelo jerárquico, ya que ofrecía una solución
eficiente al problema de redundancia de datos; pero, aun así, la dificultad que significa administrar
la información en una base de datos de red ha significado que sea un modelo utilizado en su
mayoría por programadores más que por usuarios finales.
Base de datos relacional
Éste es el modelo más utilizado en la actualidad para modelar problemas reales y
administrar datos dinámicamente. Tras ser postulados sus fundamentos en 1970 por Edgar Frank
Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo
paradigma en los modelos de base de datos.
Su idea fundamental es el uso de "relaciones". Estas relaciones podrían considerarse en
forma lógica como conjuntos de datos llamados "tuplas". Pese a que ésta es la teoría de las bases
de datos relacionales creadas por Edgar Frank Codd, la mayoría de las veces se conceptualiza de
una manera más fácil de imaginar. Esto es pensando en cada relación como si fuese una tabla que
está compuesta por registros (las filas de una tabla), que representarían las tuplas, y campos (las
columnas de una tabla).
75
En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia (a
diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de
que es más fácil de entender y de utilizar para un usuario esporádico de la base de datos. La
información puede ser recuperada o almacenada mediante "consultas" que ofrecen una amplia
flexibilidad y poder para administrar la información.
El lenguaje más habitual para construir las consultas a bases de datos relacionales es
SQL, Structured Query Language o Lenguaje Estructurado de Consultas, un estándar
implementado por los principales motores o sistemas de gestión de bases de datos relacionales.
Base de datos multidimencionales
Son bases de datos ideadas para desarrollar aplicaciones muy concretas, como creación
de Cubos OLAP. Básicamente no se diferencian demasiado de las bases de datos relacionales
(una tabla en una base de datos multidimensional podría serlo también en una base de datos
multidimensional), la diferencia está más bien a nivel conceptual; en las bases de datos
multidimensionales los campos o atributos de una tabla pueden ser de dos tipos, o bien
representan dimensiones de la tabla, o bien representan métricas que se desean estudiar.
3.9.4 Sistema de gestión de base de datos
El objetivo principal es proporcionar un entorno que sea a la vez conveniente y eficiente al
ser utilizado para extraer y almacenar información en la base de datos; otros de sus objetivos son
suministrar la interfaz entre el conjunto de datos y los usuarios, y proporcionar herramientas que
permitan la automatización de procesos sobre los datos almacenados.
El Sistema de Gestión de Bases de Datos (SGBD) es un conjunto integrado de programas,
procedimientos, lenguajes, etc., que suministra, tanto a usuarios no informáticos como a los
analistas, programadores o al administrador, los medios necesarios para describir, recuperar y
manipular los datos, manteniendo su integridad, confidencialidad y seguridad.
Las funciones del SGBD son las siguientes:
De Descripción o Definición. Para especificar los datos que integran la base de
datos, estructura y relaciones entre ellos, reglas de integridad semántica, controles
de acceso, así como las características físicas y lógicas. Esta función la realiza el
Lenguaje de Descripción de Datos, propio del SGBD.
76
De Manipulación. Permite a los usuarios buscar, eliminar o modificar los datos de
la base de datos, de acuerdo con las normas de seguridad, lo que se realiza
mediante el Lenguaje de Manipulación de Datos.
De Utilización. Reúne todas las interfaces que necesitan los diferentes tipos de
usuarios para comunicarse con la base de datos y proporciona un conjunto de
procedimientos para el administrador.
Además, es deseable que estas funciones posean las siguientes características:
Permitir consultas no predefinidas y complejas (SQL).
Flexibilidad a los cambios. Que tengan independencia física de los datos (que los
cambios tecnológicos o físicos no afecten a nadie) e independencia lógica (que
diferentes procesos usuarios puedan tener distintas visiones lógicas de una misma
base de datos).
Facilitar la eliminación de la redundancia, manteniendo la integridad de la base de
datos y actualizando los datos.
Integridad de los datos, respetando las reglas de integridad del modelo (por
ejemplo, que una tabla no tenga filas duplicadas). Todo SGBD debe disponer de
procesos de restauración o reconstrucción de la base de datos (restore o recovery)
a estados anteriores (por ejemplo, mediante copias de seguridad).
Concurrencia de diversos usuarios a la misma base de datos, superando los
problemas de interferencia, mediante el concepto de transacción (conjunto de
operaciones simples que se ejecutan como una unidad, nunca parcialmente, o se
ejecutan todas o ninguna). Para evitar interferencias entre transacciones se usan
técnicas como el bloqueo (consistente en que las otras transacciones no pueden
acceder a los datos hasta que la actual acabe).
Seguridad en el sentido de confidencialidad, autorizaciones, derechos de acceso,
encriptación de contraseñas, etc.
77
3.10 UML
3.10.1 Definición
71
En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos
ya que describen el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado
de desarrollo o estar, todavía, en un estado de planeación. Es en este momento cuando los
diseñadores del modelo deben investigar los requerimientos del producto terminado y dichos
requerimientos pueden incluir áreas tales como funcionalidad, performance y confiabilidad.
Además, a menudo, el modelo es dividido en un número de vistas, cada una de las cuales describe
un aspecto específico del producto o sistema en construcción.
El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de
pequeño tamaño se obtienen beneficios de modelado, sin embargo es un hecho que entre más
grande y más complejo es el sistema, más importante es el papel de que juega el modelado por
una simple razón: "El hombre hace modelos de sistemas complejos porque no puede entenderlos
en su totalidad".
UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994
cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente,
los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del
método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0 de UML fue
liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas construidos para toda clase de
industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronáutica, finanzas, etc.
Los principales beneficios de UML son:
Mejores tiempos totales de desarrollo (de 50 % o más).
Modelar sistemas (y no sólo de software) utilizando conceptos orientados a
objetos.
Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
Mejor soporte a la planeación y al control de proyectos.
Alta reutilización y minimización de costos.
71
Larman Craig. UML y Patrones, Introducción al análisis y diseño orientado a objetos, Editorial Pearson, México 2006.
pp. 65 – 104.
78
Vistas
Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una
gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas
juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de
modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML
tiene son:
Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la
perciben los actores externos.
Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en
términos de la estructura estática y la conducta dinámica del sistema.
Vista de Componentes: Muestra la organización de los componentes de código.
Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los
problemas con la comunicación y sincronización que están presentes en un
sistema concurrente.
Vista de Distribución: muestra la distribución del sistema en la arquitectura física
con computadoras y dispositivos llamados nodos.
Diagramas
Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve
tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema:
diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de
actividad, de componentes y de distribución.
Símbolos o Elementos de modelo
Los conceptos utilizados en los diagramas son los elementos de modelo que representan
conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones
entre estos conceptos incluyendo la asociación, dependencia y generalización.
Reglas o Mecanismos generales
Proveen comentarios extras, información o semántica acerca del elemento de modelo;
además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso
específico, organización o usuario.
79
3.10.2 Diagramas
Diagrama de caso de uso (Use-Case)
Un modelo de casos de uso es descrito en UML como un diagrama de casos de uso
(diagrama use-case) y dicho modelo puede ser dividido en varios diagramas de caso de uso. Un
diagrama de casos de uso contiene elementos de modelo para el sistema, los actores y los casos
de uso y muestra las diferentes relaciones tales como generalización, asociación y dependencia
entre estos elementos. El diagrama de caso de uso debe ser fácil de entender por el usuario final.
Los elementos de un diagrama de casos de uso son:
Sistema
Un sistema en un diagrama de caso de uso es descrito como una caja; el nombre del
sistema aparece arriba o dentro de la caja. Ésta también contiene los símbolos para los casos de
uso del sistema.
Actores
Un actor es alguien o algo que interactúa con el sistema; es quien utiliza el sistema. Por la
frase "interactúa con el sistema" se debe entender que el actor envía a o recibe del sistema unos
mensajes o intercambia información con el sistema. En pocas palabras, el actor lleva a cabo los
casos de uso. Un actor puede ser una persona u otro sistema que se comunica con el sistema a
modelar. Un actor es un tipo (o sea, una clase), no es una instancia y representa a un rol.
Gráficamente se representa con la figura de "stickman".
Diagrama de secuencia
Este diagrama muestra la interacción de los objetos entre ellos. Es importante comentar
que hasta este momento no se han considerado objetos técnicos. En UML, durante el Análisis de
los requerimientos y el Análisis, no se consideran objetos técnicos que definan detalles y
soluciones en el sistema de software, tales como objetos para interfaces de usuario, bases de
datos, comunicaciones, etc. Todos esos objetos se consideran hasta el diseño del sistema.
Diagrama de colaboración
Este se centra tanto en las interacciones y las ligas entre un conjunto de objetos
colaborando entre ellos (una liga es una instancia de una asociación). Ambos, el diagrama de
secuencia y el diagrama de colaboración, muestran interacciones, pero el diagrama de secuencia
80
se centra en el tiempo mientras que el diagrama de colaboración se centra en el espacio. Las ligas
muestran los objetos actuales y cómo ellos se relacionan unos con otros. Así como los diagramas
de secuencia, los diagramas de colaboración pueden ser utilizados para ilustrar la ejecución de una
operación, una ejecución de un use-case o simplemente un escenario de interacción dentro del
sistema. En este diagrama también se representa a los objetos en cajas rectangulares y con el
nombre subrayado. Las ligas se dibujan con líneas y se puede agregar una etiqueta para un
mensaje y un número que define la secuencia de las ligas.
Diagrama de clases
Para la realización del diagrama de clases se toman como base los diagramas de
secuencia y de colaboración por lo que se manejarán los objetos que ahí se consideraron pero
ahora a nivel de clases. Además, se pueden agregar nuevas clases que no se habían considerado
y este paso deberá ser realizado por expertos en el dominio del problema. Para poder definir las
clases, UML sugiere seis características selectivas que debe utilizar el analista para considerar una
clase candidato en el modelo de análisis:
1. Información retenida. La clase será útil durante el análisis sólo si la información
sobre el mismo ha de ser almacenada, transformada, analizada o manejada en
algún otro modo. La información puede referirse a conceptos que deberán estar
siempre registrados en el sistema, eventos o transacciones que ocurren en un
momento específico.
2. Sistema externo. Si se tiene un sistema externo a este sistema, entonces es de
interés en la etapa de modelado. Los sistemas externos deberán ser vistos como
clases que el sistema contendrá o con los cuales interactuará.
3. Patrones, librerías de clases o componentes. Si se tienen patrones, librerías de
clases o componentes, generalmente éstos son clases candidatos.
4. Dispositivos que el sistema maneja. Dispositivos técnicos que maneja el sistema
se convertirán en clases que manejarán esos dispositivos.
5. Partes organizacionales. Especialmente en modelos de negocio, todas las partes
que representan a la organización, serán clases candidatos.
6. Roles de actores. Los roles de actores serán vistos como clases, por ejemplo,
usuario, operador del sistema, administrador, cliente, etc.
Diagrama de estados
Los diagramas de estado captura el ciclo de vida de los objetos, subsistemas y sistemas.
Dicho diagrama determina los estados que un objeto puede tener y cómo los eventos afectan esos
81
estados a través del tiempo. Un diagrama de estado debe abarcar todas las clases que tengan
estados y conducta definidos claramente.
Todos los objetos tienen un estado y éste es el resultado de actividades previas ejecutadas
por el objeto. Ese estado está determinado por los valores de los atributos de este objeto y sus
relaciones con otros objetos. Una clase puede tener un atributo que especifique el estado, o el
estado puede ser determinado por los valores de los atributos "normales" del objeto.
Diagrama de componentes
Describe componentes de software y sus dependencias con otros componentes,
representando la estructura del código. Los componentes de software pueden ser: componentes de
código, componentes binarios que son los generados por la compilación de los componentes de
código y los componentes ejecutables. En este diagrama se pueden manejar paquetes, que son
contenedores de clases utilizados para mantener el espacio de nombres de clases dividido en
compartimentos, de manera que se utilizan para representar subsistemas del sistema en el mundo
físico. Cada paquete se liga con otros a través de dependencias, que se representan con flechas
de líneas discontinuas que van del componente dependiente al componente del cual depende.
Diagrama de despliegue
Contiene los nodos y las conexiones que muestran la arquitectura del sistema en tiempo de
ejecución a través de procesadores, dispositivos y los componentes de software que se ejecutan
en esta arquitectura. Esta es la última descripción física de la topología del sistema, describiendo la
estructura de las unidades de hardware y el software que se ejecuta en cada unidad. Los nodos se
representan con cubos en tres dimensiones con su nombre en el interior. Si el nodo representa a
una instancia en lugar de una clase, el nombre va subrayado. Las conexiones se representan con
líneas continuas y contienen el nombre y el estereotipo de la conexión. El nombre es el
identificador de la misma y el estereotipo indica el protocolo de comunicaciones entre los dos
nodos implicados.
3.10.3 Software para modelado en UML
Actualmente existen diferentes programas para el modelado en UML. Dentro de esta gama
de programas, algunos son libres, es decir que no se necesita pagar una licencia para su uso, y
otras bajo licencia por las cuales se tiene que pagar para su uso.
82
Programas libres
ArgoUML, Herramienta de modelado UML escrito en Java (enlace externo)
BOUML, Ligera herramienta de modelado UML y generación de código C++, Java
e IDL. Disponible para Windows, Unix/Linux y Mac OS X (Sitio Oficial)
Fujaba, No solo sirve para modelar sino que puede generar código Java
automáticamente. También es capaz de hacer ingeniería inversa y crear los
diagramas a partir del código Java.
Día Puede ser usado para modelar varios tipos de diagramas UML (enlace
externo).
gModeler Herramienta para modelado de UML basada en Flash (utilizable desde el
navegador), que permite generar código Action Script 2.0 Compatible (enlace
externo).
Herramienta gráfica basada en Eclipse para el modelado con UML2, es de código
abierto y se ofrece bajo licencia EPL (Sitio Oficial).
StarUML Herramienta de modelado para Windows desarrollada en Delphi.
Bastante estable y utilizable (enlace externo).
TCM, Toolkit for Conceptual Modeling, herramienta para crear diversos tipos de
diagramas incluidos UML [http://wwwhome.cs.utwente.nl/~tcm/ Web oficial).
Umbrello Herramienta para modelado UML para el entorno KDE (enlace externo).
UMLet Herramienta para modelado rápido de UML también escrita en Java (enlace
externo).
Netbeans módulo UML.
Open ModelSphere Herramienta de Modelado gratuita, para modelado de datos,
procesos y UML. Disponible como Open Source Software, Released Under GPL
(GNU Public License). (Web oficial).
Programas bajo licencia.
Enterprise Architect de Sparx Systems
Borland Together
Corel iGrafx
Microsoft Visio
PowerDesigner de Sybase
Rational Rose de IBM
Poseidon for UML de GentleWare
MagicDraw UML
83
Para fines de esta tesis utilizaremos:
StarUML Herramienta de modelado para Windows desarrollada en Delphi.
Bastante estable y utilizable (enlace externo).
3.11 Lenguajes de programación
3.11.1 Historia de los lenguajes de programación
72Los primeros lenguajes de programación surgieron de la idea de Charles Babagge, la
cual se le ocurrió a este hombre a mediados del siglo XIX. Era un profesor matemático de la
universidad de Cambridge e inventor ingles, que la principio del siglo XIX predijo muchas de las
teorías en que se basan los actuales ordenadores. Consistía en lo que él denominaba la maquina
analítica, pero que por motivos técnicos no pudo construirse hasta mediados del siglo XX. Con él
colaboro Ada Lovedby, la cual es considerada como la primera programadora de la historia, pues
realizo programas para aquélla supuesta maquina de Babagge, en tarjetas perforadas.
3.11.2 Lenguaje maquina
El lenguaje máquina de una computadora consta de cadenas de números binarios (ceros y
unos) y es el único que ―entienden‖ directamente los procesadores. Todas las instrucciones
preparadas en cualquier lenguaje de máquina tienen por lo menos dos partes. La primera es el
comando u operación, que dice a la computadora cuál es la función que va a realizar. Todas las
computadoras tienen un código de operación para cada una de sus funciones. La segunda parte
de la instrucción es el operando, que indica a la computadora dónde hallar o almacenar los datos y
otras instrucciones que se van a manipular; el número de operandos de una instrucción varía en
las distintas computadoras.
3.11.3 Lenguajes ensambladores
El lenguaje ensamblador es un tipo de lenguaje de bajo nivel utilizado para escribir
programas informáticos, y constituye la representación más directa del código máquina específico
para cada arquitectura de computadoras legible por un programador. Un ensamblador crea código
72
Matta G. D.A. Introducción al Desarrollo de Aplicaciones con Visual Basic, Editorial Prentice Hall México, 2005,
pp. 60 – 81.
84
objeto traduciendo instrucciones mnemónicas a códigos operativos e interpretando los nombres
simbólicos para direcciones de memoria y otras entidades.
El uso de referencias simbólicas es una característica básica de los ensambladores,
evitando tediosos cálculos y direccionamiento manual después de cada modificación del programa.
La mayoría de los ensambladores también incluyen facilidades para crear macros, a fin de generar
series de instrucciones cortas que se ejecutan en tiempo real, en lugar de utilizar subrutinas.
3.11.4 Lenguajes ensambladores
Los lenguajes de programación de alto nivel se caracterizan por expresar los algoritmos de
una manera adecuada a la capacidad cognitiva humana, en lugar de a la capacidad ejecutora de
las máquinas. En los primeros lenguajes de alto nivel la limitación era que se orientaban a un área
específica y sus instrucciones requerían de una sintaxis predefinida. Se clasifican como lenguajes
procedimentales. Otra limitación de los lenguajes de alto nivel es que se requiere de ciertos
conocimientos de programación para realizar las secuencias de instrucciones lógicas. Los
lenguajes de muy alto nivel se crearon para que el usuario común pudiese solucionar tal problema
de procesamiento de datos de una manera más fácil y rápida.Actualmente los lenguajes de alto
nivel mas usados son: C#, Visual Basic, Java, PL/SQL.
3.12 Web Client Software Factory
3.12.1 Definición
Es una herramienta que permite a los arquitectos y a los desarrolladores de software
incorporar rápidamente muchas de las mejores prácticas y patrones de la construcción de
aplicaciones cliente Web.
3.12.2 Principales Patrones y practicas de la Web Client Software Factory
MVP (Model View Presenter).73
Es un patrón de diseño que separa el modelo del dominio, la presentación y las acciones
basadas en la interacción con el usuario. El patrón Model-View-Presenter (MVP) separa el modelo
del dominio, la presentación y las acciones basadas en la interacción con el usuario en tres clases
separadas.
73
Converti Mariano. Introducción a Composite UI Application Block (CAB) IV.
http://blogs.southworks.net/mconverti/2007/09/10/introduccion-a-composite-ui-application-block-cab-iv/, consulta: 10 Febrero 2009.
85
La vista le delega a su presenter toda la responsabilidad del manejo de los eventos del
usuario.
El presenter se encarga de actualizar el modelo cuando surge un evento en la vista, pero
también es responsable de actualizar a la vista cuando el modelo le indica que ha cambiado.
El modelo no conoce la existencia del presenter. Por lo tanto, si el modelo cambia por
acción de algún otro componente que no sea el presenter, debe disparar un evento para que el
presenter se entere.
Enterprise Library74
El Enterprise Library es un conjunto de componentes de software reutilizables (bloques
de aplicación) diseñados para asistir a los desarrolladores de software con los retos comunes del
desarrollo empresarial (como validación, caching, manejo de excepciones, bitácoras y muchas
otras).
Los bloques de aplicación son un tipo de guía encapsulando las prácticas recomendadas
por Microsoft.
Estos bloques son provistos como código fuente más una documentación completa, todo
esto pudiendo ser extendido o modificado por los desarrolladores para ser usado en proyectos
complejos de nivel empresarial.
74
Perspectivas Microsoft. http://www.microsoft.com/spain/enterprise/perspectivas/numero_17/partnerI.mspx, Consulta: 10
Febrero 2009.
86
Esquema de la Web Client Software Factory 75
Figura 3 Esquema de la Web Client Software Factory
75
Software Factory Capabilities. http://msdn.microsoft.com/en-us/library/cc304787.aspx, consulta: 10 Febrero 2009.
87
3.13 AJAX Control Toolkit
76El ASP.NET AJAX Control Toolkit nace como un proyecto conjunto entre la comunidad de
programadores y Microsoft. Está desarrollado en base a ASP.NET AJAX y contiene una serie de
controles Web y extendedores con los que podremos utilizar las avanzadas características de
ASP.NET AJAX sin más que un arrastre de ratón. Del mismo modo, con su descarga disponemos
de ejemplos de uso, así como del propio código fuente de los controles. Y lo mejor de todo es que
es totalmente gratuito. Vamos a distinguir entre controles Web y extendedores, donde los primeros
tienen una entidad por sí mismos, mientras que los segundos únicamente añaden un
comportamiento a un control Web existente. Estos controles van desde un simple botón con una
alerta asociada, hasta un complejo panel que podemos arrastrar por la pantalla; en ambos casos,
mandando y recogiendo información entre el cliente y el servidor sin ningún tipo de recarga de
página.
3.14 Relaciones Jurídicas
3.14.1 ¿Qué es la empresa Relaciones Jurídicas?
77Relaciones Jurídicas es una empresa dedicada a la atención y seguimiento de asuntos
Jurídicos desprendidos incumplimientos a los acuerdos establecidos en documentos oficiales.
3.14.2 Estructura organizacional
Figura 4 Organigrama Relaciones Jurídicas 78
76
http://www.es-asp.net/tutoriales-asp-net/tutorial-0-5312/asp-net-ajax-control-toolkit.aspx, consulta: 10 Febrero 2009 77
Información obtenida a partir de reuniones con el usuario. 78
Idem.
88
3.14.3 Misión
Resolver, dar seguimiento y controlar de manera rápida y oportuna los asuntos jurídicos
desprendidos por faltas administrativas, violaciones de algún reglamento o la ley misma, con un
personal altamente capacitado y eficiente con amplio apego a la ley.
3.14.4 Visión
Ser la empresa con mayor reconocimiento en el ámbito jurídico a nivel nacional con el
personal mejor capacitado y herramientas de alta tecnología, las cuales nos van a ayudar a
controlar de manera rápida y oportuna los asuntos jurídicos.
3.14.5 Objetivo
Respetar y hacer respetar las leyes y reglamentos vigentes, buscando siempre el beneficio,
seguridad y la satisfacción de nuestros clientes.
3.14.6 Marco jurídico
Leyes
Constitución Política de los Estados Unidos Mexicanos D.O.F. 5 – 11 – 1917 y sus
Reformas.
Ley Federal de Instituciones de Fianzas D.O.F. 29 – XII – 1950
Ley Federal de Responsabilidades de los Servidores Públicos D.O.F. 31 – XII – 1982 y
sus Reformas.
Reglamentos
Reglamento de la Ley del Servicio de Tesorería de la Federación D.O.F 15 – III – 1999.
Documentos normativos
Manual Normativo de la Federación.
89
3.15 CONCLUSIÓN
Lo visto en este capítulo nos proporciona una base teórica suficiente sobre la cual
desarrollaremos nuestra propuesta tecnológica para este proyecto; esta contempla desde
metodologías hasta plataformas de desarrollo de sistemas. Pasando por cada una de las partes
importantes que se deben contemplar al desarrollar un sistema de información.
Es importante resaltar que estamos tratando de ocupar herramientas de última generación
así como metodologías probadas en el desarrollo de sistemas. Es verdad que existen muchas
otras herramientas sobre las cuales se podrían lograr resultados similares, pero seleccionamos
estas herramientas basándonos en nuestro juicio como ingenieros y en las necesidades
descubiertas, y más que todo, estas últimas determinaron la tecnología utilizada, ya que esta se
adapta más fácilmente a nuestras necesidades.
90
Capítulo IV. Procesamiento y análisis de la información de campo
4.1 Análisis De Situación Actual Del Área Jurídica De La Empresa Relaciones Jurídicas
Para el desarrollo del proyecto realizaremos un análisis de situación actual, para el cual
nos basaremos en entrevistas desarrolladas en las áreas afectadas por el mal funcionamiento de él
procedimiento y por la falta de conocimiento del mismo. Por tal motivo nosotros al detectar no solo
estos errores sino que también ya para estos días este procedimiento como tal, ya es obsoleto
ahora bien, se desarrollará una reingeniería de procesos la cual será la que dará la pauta al buen
funcionamiento de nuestra área jurídica ya que el conocimiento y seguimiento de procesos es
responsabilidad del jefe del área.
En este capitulo mostraremos la situación actual en la que se encuentra esta empresa
Relaciones Jurídicas y nos podremos dar cuenta de sus fortalezas, oportunidades, debilidades y
amenazas por medio de la matriz FODA y así determinar las causas del problema y efectos que
este tiene dentro de la empresa.
Por ello basándonos en los diagramas tanto de Pareto como Ishikawa, se podrá
diagnosticar el problema o problemas detectados después del análisis de situación actual y por
consiguiente podremos dar posibles soluciones a nuestro problema y posteriormente escoger el
más apto e idóneo para así poder automatizar el proceso nuevo a plantear dentro de la empresa
Relaciones Jurídicas.
4.1.1 Micro-escenario
El objetivo de este documento es conocer de forma general la Empresa Relaciones
Jurídicas, con el fin de obtener información que permita comprender como esta constituida así
como los servicios que brinda y tareas que desempeña esta subdirección.
Descripción general de la Empresa Relaciones Jurídicas.
La Empresa Relaciones Jurídicas, tiene bajo su responsabilidad el dar seguimiento, control
y respuesta a los asuntos de índole jurídica que se desprendan de esta empresa.
91
ORGANIGRAMA DE LA SUBDIRECCIÓN
Figura 14 Organigrama de la subdirección.
Fuente: Proporcionado por la empresa Relaciones Jurídicas.
Servicios
79
Contestación y seguimiento de oficios.
Consulta de dictaminación sobre resoluciones Jurídicas.
4.1.1.1 Identificación de Procesos
Descripción de proceso
Todos los asuntos de índole jurídica que entran a Recepción son turnados a Asuntos
Jurídicos, para que esta última se encargue de contestar y dar seguimiento a cada unos de los
asuntos. Los tipos de asuntos que atienden Asuntos Jurídicos son:
I. Reclamaciones.
II. Juicios de amparo.
III. Juicios de nulidad.
IV. Quejas
79
Proporcionado por el Director General de La Empresa Relaciones Jurídicas, información del área de Asuntos Jurídicos.
92
Una vez que la secretaria de Asuntos Jurídicos recibe el oficio a contestar por parte de
recepción de documentos, esta solicita el expediente del permisionario que se menciona en el
oficio, posteriormente captura los datos generales en un archivo Excel el cual sirve como base de
datos donde se registran todos y cada unos de los asuntos que entran a el área de Asuntos
Jurídicos. Todos los asuntos capturados son turnados ha el subdirector de la Asuntos Jurídicos.
Una vez que el subdirector tiene en su poder el oficio, lo analiza y asigna un abogado para
que prepare el oficio de contestación así mismo indica prioridades y fecha máxima de atención. El
abogado asignado recibe el oficio junto con el expediente del permisionario, lo integra, lo analiza,
selecciona la plantilla sobre la cual dará contestación a dicho oficio. Ya que el abogado ha
terminado de generar el oficio de contestación le asigna un número de oficio de contestación y lo
turna al subdirector para que este realice una revisión interna antes de pasarla con el Director de
Relaciones Jurídicas.
Si el oficio de contestación es rechazado por el Subdirector o el Director, es regresado al
abogado para que realice las correcciones pertinentes y nuevamente sea revisado por el
Subdirector y Director. Ya que el oficio de contestación ha sido autorizado por el Director, este se
turna a el notificador para que envíe la resolución a el permisionario quejoso o reclamante.
Consulta de dictaminación sobre resoluciones Jurídicas.
Roles Identificados
1. Subdirector Asuntos Jurídicos
2. Secretaria.
Descripción de proceso80
Proceso que realiza Asuntos Jurídicos para informar a las áreas de finiquitos y permisos
sobre los asuntos jurídicos que tengan los permisionarios al momento de solicitar un finiquito o
expedición de un permiso. Ya que de acuerdo a el reglamento de la Ley Federal, no se puede
finiquitar u otorgar un permiso a un permisionario que tenga algún tipo de procedimiento pendiente
en el área Jurídica. En el momento que un permisionario solicita un finiquito o un permiso, las
áreas Finiquitos ó permisos según sea el caso, se apoyan en Asuntos Jurídicos para consultar si el
permisionario en cuestión tiene actualmente reclamaciones en trámite, resoluciones pendientes de
emitir o comprobar y/o procedimientos administrativos abiertos.
80
Idem.
93
Este proceso se lleva acabo mediante la elaboración de una nota informativa y una
solicitud de dictaminación sobre resoluciones jurídicas dirigida a Asuntos Jurídicos, solicitando
información de lo arriba mencionado.
La secretaria de Asuntos Jurídicos al recibir esta nota informativa busca en su archivo de
Excel todos los asuntos correspondientes al permisionario solicitado y verifica el estatus en el cual
se encuentra cada uno de los asuntos, acto seguido la secretaria de Asuntos Jurídicos responde
con una ATENTA NOTA especificando si se existen o no procesos pendientes para el
permisionario.
4.1.1.2 Identificación de Actividades
Ficha de actividades por Puesto
Puesto Actividad
Subdirector Jurídico
Objetivo 1: Coordinar los asuntos de orden jurídico y administrativo en el ámbito de su competencia, de conformidad con la ley y su reglamento, para proponer resoluciones que permitan la legalidad de los en eventos en materia.
Dirigir los procesos de análisis de quejas, inconformidades y procedimientos administrativos, para catalogar su situación jurídica.
Asignar los asuntos jurídico – administrativos que se presenten, para su atención según sea el caso.
Asegurar la información sobre los asuntos jurídico – administrativos que ingresen a la dirección general, para contar con los antecedentes físicos y conformar su expediente.
Abogados
Preparar el oficio o nota informativa de contestación.
Asignar número de oficio de contestación e imprimir oficio de contestación.
Realizar actas de comparecencia.
Notificador Notificar de resolución de oficio de contestación.
Secretaria
Objetivo 1: Proporcionar apoyo administrativo a la Subdirección de Apoyo y Asuntos Jurídicos.
Atender las solicitudes de fotocopiado, para apoyar en la reproducción de documentos requeridos por asuntos jurídicos.
Realizar el registro diario de fotocopiado de Asuntos Jurídicos, para conciliar cifras con el proveedor del servicio.
Figura 15 Ficha de actividades por puesto.
94
4.1.2 Desarrollo de Diagramas de Actividades
Se desarrollaron estos diagramas del resultado del levantamiento de información por medio
de las entrevistas realizadas al director general así mismo unificando conocimientos ingenieriles
tanto de industrial como informática, para la utilización conjunta de estos. 81
81
Estos diagramas fueron realizados combinando las necesidades de ambas carreras ing. Industrial e ing. Informática de forma tal que no se afectan las reglas de un diagrama de flujo ni se afecto el contenido ni el proceso en si.
Figura 16 Diagrama de Juicio de Amparo
95
Figura 17 Diagrama de Juicios de Nulidad
96
Figura 18 Diagrama de Reclamaciones
97
Figura 19 Diagrama de Quejas.
98
4.1.3 Proceso del Área de Asuntos Jurídicos
Este proceso nos fue proporcionado por el Director del área de Asuntos Jurídicos, ya que
es él quien nos explico cómo se lleva a cabo el proceso actualmente.
Figura 20 Proceso del área de Asuntos Jurídicos
99
4.1.4 Análisis de Normatividad de Procesos
En este apartado realizaremos un análisis de la normatividad que involucra a los procesos
que vamos a redefinir para ello enlistaremos a todos y cada uno de ellos para darles un
seguimiento en nuestros procesos y que cumplan con lo establecido en las normas de nuestro
marco jurídico.82
Leyes
Constitución Política de los Estados Unidos Mexicanos D.O.F. 5 – 11 – 1917 y sus
Reformas.
Ley Federal de Instituciones de Fianzas D.O.F. 29 – XII – 1950
Ley Federal de Responsabilidades de los Servidores Públicos D.O.F. 31 – XII – 1982 y
sus Reformas.
Ley del Diario Oficial de la Federación y sus Gacetas Gubernamentales D.O.F 24 – XII –
1992 y sus Reformas.
Códigos
Código Federal de Procedimientos Civiles D.O.F 24 – II – 1943 y sus Reformas.
Reglamentos
Reglamento de la Ley del Servicio de Tesorería de la Federación D.O.F 15 – III – 1999.
Documentos normativos
Manual Normativo de la Federación.
En el análisis normativo se pudo detectar primeramente que de todas las normas
involucradas a esta empresa Relaciones Jurídicas, las mencionadas anteriormente son las que
intervienen en nuestra área a trabajar, posteriormente nos hemos dado cuenta en nuestra revisión
y análisis, que ninguna norma, código, ley y reglamento serán afectados en la reingeniería de
procesos, por tal motivo partiremos a ver la situación actual de nuestras áreas y de sus
procedimientos.
82
La información se busco en los manuales de políticas y procedimientos que tenían de tiempo atrás, ya que se siguen
rigiendo por las mismas normas, reglamentos, códigos, etc.
100
4.1.5 Identificación de Vulnerabilidades MATRIZ FODA
Para el análisis diagnostico del área Asuntos Jurídicos y con la información levantada por
medio de la guía de información (ver anexos). Podremos detectar la problemática real de nuestra
área a trabajar con la ayuda del FODA en la que encontramos la siguiente información.
FORTALEZAS Capacidad de dominio jurídico
por parte del Director de Asuntos Jurídicos.
Conocimiento de proceso de negocio por parte de la secretaria de Asuntos Jurídicos.
Área jurídica poca resistencia al cambio.
Organización del trabajo en el área de recepción.
Distribución equitativa de carga de trabajo en Asuntos Jurídicos.
OPORTUNIDADES Redefinición de procesos de recepción y
turnado de documentos. Automatización de Procesos. Economización de papel. Desarrollo sustentable. Disminución de los tiempos de respuesta. Disminución de los tiempos de turnado de
documentos. Manejo y control de documentos.
DEBILIDADES Procesos obsoletos de acuerdo a
las necesidades actuales del área de recepción y del área de asuntos jurídicos.
Manejo inadecuado de la documentación recibida en recepción.
Retrazo en tiempo de respuesta en contestación de documentos.
Falta de compromiso con las actividades de un servidor público.
Tiempos muertos por parte de los administrativos.
Mala atención al público por parte de la dirección de relaciones jurídicas.
Malos manejos de asuntos jurídicos.
AMENAZAS Pérdida de asuntos jurídicos ante un
juzgado o tribunal. Perdida de documentación importante. Pérdida de clientes de Relaciones
Jurídicas. Pérdida de credibilidad en asuntos
jurídicos. Imposición de sanciones administrativas.
Figura 21 Cuadro de identificación de vulnerabilidades FODA.
101
Con este método analítico que permite conocer la realidad situacional de una empresa a
través de componentes internos y externos nos basaremos para rescatar las estrategias a utilizar
aprovechando las fortalezas y oportunidades para poder atacar y disminuir las debilidades y
amenazas.
Internos
Externos
Obstáculos para FODA
Grado de objetividad
Conducta esteriotipada
Opiniones
El temor
Mezclar diversas posiciones jerárquicas
Considerar que FODA es un formato único
FFOORRTTAALLEEZZAASS
DDEEBBIILLIIDDAADDEESS
OOPPOORRTTUUNNIIDDAADDEESS
AAMMEENNAAZZAASS
102
4.1.6 Matriz (MAFE)
Las estrategias derivadas de nuestro análisis MAFE, las utilizaremos para llegar al
diagnostico de nuestra área Asuntos Jurídicos de la empresa ―Relaciones Jurídicas‖.
MATRIZ
MAFE
FORTALEZAS F1 Capacidad de dominio
jurídico por parte del Director de Asuntos Jurídicos.
F2 Conocimiento de proceso de
negocio por parte de la secretaria de Asuntos Jurídicos.
F3 Área jurídica poca resistencia
al cambio.
F4 Organización del trabajo en
el área de recepción.
F5 Distribución equitativa de
carga de trabajo en Asuntos Jurídicos.
F6 Roles bien definidos en área
jurídica y en recepción.
DEBILIDADES D1 Procesos obsoletos de
acuerdo a las necesidades actuales del área de recepción y del área de asuntos jurídicos.
D2 Manejo inadecuado de la
documentación recibida en recepción.
D3 Retrazo en tiempo de
respuesta en contestación de documentos.
D4 Falta de compromiso con las
actividades de un servidor público.
D5 Tiempos muertos por parte de
los administrativos.
OPORTUNIDADES O1 Redefinición de procesos
de recepción y turnado de documentos.
O2 Automatización de
Procesos.
O3 Economización de papel.
O4 Desarrollo sustentable.
O5 Disminución de los tiempos
de respuesta.
O6 Disminución de los tiempos
de turnado de documentos.
O7 Manejo y control de
documentos.
ESTRATEGIAS FO (MAXI – MAXI) 1.-Roles bien definidos, los puestos deben ser muy específicos.(F1,F2,O1,O7)
2.-Automatización de procesos
(F4,F5,O3,O4,O7)
3.- Control efectivo sin tanto
papeleo. (F3,F4,F6, O1, O2, O3, O4, O5, O6,)
4.- Desarrollo sustentable, en el
ahorro de papel. (F6,O3, O4,O2)
ESTRATEGIAS DO (MINI – MAXI)
1.- Rediseño de procesos.
(D1,O1, O2)
2.- Control De los documentos en
sistema (D2,D4,O1,O7)
3.- Automatización de los
procesos.(D3,D5,O5, O6)
AMENAZAS A1 Perdida de asuntos
jurídicos ante un juzgado o tribunal.
A2 Perdida de documentación
importante.
A3 Perdida de clientes de
Relaciones Jurídicas.
A4 Perdida de credibilidad en
asuntos jurídicos.
A5 Imposición de sanciones
administrativas.
ESTRATEGIAS FA (MAXI – MINI) 1.- Capacitación conforme a los procesos rediseñados (F1,F2,F6,A1,A2,A3)
2.- Automatización De procesos
(F4,F5,F6,A1,A2,A3, A5)
ESTRATEGIAS DA (MINI – MINI)
1.- Reingeniería de procesos
(D1,D2,A1,A2,A3,A4,A5)
2.- Disminución de tiempos de
respuesta de los documentos (D2,D3,D5,A3,A5,A1)
Figura 22 Cuadro de estrategias de MAFE
103
4.1.7 Matriz de Evaluación de Factores Externos (MEFE)
FACTORES DE
ÉXITO PESO CALIFICACIÓN PONDERADO
OPORTUNIDADES
Redefinición de procesos de recepción y turnado de documentos.
0.14
1 0.14
Automatización de Procesos.
0.11 1 0.11
Manejo y control de documentos
0.08 2 0.16
Desarrollo sustentable. 0.06 1 0.06
Disminución de los tiempos de respuesta.
0.09 1 0.09
AMENAZAS
Perdida de asuntos jurídicos ante un juzgado o tribunal.
0.12 4 0.48
Perdida de documentación importante.
0.10 3 0.30
Perdida de clientes de Relaciones Jurídicas.
0.13 3 0.49
Perdida de credibilidad en asuntos jurídicos.
0.07 2 0.14
Imposición de sanciones administrativas.
0.10 3 0.30
TOTAL 1.00 2.27
Figura 23 Matriz de evaluación de MEFE
Para este análisis MEFE primordialmente para entenderlo debemos saber cual es el
objetivo y el estándar de evaluación manejado que son los siguientes.
Objetivo:
El objetivo de esta matriz es permitir a los estrategas resumir y evaluar información económica,
social, cultural, demográfica, ambiental, política, gubernamental, jurídica, tecnológica y competitiva
de la empresa bajo estudio.
Estándar:
Independientemente de la cantidad de oportunidades y amenazas clave incluidas en la
Matriz EFE, el total ponderado más alto que puede obtener la organización es 4.0 y el total
104
ponderado más bajo posible es 1.0. El valor del promedio ponderado es 2.5. Un promedio
ponderado de 4.0 indica que la organización está respondiendo de manera excelente a las
oportunidades y amenazas existentes en su industria. Lo que quiere decir que las estrategias de la
empresa están aprovechando con eficacia las oportunidades existentes y Minimizando los posibles
efectos negativos de las amenazas externas. Un promedio ponderado de 1.0 indica que las
estrategias de la empresa no están capitalizando muy bien esta oportunidad como lo señala la
calificación.
Resultados de la MEFE:
El total ponderado de 2.27 indica que esta empresa está justo por debajo de la media en su
esfuerzo por no seguir estrategias que capitalicen las oportunidades externas y eviten las
amenazas, por tal motivo se debe de enfocar en trabajar en estas estrategias las cuales al
trabajarlas de manera constante dejaran de ser una debilidad.
4.1.8 Matriz de Evaluación de Factores Internos (MEFI)
FACTORES DE ÉXITO PESO CALIFICACIÓN PONDERADO
FORTALEZAS
Capacidad de dominio jurídico por
parte del Director de Asuntos
Jurídicos.
0.16
4 0.64
Conocimiento de proceso de negocio
por parte de la secretaria de Asuntos
Jurídicos.
0.08 4 0.24
Área jurídica poca resistencia al
cambio.
0.18 3 0.54
Organización del trabajo en el área de
recepción.
0.06 3 0.18
Roles bien definidos en área jurídica y
en recepción.
0.12 3 0.36
DEBILIDADES
Procesos obsoletos de acuerdo a las
necesidades actuales del área de
recepción y del área de asuntos
jurídicos.
0.15 2 0.30
Manejo inadecuado de la 0.08 4 0.32
105
documentación recibida en recepción.
Retrazo en tiempo de respuesta en
contestación de documentos.
0.06 3 0.18
Falta de compromiso con las
actividades de un servidor público.
0.05 3 0.15
Tiempos muertos por parte de los
administrativos.
0.06 3 0.18
TOTAL 1.00 3.09
Figura 24 Matriz de evaluación MEFI
Objetivo:
Este instrumento resume y evalúa las fuerzas y debilidades más importantes dentro de las
áreas funcionales de nuestra área de Asuntos Jurídicos y además ofrece una base para identificar
y evaluar las relaciones entre dicha área.
Estándar:
Independientemente de la cantidad de fortalezas y debilidades clave, incluidas en la Matriz
EFI, el total ponderado más alto que puede obtener la organización es 4.0 y el total ponderado más
bajo posible es 1.0. El valor del promedio ponderado es 2.5.
Un promedio ponderado de 4.0 indica que la organización está respondiendo de manera
excelente a las oportunidades y amenazas existentes en su industria.
Lo que quiere decir que las estrategias de la empresa están aprovechando con eficacia las
fortalezas existentes y minimizando los posibles efectos negativos de las debilidades.
Un promedio ponderado de 1.0 indica que las estrategias de la empresa no están
capitalizando muy bien esta fortaleza como lo señala la calificación.
Resultados de la MEFI:
El total ponderado de 3.09, muestra que la posición estratégica interna general de la
empresa está por arriba de la media en su esfuerzo, por seguir estrategias que capitalicen las
fortalezas internas y neutralicen las debilidades. Con este resultado nos podemos dar cuenta que
106
las fortalezas son tan fuertes para la empresa que aprovechándolas adecuadamente podremos
llegara a resolver el problema de nuestra área.
4.1.9 Tabla de Acciones FODA
Estas son las acciones a seguir derivadas de nuestros análisis de MEFE, MEFI y MAFE,
por tal motivo tenemos para ello que contemplar las consecuencias que se derivan y poder llegar
a la causa raíz del problema, por ello seguiremos el análisis consecuente ahora con el diagrama
causa-efecto. Que es el siguiente paso en nuestro análisis diagnostico, pero sin antes ver y
desarrollar la lista de nuestras causas detectadas. Las cuales se encuentran en la figura 26.
Figura 25 Tabla de Acciones FODA
FORTALEZAS Principal recurso para el
levantamiento de la información. Utilización de su conocimiento
de causa para las necesidades de la empresa.
Implementación de mayor facilidad de nuevos procesos en el área de asuntos jurídicos.
Esta organización nos sirve para acelerar el proceso de manera más sencilla.
La implementación de una automatización más sencilla.
Los roles definidos nos servirán para obtener información detallada y obtener los puntos críticos con mayor facilidad para la reingeniería de procesos.
OPORTUNIDADES Se realizará una reingeniería de
procesos para que se siga y se tenga un control de acciones y procedimientos.
La automatización de procesos nos servirá para que el control de los mismos sea más efectivo y más sencillo de llevar sin tanto papeleo.
Al tiempo de automatizar realizaremos un ahorro de papel significativo en estas áreas de relaciones jurídicas.
Porque se realizará un cambio total de papeleo a electrónico será significativo en estas áreas.
Los oficios de contestación se tendrán en tiempo y forma para evitar sanciones jurídicas.
Se disminuirá la perdida de documentos jurídicos.
DEBILIDADES Reingeniería de procesos en
área de asuntos jurídicos y recepción de documentos.
Al definir procesos y procedimientos de las áreas de asuntos jurídicos y recepción se podrá dar el seguimiento de cumplimiento de los mismos.
La disminución de tiempos será de la mano con esta reingeniería de procesos.
Implementar la mejora continúa en esta empresa Relaciones Jurídicas.
Seguir los procedimientos y promover el compromiso.
AMENAZAS Evitar la mala atención a servidores
públicos y seguir los procedimientos. Al automatizar los procedimientos se
evitara que los documentos se extravíen.
Con el seguimiento de procedimientos y con el seguir de su filosofía vigilando que esto se cumpla, se obtendrán más clientes.
Con la acción anterior se puede comenzar con obtener más credibilidad por parte de los usuarios.
Las sanciones ya serán casi nulas puesto que con la automatización se entregarán los documentos a tiempo.
107
4.2 Tabla de Diagnostico ( CAUSA, PROBLEMA, CONSECUENCIA)
CAUSA PROBLEMA EFECTO
Desconocimiento de los manuales por parte de personal nuevo.
No se siguen procedimientos existentes Retrazo en el turnado de documentación al área jurídica.
Desorden de documentación recibida por parte de recepción.
Manejo inadecuado de documentación obtenida en recepción.
Perdida de documentación en recepción.
Procesos no actualizados y por lo tanto inadecuados para la actualidad.
Procesos obsoletos de acuerdo a las necesidades actuales
No se sigue ningún proceso y por lo tanto no se tiene un control adecuado en las áreas de asuntos jurídicos y recepción.
Retrazo en los tiempos de respuesta de documentación.
Incumplimiento de una orden de un superior jerárquico.
Sanciones Administrativas en Relaciones Jurídicas.
Los procedimientos no definidos. Retrazo en la contestación de asuntos jurídicos.
Perdida de asuntos jurídicos ante un juzgado o tribunal.
Se tienen procedimientos definidos actualmente en recepción pero no se conocen.
Personal no capacitado en recepción. Al no tener los procedimientos actualizados y más aún no se conozcan el área no es funcional.
El procedimiento actual no esta bien definido en asuntos jurídicos.
Procedimiento no funcional para el área de relaciones jurídicas.
No se lleva un proceso adecuado para el área.
Figura 26 Tabla de Diagnostico
108
4.2.1 Diagrama Causa – Efecto
AREA: ASUNTOS JURIDICOS
PROBLEMA: PERDIDA DE ASUNTOS JURIDICOS ANTE UN JUZGADO O TRIBUNAL
Figura 27 Diagrama de causa - efecto de “Perdida de Asuntos Jurídicos ante un Juzgado o Tribunal.
109
AREA: ASUNTOS JURIDICOS
PROBLEMA: SANCIONES ADMINISTRATIVAS EN RELACIONES JURIDICAS
Figura 28 Diagrama de Sanciones Administrativas en Relaciones Jurídicas
110
4.3 Diagnostico de Situación Actual del Área Jurídica de la Empresa Relaciones Jurídicas
4.3.1 Tabla de Análisis Diagnostico del Mes de Noviembre 2008
No. CAUSA INCIDENCIA PORCENTAJE ACUMULADO
A Retrazo en contestación en Asuntos Jurídicos 80 29.74 29.74
B No se le da a conocer el procedimiento de área al personal
3 1.12 30.86
C Retrazo en turnado de documentación 80 29.74 60.59
D Falta de Interés por parte de el personal administrativo
5 1.86 62.45
E No se hace lo que esta documentado 5 1.86 64.31
F Manejo inadecuado del asunto jurídico 20 7.43 71.75
G Desconocimiento de los manuales por parte de personal nuevo.
1 0.37 72.12
H Desorden de documentación recibida por parte de recepción.
70 26.02 98.14
I Extravío de documentación
5 1.86 100.00
TOTAL 269 100.00
Personal Total 9
Recepción 4
Jurídico 5
Total de asuntos x mes 120
X Día 6
Figura 29 Tabla de Análisis Diagnostico del Mes de Noviembre del 2008 en Asuntos Jurídicos.
111
4.3.2 Tabla de Análisis Diagnostico
No. CAUSA INCIDENCIA PORCENTAJE ACUMULADO
A Retrazo en contestación en Asuntos Jurídicos 80 29.74% 29.74%
C Retrazo en turnado de documentación 80 29.74% 59.48%
H Desorden de documentación recibida por parte de recepción.
70 26.02% 85.50%
F Manejo inadecuado del asunto jurídico 20 7.43% 92.94%
D Falta de Interés por parte de el personal administrativo 5 1.86% 94.80%
E No se hace lo que esta documentado 5 1.86% 96.65%
I Extravío de documentación
5 1.86% 98.51%
B No se le da a conocer el procedimiento de área al personal 3 1.12% 99.63%
G Desconocimiento de los manuales por parte de personal nuevo.
1 0.37% 100.00%
TOTAL 269 100.00%
Figura 30 Tabla de Análisis Diagnostico
112
4.3.3 Diagrama de PARETO
Figura 31 Diagrama Pareto
113
4.4 Resultados de Situación Actual
En la grafica de Pareto, se puede observar con mejor claridad el porcentaje que ocupan las
causas y los efectos de la problemática detectada en las áreas de recepción y asuntos jurídicos. El
80% de los problemas son provocados por causas triviales que representan un 20%. El 20% de las
causas fundamentales ocasionan un 80% de todos los problemas de la empresa Relaciones
Jurídicas, por lo tanto con estos resultados debemos de trabajar con los principales problemas que
son:
A - Retrazo en contestación de Asuntos Jurídicos
C - Retrazo en turnado de documentación
H - Desorden de documentación recibida por parte de recepción
Estas son nuestras causas fundamentales y ocasionan el 80% de los problemas, mientras
que F, D, E, I, B, G nos representan nuestras causas triviales las cuales representan el 20% de la
problemática. Teniendo resueltos estos principales problemas habremos atacado el 80% de
nuestros problemas con tan solo el 20 % resuelto. Comparándolo con los resultados de la MEFE
y la MEFI, nos podemos dar cuenta de que si coinciden muy bien, ahora con la ventaja de la
MEFI, podemos empezar a desarrollar la reingeniería de procesos, sabiendo de antemano que no
existirá una resistencia al cambio que nos dificulte la realización de la reingeniería de los procesos
y la automatización posteriormente. Aprovechando las fortalezas nos dan cavidad a minimizar las
debilidades, sin problema de ninguna índole y más aún como otra de las ventajas es que este
proceso no involucra a muchas personas, lo que nos lleva a ser una ventaja más para nuestro
trabajo. En el siguiente capítulo se desarrollara el nuevo proceso que nos ayudara a agilizar los
documentos de la empresa Relaciones Jurídicas sin tener que alterar a los cuatro que involucran
esta acción ya que no podemos cambiar estos por políticas de la empresa, entonces solo se
desarrollara el proceso que nos causa la problemática principal, que sería nuestro 20% detectado
por nuestro Pareto, el cual nos llevara a resolver el 80% de los problemas en Asuntos Jurídicos de
los principales que son:
Procesos obsoletos.
Manejo inadecuado de la documentación.
Retraso en tiempo de respuesta en contestación de documentos.
Tiempos muertos por parte de los administrativos.
Mala atención al público por parte de la dirección de relaciones jurídicas.
Malos manejos de asuntos jurídicos
.
114
4.5 CONCLUSIÓN
En este capítulo nos podemos dar cuenta de una forma ya más real de la situación la cual
pasa la empresa Relaciones Jurídicas, nosotros atacaremos el problema para disminuirlo, que
como nos podemos dar cuenta no son los procesos en sí, de lo contrario en cada uno de estos
cuatro procesos pude observar cómo se sigue una constante en estos cuatro procesos que son el
de nulidad, de amparo, reclamaciones y quejas, en estos procesos se sigue un patrón muy
destacado el cual es un subproceso que es el de contestación de oficios, este subproceso se lleva
a cabo en todos y cada uno de estos procesos pero el cual no está registrado y por lo tanto no es
tomado en cuenta, pero es el que está afectando a el área de asuntos jurídicos de tal manera, que
por esta causa, se llegan a perder casos en juicios ante un tribunal o juzgado, este subproceso
es el que rescatare el cual posteriormente procederé a rediseñar y adecuar a lo que se necesita
en asuntos jurídicos y lo desarrollare en el capitulo siguiente.
115
Capítulo V Desarrollo de la Reingeniería de Proceso
5.1 Reingeniería del proceso
Para la reingeniería de procesos nos basaremos en la información analizada en el
capitulo anterior, empezaremos a realizar la reingeniería de procesos y los cambios necesarios
para el buen funcionamiento de nuestra área Asuntos Jurídicos.
Utilizando las herramientas adecuadas y los pasos de la reingeniería de procesos,
daremos el inicio a la reingeniería de procesos en el Área de Asuntos Jurídicos en los procesos
de Juicios de Amparo, Juicios de Nulidad, Reclamaciones y Quejas así como en el de Asuntos
Jurídicos.
El siguiente diagrama nos representa lo que se esta haciendo actualmente en el área de
relaciones jurídicas, estas actividades actualmente no siguen el procedimiento que se debería de
llevar a cabo porque en el área de Asuntos Jurídicos no se capacito al personal con los
procedimientos y no solo eso ahora en la actualidad ya los mismos procesos ya no son factibles
para el área ya que las actividades han cambiado y ahora ni el proceso es el adecuado y no es
adecuado porque no contempla lo actual por tal motivo se llego a la conclusión de hacer una
reingeniería de procesos en el área afectada.
Representaremos lo actual y posteriormente les mostraremos con base a lo arrojado en
nuestro análisis y nos enfocaremos al rediseño del proceso y los planes a seguir para su
desarrollo y su buen funcionamiento es decir las propuestas de que hacer para que el proceso
funcione correctamente para lo cual necesitaremos plantear como se tendrá que dar el
seguimiento y como se deberá de aplicar en nuestra área en especifico.
Este diagrama lo desarrollamos con la información que nos proporciono el Director
General de Asuntos Jurídicos, quien nos ha proporcionado las facilidades para la información y el
rediseño del mismo ya que sus necesidades son ahora muy específicas y pues el no cuenta con el
conocimiento del tema ni sabe cuales son las herramientas necesarias para su elaboración por ello
nosotros hemos decidido atacar este problema dándole la mejor solución.
116
5.1.1 Proceso actual del Área de Asuntos Jurídicos
Actualmente se realizan estas tareas dentro del área de Relaciones Jurídicas.83
Figura 32 Proceso actual del área Asuntos Jurídicos
83
Proceso realizado con la información proporcionada por el Director de Asuntos Jurídicos.
117
5.1.2 Representación de Análisis de Procesos en Asuntos Jurídicos
Se realizaron los procesos de Juicios de Amparo, Juicios de Nulidad, Reclamaciones y
Quejas, que nos describieron en la empresa Relaciones Jurídicas de los cuales después del
análisis realizado nos pudimos dar cuenta de que no era necesario rehacer a todos y cada uno de
ellos sino que en el análisis en los cuatro involucra una contestación de oficios del cual se deriva
el problema en los documentos asignados y nos genera los problemas más grandes que existen en
asuntos jurídicos en cuanto a la contestación de oficios.
Figura 33 Representación de análisis de los procesos
118
5.2 Mapeo de Procesos
Objetivo
Introducir la importancia que tiene, en ISO-9001:2000, el mapeo de procesos y la
elaboración de diagramas de flujo, para Mejorar la rentabilidad dentro del Sistema de Gestión de
la Calidad. Con el apego a esta metodología nos guiaremos para el rediseño de nuestro proceso
de contestación de oficios.
Principios de Gestión de la Calidad.
Enfoque al cliente
Liderazgo
Participación del personal
Enfoque basado en procesos
Enfoque de Sistemas para la Gestión
Mejora continua
Enfoque basado en hechos para la Toma de Decisiones
Principio 1- Enfoque al cliente
Las organizaciones dependen de sus clientes y por consiguiente deben comprender sus
necesidades actuales y futuras, cumplir con sus requisitos y esforzarse para exceder sus
expectativas.
Por tal motivo se desarrollara el rediseño del proceso que considero con base a los
resultados arrojados en nuestro análisis se cumplirá con las necesidades actuales de todos los
usuarios y clientes.
Principio 2- Liderazgo
Los líderes establecen unidad de propósito y dirección en una organización. Ellos deben
crear y mantener el clima interno en el cual las personas puedan sentirse totalmente involucradas
con el logro de los objetivos organizacionales. Este principio se cumplirá con la automatización del
proceso en el cual se tiene muy involucrado al personal el cual participara de manera directa en el
proceso y seguimiento de documentos.
119
Principio 3- Involucramiento del Personal
El personal, en todos sus niveles, es la esencia de la organización y su total
involucramiento posibilita el uso de sus habilidades en beneficio de la organización. Involucraremos
al personal, para que sea parte del cambio y ellos al mismo tiempo no se opondrán ni se resistirán
a este cambio el cual no será tajante sino al contrario se adaptaran sin problema por las bondades
que nos ofrece el sistema que se realizará.
Principio 4- Enfoque de Procesos
El resultado deseado es alcanzado con mayor eficiencia gestionando los recursos y
actividades relacionadas como un proceso.
Documentos Proceso de información Contestación de Oficios
Figura 34 Representación del proceso de Asuntos Jurídicos “Contestación de oficios”
Proceso: ―Cualquier actividad o conjunto de actividades que utiliza recursos para
transformar entradas en salidas‖.
Figura 35 Diagrama de Bloques del proceso “contestación de oficios” de Asuntos Jurídicos
120
Principio 5- Gestión a través de Sistemas
Identificar, comprender y gestionar un sistema de procesos interrelacionados para un
objetivo dado mejora la eficacia y la eficiencia de una organización en el logro de sus objetivos.
Principio 6- Mejora Continua
Figura 36 Cuadro de indicadores para Asuntos Jurídicos.
Sistema de Indicadores de Desempeño
AREA: Asuntos Jurídicos
Indicador Descripción Fórmula Unidad Periodicidad
Sanciones
administrati
vas.
% de sanciones
aplicadas en el mes
no. de sanciones en el
mes * 100 / no. total
de documentos
asignados.
%
Sanciones
administra
tivas
Mensual
Tiempo de
respuesta
en los
oficios
Tiempo en el que se
tarda en dar una
respuesta de los
oficios en el mes.
Promedio de tiempo
que transcurre entre la
hora de llegada y la
hora de la valoración
inicial de todos los
oficios que llegan con
la secretaria / Total de
oficios atendidos en
Asuntos Jurídicos, en
el mes
#
Absolutos Mensual
Eficiencia
del área
% oficios fuera de
plazo de tiempo de
entrega
Número de casos
perdidos en mes
actual / Número de
casos del mes
anterior * 100
% de
eficiencia Mensual
121
Principio 7- Toma de Decisiones Basada en Hechos
Las decisiones efectivas están basadas en el análisis de datos e información
obtenido en el levantamiento de información.
5.3 Diseño de la propuesta para reingeniería de procesos
5.3.1 Propuesta
Objetivo General
Obtención de procesos que cumplan con las necesidades actuales del área de Asuntos
Jurídicos, los cuales nos disminuyan el tiempo de contestación de oficios y las sanciones
administrativas por parte de un juez o tribunal.
Objetivos Específicos
Disminuir la perdida de Asuntos Jurídicos ante un tribunal o juzgado.
Disminuir las Sanciones Administrativas
Aumentar la asertividad del Proceso
Mejorar la sincronización del área de Asuntos Jurídicos
Optimizar los tiempos de entrega de documentos
Evitar perder casos por falta del documento.
Evitar reprocesos de administración (devoluciones y rechazos).
Beneficios:
Control de acciones y procedimientos.
Efectividad de procesos
Ahorro de papel
Documentos Electrónicos
Contestación en tiempo y forma
Disminución en sanciones jurídicas.
Disminución de pérdida de documentos.
122
5.3.2 Proceso Rediseñado del Área de Asuntos Jurídicos
Figura 37 Proceso Rediseñado del Área De Asuntos Jurídicos “Contestación de Oficios”
123
5.3.3 Recomendaciones para llevar a cabo la reingeniería de procesos
Para llevar a cabo una buena reingeniería se sugieren las siguientes recomendaciones las
cuales pude detectar que nos ayudaría a alcanzar el éxito en esta reingeniería del proceso
Contestación de oficios.
Con el fin de optimizar la gestión para el proceso, un sistema de indicadores el cual será
definido en función de las prioridades que la empresa otorgue se recomienda que, todos los
procesos identificados serian evaluados en términos de eficiencia, rendimiento, eficacia,
adaptabilidad, operatividad, capacidad, fiabilidad u cualquier otra magnitud que nos permitiese
proporcionarle una calificación objetiva a dichos proceso.
Se sugiere además, la participación por parte de todo el equipo que representa a la
organización, tanto personal directivos como personal técnico u operativo, y no estar centrado el
mando y con el seguimiento por parte de un líder correspondiente; es importante apoyar a estas
personas para facilitar su labor y facilitarles la preparación e información necesaria para que
comprenda la consecuencia de su actividad en la consecución de los objetivos estratégicos de la
empresa.
Con el desarrollo de los procesos básicos, es indispensable emplear una plataforma Web,
ya que la información estará a la disposición en cualquier área del instituto lo cual facilitara su
intercambio y los usuarios podrán utilizarla en cualquier momento.
La necesidad de desarrollar manuales, estudios y un plan de acción o estratégico orientado
a consolidar y ubicar en su justo lugar, el importante papel que tienen estos procesos en cualquier
esfuerzo de cooperación en la empresa ―Relaciones Jurídicas‖.
5.4 Reciclaje
Desarrollaremos un procedimiento de reciclaje contribuyendo a la sustentabilidad que es
nuestro tema base de este seminario, lo cual nos ayudara a poner un granito de arena al cuidado
de nuestro ambiente que pide ayuda a gritos y nosotros somos los únicos que podemos hacer algo
al respecto.
124
5.4.1 Objetivo
Crear conciencia al personal de la empresa ―Relaciones Jurídicas‖ para contribuir al
cuidado del medio ambiente y ser una empresa sustentable.
5.4.2 Alcance
En todas las áreas de la empresa ―Relaciones Jurídicas‖.
5.4.3 Terminología y definiciones
Reciclaje: Es la actividad de recolectar y clasificar materiales que son considerados como
desechos, con el objeto que puedan ser reprocesados por la industria y vuelvan a entrar en la
corriente del consumo. Esto reduce la cantidad de materiales vírgenes requeridos para la
manufactura.
Ambiente: Entorno que afecta y condiciona especialmente las circunstancias de vida de
las personas o la sociedad en su conjunto. Comprende el conjunto de valores naturales, sociales y
culturales existentes en un lugar y un momento determinado, que influyen en la vida del ser
humano y en las generaciones venideras. Es decir, no se trata sólo del espacio en el que se
desarrolla la vida sino que también abarca seres vivos, objetos, agua, suelo, aire y las relaciones
entre ellos, así como elementos tan intangibles como la cultura.
Sustentabilidad: La capacidad de una sociedad humana de apoyar en su medio ambiente
el mejoramiento continuo de la calidad de vida de sus miembros para el largo plazo; las
sustentabilidades de una sociedad es en función del manejo que ella haga de sus recursos
naturales y puede ser mejorada indefinidamente.
Satisfacer las necesidades del presente sin comprometer la capacidad de las futuras
generaciones de satisfacer sus necesidades, esto es la definición de Brundtland sobre desarrollo
sustentable.
125
5.4.4 Responsabilidades
5.4.4.1 Dirección
Dirigir a los miembros del equipo responsable para el buen funcionamiento de la tarea
asignada.
Implantar en su personal la sensibilidad del cuidado del medio ambiente.
5.4.4.2 Miembros que ejecutan las acciones
Solicitar los recursos necesarios
Informar sobre cualquier incidencia
Aportar soluciones inmediatas
Realizar el trabajo en equipo
5.4.4.3 Calidad
Supervisión de que las acciones se lleven a cabo
Registrar los avances obtenidos
5.4.5 Descripción del procedimiento
5.4.5.1 Colocación de contenedores de reciclaje en todas las áreas.
Se colocaran los contenedores en cada una de las áreas, uno de rehusó de hojas y otro
de hojas para proceso de reciclaje.
Paso 1
Cada área se encargará de colocar las hojas en su respectivo contenedor, de rehusó; que
son las que podemos utilizar por el otro lado.
Paso 2
Cuando las hojas ya se hayan utilizado por ambos lados, se colocaran en el contenedor de
proceso de reciclado; que son las hojas que ya no se ocuparan pero que ya utilizaron de ambos
lados.
126
Paso 3
Se trasladaran las hojas de proceso a un depósito previamente establecido para almacenar
este papel. El traslado lo pueden hacer las mismas personas de intendencia cuando recogen la
basura de los cubículos, solo que ahora ya no lo revolverán, si no que en otra bolsa se colocara,
únicamente el papel y este se llevará a su depósito.
Paso 4
Se asignará un lugar que funja como depósito para el almacenaje del papel, en el que
únicamente se dejara el papel en almacenaje para la espera de su traslado por la ―empresa X‖
encargada del reciclaje del papel.
5.4.5.2 Referencias
En esta tesina no desarrollare los documentos que se llevarán por falta de tiempo.
5.4.5.3 Anexos y registros
Documento Tiempo de archivo Responsable
5.4.6 Análisis costo beneficio
RECICLADO DE PAPEL
SE VENDE
Se generan aproximadamente en 1 día 100 KG. $ 120.00
En un mes 3000 KG. $ 3600.00
En un año 36000 KG $ 43,200.00
La empresa GENOVA S.A. de C.V. es quien vendría a recoger el desperdicio de papel cada
mes.
Siguiendo la técnica de calidad, "hacer más con los mismos recursos."
127
Como podemos ver en este cuadro, no solo ayudamos al ambiente, sino que también tal
vez sea poco pero obtendremos una pequeña remuneración por la separación del papel que
aproximadamente variara de 40,000 a 45,000 anuales, ahora si consideramos también el periódico
y el cartón será un monto más, no mucho pero unos diez mil más se le sumaria al año.
Ahora viéndolo desde la otra perspectiva, contribuyendo con el cuidado del medio
ambiente será una empresa sustentable y podrá manejarse como tal, ya que nuestra
contribución en el reciclaje del papel ayuda en mucho a nuestra ecología, de este modo serán
menos los árboles que se utilizarán para el papel ya que las empresas de reciclaje se encargaran
de procesarlo para volverlo a obtener como papel de uso.
5.4.7 Presentación del procedimiento
Por medio de estas presentaciones en diapositivas, nos ayudaremos para la explicación
de cómo se llevara a cabo este procedimiento de una manera muy simple, que paulatinamente
puede llevar a cabo esta área para la contemplación de sustentabilidad antes mencionada.(ver el
capitulo 2 en el punto 2.2.)
128
129
5.5 CONCLUSIÓN
Con la reingeniería de procesos la empresa ahora puede llevar a cabo su trabajo en una
forma ordenada y simplificada la cual como beneficio es la disminución de demandas por falta de
oficios.
También con esta reingeniería del proceso de la contestación de oficios, la empresa
―Relaciones Jurídicas‖ se pudo dar cuenta de que sus procesos no eran el problema exactamente
si no que existía un subproceso el cual nadie tomo en cuenta y pues con este análisis salió a flote
y es el que obtuvimos y lo representamos en diagrama para posteriormente rediseñarlo y
adecuarlo a las necesidades actuales de Asuntos Jurídicos, ahora la empresa puede disfrutar de
los beneficios de este rediseño y solo ocuparse de los problemas que surjan de otro tipo de
actividades, por ello es que yo como ingeniera industrial recomiendo la automatización de este
proceso para que funcione de tal forma que sea sencillo y entendible para todos pero con un
resultado de rapidez en la contestación de oficios, para esto se llevara a cabo una automatización
de proceso de contestación de oficios, la cual nos dará paso a la sustentabilidad ya que se
obtendrá un ahorro de papel de manera tal que la empresa no solo ahorrara sino que contribuirá a
el ahorro del papel con tan solo la aplicación de este proceso ya automatizado y no solo eso como
aportación realice el proceso de reciclaje para toda la empresa ―Relaciones Jurídicas‖.
En el siguiente capítulo lo veremos de manera más detallada y daremos por terminada
nuestra propuesta de proyecto para la empresa ―Relaciones Jurídicas.‖
130
Capítulo VI Propuesta de Automatización de procesos
6.1 Identificación de servicios a automatizar
De acuerdo con la información levantada y analizada, los servicios detectados en el área
de jurídico fueron los siguientes:
Puesto Servicio
Secretaria, Director Asignar abogado
Secretaria, Director Desasignación de abogado
Notificador Alta de Notificación de oficios
Notificador Baja de Notificación de oficios
Notificador Modificación de Notificación de oficios
Notificador Consulta de Notificación de oficios
Notificador Reporte de Notificación de oficios
Secretaria
Alta de documentos recibidos y expediente
digitalizados
Secretaria
Modificación de documentos recibidos y
expediente digitalizados
Secretaria
Baja de documentos recibidos y expediente
digitalizados
Secretaria, Abogado,
Director
Consulta de documentos recibidos y expediente
digitalizados
Abogado Generación de oficios de Reclamaciones
Abogado, Director Modificación de oficios de Reclamaciones
Abogado Baja de oficios de Reclamaciones
Abogado Consulta de oficios de Reclamaciones
Director
Revisión y autorización de oficios de
Reclamaciones
Abogado Generación de oficios de Quejas
Abogado, Director Modificación de oficios de Quejas
Abogado Baja de oficios de Quejas
Abogado Consulta de oficios de Quejas
Director Revisión y autorización de oficios de Quejas
Abogado Generación de oficios Juicios de Nulidad
Abogado, Director Modificación de oficios de Juicios de Nulidad
131
Abogado Baja de oficios de Juicios de Nulidad
Abogado Consulta de oficios de Juicios de Nulidad
Director
Revisión y autorización de oficios de Juicios de
Nulidad
Abogado Generación de oficios Juicios de amparo
Abogado, Director Modificación de oficios de Juicios de amparo
Abogado Baja de oficios de Juicios de amparo
Abogado Consulta de oficios de Juicios de amparo
Director
Revisión y autorización de oficios de Juicios de
amparo
Abogado, Director
Impresión de oficios para todos los tipos de
asuntos
Director, Secretaria Consulta de asuntos abiertos
Director, Secretaria Reporte de asuntos abiertos
Director, Secretaria Consulta de totales por tipo de asunto
Director, Secretaria Reporte totales por tipo de asunto
Director, Secretaria Consulta de totales por estatus de oficio
Director, Secretaria Reporte totales por estatus de oficio
Director, Secretaria Consulta desglosado por estatus de oficio
Director, Secretaria Reporte desglosado por estatus de oficio
Director, Secretaria Consulta de Totales por estatus de proceso
Director, Secretaria Reporte totales por estatus de proceso
Director, Secretaria Consulta Desglosado por estatus de proceso
Director, Secretaria Reporte Desglosado por estatus de proceso
Director, Secretaria Consulta de actividades.
Director, Secretaria Reporte de actividades.
Director, Secretaria Consulta Para carga de página de Internet SIS
Director, Secretaria Reporte Para carga de página de Internet SIS
Director, Secretaria Consulta de Turno de abogados
Director, Secretaria Reporte de Turno de abogados
Director, Secretaria Consulta de notificaciones de oficio
Director, Secretaria Reporte de notificaciones de oficio
Director, Secretaria
Consulta de Monto por multas y
participaciones
Director, Secretaria Reporte de Monto por multas y participaciones
Director, Secretaria Consulta de Amparos de habilidad y destreza y
132
de amparos sobreseídos.
Director, Secretaria
Reporte de Amparos de habilidad y destreza y de
amparos sobreseídos.
Director, Secretaria Consulta de fianzas
Director, Secretaria Reporte de fianzas
Director, Secretaria Consulta de disponibilidad de Abogado
Notificador Alta de carátula de expediente
Notificador Baja de carátula de expediente
Notificador Modificación de carátula de expediente
Notificador Impresión de carátula de expediente
Director, Secretaria,
Abogado
Consulta de asuntos vencidos y próximos a
vencer
Abogado Consulta de datos de permisionario en archivo
Director, Secretaria Alta de catálogo de Abogados
Director, Secretaria Baja de catálogo de Abogados
Director, Secretaria Modificación de catálogo de Abogados
Director, Secretaria Alta de catálogo de estatus de oficio
Director, Secretaria Baja de catálogo de estatus de oficio
Director, Secretaria Modificación de estatus de oficio
Director, Secretaria Alta de catálogo de afianzadora
Director, Secretaria Baja de catálogo de afianzadora
Director, Secretaria Modificación de afianzadora
Director, Secretaria Alta de catálogo de salas
Director, Secretaria Baja de catálogo de salas
Director, Secretaria Modificación de salas
Director, Secretaria Alta de catálogo de subdirecciones
Director, Secretaria Baja de catálogo de subdirecciones
Director, Secretaria Modificación de subdirecciones
Director, Secretaria Alta de catálogo de plantillas de oficio
Director, Secretaria Baja de catálogo de plantillas de oficio
Director, Secretaria Modificación de plantillas de oficio
Figura 38 Tabla de servicios
133
6.2 Etapa de Inicio
6.2.1 Definición de alcance de automatización
Alcance de proyecto
Introducción
La empresa de ―Relaciones Jurídicas‖ dentro de las diversas actividades se encuentra la
contestación y seguimiento de asuntos jurídicos. La construcción de un sistema de información
apoyará y automatizará los asuntos que se manejan en el área de jurídico.
Objetivos de Proyecto
Objetivo General
Generar una herramienta tecnológica que ayude a agilizar el flujo de información del área
de asuntos jurídicos así mismo permita acceder a su información fácilmente con la seguridad
correspondiente.
Objetivos Específicos
Agilizar procesos críticos.
Mejorar control de la información.
Información Oportuna.
Acceso controlado a la información.
Generar una herramienta que permita reducir el consumo excesivo de papel.
Descripción del Alcance
1. Generación de un sistema de informático que administre la operación cotidiana de los
asuntos que maneja el área de jurídico en la empresa relaciones jurídicas.
Para este proyecto, queda fuera del alcance:
Los asuntos que por su naturaleza e información confidencial no pueden ser incluidos.
134
Involucrados en el proyecto
Organigrama del área
Figura 3984 Organigrama
Promotores
Puesto que desempeña
En el área
Responsabilidades
en el área
Director de asuntos Jurídicos
Revisar los Expedientes que ingresan a la
Subdirección.
Asignar prioridades a los Expedientes.
Asignar Expedientes a los abogados.
Autorizar los Expedientes.
Figura 40 Promotores del proyecto
Equipo del proyecto
Puesto que desempeña
En el área Área que representa
Líder de Proyecto UPIICSA
Ingeniero de procesos UPIICSA
Figura 41 Equipo del proyecto
84
Información obtenida a partir de reuniones con el usuario.
135
Usuarios finales
Puesto que
desempeña
En el área
Área que
representa
Responsabilidades
en el área
Secretaria Asuntos
Jurídicos
Captura y registro de datos.
Control de expedientes.
Generación de reportes
Director de
asuntos
Jurídicos
Asuntos
Jurídicos
Revisar los Expedientes que ingresan a la
Subdirección.
Priorizar los Expedientes.
Asignar Expedientes a los abogados.
Autorizar los Expedientes.
Abogado Asuntos
Jurídicos Contestación de asuntos.
Notificador Asuntos
Jurídicos Envío de notificación de resoluciones de oficio.
Figura 42 Usuarios Finales
Estándares Aplicables
Para el desarrollo de este sistema, se utilizarán los estándares definidos por la empresa
Relaciones Jurídicas
Desarrollo de Aplicaciones y Sitios
o Estándares de Desarrollo para Sistemas de Información y Sitios de Internet.doc
o Estándares de Programacion.doc
Diseño de Base de Datos
o Estándares de Diseño de BD.doc
Diseño Gráfico
o Estándares de Diseño Grafico.doc
Metodología de Desarrollo de Aplicaciones
136
Límites del Proyecto
La duración de este proyecto estará sujeta a la duración del seminario de la sociedad del
conocimiento.
Factores clave de éxito:
Cooperación constante de los usuarios finales.
Revisiones constantes por parte del equipo de desarrollo.
Supuestos y dependencias
Se asume que:
Se contará con la participación de los involucrados en el proyecto por parte de Relaciones
Jurídicas.
Para la atención de cualquier solicitud de servicio se requiere de la autorización del Director
de Asuntos Jurídicos.
Riesgos identificados
La rotación de los directivos puede afectar e incidir en adecuaciones al alcance inicial del
proyecto.
Control de cambios
Si a lo largo del desarrollo del proyecto surgen modificaciones, estas se registraran en el
documento de Control de Cambios y deberán de ser evaluadas por el director de asuntos jurídicos
y por el equipo de desarrollo. Si los cambios impactan de manera importante al proyecto, estos se
consideraran como requerimientos nuevos y se reorganizaran prioridades.
137
6.3 Elaboración
6.3.1 Especificación de requerimientos
Introducción
La especificación de requerimientos describe de forma detallada cada uno de los
requerimientos del usuario o promotor del proyecto e incluye las necesidades del sistema que no
se describen en los casos de uso tales como:
Las necesidades de reglamentación, incluyendo las normas de aplicación.
Los atributos de calidad necesarios para la construcción del sistema, incluyendo utilidad,
confiabilidad, desempeño y requisitos de soporte.
Otras necesidades tales como sistemas operativos y ambientes, requisitos de
compatibilidad y limitaciones del diseño.)
Objetivos de Proyecto
Generar una herramienta tecnológica que ayude a agilizar el flujo de información del área
Jurídica, y a su vez permita reducir el consumo de papel en la contestación de asuntos jurídicos.
Reporte de Investigación Preliminar (Situación Actual)
Actualmente el área Jurídica registra los expedientes mediante el uso de archivos de
Excel, en este archivo de Excel se mantiene el histórico, clasificación y estatus en el que se
encuentran cada uno de los oficios.
La forma de trabajo actual, no permite responder de manera fácil y rápida a las solicitudes
de reportes estadísticos de proceso retrazando la operación. Por otro lado el consumo del papel
que se tiene durante la contestación de los asuntos es muy elevado debido a que por cada asunto
durante el proceso se imprime en promedio 5 veces antes de la versión final.
Visión
El sistema ―SISJUR‖ (Sistema de Relaciones Jurídicas), manejará y administrará los
expedientes que genere el área jurídica.
Al sistema se podrá tener acceso desde cualquier equipo que se encuentre dentro de la
138
intranet de la empresa Relaciones Jurídicas siempre y cuando esta tenga conexión a Intranet así
como explorador Web.
Funcionalidad
Las funciones que manejará y administrará comprenden desde que un expediente es
remitido por recepción de documentos hasta su Notificación.
Actores del Sistema
Actor Cargo Descripción
Director de asuntos Jurídicos Director de asuntos
Jurídicos
Revisar, asignar prioridades, abogado y
autorizar
Abogado Abogado Integrar expediente, preparar proyecto
de contestación.
Notificador Notificador Notificar la resolución de oficio.
Secretaria Secretaria del director
Capturar información del expediente,
Asignar abogado, Descargar folios,
desahogar oficios.
Figura 43 Actores del sistema
Requisitos funcionales
No.
Requerimiento Requerimiento Notas
1.
El sistema permite iniciar expediente (captura de
datos en el sistema y asociación de documento
PDF).
2.
El sistema permite liberar el asunto a la siguiente
etapa una vez que se han guardado los datos
requeridos.
3. El sistema permite revisar información capturada
así como el tipo de proyecto.
4. El sistema permite al director asignar prioridades
para la atención así como días máximos de
139
No.
Requerimiento Requerimiento Notas
atención.
5. El sistema permite al director asigna abogado.
6. El sistema permite al director libera el proyecto a
la siguiente etapa.
7. El sistema permite al abogado analizar la
información.
8.
El sistema permite al abogado revisar prioridad
del asunto, Fecha en que llegó y fecha en la que
hay que dar respuesta.
9.
El sistema permite al abogado se autogenera la
orden de atención en el sistema y selecciona la
plantilla de contestación.
10.
El sistema permite al abogado preparar proyecto
para revisión del director llenando la plantilla
seleccionada, tomando como base el expediente
en PDF asociado desde la captura de los datos.
El abogado podrá agregar observaciones en la
contestación.
11.
El sistema permite guardar el documento con el
botón guardar del sistema una vez que termine el
documento.
12. El sistema permite al abogado liberar el proyecto
a la siguiente etapa.
13.
El sistema permite al director recibir proyecto
liberado por parte de abogado para su revisión.
La revisión se hace en la plantilla sobre la cual se
contesto el proyecto y con el documento PDF
asociado.
14. El sistema permite al abogado liberar el proyecto
a la siguiente etapa.
15.
El sistema permite al abogado recibir Proyecto del
Director para correcciones o para asignar número
de oficio de contestación.
16. El sistema permite Imprimir proyecto.
17. El sistema permite liberar el proyecto a la
140
No.
Requerimiento Requerimiento Notas
siguiente etapa.
18.
El sistema permite regresar el proyecto al
abogado si el director no da su autorización final.
De lo contrario la secretaria recibe el proyecto
19. El sistema permite liberar el proyecto a la
siguiente etapa.
20. El sistema permite descargar folios y desahogar
oficios
21.
El sistema permite al Notificador, capturar el
número de guía del correo, notas de la
notificación, acuse de recibo de notificación.
22. El sistema permite al Notificador marcar como
notificado el oficio. Fin de proceso
23. El sistema permite al director auto asignar un
expediente.
24.
El sistema permite modificar al abogado asignado
a un expediente en cualquier momento por el
director.
25.
El sistema para cada reasignación de abogado,
registrará una bitácora de movimientos con los
siguientes datos: Abogado actual, Abogado nuevo
status de proceso, status del oficio, fecha de
reasignación, Motivo.
26. El sistema notificará a los usuarios cada vez que
tenga un pendiente en su bandeja de entrada.
27. El sistema permite generar reportes de monitoreo
de expedientes
28. El sistema permitirá asignar permisos temporales
de director a los abogados.
29. Todos los catálogos tendrán su módulo de altas,
bajas y cambios.
30. En cada inicio de etapa de proceso se registrará
el acuse de recepción del oficio.
31. El sistema contará con un catálogo de Plantillas
de contestación con altas, bajas y cambios.
141
No.
Requerimiento Requerimiento Notas
32. El sistema permitirá generar reportes solo al
director y a la secretaria del director.
33. El sistema contará con un motor de búsqueda de
oficios.
Figura 44 Requisitos funcionales
Requisitos no funcionales
El sistema será baja tecnologías WEB
Acceso a la intranet.
Servidor WEB, Internet Information Services 6.0
Base de datos SQL 2005
Programación WEB: C#, ASP.NET, AJAX, HTML, Framework 3.0, Patrones de
diseño, ―Enterprise Application Blocks‖, la mas reciente, Enterprise Library.
Sistema Operativo Servidor: Windows 2003 Server
Explorador de Internet de Windows versión 6.0 en adelante o compatible.
Utilidad
Manejo de oficios y explotación de información
La explotación de la información es una de las utilidades más importantes del sistema,
permitiendo al usuario tener acceso a la información en todo momento y conocer el estatus de
algún procedimiento así como generación de reportes estadísticos de una manera ágil.
Confiabilidad
Seguridad de información: La seguridad de información será manejada por métodos de
encriptación de campos de tablas (los más importantes).
Requerimientos de desempeño
No existen requerimientos de desempeño.
142
Requerimientos de seguridad
El acceso al sistema se controlará mediante creación de usuarios con password y perfiles,
dichos perfiles tendrán acceso solo a opciones específicas del sistema.
Capacidad de soporte
Modelo de programación
El sistema se desarrollará a con base en una ―Web Client Software Factory‖, Patrones de
diseño y ―Enterprise Application Blocks‖.
Reusabilidad.
Debido al uso de patrones de diseño, desarrollo de librerías y controles, el código
generado, es altamente reutilizable, para futuras modificaciones o evoluciones del sistema.
Limitaciones de diseño
Limitación de diseño con base a navegadores Web.
El sistema deberá visualizarse en Internet Explorer 6 o superior, Mozilla Firefox 2.0 o
superior.
Documentación de usuario y ayuda en línea
No aplica para esta primera etapa.
Interfaces de usuario
Herramienta de navegación Web
Interfaces de hardware
Comunicación entre servidor de la aplicación Web y el equipo de Base de datos.
143
Interfaces de software
Instalación y registro de OCX ―dsoframer.ocx‖.
Adobe Reader 6.0 ó superior.
Interfaces de comunicación
Comunicación entre redes:
Donde residirá el servidor WEB.
Donde se ubica la PC del usuario
Requerimientos de licencias
SQL Server 2005 Enterprise Edition.
Avisos legales, derechos de autor y otros
No Aplica
Estándares aplicables
No Aplica
Criterios de aceptación
Se elaboraran casos de prueba con base en la funcionalidad definida.
6.3.2 Desarrollo de casos de uso
6.3.2.1 Especificación de CU 01: Captura de Datos
Descripción
Una vez que la secretaria recibe los documentos; el sistema le permitirá la captura de
datos, asociar un documento en formato PDF para iniciar un expediente de los diferentes
conceptos o tipos de asuntos que se manejarán.
144
Contribución a los requerimientos
Este caso de uso satisface los requerimientos 1 y 2 detallados en la sección especificación
de requerimientos.
Actores
Actor Descripción
Secretaria
Recibe documentos.
Captura datos.
Imprime Carátula.
Preasigna Abogado.
Figura 45 Actores Captura de datos
Flujo de Eventos
Diagrama de Casos de Uso
Figura 46 Diagrama de caso de uso captura de datos
Flujo básico
Actor Acción que realiza el actor Acción que realiza el sistema
Secretaria
1. Una vez que la secretaria recibe
los documentos del expediente
inicia la captura.
2. El sistema carga la carátula de captura
correspondiente.
3. Captura los datos y asocia el
documento electrónico en PDF.
145
4. Guarda Datos
5. Almacena el documento en el servidor
y guarda la referencia del archivo así
como los datos capturados en la base
de datos.
6. Libera asunto a siguiente etapa. 7. Cambia de estatus de proceso el oficio.
8. Termina caso de uso.
Figura 47 Flujo Básico Captura de datos
Flujos alternos
No aplica
Requerimientos especiales
No aplica
Precondiciones
Ingresar al sistema y contar con los privilegios de captura de datos
Poscondiciones
El asunto pasara a la etapa de asignación de abogado y prioridades del director.
Excepciones
Excepción Acción
E01 Falta de campos obligatorios
1. El sistema mostrará en una ventana el mensaje
―Hay campos obligatorios no capturados, verifique
por favor‖, con botón ―aceptar‖.
2. El actor da clic en el botón ―Aceptar‖
3. El sistema cierra la ventana.
4. El sistema regresa el control a la pantalla anterior.
Figura 48 Excepciones Captura de datos
146
6.3.2.2 Especificación de CU 02: Asignación
Descripción
Después de la captura, el oficio se recibe en la etapa de asignación, en la cual se revisa la
información capturada, se asigna o confirma el abogado que va ha atender el asunto así como las
prioridades de atención.
Contribución a los requerimientos
Este caso de uso satisface los requerimientos 3, 4, 5 y 6 detallados en la sección
especificación de requerimientos.
Actores
Actor Descripción
Director
Revisa Información capturada.
Asigna prioridades y días máximos de
atención.
Asigna o confirma abogado.
Libera asunto a siguiente etapa.
Figura 49 Actores Asignación
Flujo de Eventos
Diagrama de Casos de Uso
Figura 50 Diagrama de caso de uso Asignación
147
Flujo básico
Actor Acción que realiza el actor Acción que realiza el sistema
Director
1. El caso de uso inicia cuando
termina el Caso de uso 01
Captura de Datos.
2. Muestra la lista pendientes de
atención.
3. Selecciona oficio a revisar.
4. Muestra una ventana de acuse de
recepción mostrando el usuario que
recibió el oficio y la fecha de recepción.
5. Carga información capturada
dependiendo de tipo de asunto del
oficio.
6. Revisa información capturada.
7. Asigna Abogado, prioridades,
datos complementarios y
observaciones.
8. Guarda información
9. Valida que se asigne un abogado <E01
Abogado no seleccionado >
10. Guarda datos capturados en la base de
datos.
11. Libera asunto a siguiente etapa. 12. Cambia de estatus de proceso el oficio.
13. Termina caso de uso.
Figura 51 Flujo básico Asignación
Flujos alternos
No aplica
Servicios
Lista de oficios capturados
Muestra la lista de oficios capturados por la secretaria que aun no han sido atendidos por
el Director para ser analizados y asignados,
148
Lista de oficios pendientes de revisión, análisis.
Es la lista de los oficios que ya fueron revisados por Director pero aun no han sido
liberados a la siguiente etapa.
Requerimientos especiales
No aplica
Precondiciones
Ingresar al sistema y contar con los privilegios de Director
Que el oficio sea previamente capturado.
Que el oficio sea previamente liberado de la etapa de captura.
Poscondiciones
El asunto liberado pasara a la etapa de contestación por parte de abogado.
Excepciones
Excepción Acción
E01 Abogado no seleccionado
1. El sistema mostrará en una ventana el mensaje
―Seleccione un abogado‖, con botón ―aceptar‖.
2. El actor da clic en el botón ―Aceptar‖
3. El sistema cierra la ventana.
4. El sistema regresa el control a la pantalla anterior.
Figura 52 Excepciones Asignación
Reglas de negocio
Características y reglas de negocio de los campos capturados en documento.
El Director se puede auto asignar un expediente.
Algunos campos se pueden modificar en cualquier momento por cualquier
abogado o el Director.
El abogado asignado a un expediente, puede ser modificado en cualquier
momento por el Director.
149
6.3.2.3 Especificación de CU 03: Contestación de oficio
Descripción
Una vez que un oficio es asignado a un abogado, este revisa la información capturada así
como el documento adjunto en PDF en la pantalla para posteriormente generar una orden de
atención en la cual selecciona la plantilla de contestación con la cual atenderá el oficio.
Contribución a los requerimientos
Este caso de uso satisface los requerimientos 7, 8, 9, 10, 11, 12, 13 y 14 detallados en la
sección especificación de requerimientos.
Actores
Actor Descripción
Abogado
Revisa Información capturada.
Genera Orden de atención y selecciona
plantilla.
Llena plantilla
Guarda información
Libera asunto a siguiente etapa.
Figura 53 Actores Contestación de Oficio
Flujo de Eventos
Diagrama de Casos de Uso
Figura 54 Diagrama de Caso de uso Contestación de Oficio
150
Flujo básico
Actor Acción que realiza el actor Acción que realiza el sistema
Abogado
1. El caso de uso inicia cuando
termina el Caso de uso 02
Asignación.
2. Muestra la lista de oficios nuevos
asignados, oficios pendientes de
contestar, oficios contestados
rechazados y Asuntos turnados como
responsable general.
3. Selecciona oficio a contestar de la
lista Asuntos turnados como
responsable general.
4. Muestra una ventana de acuse de
recepción mostrando el usuario que
recibió el oficio y la fecha de
recepción.
5. Carga información capturada
dependiendo de tipo de asunto del
oficio.
6. Revisa información capturada y
documento adjunto.
7. Crea instrucciones de atención y
selecciona la plantilla de
contestación
8. Cambia el oficio a la lista de oficios
pendientes de contestar.
9. Selecciona el oficio de la lista
Oficios nuevos asignados.
10. Llena la plantilla seleccionada.
11. Guarda documento y
observaciones con botón guardar
del sistema
12. Guarda el documento en el servidor,
la referencia del documento y
observaciones en la base de datos.
13. Libera asunto a siguiente etapa.
14. Cambia de estatus de proceso el
oficio.
15. Termina caso de uso.
Figura 55 Flujo Básico Contestación de Oficio
151
Flujos alternos
No aplica
Servicios
Oficios nuevos asignados
Es la lista de los oficios que ya fueron revisados por Director y asignados a un abogado
pero aun no ha revisados el abogado asignado.
Oficios pendientes de contestar
Son los oficios que tiene asignados un abogado que ya fueron revisados pero aun no son
contestados.
Oficios contestados
Son los oficios que fueron contestados por el abogado pero que aun no tienen la
autorización final y pueden ser rechazados.
Rechazados
Son los oficios cuya contestación fue rechazada por el Director
Requerimientos especiales
No aplica
Precondiciones
Ingresar al sistema y contar con los privilegios de abogado
Que el oficio sea previamente capturado.
Que el oficio sea previamente liberado de la etapa de captura.
Que el oficio sea previamente liberado de la etapa de asignación.
Poscondiciones
El asunto liberado pasará a la etapa de preautorización.
152
Excepciones
No aplica
Reglas de negocio
Las listas de oficios, solo mostrarán los oficios que le fueron asignados al abogado
Firmado en el sistema.
Un abogado no puede rechazar la asignación de un oficio.
Algunos campos se pueden modificar en cualquier momento por cualquier
abogado o el Director.
6.3.2.4 Especificación de CU 04: Autorización previa
Descripción
Una vez contestado el oficio, el Director, debe de revisar el oficio de contestación (Plantilla
de Word), para su preautorización o rechazo. Si es autorizado por el Director pasa a la siguiente
etapa de lo contrario es regresado a la bandeja de rechazados del abogado responsable.
Contribución a los requerimientos
Este caso de uso satisface los requerimientos 13 detallados en la sección especificación
de requerimientos.
Actores
Actor Descripción
Director
Revisa Información capturada.
Revisa plantilla de contestación
Autoriza o rechaza plantilla de contestación.
Figura 56 Actores Autorización previa
153
Flujo de Eventos
Diagrama de Casos de Uso
Figura 57 Diagrama de caso de uso Autorización previa
Flujo básico
Actor Acción que realiza el actor Acción que realiza el sistema
Director
1. El caso de uso inicia cuando
termina el Caso de uso 03
Contestación de Oficio.
2. Muestra la lista de oficios pendientes de
atención, oficios pendientes de
autorización, oficios atendidos.
3. Selecciona oficio a autorizar de la
lista de oficios pendientes de
atención u oficios pendientes de
autorización.
4. Muestra una ventana de acuse de
recepción mostrando el usuario que
recibió el oficio y la fecha de recepción.
5. Carga información capturada
dependiendo de tipo de asunto del
oficio.
6. Revisa información capturada y
documento adjunto.
7. Revisa la o las plantillas de
contestación con el botón ―Ver
Plantilla‖
8. Muestra detalle de plantilla en
documento Word.
9. Autoriza Oficio. 10. Cambia de estatus de proceso el oficio.
11. Termina caso de uso.
Figura 58 Flujo Básico Autorización previa
154
Flujos alternos
Actor Acción que realiza el actor Acción que realiza el sistema
Director
1. El caso de uso inicia cuando
termina el Caso de uso 03
Contestación de Oficio.
2. Muestra la lista de oficios pendientes
de atención, oficios pendientes de
autorización, oficios atendidos.
3. Selecciona oficio a autorizar de
la lista de oficios pendientes de
atención u oficios pendientes de
autorización.
4. Muestra una ventana de acuse de
recepción mostrando el usuario que
recibió el oficio y la fecha de
recepción.
5. Carga información capturada
dependiendo de tipo de asunto del
oficio.
6. Revisa información capturada y
documento adjunto.
7. Revisa la o las plantillas de
contestación con el botón ―Ver
Plantilla‖
8. Muestra detalle de plantilla en
documento Word.
9. Rechaza Oficio.
10. Regresa oficio a etapa de
contestación de oficio en la bandeja
del abogado asignado he inicia Caso
de uso Contestación de oficio
11. Termina caso de uso.
Figura 59 Flujo Alterno Autorización previa
Servicios
Oficios pendientes de atención
Es la lista de los oficios que ya fueron contestados por un abogado pero no han sido
revisados por el Director.
155
Oficios pendientes de autorización
Es la lista de oficios que ya fueron revisados por el Director, pero que aun no se han
autorizado ni rechazado.
Oficios atendidos
Es la lista de oficios que ya fueron autorizados por el Director.
Requerimientos especiales
No aplica
Precondiciones
Ingresar al sistema y contar con los privilegios de Director.
Que el oficio sea previamente liberado de la etapa Contestación de oficio.
Poscondiciones
El oficio será liberado a la etapa de Asignación de número oficio de contestación e
impresión.
Excepciones
No aplica
Reglas de negocio
Algunos campos se pueden modificar en cualquier momento por cualquier
abogado o el Director.
6.3.2.5 Especificación de CU 05: Asignación de número de oficio de contestación e
impresión
Descripción
Una vez autorizado el oficio, este regresa al abogado para que asigne el número de oficio
de contestación y lo imprima.
156
Contribución a los requerimientos
Este caso de uso satisface los requerimientos 16 y 17 detallados en la sección
especificación de requerimientos.
Actores
Actor Descripción
Abogado
Asigna número de Oficio de contestación.
Imprime Oficio.
Marca como impreso el oficio.
Figura 60 Actores Asignación de número oficio de contestación e impresión
Flujo de Eventos
Diagrama de Casos de Uso
Figura 61 Diagrama de casos de uso Asignación de número oficio de contestación e impresión
Flujo básico
Actor Acción que realiza el actor Acción que realiza el sistema
Abogado
1. El caso de uso inicia cuando
termina el Caso de uso 04
Preautorización.
2. Muestra la lista de oficios enviados para
ser impresos, oficios pendientes de
impresión, oficios atendidos.
157
3. Selecciona oficio a imprimir de
la lista de oficios Enviados
para ser impresos o
pendientes de impresión
4. Muestra una ventana de acuse de
recepción mostrando el usuario que
recibió el oficio y la fecha de recepción.
5. Carga información capturada
dependiendo de tipo de asunto del oficio.
6. Asigna número de Oficio de
contestación
7. Imprime oficio
8. Marca el oficio como impreso.
9. Cambia de estatus de proceso el oficio.
10. Termina caso de uso.
Figura 62 Flujo Básico Asignación de número oficio de contestación e impresión
Flujos alternos
No aplica
Servicios
Oficios enviados para ser impresos
Es la lista de oficios que ya fueron preautorizados y aun no han sido revisados por el
abogado responsable.
Oficios pendientes de impresión
Son aquellos oficios que ya fueron revisados por el abogado responsable pero no han sido
marcados como impresos.
Oficios atendidos
Es la lista de los oficios que ya fueron marcados como impresos, pero que aun no tienen
autorización final.
158
Precondiciones
Ingresar al sistema y contar con los privilegios de abogado.
Que el oficio sea previamente liberado de la etapa de Preautorización como
autorizado.
Poscondiciones
El oficio será liberado a la etapa de Autorización final.
Excepciones
No aplica
Reglas de negocio
Algunos campos se pueden modificar en cualquier momento por cualquier
abogado o el Director.
Un oficio solo lo puede imprimir el abogado responsable del mismo.
6.3.2.6 Especificación de CU 06: Autorización final
Descripción
El proceso de autorización final consiste en que una vez impreso el oficio, el subdirector o
la secretaria llevan personalmente el oficio al director, para que este lo autorice o rechace.
Dependiendo de la decisión del director el subdirector marcara como autorizado o rechazado el
oficio.
Contribución a los requerimientos
Este caso de uso satisface los requerimientos 18 detallados en la sección especificación
de requerimientos.
159
Actores
Actor Descripción
Director Rechaza o autoriza oficio.
Libera oficio a siguiente etapa.
Figura 63 Actores Autorización final
Flujo de Eventos
Diagrama de Casos de Uso
Figura 64
Flujo básico
Actor Acción que realiza el actor Acción que realiza el sistema
Subdirector
1. El caso de uso inicia cuando
termina el Caso de uso 05
Asignación de número oficio de
contestación e impresión.
2. Muestra la lista de oficios enviados
para autorización final, pendientes de
autorización final, oficios atendidos.
3. Selecciona oficio a autorizar de
la lista de oficios enviados para
autorización final o pendientes de
autorización final
4. Muestra una ventana de acuse de
recepción mostrando el usuario que
recibió el oficio y la fecha de
recepción.
5. Carga información capturada
dependiendo de tipo de asunto del
160
oficio.
6. Revisa plantilla de contestación.
7. Autoriza oficio.
8. Cambia de estatus de proceso el
oficio.
9. Termina caso de uso.
Figura 65 Flujo Básico Autorización final
Flujos alternos
Actor Acción que realiza el actor Acción que realiza el sistema
Subdirector
1. El caso de uso inicia cuando
termina el Caso de uso 05
Asignación de número oficio de
contestación e impresión.
2. Muestra la lista de oficios enviados
para autorización final, pendientes de
autorización final, oficios atendidos.
3. Selecciona oficio a autorizar de la
lista de oficios enviados para
autorización final o pendientes de
autorización final
4. Muestra una ventana de acuse de
recepción mostrando el usuario que
recibió el oficio y la fecha de
recepción.
5. Carga información capturada
dependiendo de tipo de asunto del
oficio.
6. Revisa plantilla de contestación.
7. Rechaza oficio.
8. Regresa oficio a etapa de
contestación de oficio en la bandeja
del abogado asignado he inicia Caso
de uso Contestación de oficio
9. Termina caso de uso.
Figura 66 Flujo Alterno Autorización final
161
Servicios
Oficios enviados para autorización final.
Lista de oficios pendientes de revisión para autorización final.
Pendientes de autorización final.
Lista de oficios revisados pero que aun no tienen autorización final.
Oficios atendidos
Es la lista de oficios que ya tienen autorización final pero aun no se desahoga el oficio.
Requerimientos especiales
No aplica
Precondiciones
Ingresar al sistema y contar con los privilegios de Subdirector.
Que el oficio sea previamente liberado de la etapa de Asignación de número oficio
de contestación e impresión.
Poscondiciones
El oficio será liberado a la etapa de Desahogo de oficio
Excepciones
No aplica
Reglas de negocio
El subdirector solo puede autorizar o rechazar, en ningún momento puede
modificar la plantilla de contestación.
162
6.3.2.7 Especificación de CU 07: Desahogo de funciones
Descripción
Es el proceso con el cual se marca un oficio una vez este ya fue contestado, autorizado y
firmado por el director.
Contribución a los requerimientos
Este caso de uso satisface los requerimientos 20 detallados en la sección especificación
de requerimientos.
Actores
Actor Descripción
Secretaria Desahoga oficios.
Libera oficio a siguiente etapa.
Figura 67 Actores Desahogo de funciones
Flujo de Eventos
Diagrama de Casos de Uso
Figura 68 Diagrama de caso de uso Desahogo de funciones
163
Flujo básico
Actor Acción que realiza el actor Acción que realiza el sistema
Secretaria
1. El caso de uso inicia cuando
termina el Caso de uso 06
autorización final
2. Muestra la lista de oficios enviados a
desahogo, oficios pendientes de
desahogo, oficios desahogados.
3. Selecciona oficio a desahogar de
la lista de enviados a desahogo o
oficios pendientes de desahogo
4. Muestra una ventana de acuse de
recepción mostrando el usuario que
recibió el oficio y la fecha de
recepción.
5. Carga información capturada
dependiendo de tipo de asunto del
oficio.
6. Desahoga oficio.
7. Cambia de estatus de proceso el
oficio.
8. Termina caso de uso.
Figura 69 Flujo Básico Desahogo de funciones
Flujos alternos
No aplica
Servicios
Oficios enviados a desahogo
Lista de oficios pendientes de revisión para desahogo.
Oficios pendientes de desahogo
Lista de oficios que ya han sido revisados pero no se han desahogado.
Oficios desahogados
Es la lista de oficios que ya han sido desahogados.
164
Requerimientos especiales
No aplica
Precondiciones
Ingresar al sistema y contar con los privilegios de Subdirector o secretaria.
Que el oficio sea previamente liberado de la etapa de Autorización final.
Poscondiciones
No aplica
Excepciones
No aplica
Reglas de negocio
No aplica
6.3.2.8 Especificación de CU 08: Notificación de oficio
Descripción
Una vez que se ha desahogado un oficio, este debe ser notificado. Para la notificación se
lleva un proceso de envío por correo el cual genera varios datos que deben ser registrados para su
seguimiento y referencia.
Contribución a los requerimientos
Este caso de uso satisface los requerimientos 20 detallados en la sección especificación
de requerimientos.
Actores
Actor Descripción
Notificador Captura de datos de notificación.
Notifica oficio.
Figura 70 Actores Notificación de oficio
165
Flujo de Eventos
Diagrama de Casos de Uso
Figura 71 Diagrama de caso de uso Notificación de oficio
Flujo básico
Actor Acción que realiza el actor Acción que realiza el sistema
Notificador
1. El caso de uso inicia cuando
termina el Caso de uso 07
Desahogo de oficios
2. Muestra la lista de oficios enviados a
Notificación, oficios pendientes
Notificar, oficios Notificados.
3. Selecciona oficio a Notificar de la
lista de enviados a notificación u
oficios pendientes de notificar.
4. Muestra una ventana de acuse de
recepción mostrando el usuario que
recibió el oficio y la fecha de
recepción.
5. Captura datos de notificación.
6. Guarda datos capturados
7. Valida campos obligatorios <E01 Falta
de campos obligatorios>
8. Guarda información en la base de
datos.
9. Marca como notificado el oficio
10. Guarda el oficio como notificado en la
base de datos.
11. Termina caso de uso.
Figura 72 Flujo básico Notificación de oficio
166
Flujos alternos
No aplica
Servicios
Oficios enviados a Notificación
Lista de oficios enviados a notificar pendientes de revisar.
Oficios pendientes Notificar
Lista de oficios pendientes de notificar
Oficios Notificados
Lista de oficios notificados
Precondiciones
Ingresar al sistema y contar con los privilegios de Notificador.
Que el oficio sea previamente liberado de la etapa de Desahogo de oficios.
Poscondiciones
No aplica
Excepciones
Excepción Acción
E01 Falta de campos obligatorios
1. El sistema mostrará en una ventana el mensaje
―Hay campos obligatorios no capturados, verifique
por favor‖, con botón ―aceptar‖.
2. El actor da clic en el botón ―Aceptar‖
3. El sistema cierra la ventana.
4. El sistema regresa el control a la pantalla anterior.
Figura 73 Excepciones Notificación de oficio
167
Reglas de negocio
No aplica
6.3.2.9 Especificación de CU 09: Reasignación de abogado
Descripción
Por la naturaleza de la SAAJ, es necesario tener una opción dentro del sistema que
permita reasignar oficios a otro abogado, algunas veces por ausencia o por carga de trabajo entre
otras razones.
Contribución a los requerimientos
Este caso de uso satisface los requerimientos 24, 25 y 26 detallados en la sección
especificación de requerimientos.
Actores
Actor Descripción
Subdirector
Selecciona oficio
Reasigna Abogado responsable.
Guarda reasignación.
Figura 74 Actores Reasignación de abogado
Flujo de Eventos
Diagrama de Casos de Uso
Figura 75 Diagrama de caso de uso Reasignación de abogado
168
Flujo básico
Actor Acción que realiza el actor Acción que realiza el sistema
Subdirector
1. El caso de uso inicia cuando el
actor selecciona el oficio a
reasignar.
2. Muestra en la pantalla el oficio
seleccionado.
3. Selecciona el nuevo abogado
responsable del oficio.
4. Selecciona el botón guardar.
5. Guarda los datos en la base de datos.
6. Guarda el cambio realizado en la
bitácora de movimientos. Los datos
que se guardaran son:
i. Abogado actual.
ii. Nuevo abogado.
iii. Fecha de reasignación.
iv. Status de proceso.
v. Status de oficio.
vi. Motivo de reasignación.
7. Fin de caso de uso
Figura 76 Flujo básico Reasignación de abogado
Flujos alternos
No aplica
Servicios
No aplica
Requerimientos especiales
No aplica
Precondiciones
Ingresar al sistema y contar con los privilegios de Subdirector.
Que el oficio se encuentre previamente capturado.
169
Poscondiciones
No aplica
Excepciones
No aplica
Reglas de negocio
El oficio solo se puede reasignar si no esta concluido.
El oficio solo se puede reasignar si esta en la etapa de proceso contestación de
oficio.
6.3.2.10 Especificación de CU 10: Asignación de privilegios de subdirector
Descripción
Debido a las labores del subdirector y ausencias que pudiera tener durante la jornada
laboral, se debe contar con la opción dentro del sistema para asignar temporalmente permisos de
subdirector a algún abogado de la misma SAAJ permitiendo con esto al abogado realizar
actividades de subdirector en el sistema.
Contribución a los requerimientos
Este caso de uso satisface los requerimientos 28 detallados en la sección especificación
de requerimientos.
Actores
Actor Descripción
Subdirector Selecciona abogado.
Asigna privilegios de subdirector.
Figura 77 Actores Asignación de privilegios de subdirector
170
Flujo de Eventos
Diagrama de Casos de Uso
Figura 78 Diagrama de casos de uso Asignación de privilegios de subdirector
Flujo básico
Actor Acción que realiza el actor Acción que realiza el sistema
Subdirector
1. El caso de uso inicia cuando el
actor selecciona la opción
Permisos temporales.
2. Muestra la pantalla de permisos
temporales.
3. Selecciona el abogado
responsable del catálogo de
abogados.
4. Selecciona el botón Asignar
privilegios.
5. Guarda los datos en la base de
datos.
6. Fin de caso de uso
Figura 79 Flujo básico Asignación de privilegios de subdirector
Flujos alternos
No aplica
Servicios
No aplica
Requerimientos especiales
No aplica
171
Precondiciones
Ingresar al sistema y contar con los privilegios de Subdirector.
Que el abogado a signar privilegios se encuentre en el catálogo de abogados.
Poscondiciones
No aplica
Excepciones
No aplica
Reglas de negocio
No aplica
6.3.3 Desarrollo de arquitectura
Introducción
Esta sección provee de una visión general de la arquitectura del sistema para bosquejar
diferentes aspectos del mismo. Intenta capturar y transmitir la razón de la decisión arquitectónica
sobre la que se construirá la solución del sistema.
Representación de la arquitectura
Una arquitectura de software describe como un sistema se desglosa en componentes,
cómo son interconectados y la manera en que se comunican e interactúan entre sí. Para la
solución de este sistema. Utilizaremos una arquitectura basada en una Web Client Software
Factory.
Con el desarrollo de un Software Factory
El desarrollo de aplicaciones basado en Fábrica de software aborda el problema tradicional
del desarrollo de aplicaciones donde las aplicaciones se desarrollan y entregan sin aprovechar los
conocimientos adquiridos y los bienes producidos a partir de desarrollo de aplicaciones similares.
Muchos enfoques, tales como la formación, la documentación, y los marcos, se utilizan para
abordar este problema. El desarrollo de aplicaciones utilizando una fábrica de software adecuado
172
puede proporcionar muchos beneficios, entre ellos los siguientes, en comparación con los
enfoques convencionales de desarrollo de software:
Coherencia: Usando una fábrica de software para crear múltiples instancias de una línea
de productos de software (un conjunto de aplicaciones que comparten características y la
arquitectura) hace más fácil para lograr la coherencia. Esto simplifica la gestión y reduce el
mantenimiento y los costes de formación.
Calidad: Usando un software de fábrica hace que sea más fácil para los desarrolladores a
aprender y aplicar las prácticas. Dedicar menos tiempo a los desarrolladores para escribir código y
dedicar más tiempo a la creación de características que son únicas para cada aplicación. Esto
reduce la probabilidad de que la aplicación tenga defectos de diseño o defectos de código.
Aplicaciones desarrolladas con una fábrica de software también puede ser verificada antes de su
liberación, lo que garantiza que las mejores prácticas fueron seguidas durante el desarrollo.
Productividad: Usando un software de fábrica simplifica y automatiza las actividades de
desarrollo de aplicación prescrita de las siguientes maneras:
Se reutiliza los activos de software, en particular la arquitectura extensible de referencia, la
aplicación de marcos, y la aplicación bloques.
Proporciona el contexto y orientación automática.
Genera el código de los modelos que representan abstracciones de los elementos y
mecanismos de aplicación.
Vista de despliegue
Figura 8085 Vista de despliegue
85
Software Factory Capabilities. http://msdn.microsoft.com/en-us/library/cc304787.aspx, consulta: 10 Febrero 2009.
173
En términos de despliegue, los servidores utilizados tendrán las siguientes características:
Servidor de aplicaciones. IIS 6
Servidor de base de datos. SQL Server 2005 Enterprise Edition.
Metas de diseño
La siguiente figura muestra una perspectiva general la arquitectura con la Web Client Software
Factory.86
Figura 81 Perspectiva general de la arquitectura
86
Software Factory Capabilities. http://msdn.microsoft.com/en-us/library/cc304787.aspx, consulta: 10 Febrero 2009.
174
Del conjunto de servicios comunes generalmente incluidos a una aplicación, los que se utilizarán
en el proyecto son los siguientes:
Autentificación
Autorización
Integridad de datos
Manejo de Errores
Manejo de imágenes
Bitácoras
Paginador
Manejo de archivos.
Tamaño y desempeño
No hay consideraciones en la arquitectura referentes al tamaño y el desempeño del sistema.
Esquema de Seguridad
Este se implementar con base en el esquema de seguridad proporcionado por el
Framework de Microsoft. El cual se basa en el encriptamiento de información sensible como
password, nombre de usuario. La implementación de la seguridad se basa en lo establecido en el
namespace System.Web.Security.
El se controlara con un MemberShip provider.
Los roles se manejaran con un roleprovider.
175
6.3.4 Diagrama entidad relación
Figura 82 Diagrama Entidad Relación
176
6.3.5 Interfaz gráfica
A continuación se muestran las vistas de las principales pantallas con las que contará el
sistema para el manejo de los asuntos.
1. Acceso al sistema.
Figura 83 Acceso al sistema
2. Pantalla principal.
Figura 84 Pantalla principal
177
3. Captura
Figura 85 Captura
4. Contestación de oficio. Esta pantalla permite contestar los oficios así como
revisar los asuntos por parte de los directores de relaciones jurídicas.
Figura 86 Contestación de oficio
178
6.4 Construcción
La construcción de este sistema como se menciono en el alcance arriba mencionado se
limitará al tiempo de duración de este seminario, por lo que en esta primera etapa se desarrollara
modulo funcional que demuestre la solución del problema planteado y no la totalidad de los casos
de uso, ya que el tiempo requerido para este sistema es mayor al tiempo de duración del
seminario. La estimación del tiempo requerido para este sistema dentro de la metodología RUP en
sus 4 fases lo calculamos de la siguiente manera de acuerdo en la experiencia de desarrollos
anteriores y en los porcentajes para cada fase establecidos en RUP.
Unidad de
medida
Numero de casos de uso 10
Tiempo promedio de desarrollo por caso de uso 250 Horas
Desarrollo de módulos se seguridad y administración de
sistema 500 Horas
Total 3000 Horas
Figura 87 Estimación de tiempo
Por lo tanto de acuerdo a los datos de la figura anterior, hay que tomar en cuenta los
siguientes factores:
El equipo se compone de 2 personas, un ingeniero industrial y un ingeniero en informática.
Una persona en promedio puede cubrir de 2000 a 2400 horas al año con jornadas de
trabajo de 8 ó 9 horas.
Hasta el día de hoy se tiene un el siguiente avance en las etapas de Inicio, Elaboración.
Etapa % de avance Avance del proyecto en
horas
Inicio 100 300
Elaboración 100 900
Construcción 20 600
Transición 0 0
Avance Total 60 1800
Figura 88 Avance actual
De acuerdo con lo anterior tenemos un avance del 60 % en el desarrollo del sistema con
179
un total de 1800 horas cubiertas, faltándonos un total de 1200 horas para poder terminar al 100%
este sistema.
Para la terminación de l sistema al 100% se propone continuar en una segunda fase. El
avance actual se muestra en la Figura 51.
6.5 Transición
Esta etapa no será cubierta para fines de esta tesina, por falta de tiempo.
180
6.6 CONCLUSIÓN
El uso de una metodología probada así como el uso de la herramienta adecuada,
garantizan el resultado esperado y en el caso de que existan retrasos o falta de tiempo para
realizar el 100% del proyecto, nos permite saber perfectamente donde estamos parados y poder
establecer un aproximado del tiempo y el esfuerzo que se requiere para terminar el proyecto.
Por otro lado, es cierto que el uso de metodologías en México no es muy común, pero
parte de los objetivos de esta tesis es mostrar que trabajar de forma ordenada no se casualidad,
hay que basarnos en la experiencia de otros proyectos pero no solo en los nuestros si no de otros
en la industria, esa es la razón de ser de las metodologías, es decir que no nosotros ya no
tenemos que inventar el hilo negro cada vez que iniciamos un proyecto, si no tomar lo mejor de
cada una de ellas con el propósito de obtener un producto de calidad. Lo que podemos tomar de
otros proyectos son: administración, técnicas, herramientas. Algo importante de mencionar es que
al decir que podemos utilizar experiencias de otros no nos referimos a copiar tal cual, si no, es
tomar lo mejor de cada una de ellas y adaptarlas a las nuestras, con mejoras, y particularidades
nuestras.
Con esta propuesta logramos hasta el día de hoy una modulo funcional que demuestra lo
analizado y propuesto en los capítulos anteriores. Así mismo con la arquitectura propuesta se
podrá continuar con la construcción en una segunda etapa.
181
CONCLUSIONES
Siguiendo las metodologías y utilizando una diversidad de herramientas de análisis,
tecnológicas y con base en las pruebas realizadas con el usuario sobre la aplicación resultante de
este trabajo, podemos confirmar lo expuesto en nuestra Hipótesis.
“La reingeniería y la automatización de los procesos de recepción, contestación y
seguimiento, disminuirá el tiempo de respuesta de los asuntos jurídicos ingresados en la empresa
Relaciones Jurídicas evitando las sanciones administrativas por incumplimiento de una orden de
un superior jerárquico, por que se incumpla lo establecido en las leyes correspondientes al tipo de
asunto o se pierda el caso ante un Tribunal o Juzgado.”
¿Cómo aporta esta solución a la sustentabilidad y a la sociedad del conocimiento?
Como aportación a la sustentabilidad, el proceso de reciclaje dentro de la empresa
―Relaciones Jurídicas‖, ayudara a reducir el consumo desmedido de papel en la impresión de los
asuntos jurídicos, que paulatinamente ira generando una cultura ambiental entre el personal de
dicha empresa.
En cuanto a la sociedad del conocimiento, actualmente el uso de las tecnologías ha
modificado la forma de trabajar de las empresas, incluso aquellas que se rehúsan ha incorporar
dentro de su operación nuevas tecnologías han perdido competitividad en algunos de los
mercados. El uso de nuevas tecnologías es tan diverso como diversas son las necesidades de
cada empresa en los diferentes mercados, es por esto que hoy en día particularmente en la
industria del software y hardware existen diferentes ofertas para satisfacer las necesidades
demandadas.
Si bien es cierto que las tecnologías nos han ayudado a optimizar tiempo, reducir
esfuerzos, reducir costos, reducir las distancias con la utilización de las redes de comunicación
entre otros muchos beneficios; también es cierto que en un principio la generación de tecnología
principalmente en el ramo industrial, no contemplo el daño al medio ambiente. Este daño al medio
ambiente ha prendido los focos de alerta a nivel mundial y ahora se están generando propuestas
tecnológicas que no solo generen todos los beneficios antes mencionados si no que también
contemplen el impacto que tendrán ante el medio ambiente. Aunado con esto, uno de los grandes
problemas y retos es cambiar la forma de pensar de la mayoría de las personas que se forjaron
con esta ideología de generar y tirar tecnología sin preocuparse por la afectación a su entorno.
182
Uno de los objetivos de este seminario es la de generar nuevos enfoques profesionales
para rediseñar el futuro. Basado en este objetivo nuestra solución no solo esta enfocada en agilizar
los procesos actuales de la organización y en mejorar el control de los asuntos, si no basados en
este objetivo estamos firmemente convencidos que las nuevas tecnologías y herramientas
informáticas deben contemplar el cuidado del entorno y el medio ambiente así como los recursos
de las generaciones futuras.
Nuestra solución permitirá reducir el consumo de papel de una manera significativa como
se menciona arriba en este documento mediante el manejo de expedientes electrónicos así como
revisiones electrónicas de documentos de contestación de asuntos.
Dentro de la sociedad del conocimiento, no podemos negar que nos encontramos en una
época de transición, una época en la que la sociedad tiene que cambiar la forma de hacer las
cosas para seguir con este proceso evolutivo. Tal y como lo menciono Alvin Toffler en su libro ―LA
TERCERA OLA‖, la sociedad ha cruzado por varias olas en las cuales la sociedad ha modificado la
forma de vivir y trabajar. Siguiendo con esta teoría muchos afirman que nos encontramos en la Ola
de la Sociedad del conocimiento, en la cual el conocimiento es lo que mas vale dentro de las
organizaciones y en la sociedad.
Los sistemas informáticos son una de las herramientas principales sobre las cuales se
basa la sociedad del conocimiento, ya que a través de ellos se ha facilitado la comunicación y la
transición del conocimiento sin importar el lugar en donde nos encontremos, ya que a través de las
redes de comunicación se han acortado las distancias, es muy cierto que falta mucho por cubrir
para que toda la humanidad tenga acceso a este recurso tan valioso que es el conocimiento, pero
retomando un termino de Alvin Toffler llamado ―La cuña invisible‖ el cual se refiere a que entre
cada Ola existe un periodo de transición, así es que en algún momento toda lo sociedad se
encontrará con las mismas oportunidades de acceso a este recurso.
La propuesta aquí expuesta, se basa en la automatización de los procesos, basada en una
solución Web, usando herramientas y técnicas de ultima generación, lo que permitirá tener acceso
al sistema desde cualquier parte del mundo donde exista una conexión a Internet. De esta manera
se descentraliza la operación permitiendo trabajar a distancia y adquirir una ventaja competitiva
sobre las demás empresas.
―Es cierto que el cambio a nivel global es mínimo pero es necesario iniciar poco a
poco para así rediseñar el futuro.”
183
BIBLIOGRAFÍA
Ceballos Francisco Javier, POO Visual Basic Curso de programación, RA – MA,
México 2004, pp. 478.
Craig Larman, UML y Patrones, Introducción al análisis y diseño orientado a objetos,
Editorial Pearson, México, 2006, pp. 628.
Crovi Delia, Sociedad de la Información y el Conocimiento: Entre lo falaz y lo posible,
McGraw Hill, Buenos Aires, 2004, pp.391.
Echeverría Javier, "El futuro de las lenguas en Internet", en comentario sobre la obra "Los
señores del aire: Telépolis y el tercer entorno", Editorial Destino, Barcelona 1999, pp. 286.
Fred, R. David, Conceptos de administración estratégica, Quinta Edición, Prentice Hall
Hispano Americano. México, 1997 pp.336.
Fumero Antonio y Roca Genis Con la Colaboración de Sáez Vacas Fernando, Web 2.0,
Fundación Orange, España, 2007, pp.131.
Hammer Michell, Reingeniería, Editorial Norma, México, 1994, pp.226.
Harrington H.James, Administración Total del mejoramiento continuo, McGraw Hill.
México.1997. pp.464.
Ing. Pérez Verzini Raúl A. "Como entender reingeniería de procesos", primera edición en
español, Editorial McGraw Hill, México, 1996. pp.250.
Jacaboson I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software,
Addison Wesley. E.U, 1999, pp.784.
Joiner Brian, Gerencia de la cuarta generación, McGraw-Hill, México,1995, pp.302.
Martín Martínez Francisco Javier, Operaciones con bases de datos ofimáticas y
corporativas. RA – MA, México, 2004, pp.393.
Matta G., D.A. Introducción al Desarrollo de Aplicaciones con Visual Basic, Editorial
Prentice Hall, México, 2005, pp.411.
Pons Capote Olga. Nicolás Marín Ruiz, Introducción a los sistemas de bases de datos, 1ª
Edición, Editorial Thomson, México, 2005. pp.230.
Porter M, Técnicas para el análisis de los sectores industriales y de la competencia,
Editorial CECSA, México, 2005, pp.400.
Pressman Roger S, ―Ingeniería del Software: Un enfoque práctico‖, Segunda edición,
Editorial McGraw Hill, E.U, 1990, pp.601.
Sherkenbach William w, McGraw Hill, México,1999, pp.248.
Thompson, "Análisis SWOT. Qué es necesario buscar para medir los puntos fuertes,
débiles, las oportunidades y las amenazas de una compañía", primera edición en español,
Editorial McGraw Hill, México, 1998, pp.142.
184
Referencias de internet
Automatización industrial, http://es.wikipedia.org/wiki/Automatización, Marzo / 2009.
Diagrama causa-efecto. www.monografias.com/trabajos42/diagrama-causa-
efecto/diagrama-causa-efecto.shtml - 34k, Enero / 2009.
Diagrama de Flujo.www.fundibeq.org/metodologias/herramientas/diagrama_de_flujo.pdf,
Enero / 2009.
http://cecadesu.semarnat.gob.mx/biblioteca_digital/desarrollo_sustentable/desarrollo_suste
ntable02.shtml. Abril / 2009.
http://www.es-asp.net/tutoriales-asp-net/tutorial-0-5312/asp-net-ajax-control-toolkit.aspx.
Febrero / 2009.
Instituto Tecnológico de sonora, www.itson.mx/dii/itapia/Conceptos%20de%20RUP.doc.
Marzo / 2009.
Mapeo de procesos.
http://www.google.com.mx/search?hl=es&q=mapeo+de+procesos&meta. Enero / 2009.
Mariano Converti. Introducción a Composite UI Application Block (CAB) IV.
http://blogs.southworks.net/mconverti/2007/09/10/introduccion-a-composite-ui-application-
block-cab-iv/. Febrero / 2009.
Matriz de Evaluación de los Factores Externos (MEFE) www.eumed.net/ce/2006/hpt-
FODA.htm . Febrero / 2009.
Perspectivas Microsoft.
http://www.microsoft.com/spain/enterprise/perspectivas/numero_17/partnerI.mspx,
Febrero/2009.
Programación extrema, http://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema.
Marzo/2009.
Sociedad del Conocimiento y Nuevas Tecnologías. Fernando Zapata López.
http://www.oei.es/salactsi/zapata.htm. Frebrero / 2009.
Software Factory Capabilities. http://msdn.microsoft.com/en-us/library/cc304787.aspx.
Frebrero / 2009.
Software Factory Capabilities. http://msdn.microsoft.com/en-us/library/cc304787.aspx.
Frebrero / 2009.
Tecnología de la información,
http://es.wikipedia.org/wiki/Tecnolog%C3%ADa_de_la_informaci%C3%B3n. Febrero / 2009
Web 2.0 http://es.wikipedia.org/wiki/Web_2.0. Febrero / 2009.
185
GLOSARIO
ABSTRACCIÓN: Denota las características esenciales de un objeto, donde se capturan sus
comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que
puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el
sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los
métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son
requeridas para ampliar una abstracción.
ARQUITECTURA DE SOFTWARE: Una Arquitectura de Software, también denominada
Arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que
proporcionan el marco de referencia necesario para guiar la construcción del software para un
sistema de información.
ASERTIVIDAD: Estado emocional que propicia una conducta positiva.
ASP.NET: Es una tecnología de scripts que corren en el servidor y pueden ser utilizados para crear
aplicaciones dinámicas e interactivas en el Web.
BASE DE DATOS: Es un conjunto auto descriptivo de registros integrados.
BIFURCACIÓN: Que tiene varias decisiones en donde evalúas una condición para la ejecución
de acciones.
C#: (pronunciado "ci sharp") es un lenguaje de programación orientado a objetos desarrollado y
estandarizado por Microsoft como parte de su plataforma .NET, que después fue aprobado como
un estándar por la ECMA e ISO.
CALIDAD: El grado en el que un conjunto de características inherentes cumple con los requisitos‖
CASO DE USO: Es una especificación de aquellas acciones que el sistema debe ejecutar con el
fin de satisfacer las necesidades del negocio.
CLASE: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La
instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.
DIAGRAMA DE FLUJO: El Diagrama de Flujo es una representación gráfica de la secuencia de
186
pasos que se realizan para obtener un cierto resultado. Este puede ser un producto, un servicio, o
bien una combinación de ambos.
DIAGRAMA: Representación gráfica de un modelo.
DISEÑO: Es el proceso creativo de programar, proyectar, coordinar, seleccionar y organizar una
serie de factores técnicos y elementos gráfico-plásticos, con los objetivos de crear objetos o
productos de acuerdo a unas especificaciones e integrando en el proyecto los instrumentos de
comunicación.
FODA: Es una herramienta que permite conformar un cuadro de la situación actual de la empresa
u organización, permitiendo de esta manera obtener un diagnóstico preciso que permita en función
de ello tomar decisiones acordes con los objetivos y políticas formulados. El término FODA es una
sigla conformada por las primeras letras de las palabras Fortalezas, Oportunidades, Debilidades y
Amenazas (en inglés SWOT: Strenghts, Weaknesses, Oportunities, Threats). De entre estas cuatro
variables, tanto fortalezas como debilidades son internas de la organización, por lo que es posible
actuar directamente sobre ellas. En cambio las oportunidades y las amenazas son externas, por lo
que en general resulta muy difícil poder modificarlas.
ENCAPSULAMIENTO: Significa reunir a todos los elementos que pueden considerarse
pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la
cohesión de los componentes del sistema. Algunos autores confunden este concepto con el
principio de ocultación, principalmente porque se suelen emplear conjuntamente.
ENCRIPTACIÓN: Encriptar es hacer ilegible un escrito por medio de aplicar al texto un algoritmo.
Por ejemplo, si yo a este escrito le aplico que cada vocal cambie por el número correspondiente, y
cada consonante por... lo que sea, otro número, si se sabe lo que he hecho, el destinatario lo leerá,
es decir, lo "desencriptará o descifrará". El ejemplo no sería válido si el cifrado es de una sola
dirección.
FLUJO DE EVENTOS: Son la serie de acciones que se ejecutaran de forma lógica para completar
un caso de uso del sistema.
FRAMEWORK: Conjunto de APIs y herramientas destinadas a la construcción de un determinado
tipo de aplicaciones de manera general.
GAPS: Abertura, brecha: Espacio entre bloques de datos en una cinta magnética; Espacio en un
cabezal de lectura/escritura por el cual el flujo magnético (energía) fluye, haciendo que la cinta
187
magnética o la superficie del disco quede magnetizada en la dirección Correspondiente.
HERENCIA: Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y
operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D.
Por lo tanto, puede usar los mismos métodos y variables públicas declaradas en C. Los
componentes registrados como "privados" (prívate) también se heredan, pero como no pertenecen
a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros
métodos públicos. Esto es así para mantener hegemónico el ideal de OOP.
IIS: Internet Information Server, es una serie de servicios para los ordenadores que funcionan con
Windows. Originalmente era parte del Option Pack para Windows NT. Luego fue integrado en otros
sistemas operativos de Microsoft destinados a ofrecer servicios, como Windows 2000 o Windows
Server 2003. Windows XP Profesional incluye una versión limitada de IIS. Los servicios que ofrece
son: FTP, SMTP, NNTP y HTTP/HTTPS.
ISHIKAWA: Diagrama causa – efecto.
LENGUAJE DE PROGRAMACIÓN: Un lenguaje de programación es un conjunto de símbolos y
reglas sintácticas y semánticas que definen su estructura y el significado de sus elementos y
expresiones. Es utilizado para controlar el comportamiento físico y lógico de una máquina.
LINK: Apuntadores de Hipertexto que sirven para saltar de una información a otra, o de un servidor
a otro, cuando se navega por Internet.
LLAVE FORÁNEA: Se refiere a la clave de un campo o columna que identifica un registro en una
tabla al coincidir con una clave primaria en una tabla distinta. Las llaves foráneas se utilizan para
realizar tablas con referencias cruzadas.
LLAVE PRIMARIA: Contiene valores únicos que identifican cada registro de esa tabla. Puede ser,
tanto un campo o columna del cual se tenga seguridad que sus valores son únicos, como un
campo generado automáticamente por el mismo sistema de base de datos. Las llaves primarias
pueden estar compuestas por más de un campo o columna de una tabla.
MAPEO: Es la acción por la cual se asigna una letra a una unidad de disco, que se encuentra
compartida en una red de ordenadores, como si de un disco más del ordenador se tratase.
MEJORA CONTINUA: Avance progresivo (paulatino) por medio de oportunidades para
incrementar eficiencia y calidad resultante de las actividades rutinarias -- tiene enlace directo con
188
principios bajo Kaizen.
MICROSOFT: (NASDAQ: MSFT) es una empresa multinacional estadounidense, fundada en 1975
por Bill Gates y Paúl Allen. Dedicada al sector de la informática, con sede en Redmond,
Washington, Estados Unidos. Microsoft desarrolla, fabrica, licencia y produce software y equipos
electrónicos. Siendo sus productos más usados el Sistema operativo Microsoft Windows y la suite
Microsoft Office, estos productos tienen una importante posición entre los ordenadores personales.
Con una cuota de mercado cercana al 90% para Office en 2003 y para Windows en el 2006.
Siguiendo la estrategia de Bill Gates de "tener una estación de trabajo que funcione con nuestro
software en cada escritorio y en cada hogar".
NOM.ISO: Norma Oficial Mexicana de la Organización Internacional para la Normalización
PARADIGMA: Un paradigma es el resultado de los usos, y costumbres, de creencias establecidas
de verdades a medias; un paradigma es ley, hasta que es desbancado por otro nuevo.
PARETO: El Diagrama de Pareto consiste en un gráfico de barras similar al histograma que se
conjuga con una ojiva o curva de tipo creciente y que representa en forma decreciente el grado de
importancia o peso que tienen los diferentes factores que afectan a un proceso, operación o
resultado.
PATRÓN DE DISEÑO: Los patrones de diseño son la base para la búsqueda de soluciones a
problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción
o interfaces.
POO: Programación Orientada a Objetos (u OOP según sus siglas en inglés) es un paradigma de
programación que usa objetos y sus interacciones para diseñar aplicaciones y programas de
computadora. Está basado en varias técnicas, incluyendo herencia, modularidad, polimorfismo y
encapsulamiento. Su uso se popularizó a principios de la década de 1990. Actualmente son
muchos los lenguajes de programación que soportan la orientación a objetos.
PROCESO: Es una red de actividades vinculadas ordenadamente las cuales se llevan a cabo
repetidamente y que utilizan recursos e información para transformar insumos en productos
abarcando desde el inicio del proceso hasta la satisfacción de las necesidades del cliente.
QUERY (CONSULTA): Las consultas son la forma principal de hacer solicitudes de información a
la base de datos. Las consultas están compuestas de comandos que se envían a la base de datos
en un formato predefinido, generalmente utilizando el formato SQL.
189
REDISEÑAR: Significa llegar hasta la raíz de las cosas: no efectuar cambios superficiales ni tratar
de arreglar lo que ya está instalado sino abandonar lo viejo. Al hablar de rediseñar radicalmente se
quiere decir que se debe descartar todas las estructuras y los procedimientos existentes e inventar
maneras enteramente nuevas de realizar el trabajo.
REINGENIERÍA: Es la revisión fundamental y el rediseño radical de procesos para alcanzar
mejoras espectaculares en medidas críticas y contemporáneas de rendimiento, tales como costos,
calidad, servicio y rapidez.
SISTEMA OPERATIVO: Programas que controlan los recursos del sistema y sirven de
intermediarios entre las aplicaciones y dichos recursos.
SITIO WEB: Un sitio Web es un conjunto de páginas Web, típicamente comunes a un dominio de
Internet o subdominio en la World Wide Web en Internet.
SQL: Siglas en inglés para Structured Query Language (Lenguaje Estructurado de Consultas) y
que representa un lenguaje estándar de la industria utilizado para la manipulación de datos en
sistemas de bases de datos relacionales.
SUSTENTABILIDAD: La capacidad de una sociedad humana de apoyar en su medio ambiente el
mejoramiento continúo de la calidad de vida de sus miembros para el largo plazo; las
sustentabilidades de una sociedad es función del manejo que ella haga de sus recursos naturales y
puede ser mejorada indefinidamente.
TI: Son herramientas y métodos empleados para recabar, retener, manipular o distribuir
información.
UML: Unified Modeling Language. Lenguaje de modelado visual que se usa para especificar,
visualizar, construir y documentar artefactos de un sistema de software.
190
ANEXO
Guía de información levantada y utilizada para el desarrollo de este proyecto de tesina
llamada “Reingeniería y Automatización de Procesos en la empresa “Relaciones Jurídicos”
El objetivo de este documento es proporcionar una guía de entrevista para conocer de
forma general el área de Asuntos Jurídicos de la empresa ―Relaciones Jurídicas‖ con el fin de
obtener información que permita comprender como esta conformada el área y los servicios que
brinda así como tareas que desempeña esta empresa.
¿La subdirección de Asuntos Jurídicos se encuentra dividida en sub áreas?
¿Cuáles son las responsabilidades para cada puesto?
¿Cuáles son los servicios que brinda?
¿Cuáles son los tipos de asuntos que atiende?
¿En que consiste cada tipo de asunto?
¿Qué documento recibe inicialmente la secretaria para iniciar proceso?
¿De quien o quienes puede recibir los documentos?,
¿Todos los tipos de asuntos entran por recepción de documentos?
¿A quien o a quienes se solicita el expediente?
¿Con que documento se solicita el expediente?,
¿Qué pasa si no existe el expediente?,
¿Todos los tipos de asuntos tienen el mismo proceso?
¿Con que áreas se interactúa para cada uno de los tipos de asuntos al inicio, durante y fin?
¿El seguimiento de los tipos de asuntos, se atiende por recepción o el área jurídica se encarga
directamente?
¿Cuál es el proceso de notificación?
¿Dónde se registran los oficios notificados?
¿Qué envía exactamente el notificador?
¿Qué recibe el notificador una vez notificado el oficio?
¿Cuáles son las formas en las que puede notificar?
¿Qué pasa si no fue posible notificar?
Actividades identificadas
Recepción de documentos
Solicitar de expediente.
Captura de datos.
191
Analizar de oficio.
Asignar prioridades, abogado y fecha máxima de contestación
Preparar de oficio de contestación.
Asignar número de oficio de contestación e imprimir oficio de contestación.
Revisar de oficio de contestación
Autorización final
Desahogar oficios.
Notificar de resolución de oficio de contestación.
¿Son todas las actividades?
¿Cuáles son los roles que interactúan en el proceso?