Tesis Josué Cruz
107
I ESTUDIOS CON RECONOCIMIENTO DE VALIDEZ OFICIAL SEP NUMERO 972142 DE FECHA 10 DE JUNIO DE 1997 LOS MODELOS DE MICROSOFT SOLUTIONS FRAMEWORK APLICADOS A LA PLANIFICACIÓN Y GESTIÓN DE UN PROYECTO TECNOLÓGICO DE UN SISTEMA DE AUDITORIA Y CONTROL INTERNO TESIS QUE PARA OBTENER EL TITULO DE INGENIERO EN COMPUTACIÓN PRESENTA: JOSUÉ DAVID CRUZ SORIANO ASESOR: ING. IVÁN CARLOS RIVERA GONZÁLEZ MEXICO, D.F. MARZO 2007
-
Upload
josue-cruz -
Category
Documents
-
view
1.656 -
download
6
description
Este material es mi tesis para el grado de Ingeniero en Computación, se trata de la metodología de Microsoft (COM), para proyectos, no es gran material pero la pueden usar como modelo para su tesis y aplicarla a algún proyecto que tengan en mente.
Transcript of Tesis Josué Cruz
I
ESTUDIOS CON RECONOCIMIENTO DE VALIDEZ OFICIAL SEP
NUMERO 972142 DE FECHA 10 DE JUNIO DE 1997
LOS MODELOS DE MICROSOFT SOLUTIONS FRAMEWORK APLICADOS A LA PLANIFICACIÓN Y GESTIÓN DE UN
PROYECTO TECNOLÓGICO DE UN SISTEMA DE AUDITORIA Y CONTROL INTERNO
TESIS
QUE PARA OBTENER EL TITULO DE
INGENIERO EN COMPUTACIÓN
PRESENTA:
JOSUÉ DAVID CRUZ SORIANO
ASESOR: ING. IVÁN CARLOS RIVERA GONZÁLEZ
MEXICO, D.F. MARZO 2007
i
Resumen
El presente documento plantea un análisis de la metodología a aplicar en la
planificación, el desarrollo y la gestión de un proyecto tecnológico de la migración de
un sistema de auditoria y control interno en Coca-Cola FEMSA.
En primera instancia se analiza el proceso actual de auditoria y sus características
principales, antecedentes históricos y el sistema actual del proceso de auditoria.
Posteriormente se muestran las necesidades y requerimientos actuales del área
participante para llevar a cabo este proyecto, considerando conceptos y prácticas de
uso en la ingeniería de software.
Se presentan los modelos y prácticas usados por la metodología de gestión de
proyectos de Microsoft Solutions Framework aplicados a la migración del sistema de
auditoria y control interno.
Aunque este trabajo se centra en los modelos de proceso y de equipo del proyecto,
se mencionan las elecciones tecnológicas para el comienzo del desarrollo del
mismo.
Finalmente se mencionan dos posibles escenarios de éxito del sistema al concluir
con las fases de prueba. Así también se realiza una proyección de los posibles usos
y necesidades del sistema a futuro.
ii
Agradecimientos y dedicatorias
A mis padres, por su comprensión, apoyo, paciencia y cariño.
A Jorge Díaz, por su apoyo, confianza y amistad.
A la familia Soriano, la familia Cruz, Edgar Garduño, Renato Vilchis, Humberto Uribe,
Virgilio Ruiz, Jorge Castro, Ricardo Macedo, Luis Rosete, Luis Gabriel León,
Francisco García, Pablo López, Luis Daniel Lucio.
A Clarita y a Valeria.
iii
INDICE
Índice de figuras ..................................................................................................... vi Índice de tablas...................................................................................................... vii Introducción .............................................................................................................1 Antecedentes...........................................................................................................5 Planteamiento del problema ....................................................................................7 Objetivo....................................................................................................................8 Propósito..................................................................................................................8 Justificación .............................................................................................................8 Alcance....................................................................................................................9 Metodología ...........................................................................................................10
CAPITULO I. MARCO CONCEPTUAL
1.1 ¿Qué se entiende por aplicar?.........................................................................13 1.2 ¿Qué se entiende por ofrecer? ........................................................................13 1.3 ¿Qué entiende el investigar por administrar? ..................................................13 1.4 ¿Qué se entiende por proceso? ......................................................................13 1.5 ¿Qué se entiende por garantizar? ...................................................................13 1.6 ¿Qué se entiende por planear? .......................................................................13 1.7 ¿Qué se entiende por planeación de proyectos? ............................................14 1.8 Definición de conceptos...................................................................................14 1.8.1 Proyecto.....................................................................................................14 1.8.2 Auditoria dentro de una empresa...............................................................15 1.8.3 Control Interno ...........................................................................................15 1.8.4 Migración ...................................................................................................15 1.8.5 Intranet.......................................................................................................15 1.8.6 Tablero de control ......................................................................................15 1.8.7 La metodología de una auditoria ...............................................................16
CAPITULO II. MARCO TEORICO
2.1 Estructura empresarial de servicios Microsoft .................................................18 2.2 Estructura de solución Microsoft Solution Framework (MSF) ..........................20 2.2.1 El modelo de equipo ..................................................................................22 2.2.1.1 Objetivos del equipo de trabajo MSF...................................................23 2.2.1.2 Roles del equipo ..................................................................................24 2.2.2 El modelo de proceso MSF........................................................................29 2.2.2.1 Fases del modelo de proceso MSF .....................................................31 2.2.2.2 Objetivos del modelo de proceso MSF ................................................32 2.2.3 El modelo de diseño de componentes MSF ..............................................34 2.2.4 Relación con el modo de proceso MSF .....................................................35 2.3 El modelo de aplicaciones de la estructura de solución Microsoft (MSF
Application Model)..............................................................................................36 2.3.1 Características del modelo de aplicaciones MSF ......................................36 2.3.1.1 Servicios de usuario.............................................................................37 2.3.1.2 Servicios de negocio............................................................................37 2.3.1.3 Servicios de la información ..................................................................38 2.3.2 Beneficios de las aplicaciones basadas en servicios.................................38 2.3.2.1 Flexibilidad para distribución................................................................38
iv
2.3.2.2 Paralelismo del proceso de desarrollo .................................................38 2.3.2.3 Uso eficiente de recursos y habilidades...............................................39 2.3.2.4 Rehúso de servicios.............................................................................39 2.3.2.5 Facilidad de mantenimiento .................................................................39
CAPITULO III. MARCO CONTEXTUAL
3.1 Coca-Cola FEMSA S.A. de C.V.......................................................................41 3.2. Antecedentes históricos..................................................................................41 3.3 Visión ...............................................................................................................43 3.4 Misión ..............................................................................................................43 3.5 Situación actual ...............................................................................................43 3.5.1 ¿Qué se mide en el sistema de auditoria actual? ......................................45 3.5.2 ¿Cómo se evalúan las auditorias?.............................................................46 3.5.2.1 Propósito del tablero de indicadores en la evaluación .........................47 3.5.2.2 Consideraciones y ponderaciones del tablero de indicadores .............48 3.5.2.3 El tablero de indicadores y su parte de Metodologia. ..........................48 3.5.2.4 Resultado del tablero de indicadores...................................................49 3.5.2.5 Fases del proceso de auditoria ............................................................50 3.5.2.6 Reportes de auditoria...........................................................................51 3.6 Modernización .................................................................................................52
CAPITULO IV. PLANIFICACION DEL PROYECTO DEL SISTEMA DE AUDITORIA Y CONTROL INTERNO
4.1 Los modelos de Microsoft Solution Framework, aplicados a la planificación del sistema de auditoria y control interno.................................................................54
4.2 Beneficios que aportan los modelos de Microsoft Solution Framework al diseño del sistema de auditoria y control interno...........................................................55
4.2.1 El modelo de equipo de Microsoft Solution Framework aplicado a la planificación del SACI ........................................................................................55
4.3 El modelo de proceso MSF, aplicado al diseño del SACI ................................57 4.3.1 El modelo de proceso y la planeación del SACI ........................................57 4.3.2 Fase del modelo de proceso MSF aplicada al SACI..................................58 4.3.3 Fase de conceptualización ........................................................................59 4.3.4 Fase de planeación....................................................................................61 4.3.5 Fase de estabilización ...............................................................................65 4.4 MSF Application Model al desarrollo del sistema de auditoria y control interno.
...........................................................................................................................66 4.4.1 Servicio del usuario del aplicativo SACI.....................................................66 4.4.1.1 Operación de la interfase y páginas.....................................................66 4.4.2 Servicios de negocio del SACI...................................................................68 4.4.3 Servicios de información del aplicativo ......................................................74 4.4.3.1 Herramientas de tecnología web .........................................................75 4.4.3.2 Plataforma de desarrollo web de SAP .................................................76 4.4.4 Propuesta de arquitectura para el sistema de auditoria y control interno ..78 4.5 Propuesta de desarrollo para el SACI, con base a la plataforma web de SAP 81 4.6 Fases de pruebas del SACI .............................................................................82 4.7 Fase de documentación...................................................................................82
v
Conclusiones .........................................................................................................83 Trabajos futuros.....................................................................................................89 Bibliografía.............................................................................................................91 Glosario .................................................................................................................94
vi
INDICE DE FIGURAS Figura 2.1 Estructura empresarial de servicios Microsoft ..........................................19 Figura 2.2 Roles de equipo .......................................................................................25 Figura 2.3 El modelo de equipo MSF orientado al cumplimiento de objetivos ..........29 Figura 2.4 El modelo de proceso MSF ......................................................................31 Figura 2.5 Modelo de diseño de componentes..........................................................36 Figura 3.1 Ponderaciones de los indicadores del tablero de control .........................48 Figura 4.1 Aplicación del modelo de equipo MSF al SACI ........................................55 Figura 4.2 Roles del modelo de equipo MSF aplicados al SACI ...............................56 Figura 4.3 Modelo de proceso MSF aplicado al SACI...............................................58 Figura 4.4 Cronograma del proyecto del SACI..........................................................61 Figura 4.5 Ambiente del SACI ...................................................................................62 Figura 4.6 Diseño lógico del SACI.............................................................................64 Figura 4.7 Diseño lógico del SACI.............................................................................69 Figura 4.8 Arquitectura cliente/servidor.....................................................................79 Figura 4.9 Arquitectura de servicios empresariales...................................................79 Figura 4.10 Estructura de costos sostenible..............................................................80 Figura 4.11 Desarrollo propuesto del SACI ...............................................................82
vii
INDICE DE TABLAS Tabla 1.1 Rangos de cumplimiento del tablero de indicadores .................................50 Tabla 4.1 El modelo de proceso MSF y su relación con el proceso de planeación...58
1
Introducción
2
Introducción
La información en una empresa es imprescindible para otorgar a la gerencia y a la
sociedad la posibilidad de conocer el ente sobre el cual tomara importantes
decisiones de carácter financiero y económico. Según Michael Porter “los
compradores “clientes” compiten en el sector industrial forzando la baja de precios,
negociando por una calidad superior o más servicios y haciendo que los
competidores compitan entre ellos”1.
El proceso de modernización dentro de Coca Cola FEMSA ha introducido
cambios en los sistemas financieros, operativos, administrativos y de información;
por lo que se hace necesario de normas técnicas de control interno, para establecer
pautas generales que orienten el accionar de sus entidades operativas y
administrativas, en un adecuado sistema de control interno para el logro de la
eficiencia, efectividad, economía y transparencia en la gestión que desarrollan.
Para lograr estos objetivos, se han implementado diversos sistemas a través
del tiempo, que han requerido de una constante revisión, tomando en cuenta el
volumen de información que se presenta y la necesidad de detectar oportunamente
cualquier desviación a las políticas establecidas.
El sistema actual de auditoria y control interno de Coca Cola FEMSA ha
cumplido con la encomienda de prestar servicio a los usuarios de nueve países del
grupo refresquero; sin embargo genera un servicio lento, inoportuno y no cubre con
1 Porter Michael.The competitive advantage of Nations, Free press, NewYork, 1990
3
las necesidades actuales del área, haciendo susceptible las alteraciones y el robo de
la información.
En el marco de la modernización surge la necesidad de crear un sistema
informático que automatice el proceso de auditoria realizados en cada unidad
operativa de manera organizada, para así mejorar los tiempos de respuesta, y a su
vez permita un rápido análisis de la información.
De esta manera surge la idea de desarrollar un sistema de información de
auditoria y control interno más moderno o SACI, como se mencionara a través del
presente trabajo.
El SACI basa su flujo de trabajo en el procedimiento actual de auditoria,
encontrando una metodología aplicable para la gestión de este proyecto y asegurar
el éxito del mismo.
El capitulo I, plantea el marco de conceptos que son importantes para la
realización de esta investigación.
En el capítulo II, se hace una analogía entre el sistema actual y el SACI,
orientando a la organización con hechos significativos del problema actual del
sistema, así mismo se menciona la estrategia de validez y confiabilidad que es
flexible para gestionar el proyecto del sistema
En el capítulo III, se describen las bases teóricas para llevar a cabo un
planteamiento de la gestión de un proyecto con la metodología de Microsoft
(Microsoft Solution Framework MSF), que más que ser una metodología para
desarrollar proyectos de sistemas de información, lo cuál implica cierta rigidez, se
apreciará que es flexible ya que sigue de manera sistemática una serie de modelos
análogos a las fases de la planeación formal, que abarcan las fases del diseño,
planeación, desarrollo e implantación. Los modelos propuestos en este capitulo son:
el modelo de equipo, el modelo de proceso y el modelo de diseño de componentes.
4
La utilización de los modelos mencionados, permitió hacer un análisis de cada
proceso que interviene en el sistema SACI y de los elementos que fueron migrados
hacia el ambiente Web; así como la integración de los recursos, gente y técnicas
necesarias para satisfacer los requerimientos y los objetivos del mismo.
Todo este análisis para el diseño del SACI se retomará en el capitulo IV, a fin
de detallar la planeación del proyecto, el aspecto técnico que involucra el desarrollo
del sistema y las herramientas o programas propuestos para el mismo, al seguir
utilizando el modelo Microsoft relacionado es decir, el modelo de aplicaciones.
Otros aspectos técnicos, como por ejemplo, el tema de la seguridad a través
de la red, la estructura físico de las redes y de sus componentes como son
servidores, estaciones de trabajo, conexiones etc. Serán tratados como variables no
controlables, es decir, aunque son elementos determinantes para la implantación de
los sistemas informáticos, nos serán objeto de análisis durante el trabajo de
investigación.
Finalmente, se viene a demostrar, que en este mundo global, se tenderá a
mezclar productos con metodologías de diversas fuentes para sacar al mercado
nuevas tecnologías que permitan a las organizaciones seguir a la vanguardia y
competir a los niveles que el inicio del siglo XXI está marcando.
5
Antecedentes
6
Antecedentes
A continuación se mencionan los trabajos los realizados respecto al tema tratado en
esta tesis.
Existe la evidencia que algún tipo de sistema de auditoria se practicó desde
tiempos remotos. Pero no obstante fue hasta la revolución industrial donde surgió la
necesidad de implementar un método más propio.
A partir de que aparecen las nuevas tecnologías, computadoras, etc., se
hacen revisar los procesos de auditoria en las empresas y se implementan nuevos
sistemas informáticos que apoyen a este proceso.
En la construcción de sistemas informáticos se han desarrollado muchas
metodologías de planificación y gestión de los proyectos, que apoyen y guíen a los
equipos de trabajo en el camino a la finalización y el éxito del mismo.
Proporcionando a las personas las herramientas necesarias. Estas metodologías no
están basadas propiamente a un caso en específico como el tratado en este trabajo,
pero si están implementadas para apoyar a cualquier proyecto tecnológico.
Dada la situación de cambios en los sistemas dentro de las compañías, con
motivo de satisfacer las necesidades cambiantes de las mismas, se hacen
planificaciones y estudios que facilitan la gestión de los equipos de trabajo que
participan en dicha tarea.
En este trabajo se investigaron las diferentes metodologías que se utilizaron
en proyectos de modernización de sistemas informáticos y que fueron casos de éxito
7
debido al apoyo de estas herramientas. Tal es el caso del Banco Industrial de
Venezuela, que cambio su sistema de Internet Banking con el apoyo de la tecnología
y los servicios de Microsoft. En este proyecto se conformo un equipo de trabajo para
desarrollar un nuevo Internet Banking a la altura de las necesidades de la entidad, y
acorde con la dinámica del sector financiero.
Para desarrollar el proyecto se utilizó el Modelo de Equipos del marco de
trabajo Microsoft Solution Framework (MSF) y Microsoft Operations Framework
(MOF), mediante el cual se identificaron los roles principales y sus respectivas
responsabilidades en las fases del proyecto, además de contemplar el
entrenamiento y soporte post-implantación.
La nueva aplicación fue desarrollada, tanto por el personal del BIV, como de
Microsoft, bajo la filosofía de transferencia de conocimientos. Es decir que Microsoft
en todo momento le estuvo indicando al personal del Banco todos los conceptos
acerca de la conceptualización de la solución.
Cabe recalcar que el nuevo Internet Banking se diseño, desarrolló y liberó en
ambiente de producción con éxito, en un período de tres meses, cumpliendo con las
expectativas y lo planeado con el Banco y a conseguido a corto plazo lograr un
descongestionamiento de las oficinas bancarias, mayor rapidez en la ejecución de
las transacciones, alta disponibilidad de la aplicación y mayores oportunidades de
negocio .
Planteamiento del problema
El sistema de auditoria y control interno de Coca-Cola FEMSA es un proceso
importante dentro de la compañía, ya que por medio de esta evaluación se puede
obtener una visión general del estado de los procesos y entes del negocio. Cambiar
este sistema por una más moderno y que aproveche la tecnología actual es un
proceso de un cambio difícil y riesgoso, y más que ser un proyecto tecnológicamente
hablando, complicado, es un proyecto que se debe planificar bien, ya que no puede
sufrir retrasos en su salida a producción por la operación de las auditorias que se
8
llevan periódicamente en la empresa. Otro factor clave en este tipo de proyectos, es
el cambio cultural que se genera en los usuarios del sistema y en los usuarios
funcionales, por lo que habrá que plantearse la pregunta de ¿cómo actuar ante
dicho cambio?
Las investigaciones que se realizaron en esta tesis sobre las mejores
prácticas y casos de éxito en otros proyectos de este tipo, como es el caso del
Banco Industrial de Venezuela, sugieren que es factible aplicar algunos modelos de
Microsoft Solution Framework al proyecto de modernización de auditoria y control
interno de Coca-Cola FEMSA. Por lo que se pretende con esta metodología
planificar el proyecto de una manera sana y factible a corto plazo para la realización
de este nuevo sistema.
Por los planteamientos antes mencionados, se plante la pregunta de ¿Cómo
planificar y gestionar el proyecto de auditoria y control interno, de una manera sana y
factible a corto plazo para que pueda ser implementado con éxito?
Objetivo
Aplicar en la planificación del proyecto de auditoria y control interno de Coca-Cola
FEMSA, los modelos pertinentes que ofrece Microsoft Solution Framework para que
sirvan como guía para administrar a la gente, los procesos en el desarrollo y las
actividades de entrenamiento.
Propósito
El propósito de este trabajo de tesis, consiste en la aplicación de los
modelos de Microsoft Solution Framework a la planeación del proyecto de auditoria y
control interno de Coca-Cola FEMSA, con el fin de que sean usados durante el ciclo
de vida del proyecto y así crear beneficios de rentabilidad y productividad en el
producto final.
Justificación
9
La razones por las que este trabajo de investigación es importante es
porque:
• Se podrá entregar el sistema de control interno dentro de las restricciones del
proyecto (tiempo, recursos, costos).
• Se podrán identificar todos los problemas o riesgos de importancia para el
usuario y manejarlos de forma oportuna.
• Se puede asegurar una implantación/replicación del sistema sin
contratiempos.
• Se obtiene una visión general del sistema.
Los beneficios que trae consigo este proyecto de investigación a la
organización, y al equipo entero involucrado en el mismo, es que:
• Se mantiene siempre el enfoque al usuario. Es decir, se ayuda a asegurar
que la aplicación de control interno implantada realmente es lo que el usuario
necesita, y que mejorará su desempeño.
• Permitirá desarrollar siguiendo una filosofía de reutilización de múltiples
componentes, lo cual reduce el tiempo necesario para desarrollar nuevas
aplicaciones, garantiza la uniformidad de interoperabilidad entre las mismas, y
las hace mucho más flexibles para incorporar cambios que sean necesarios
en el futuro.
• Se establece un equipo de trabajo balanceado, con tareas y objetivos
claramente definidos, que permitirán no solo desarrollar un buen sistema, sino
también en todo momento cuál es el grado real de avance del proyecto, y
cuáles son los riesgos que se corren si se decide hacer modificaciones al
mismo una vez desarrollado.
Alcance
El alcance de este trabajo abarca la investigación y análisis de los modelos de
Microsoft Solution Framework, considerados necesarios para un proyecto del tipo de
él sistema de auditoria y control interno, y los cuales se mencionan a continuación:
• El modelo de equipo.
10
• El modelo de proceso.
• Fase de conceptualización del proyecto.
• Fase de planeación.
• Fase de estabilización.
• Modelo de aplicación.
Metodología
La técnica de metodológica usada para este trabajo es de tipo analítico. Es decir
maneja juicios y síntesis. La síntesis considera los objetos como un todo. El método
que emplea el análisis y la síntesis separara el objeto de estudio en dos partes y,
una vez comprendido su esencia, construir un todo.
Los recursos y fuentes para recolectar los datos son:
• Libros
• Internet
El universo de estudio cae en un análisis enfocado a la planificación y
modernización de un sistema de auditoria y control interno de Coca-Cola FEMSA,
dentro del cuál están las siguientes fases:
• Realización del modelo de equipo. En esta fase se propondrán los elementos
humanos necesarios que conformarán el equipo de trabajo para la
elaboración del proyecto.
• Realización del modelo de proceso. Esta fase conformará el ciclo de vida que
aplicará a la realización del proyecto de auditoria y control interno.
• Fase de conceptualización. Esta conforma el entendimiento de los
requerimientos del sistema a construir.
• Realización de la planeación. En esta fase se crea el plan de trabajo para el
proyecto.
• Fase de estabilización. En esta fase se describen actividades como las
pruebas integrales, documentación, pruebas de aceptación y capacitación.
11
• Modelo de aplicación. Se plantea el modelo de la solución, tanto en la
interfase gráfica, herramientas y plataforma a utilizar.
12
Capítulo I
Marco Conceptual
13
El estudio de este trabajo se ubica en la planificación de un proyecto tecnológico,
aplicando la metodología que ofrece Microsoft Solution Framework, por lo que a
continuación se tratan los conceptos relacionados con este tema y, así mismo lo que
el investigador entiende por algunos otros más.
1.1 ¿Qué se entiende por aplicar?
Aplicar es poner una cosa sobre otra de modo que quede adherida a ella,
pegándola o sin pegarla.
1.2 ¿Qué se entiende por ofrecer?
Presentar a alguien una cosa que puede tomar, mirar, utilizar o disfrutar, o también decirle que puede hacer algo de una determinada forma.
1.3 ¿Qué entiende el investigador por administrar? Dirigir la economía de una persona o de una entidad cualquiera. También
entenderse como el acto de cuidar los intereses de alguien.
1.4 ¿Qué se entiende por proceso? Por proceso se entiende el desarrollo o marcha de alguna cosa. Por ejemplo,
el proceso para construir un determinado producto químico.
1.5 ¿Qué se entiende por garantizar?
Es dar u ofrecer garantías a cierta cosa. Es un compromiso para que algo
funcione bien.
1.6 ¿Qué se entiende por planear?
Es el sentido más universal implica tener uno o más objetivos a realizar junto con las acciones requeridas para concluirse exitosamente.
14
Es un proceso que consiste básicamente en tomar decisiones por adelantado.
1.7 ¿Qué se entiende por planeación de proyectos?
Definición del problema, metas y requisitos. La definición del problema requiere de un entendimiento cabal del dominio del problema. Las técnicas para obtener este conocimiento, son entrevistas con el cliente, observación de la problemática, etc. La planeación de un proyecto es tecnológico, es determinar lo apropiado de una solución computacional. Además de ser eficaz en términos de costo, un sistema computacional debe aceptarse social y políticamente. Las metas y los requisitos de alto nivel se pueden expresar en términos de atributos de calidad que el sistema deberá poseer. Es importante que los criterios de alto nivel para la aceptación del sistema se definan durante la fase de planeación. Todo proyecto debe tener una estructura organizacional, una de equipos, y un mecanismo para asignar y evaluar el trabajo. Es además importante tomar en cuenta las actividades adicionales como la planeación de la administración de la configuración, control de calidad, validación y verificación externa, así como las herramientas y técnicas que dependen de cada fase del proyecto.
1.8 Definición de conceptos 1.8.1 Proyecto
Un proyecto es cualquier empresa humana con un claro principio y un claro final.
Los proyectos poseen algunas características comunes:
• Combinación de actividades. • Relación secuencial entre actividades. • Preocupación por el tiempo. • Preocupación por los recursos.
15
1.8.2 Auditoria dentro una empresa “Auditoria es la recopilación de datos sobre información cuantificable de una entidad económica para determinar e informar sobre el grado de correspondencia entre la información y los criterios establecidos”2. En otras palabras la auditoria comprueba que lo que se dice que se tiene, se tenga en realidad, y además da enfoque de la situación de alguna entidad. 1.8.3 Control Interno
“Es un proceso cíclico y sistemático que permite mejorar los resultados de una compañía, evitando perdidas por ineficiencias en control” y reflejando la realidad interna”3. 1.8.4 Migración Hablando de tecnologías, la migración es el proceso de trasladar el uso de un ambiente de operaciones hacia otro ambiente operacional, en la mayoría de los casos a otro ambiente mejor. La migración involucra el movimiento hacia un nuevo hardware o software. “La migración se emplea para definir los procesos involucrados en la conversión de sistemas, o base de datos, que van desde la exportación de los sistema heredados, hasta la manipulación o transformación, concluyendo con la recepción de nuevos sistemas4”. 1.8.5 Intranet
Una intranet es una red privada de computadoras que utiliza tecnologías
basadas en Internet, es usada por una única organización, facilita la comunicación y
accesos a la información.
1.8.6 Tablero de control El concepto de tablero de control parte de la idea de configurar un tablero cuyo objetivo y utilidad básica es diagnosticar adecuadamente una situación.
2 Nidiarem. Auditoria, concepto de auditoria, historia y evoluc ión. España. http://riie.com.mx/?a=28897 3 Uron Gabril. Hacia el efectivo cumplimiento de las metas. http://gestiopolis.com/canales2/gerencia/1/planaccion.html 4 Migración . http://pcwebopedia.com/term/migracion.html
16
1.8.7 La metodología de una auditoria
La metodología comienza identificando como áreas clave a aquellos “temas
relevantes a monitorear y cuyo fracaso permanente impediría la continuidad y el
progreso de una empresa o sector dentro de un entorno competitivo, aun cuando el
resultado de todas las demás áreas fuera bueno”.
17
Capítulo II
Marco Teórico
18
El marco teórico presentado en este capítulo orientará al lector sobre los
fundamentos teóricos, que permitirán tener una precisión en la comprensión del
asunto que se aborda en este trabajo.
2.1 Estructura empresarial de servicios Microsoft
“Hay en muchas compañías una generalizada falta de apreciación de la
importancia de la planeación de proyectos. La alta administración no parece
comprender su necesidad y, por tanto, casi nunca destina el tiempo suficiente a la
planeación adecuada. Algunos altos ejecutivos consideran la planeación como algo
que realiza un departamento o es tarea que deben realizar los gerentes en una junta
fuera de la oficina una vez al año, y no como algo que afecta a su vida diaria. No
consideran que haya gran relación entre el plan estratégico y el trabajo cotidiano de
la compañía. Piensan que las personas tienden a hacer hoy lo que hicieron ayer, lo
que al parecer no requiere de una planeación especial. Quizás estén acostumbrados
a trabajar en departamentos que utilizan procesos y productos repetibles”5.
La Estructura Empresarial de Servicios Microsoft (Enterprise Services
Framework ESF), esta constituida por tres elementos o subestructuras, orientadas a
diferentes fases del ciclo de vida de los proyectos de tecnologías de información
dirigidas a las empresas. Esta especialización le permite a cada estructura
proporcionar información a detalle acerca de los recursos humanos, procesos y
tecnología que se requiere para el éxito de los proyectos. El diagrama de la figura
2.1 muestra las tres estructuras que conforman esta plataforma de servicios de
Microsoft.
5 Graham J. Robert, England L. Randall, Administracion de proyectos exitosos p.p 67-68 Pearson Prentice
19
Figura 2.1 Estructura empresarial de servicios Microsoft6.
La primera es la estructura de preparación Microsoft (Microsoft Readiness
Framework). Ofrece un acrecimiento estructurado para asegurar eficientemente a las
organizaciones sobre requerimientos técnicos para planear, construir y administrar
soluciones de tecnologías de información bajo el ambiente de Microsoft. Ayuda a las
organizaciones a alcanzar esos requerimientos con la debida planeación,
identificando la competencia organizacional, las asignaciones individuales y de la
organización, así como también proporciona los planes de capacitación, y el material
de entrenamiento apropiado para acrecentar y mantener el potencial de las
organizaciones en lo que se refiere a tecnologías de información.
La segunda es la estructura de solución Microsoft (Microsoft Solution
Framework MSF), la cual es la guía para las fases de planeación, construcción e
implantación de un proyecto a lo largo de su ciclo de vida. Esta guía incluye
documentación, casos de estudio, y capacitación en las áreas de arquitectura
empresarial, desarrollo de aplicaciones, diseño de componentes, etc.
La tercera es la estructura de operaciones Microsoft (Microsoft Operation
Framework MOF). Provee la guía técnica para analizar la confiabilidad del sistema 6 Fuente: Traducción de grafica tomada de Microsoft Solutions Framework, White Paper, Microsoft Corporation.
20
en producción, así como la disponibilidad y capacidad de manejo sobre tecnologías
y productos de software. Esta estructura consiste de documentación, guías
operativas, herramientas de asignación, casos de estudio, etc.
2.2 Estructura de solución Microsoft Solution Frame work (MSF)
El desarrollo de sistemas tiene una misión en común: el desarrollar software
de calidad que sea entregado a tiempo, y que cumpla los requerimientos de
presupuesto y del negocio sin un proceso que pueda guiar a los miembros del
equipo de desarrollo del proyecto, estas metas son prácticamente inalcanzables. Los
resultados se vuelven impredecibles, las pruebas se vuelven caras y tediosas, y
seguramente el proyecto fracasará.
Una manera de alcanzar el éxito es seguir los pasos de otros, esto no
significa que se debe de esperar a ver lo que hacen los demás para después hacer
una copia, si no más bien seguir los pasos de las personas que han tenido éxito
para seguir su mismo planteamiento.
La empresa líder en software desde hace mas de 25 años, Microsoft, integra
modelos principios y guías que conforman un proceso difícil de seguir para el diseño
e implantación de sistemas, este proceso se conoce como Estructura de Solución
Microsoft o Microsoft Solution Framework (MSF) como se mencionará a lo largo del
presente trabajo.
MSF integra las experiencias de profesionales de tecnologías de información.
Únicamente las prácticas exitosas se incorporan a este modelo donde una amplia
gama de conocimientos de programadores, socios de negocio, grupos de
tecnologías de información, clientes y desarrolladores de productos. Este modelo
ayuda a integrar los ambientes tanto de tecnología como de negocio, construye
equipos de trabajo, pone al descubierto los riesgos, identifica los costos, permite la
creación de diseños flexibles, mejora la implantación y anticipa las necesidades de
los usuarios finales y del cliente. Utilizando los recursos, guías y prácticas de MSF,
21
se creara un mejor ambiente de trabajo y se podrá disminuir la probabilidad de
fracaso de un proyecto.
Cada proyecto donde se desarrolla software implica un riesgo, bajo el
esquema de MSF, un riesgo se define como la posibilidad de sufrir algún tipo de
perdida inherente a cualquier proyecto, esto no necesariamente convierte al riesgo
en un punto en contra sino al contrario se puede ver como una oportunidad. Al inicio
se comento que es bueno seguir el ejemplo de otros, la competencia puede
absorber los riesgos así como los beneficios que se den durante un proyecto.
Además de los principios del manejo de riesgo, MSF proporciona otros modelos que
ayudan al éxito de un proyecto. MSF consiste de siete modelos, los cuales se
pueden utilizar de manera individual o combinada dependiendo del tipo de
aplicación, es decir el programa final que se pretende desarrollar, no es obligatorio,
el uso de todos y solo se pueden implementar los modelos que las necesidades del
proyecto específico y determine por sus características propias. Los modelos MSF
son:
• Modelo de equipo.
• Modelo de proceso.
• Modelo de diseño.
• Modelo de diseño de componentes.
• Modelo de aplicación.
• Modelo de infraestructura.
Cada uno de los modelos se utiliza para diferentes propósitos durante el
proyecto, a fin de dirigir los diferentes factores que determinan el éxito del mismo.
“El desempeño de todo sistema, y por extensión de una empresa, nunca es
igual a la suma del desempeño de cada una de sus partes. Es el producto de cada
una de sus partes”7.
7 Ackoff, Russel L. Capsulas de Ackoff p.149 Edit. Limusa México, México 1999
22
El factor clave para aplicar el modelo MSF, es saber diferenciar los diversos
tipos de proyectos. Dado que el proyecto en cuestión es la migración de un sistema
convencional hacia un sistema intranet, se considera un proyecto de desarrollo de
código para las interfaces tanto con el usuario (paginas Web), como para programas
que se comuniquen con la base de datos, así como la labor de pruebas unitarias e
integrales antes de liberar a producción la versión definitiva.
Dadas las características del proyecto que se estudia, los modelos de
Microsoft que se analizarán en el presente capitulo son: el de aplicación y el de
infraestructura.
2.2.1 El modelo de equipo
Uno de los recursos fundamentales de cualquier proyecto es el equipo de
trabajo que participa en él, sin un efectivo y experimentado equipo de individuos
nada podría llevar a cabo. El modelo de equipo reconoce esta importancia, y le
facilita a los miembros del equipo aprovechar al máximo su experiencia y creatividad
durante su participación en el proyecto.
El modelo de equipo de trabajo, promueve la responsabilidad individual,
autoridad y las decisiones compartidas. Cada individuo del equipo conoce
exactamente su rol y posee las habilidades, autoridad y responsabilidad para llevar a
cabo las tareas acordes a su rol.
Las estructuras de trabajo tradicionales o jerárquicas, aunque bien han tenido
éxito y han sido apropiadas para planear proyectos de tecnologías de información
(IT), el modelo de equipo MSF, proporciona otra alternativa. Este modelo no
pretende reemplazar o cambiar el organigrama tradicional. Cabe mencionar algunos
inconvenientes de los equipos de trabajo basados en una estructura jerárquica
tradicional.
• Las estructuras jerárquicas de equipo centralizan el control y la toma de
decisiones detienen la creatividad, retrasan la toma de decisiones y cierran
los canales de comunicación.
23
• Los miembros del equipo en ocasiones no entienden sus roles
apropiadamente surgiendo de esta manera malentendidos.
• Los equipos tienden a desacoplarse sin no tienen claramente definidos sus
objetivos.
Los equipos de trabajo formados por el modelo de equipos MSF son
pequeños, multidisciplinarios y cada uno de los miembros comparte las
responsabilidades y equilibran sus capacidades. Tienen una misma visión del
proyecto, altos estándares de calidad y gran disponibilidad para aprender.
“El primer paso en la lucha contra la suboptimizacion (cuando los
administradores de cada proyecto tratan de optimizarlo mediante el acaparamiento
de los recursos o desempeñándose en forma independiente de todos los demás) y a
favor de la puesta en práctica del énfasis estratégico es que todos los participantes
comprendan el sistema completo”8.
2.2.1.1 Objetivos del equipo de trabajo MSF
Hay seis objetivos que son la base del modelo de equipo de trabajo MSF,
cada equipo debe de esforzarse por llevar a cabo estos seis objetivos, los cuales
son:
• Satisfacción del cliente. El hecho de satisfacer al cliente es el principal
objetivo del equipo de trabajo durante el proyecto. Aun cuando un proyecto se
pueda considerar exitoso, si no se ha considerado la satisfacción del cliente
no se considerará del todo exitoso.
• Entrega a tiempo. A lo largo de la historia muchos proyectos de tecnologías
de información han sufrido retrasos significativos y por consiguiente, perdidas
económicas; esto reduce su rentabilidad, provoca retrasos y daña la
confianza del cliente para proyectos futuros. Un producto que se entrega a
destiempo o que se encuentra por encima del presupuesto no se considera
un éxito.
8 Graham J.Robert, England L. Randall. Administración de proyectos exitosos p. 38 Pearson Prentice Hall.
24
• Entrega acorde a las especificaciones con base a los requerimientos del
usuario. Este objetivo incluye dos puntos. El primero es que el equipo debe
definir las especificaciones, que estarán basadas en lo que el usuario
necesita y lo que quiere. El segundo es que el equipo debe de entregar un
producto con el cual estén ambas partes de acuerdo.
• Liberar la versión después de solucionar todos los problemas reportados. El
equipo no liberara la versión hasta que haya identificado todos los problemas,
y los haya canalizado de algún modo, ya sea corrigiéndolos o
mencionándolos como tópicos por resolver para la siguiente liberación de
versión.
• Resaltar el desempeño del usuario. El producto se diseñara con el
desempeño del usuario en mente, de lo contrario, el usuario se podrá volver
ineficiente, lo cual reducirá su adaptación al cambio. A pesar de que un
producto, se encuentre entregado a tiempo si no ayuda al usuario a
incrementar su productividad en el trabajo.
• Manejo de proceso y transparencia en la implantación. El éxito de un proyecto
se mide por el costo a lo largo del tiempo de vida del producto, no únicamente
por los costos de desarrollo inmediatos. Un equipo exitoso creará un producto
que se implantará sin mucha dificultad y tendrá la certeza de que reforzara la
confianza del usuario por el producto.
2.2.1.2 Roles del equipo
Los equipos están conformados por seis roles: gerencia de producto, gerencia
de programa, desarrollo, pruebas, capacitación al usuario y gerencia de logística. En
cualquier proyecto estos roles deben de estar representados. El número de
personas asignadas a cada rol variará dependiendo del tamaño del equipo, por
ejemplo en un equipo pequeño, una persona podría ocupar más de un rol. La figura
2.2 muestra los roles del equipo.
25
Figura 2.2 Roles de equipo9
• Gerencia de producto
Generalmente, no tiene importancia el orden en el cual aparezcan los seis
roles del modelo de equipo MSF, sin embargo, la gerencia de producto es la
excepción, este rol aparece primero ya que él gerente de producto dará inicio al
proyecto en respuesta a una necesidad del cliente. Entre las principales actividades
que lleva a cabo se encuentran las siguientes:
1. Actúa como representante del cliente hacia el equipo. Dirige al equipo a
compartir la visión del cliente y sus expectativas. Existe una diferencia muy
importante entre el cliente y el usuario final.
2. Actúa como representante del equipo hacia el cliente. Esta convencido de que
el cliente entiende la labor que realiza el equipo y de lo que el equipo necesita
para cumplir las expectativas del cliente.
3. Manejo de las expectativas del cliente. Si el cliente espera una cosa y recibe
otra, el proyecto fallará. El gerente de producto se encargará de que el cliente
valore lo que se encuentra sucediendo con el producto y se asegura de que
las expectativas del cliente y el producto sean congruentes.
9 Fuente: Traducción de gráfica tomada de Microsoft Solution Framework, White Paper, Microsoft Corporation
26
4. Desarrolla, mantiene y lleva a cabo el plan del proyecto. Maneja la
identificación de funcionalidad adicional y le asigna prioridades. La gerencia
de producto maneja el enfoque del proyecto. El manejo de la funcionalidad
adicional debe de hacerse mediante un control de cambios donde se debe
considerar recursos y tiempo.
5. Desarrolla, mantiene y ejecuta el plan de comunicación. El plan de
comunicación describe como la información del producto será transmitida
hacia el cliente y los usuarios. Para el caso de un producto externo, se puede
ver como un plan de ventas. Pero generalmente, para un desarrollo interno,
se puede ver como un plan de comunicaciones.
• Gerencia de programa
El rol de gerente de programa es muy similar al del líder de proyecto o
gerente de proyecto de un equipo jerárquico. El gerente de programa es el
coordinador del proyecto pero no propiamente el líder. Algunas actividades de las
que se encarga son las siguientes:
1. Conducir todo el proceso en su conjunto. El gerente de programa es él
responsable de entregar el producto correcto en el tiempo exacto. El gerente
de programa es el encargado de seguir la calendarización del proyecto,
reportar su estatus y el manejo de asignación de recursos. A diferencia de la
estructura tradicional la labor del gerente del programa permite al resto del
equipo conocer y comprometerse con sus objetivos, más que ser un
mecanismo de control hacia los miembros del equipo.
2. Manejo de la “salud” del equipo y de los roles. Es crítico para el éxito del
proyecto el hecho de mantener al equipo motivado, así como el mantener los
roles bien definidos a través del mismo.
• Desarrollo
Las actividades que se encarga el rol de desarrollo son las siguientes:
27
1. Construir y probar el producto para que se cumpla con las especificaciones y
expectativas del cliente. El desarrollo será responsable de construir el
producto que el cliente desea.
2. Realizar las estimaciones de tiempo y esfuerzo para completar el desarrollo
del producto. El resultado de esta estimación, determinará la calendarizacion
global del producto.
3. Ser un asesor técnico para el equipo. Al inicio del desarrollo, los
desarrolladores proveen de asesoría técnica, evaluando tecnologías, y
validando soluciones alternativas y potenciales a fin de reducir riesgos
tecnológicos.
4. Instalar e implantar el producto. Los desarrolladores son los encargados de
elaborar los scripts o guiones de instalación y el código necesario para la
puesta en marcha del producto.
5. Desarrollo de la documentación técnica del producto.
A menudo es el programador (desarrollador), el que descubre errores y
ambigüedades en la “propuesta de requerimientos” (especificación de la
funcionalidad) entregada por el analista, (gerente de producto) pues es durante la
programación cuando se detecta si algo falta, está mal o confuso, el programador
tiene dos opciones; pedirle una aclaración al analista o bien preguntarle al usuario.
• Pruebas
El propósito del rol de pruebas es poder determinar el estatus del producto en
cualquier momento, identificando los defectos o fallas durante la fase de
implantación.
Lo primero que hay que entender es que hay distintas estrategias de prueba;
las dos más comunes se conocen como prueba ascendente y descendente. El
enfoque ascendente empieza por probar módulos individuales pequeños
separadamente; esto a menudo se conoce como prueba de unidades, prueba de
módulos, o prueba de programas. Luego los módulos individuales se combinan
unidades cada vez mas grandes que se probaran en masa; esto se conoce como
pruebas de subsistemas. “Finalmente, todos los componentes del sistema se
28
combinan para probarse; esto se conoce como prueba del sistema, y suele estar
seguido de las pruebas de aceptación, donde se permite al usuario usar sus propios
casos de prueba para verificar que el sistema este trabajando de manera correcta”10.
Las principales actividades del rol de pruebas son las siguientes:
1. Desarrollo del plan de pruebas.
2. Manejo del proceso de construcción, para el caso de proyectos
pequeños.
3. Determinar el nivel de tolerancia de errores del producto.
• Capacitación del usuario
Sus principales actividades son:
1. Actuar como representante del equipo ante el usuario final.
Frecuentemente el material de apoyo que se elabora se entabla un
acercamiento entre el usuario final y sus expectativas.
2. Actuar como representante del usuario final hacia el equipo. Tras de
esperarse que se tenga un entendimiento del usuario y de sus
necesidades para que se reflejen hacia los miembros del equipo.
3. Participar en la definición de los requerimientos del usuario, en
conjunción con el gerente de programa.
4. Desarrollar material de ayuda complementaria, como por ejemplo
manuales de usuario, ayudas en línea e inclusive a la impartición de
cursos de capacitación si es requerido.
• Gerencia de logística
Actuar como intermediario entre el equipo técnico y el área de soporte
técnico. Elabora la documentación técnica sobre la instalación en la fase de pruebas.
10 Yourdan Edgard. Análisis estructurado moderno p. 65 Pearson Pentice Hall. México 1993
29
Existe un mapeo uno a uno entre cada uno de los roles del equipo, orientada
al cumplimiento de los objetivos base del modelo. La figura 2.3 enfatiza esta
relación.
Cabe hacer mención que para el estudio del proyecto del sistema SACI, no se
adecuara el último rol, la gerencia de logística, como se explicará más adelante.
Figura 2.3 El modelo de equipo MSF orientado al cumplimiento de objetivos11
2.2.2 El modelo de proceso MSF
Cada desarrollo de software tiene su ciclo de vida que incluye todas las
actividades necesarias que involucra este desarrollo hasta poder liberar la primera
versión del producto. La función principal de un modelo de ciclo de vida es la de
establecer el orden en el cual el proyecto se especifican, implementan, prueban y se
ejecutan sus actividades. El modelo de ciclo de vida apropiado puede delinear el
proyecto y con esto asegurar que cada paso lleve al éxito del mismo.
Los modelos de procesos establecen un orden para desempeñar las
actividades de un proyecto, de esta forma representan el ciclo de vida de un
proyecto. Existen diversos tipos de modelos de procesos actualmente en el ámbito
11 Fuente: Traducción de grafica tomada de Microsoft Solutions Framework, White Paper, Microsoft corporation.
30
de negocios. El modelo de procesos MSF tiene su origen en los procesos que usa
Microsoft para desarrollo de aplicaciones así como contiene algunos principios de
los modelos de procesos más populares que se pueden aplicar de manera general a
proyectos de diversos tipos. Es un modelo iterativo, basado en fases y dirigido a
objetivos.
El modelo de cascada y el de espiral son dos de los modelos de procesos
más populares actualmente en la industria.
El modelo de espiral. Este modelo se dirige hacia la refinación de los
requerimientos y estimados para un proyecto. Este modelo de espiral puede ser muy
efectivo cuando se utiliza para desarrollo rápido de aplicaciones en proyectos a
pequeña escala. Este tipo de modelo produce sinergia entre el equipo desarrollador
y el cliente, debido a que el cliente se involucra activamente en todas las fases del
proyecto.
Este modelo de espiral esta orientado hacia el riesgo que divide el proyecto
en diferentes subproyectos. Cada subproyecto se dirige a uno o unos de los riesgos
principales antes de que se identifiquen como tales. El modelo espiral permite
fomentar la creatividad y permite un manejo del riesgo debido a su naturaleza
cíclica.
El modelo de procesos MSF combina ambos modelos: el de cascada y el de
espiral, obteniendo los beneficios de la planeación por objetivos del modelo de
cascada, así como los beneficios de creatividad y la retroalimentación del modelo
espiral. La figura 2.4 muestra el modelo general de proceso MSF.
31
Figura 2.4 El modelo de proceso MSF12
2.2.2.1 Fases del modelo de proceso MSF
El modelo MSF proporciona una estructura de planeación de proyectos que
consta de cuatro distintas fases. Cada fase concluye con un objetivo culminado. El
tipo de cada una de las fases y de los objetivos, dependen del tipo de proyecto que
se requiera aplicar al modelo.
Para los proyectos de tipo de desarrollo de aplicaciones. El modelo de
proceso consta de las siguientes fases:
• Conceptualización. En esta etapa se logra un consenso entre el equipo de
trabajo y el cliente acerca de la visión de los objetivos y las restricciones. En
un primer entregable se plasma un análisis tomando en cuenta el problema
de negocio, una descripción de los objetivos del producto, de los tipos de
usuarios del sistema, etc. Esta fase termina con el objetivo de visión
aprobada, que se explicara con mayor detalle en la siguiente sección.
12 Fuente: Traducción de gráfica tomada de Microsoft Solutions Framework, White Paper, Microsoft corporation
32
• Planeación . Durante esta etapa el equipo bosqueja las especificaciones
funcionales del sistema, un plan global y una calendarización del proyecto. El
detalle de la especificación funcional describe lo que se va a desarrollar, los
objetivos del mismo, características, etc. El plan describe como se va a
construir el sistema, y la calendarización señala los tiempos para efectuar las
actividades inherentes al proyecto. La fase culmina con el objetivo de plan de
proyecto aprobado, lo que se traduce en la aceptación por parte del clienta
para iniciar el desarrollo del aplicativo.
• Desarrollo . Durante la fase de desarrollo, el equipo se orienta a la
construcción y prueba del nuevo sistema. En esta fase se liberan
paralelamente versiones preliminares de prueba asegurándose de esta
manera una sincronía entre todas las piezas de software.
• Estabilización . Esta fase comienza con las pruebas de aceptación y termina
con la aceptación total del cliente. Las pruebas en esta fase son pruebas lo
mas apegadas a la realidad. El equipo se enfoca a resolver los detalles que
surjan y tener listo el producto para la entrega final. Esta parte concluye con la
liberación del producto final.
2.2.2.2 Objetivos del modelo de proceso MSF
El modelo de procesos MSF se encuentra basado en objetivos alcanzables a
corto plazo, estos objetivos se revisan y actúan como puntos de sincronía más que
ser solamente puntos estáticos. Permiten al equipo ajustar el enfoque del proyecto
para reflejar los requerimientos del cliente que vayan cambiando, con el fin de
vislumbrar los posibles riesgos a lo largo del proyecto.
Los objetivos se alcanzan cuando los miembros del equipo sincronizan sus
entregables hacia el cliente y los usuarios finales, estos entregables pueden
traducirse en documentos, operaciones, programación (código), soporte, personal de
apoyo, etc.
33
• Objetivo de visión aprobada
El primer objetivo terminado al finalizar la etapa de conceptualización, es el
objetivo de visión aprobada. Este primer objetivo se cumple cuando el equipo de
trabajo llega a un acuerdo con el cliente acerca del alcance del proyecto, esto
incluye lo que el sistema hará y lo que no. La fase de conceptualización identifica las
necesidades primarias para que el proyecto sea exitoso.
El equipo tendrá una visión clara de lo que el cliente espera. El tener una
perspectiva general de los objetivos y restricciones del proyecto establece las bases
de un proyecto formal de planeación. Los entregables de esta fase son:
• Documentación de enfoque
• Asignación de riesgo.
• Objetivo de plan de proyecto aprobado
La fase de planeación culmina con el objetivo del plan de proyecto aprobado.
En este segundo objetivo, el equipo de trabajo y el cliente establecen que es lo que
el sistema hará. Se puede decir que es básicamente el contrato con el cliente para
proceder con el proyecto.
Los entregables de este objetivo son:
• Especificación de funcionalidad.
• Asignación de riesgo
• Calendarización del proyecto.
• Objetivo de enfoque completo
La etapa de desarrollo culmina con el objetivo de enfoque completo. En este
punto el producto se encuentra casi listo, la mayor parte de la funcionalidad esta
desarrollada, y se encuentra preparado para la fase de pruebas externas o de
34
usuarios finales, a su vez se encuentra listo para la última fase del proceso que es la
estabilización. Este objetivo es importante ya que brinda la oportunidad de todo el
personal involucrado en el producto (cliente, usuario final, personal de operación y
soporte), pueda identificar algún detalle que se detecte para corregirlo antes de la
liberación final. Los entregables en esta etapa son los siguientes:
• Código fuente y programas ejecutables.
• Especificaciones de pruebas y casos de prueba.
• Plan de proyecto y calendarización del mismo.
• Objetivo de liberación
Una vez corregidos los detalles o pendientes detectados en la fase anterior y
una vez estando de acuerdo con el cliente se entregará la versión liberada del
producto.
• Versión en disco con los elementos necesarios para la instalación del
producto.
• Notas acerca de la versión entregada
• Resultado de las pruebas.
• Código fuente y programas ejecutables.
• Documentación del proyecto.
2.2.3 El modelo de diseño de componentes MSF
“La actividad de diseño se dedica a asignar porciones de la especificación a
procesadores adecuados (según maquinas o humanos) y a labores apropiadas (o
tareas, participaciones, etc.) dentro de cada procesador. Dentro de cada labor, la
actividad de diseño se dedica a la creación de una jerarquía de módulos de
programas y de interfaces entre ellos para implantar la especificación creada con
anterioridad”13.
13 Yourdan Edgard. Análisis estructurado moderno pp. 101-102. Pearson Prentice Hall. México 1993
35
El modelo de diseño de componentes MSF es la estructura secuencial de tres
actividades del diseño de un proyecto: el diseño conceptual; lógico y físico.
• Diseño conceptual : el principal objetivo del diseño conceptual es identificar
las necesidades del negocio y entender perfectamente lo que el usuario hace
y lo que necesita. En esta parte del diseño se bosquejan los diferentes
escenarios creados en conjunto con el cliente.
• Diseño lógico . El diseño lógico presenta el detalle de lo que el sistema hará
para satisfacer las necesidades del cliente. Se presentan las estructuras de
comunicación entre cada uno de los elementos del sistema.
• Diseño físico . El diseño físico se enfoca hacia la tecnología con la que se
desarrollara el nuevo sistema. El objetivo será aplicar los elementos
tecnológicos al diseño lógico tales como consideraciones de implantación, y
desempeño; estos elementos son desde el lenguaje de programación, la
plataforma de base de datos, estructura de la red que comunicará a los
equipos de cómputo, etc. Se obtendrá a detalle la estructura del sistema
como un todo.
2.2.4 Relación con el modo de proceso MSF
Existe flexibilidad entre los puntos de comienzo y fin para las actividades de
diseño. Es posible comenzar el diseño conceptual al principio de la fase de
conceptualización, también muchas de las actividades del diseño se pueden realizar
en paralelo simultáneamente; sin embargo, a pesar de esta flexibilidad, es
recomendable seguir un proceso secuencial en la medida de lo posible. El equipo
comienza el diseño lógico antes del diseño físico.
En el modelo de proceso MSF, el diseño de los componentes ocurre dentro
de la fase de planeación como parte del desarrollo de las especificaciones de
funcionalidad; con la cual se vendrán las bases para el desarrollo del plan de
proyecto y su calendarización. La siguiente figura muestra un corte en el modelo de
proceso MSF, donde se resalta la fase de planeación y la representación de las
distintas etapas del diseño.
36
Figura 2.5 Modelo de diseño de componentes14
2.3 El modelo de aplicaciones de la estructura de s olución Microsoft (MSF Application Model)
La estructura de soluciones Microsoft visualiza la creación de aplicaciones
(software) como una red lógica de servicios cooperativos entre los clientes y el
equipo de desarrollo. Estos servicios se distribuyen a través de límites físicos y de
funcionalidad para apoyar las necesidades de la solución de negocio, y que a su vez
pueden ser realizados para apoyar diferentes aplicaciones. De esta manera una
aplicación deja de implementarse de una manera tradicional o clásica y se entrega
como red lógica con servicios reutilizables.
El enfoque de servicios es la nueva forma de una red lógica de servicios
cooperativos y es la filosofía del modelo de aplicaciones MSF. En esta visión de
aplicaciones, los servicios se pueden compartir entre aplicaciones.
2.3.1 Características del modelo de aplicaciones MS F
El modelo de aplicaciones MSF:
14 Fuente: Traducción de grafica tomada de Microsoft Solutions Framework, White Paper, Microsoft Corporation.
37
• Establece definiciones, reglas y relaciones. Un modelo de aplicación
establece las definiciones, reglas y relaciones que construirán la
estructura de la aplicación. Sirve como la base para el intercambio de
ideas durante el diseño lógico de una aplicación. El modelo de
aplicaciones MSF muestra como se estructura la aplicación, no como
será implementada.
• Hace consistente la relación entre el diseño de la aplicación y el
desarrollo de la misma.
• Utiliza un diseño de componentes basado en servicios. Una
organización puede utilizar más de un modelo de aplicación para
adecuar los diferentes tipos de aplicaciones que se desarrollen.
El modelo de aplicaciones utiliza las siguientes categorías de servicio:
1. De usuario.
2. De negocio.
3. De información.
2.3.1.1 Servicios de usuario
Los servicios del usuario, se refieren a como el aplicativo va a interactuar con
el usuario, por medio de una interfase con el mismo. Entre las funciones de los
servicios del usuario están:
• Proveer una interfase ya sea visual o de otro tipo, la cuál estará dirigida al
usuario, el cuál puede ser una persona o bien otro aplicativo.
• Presentar la información que se extrae de algún medio de almacenamiento
como una base de datos; o también como el usuario alimentará al sistema,
por ejemplo, pantallas para capturar información.
• Esconder información que el usuario no deba ver.
38
2.3.1.2 Servicios de negocio
Los servicios de negocio se refieren a como se llevará a cabo la secuencia de
operaciones del sistema y de que manera se cumplirán adecuadamente las reglas
de negocio. Los servicios de negocio:
• Aseguran la integridad de las transacciones del negocio.
• Transforman los datos en información aplicando las reglas del negocio.
• Definen los procesos del negocio, reglas y flujos de trabajo que la
organización deba seguir.
2.3.1.3 Servicios de la información
Los servicios de la información detallan la manipulación de los datos:
• Mantienen persistentes los datos del aplicativo.
• Se define la actividad de la base de datos: creación, lectura,
actualizaciones y borrados.
• Mantener oculta la estructura de los datos (seguridad).
2.3.2 Beneficios de las aplicaciones basadas en ser vicios
2.3.2.1 Flexibilidad para distribución
El modelo de aplicaciones MSF tiene la característica de construir un
aplicativo lógico en tres capas, que se puede distribuir sobre N capas físicas. Dicho
de otra manera este modelo promueve que se simplifique el trabajo, ya que de
alguna manera se reutilizarán las características de cada servicio para la creación de
aplicativos posteriores o similares, o bien para el mantenimiento del mismo.
2.3.2.2 Paralelismo del proceso de desarrollo
Una de las ventajas del enfoque basado en servicios es que debido a que la
construcción de un aplicativo se descompone en partes pequeñas, se puede trabajar
39
en paralelo. Esta característica permite aprovechar al máximo las habilidades y
especializaciones de cada miembro del equipo de desarrollo.
2.3.2.3 Uso eficiente de recursos y habilidades
Este punto esta relacionado con el anterior; debido a que los diferentes
servicios requieren generalmente diferentes habilidades y herramientas, los recursos
se usan eficientemente, sacando ventaja de las diversas habilidades de la mayoría
de la gente que conforma el equipo de desarrollo. Ahora se requerirán especialistas
en tecnologías, en vez de buscar personas que conozcan varios ambientes para la
implantación de la solución.
2.3.2.4 Rehúso de servicios
El modelo de aplicaciones MSF basado en servicios permite a los aplicativos
compartir servicios de tal forma que haya menos carga de trabajo ya hecho y una
mejor consistencia en la implementación de las reglas de negocio.
2.3.2.5 Facilidad de mantenimiento
Esta característica esta relacionada con la evolución del producto. Al proveer
en un servicio la implantación de una regla de negocio a través de todas las
aplicaciones con las que se relaciona, una actualización se hará solamente en aquel
punto y tendrá efecto en todas las aplicaciones sin necesidad de actualizar toda la
estructura. Además, el diseño de componentes MSF basado en servicios hace más
fácil detectar y arreglar las unidades más pequeñas y en determinado momento
reconstruir el componente. Los aplicativos pueden evolucionar gradualmente,
actualizando o mejorando servicios críticos, en vez de que se requieran una
completa reestructuración como los aplicativos tradicionales.
40
Capítulo III
Marco Contextual
41
En este capítulo, se informará a él lector sobre la institución donde el trabajo de la
investigación se enfoco, además se pone en contexto la situación que en ella
prevalece con su sistema de auditoria actual.
3.1 Coca-Cola FEMSA, S.A. de C.V.
Coca-Cola FEMSA (KOF), es la segunda embotelladora de refrescos más
grande en el mundo y la primera de Latinoamérica, contabilizando más del 10% de
las ventas globales. En Latinoamérica, entrega aproximadamente 1.8 billones de
unidades de cajas, para contabilizar aproximadamente 40% de los volúmenes de
Coca-Cola en la región.
Coca-Cola FEMSA, produce y distribuye Coca-Cola, Sprite, Fanta, Lift y
otras bebidas más, en México, Guatemala, Nicaragua, Costa Rica, Panamá,
Colombia, Venezuela, Brasil y Argentina.
3.2. Antecedentes históricos
“Existe la evidencia de que alguna especie de auditoria se practicó en
tiempos remotos. El hecho de que los soberanos exigieran el mantenimiento de las
cuentas de sus residencias por escribanos independientes, esto pone de manifiesto
que fueron tomadas algunas medidas para evitar desfalcos en dichas cuentas. A
medida que se desarrollo el comercio, surgió la necesidad de las cuentas. A medida
que se desarrollo el comercio, surgió la necesidad de las revisiones independientes
42
para asegurarse de la adecuación y finalidad de los registros mantenidos en varias
empresas comerciales”15.
A partir de 1991 se inicio en “Coca-Cola FEMSA”16 un proceso de
fortalecimiento de su Ambiente de Control, lo cuál ha permitido paulatinamente ir
disminuyendo el grado de riesgo en los negocios.
Entre las más importantes acciones implementadas durante los últimos 10
años para mejorar el ambiente de control, se encuentran las siguientes:
• Determinación, promulgación y promoción permanente de la misión y visión del
negocio, al igual que un conjunto de valores como pieza esencial de la cultura
corporativa.
• Implantación de políticas corporativas que regulan operación, incluyen un
código de ética de negocios.
• Establecimiento de un sistema de metas y objetivos, además de la evaluación
de desempeño y seguimiento del desarrollo de la cultura corporativa.
• Creación de un departamento de Auditoria Interna, cuya práctica profesional
está regida por estándares internacionales.
• Establecimiento de un Comité de Auditoria del Consejo, incorporando
miembros que no están involucrados en la operación y aportan una visión
externa independiente.
• Evaluación sistemática del grado de control interno de cada una de las
unidades operativas mediante el uso de tablero de indicadores de Control
Interno, y del proceso de auditoria.
• Implementación de un Equipo de Control Interno, cuyo rol principal es el
asegurar un ambiente de control interno adecuado para la operación, siendo
responsable a su vez, del seguimiento del tablero de control y del seguimiento
a los planes correctivos.
En el año de 2003, el Equipo de Control Interno de Colombia, se aventura a
implementar un sistema con el cuál pudieran facilitar el proceso de auditoria 15 JIMÉNEZ, ARMANDO. Monografías.com. http://www.monografias.com/trabajos12/condeau/condeau/shtml 16 KOF: Es el embotellador de Coca-Cola más grande de Latinoamérica.
43
dentro de su país. Dicho sistema fue desarrollado por personas sin muchos
conocimientos en informática, por lo que usaron las herramientas que ellos
conocían en su momento, como son las macros de Excel. Con el paso del tiempo
el corporativo de Coca-Cola FEMSA, con sede en México, D.F. adopta este
pequeño sistema para aplicarlo en los demás países donde tiene presencia la
refresquera. Es así como nace la primera versión del sistema de auditoria dentro
de Coca-Cola.
3.3 Visión
El Equipo de Control Interno, tiene como visión ser un órgano fiscalizador y
asesor altamente calificado, conformado por un grupo de profesionales
comprometidos con una gestión eficiente y oportuna que propicie la generación de
servicios de calidad, para colaborar con la administración en el cumplimiento de los
objetivos de la empresa, el mejoramiento del control interno y la prevención del
fraude.
3.4 Misión
El Equipo de Control Interno es un área asesora de Coca-Cola FEMSA, que
mediante la práctica de un enfoque preventivo, sistémico y profesional coadyuva con
la administración al mejoramiento del control interno de la empresa, y proporciona
una garantía razonable de que la actuación del jerarca, el personal y los procesos de
la empresa se realicen con apego al marco legal y técnico, conforme a las sanas
prácticas del control interno en aras de que la administración alcance los objetivos
de la corporación de manera eficaz, eficiente y transparente.
3.5 Situación actual
El Equipo de Control Interno de Coca-Cola FEMSA ha sido el encargado de
evaluar de forma continua los controles básicos de las operaciones de la empresa,
permitiendo así detectar oportunamente cualquier desviación a las políticas y
procedimientos establecidos.
44
La evaluación a las operaciones de la compañía, se realizan a las diferentes
unidades operativas que a continuación se describen:
• Plantas: Centros de producción de bebidas gaseosas.
• Depósitos: Lugar donde se resguardan y conservan los productos
terminados de las plantas, antes de su distribución hacia los diferentes
puntos de venta.
• Oficinas administrativas: Centro de operaciones y administración de las
plantas y depósitos en donde tiene presencia la refresquera.
• Oficina corporativa: Entidad en el nivel mas alto organizacional de la
empresa y es además la responsable de crear y tomar las decisiones que
la rigen.
Actualmente, el Equipo de Control Interno cuenta con un sistema realizado
por ellos mismos y utilizado en cada país donde opera la refresquera.
El personal de Control Interno de las oficinas corporativas realiza visitas
periódicamente a las diferentes unidades operativas de la empresa, con el fin de
revisar el cumplimiento de las normas y reglas de los manuales internos de control
interno. Una vez realizada las visitas, el personal elabora los planes de acción y los
indicadores a tomar en cuenta en las evaluaciones para los siguientes periodos de
evaluación.
“Los indicadores miden el porcentaje de ejecución de las metas
comprometidas por los auditores hacia los entes evaluados, durante ciertos periodos
de vigencia”17.
Los periodos de vigencia de estos indicadores son:
• Mensual: Los indicadores se miden mensualmente durante todo el año.
17 URON,GABRIEL Hacia la efectividad de las metas. http://gestiopolis.com/canales2/gerencia/1/planeacion.htm
45
• Trimestral: El periodo que abarca la medición de los indicadores es de cada
tres meses durante todo el año.
• Semestral: La medición se realiza cada seis meses.
• Anual: se elabora la evaluación una vez al año.
Una vez terminado el periodo de evaluación, las unidades evaluadas envían
por valija su reporte a la oficina de control interno de su respectiva área o país, para
después ser recopilados por el departamento de control interno de las oficinas
centrales del corporativo, lugar donde analizan y revisan los documentos para hacer
una medición de los puntos de control que se aplicaron a las unidades para esa
evaluación, y así poder emitir reportes para el área gerencial y ofrecerles una visión
general e información que es imprescindible para conocer los entes en los cuales
tomaran importantes decisiones.
3.5.1 ¿Qué se mide en el sistema de auditoria actua l?
Una vez que se especificaron los objetivos de las evaluaciones, estos se
traducen a indicadores, en donde se especifican aun más los objetivos del
programa, para así poder identificar las variables que son importantes a examinar.
Cabe mencionar que el Equipo de Control Interno, configura sus macros de Excel
con estas configuraciones de los indicadores a evaluar de una forma manual y
especial para cada unidad operativa. Los posibles indicadores que se miden son:
• Toma física de inventarios. La toma física de inventarios realiza un conteo a
diferentes cosas de las unidades operativas, algunas cosas que se miden en
esta son: arqueo de caja, materia prima, producto terminado, refacciones y
enfriadores.
• Conciliaciones. El propósito de las conciliaciones es el de identificar los
faltantes o sobrantes a un punto de revisión y aplica a los siguientes puntos:
arqueo de caja, bancos, materia prima, producto terminado, refacciones,
enfriadores, clientes formales, clientes informales y cuenta corriente inter
compañías.
• Antigüedad de saldos. La antigüedad de saldos identifica partidas en
conciliación que tengan una antigüedad mayor a las políticas y
46
procedimientos establecidos, con el propósito de conocer las causas que los
originan y así tomar las acciones correctivas correspondientes. Este rubro
aplica para los siguientes puntos: arqueo de caja, conciliaciones bancarias,
materia prima, producto terminado, refacciones, enfriadores, clientes formales
(0-30 días después del vencimiento), clientes informales (+30 días después
del vencimiento), clientes informales excedidos en monto, clientes informales
excedidos en plazo y cuenta corriente intercompañías
• Activo fijo. Su objetivo es el de registrar el activo de toma física de
inventarios, conciliaciones y antigüedad de saldos, los puntos a considerar
son: toma física, conciliación y antigüedad de saldos.
• Liquidación de promociones. Identifica y asegura que la utilización y destino
de los artículos promociónales se realice conforme a las políticas y
procedimientos establecidos, con el propósito de detectar oportunamente
cualquier desviación, los puntos involucrados son: liquidación de artículos
promociónales.
• Back up de información fiscal. Verifica que se este llevando a cabo el
respaldo de información. Los puntos son: respaldo de información e
información con +30 días sin respaldar.
• Ahorros inmediatos. Identifica y asegura el grado de avance de los posibles
ahorros definidos en las observaciones realizados por auditoria interna.
• Avances. Identifica y asegura el grado de avance de recuperación de las
irregularidades definidas en las observaciones realizadas por auditoria
interna.
• Ajustes. Identifica y asegura el grado de avance de realización de los
posibles ajustes definidos en las observaciones realizadas por auditoria
interna.
3.5.2 ¿Cómo se evalúan las auditorias?
La medición a los indicadores se hace a través de un instrumento llamado
“Tablero de Indicadores”, que se encarga de hacer la medición del cumplimiento de
los controles internos básicos. Los indicadores anteriormente mencionados se llenan
en hojas de Excel, una vez ingresado el dato, la macro calcula el resultado en otra
47
hoja de Excel llamado el “Tablero de indicadores”, e indica el resultado parcial de la
evaluación de esa unidad.
Una vez que la unidad operativa lleno su evaluación de auditoria, esta se
manda a las oficinas centrales de cada país. Las oficinas centrales recolectan la
información de todas sus entidades y la mandan a las oficinas corporativas en
México. Este hecho es susceptible de robo o perdida durante su traslado, así como
posibles alteraciones a los documentos. Cuando el Equipo de Control Interno
recopila la información de todas las unidades operativas, comienzan con un proceso
de corrección, evaluación y análisis de todas las evaluaciones, para poder así
entregar y hacer los resúmenes y reportes ejecutivos que necesitan entregar a las
áreas gerenciales.
Además cuando se termina con un ciclo de evaluación comprendido por 12
meses, se hace una medición de la evaluación total de todas las unidades
operativas, además de los resúmenes a más alto nivel, donde se valora a todo un
país o una zona geográfica. Hecho que lleva mucho tiempo y desgaste para el
personal de Control Interno.
3.5.2.1 Propósito del tablero de indicadores en la evaluación
El propósito del tablero de indicadores es principalmente:
1. Detectar oportunamente desviaciones a los indicadores clave incluidos en el
manual de Control Interno.
2. Tomar acciones preventivas
3. Asegurar la rápida respuesta a las observaciones detectadas por Auditoria
Interna Corporativa.
4. Homologar el sistema de medición del grado de cumplimiento de los
indicadores en todas las operaciones de la empresa.
5. Comparar las calificaciones periódicamente y analizar sus tendencias.
48
3.5.2.2 Consideraciones y ponderaciones del tablero de indicadores
Las consideraciones tomadas para el tablero de indicadores es la de poder
expresar en porcentajes la medida de valor para los indicadores que se programan
cada año respecto a ponderaciones dadas, permitiendo así, obtener un resultado
cuantificable y medible a través del tiempo.
A continuación se muestra una gráfica donde se muestra el tablero de
indicadores con sus respectivas ponderaciones por cada indicador.
Figura 3.1 Ponderaciones de los indicadores del tablero de control.18
Como se muestra en la figura 3.1 el tablero de indicadores se divide en dos
partes, por una están los indicadores básicos del control de auditoria y por otro lado
esta el seguimiento a observaciones de los planes de acción que se han establecido
en las visitas de Control Interno a cada unidad operativa. Esta segunda parte del
tablero se conoce como “Metodología” y se genera a través de un informe de
auditoria donde vienen los compromisos a los cuales se compromete una unidad
operativa, con el fin de hacer seguimientos a ciertos puntos de interés para el área.
3.5.2.3 El tablero de indicadores y su parte de Met odología
La metodología es otra herramienta que busca dar seguimiento a planes de
Auditoria, Control Interno y Tablero de control realizados en cada unidad operativa,
18 Fuente: Grafica del Manual de Control Interno de Coca-Cola FEMSA. p.16
49
con la documentación soporte necesaria y de manera unificada, esta herramienta
ayuda a controlar en un tiempo determinado, los diversos planes de acción que
serán aplicados a las diferentes unidades que competen al grupo Coca-Cola
FEMSA.
En otras palabras, lo mencionado anteriormente quiere decir que existe
además del Tablero de Indicadores, otra herramienta (hojas de Excel), que sirve
para registrar los compromisos asignados a cada unidad operativa, simulando ser un
semáforo, que según la fecha en la que se cumplió un compromiso o plan de acción
asignado, esta se ubica en los siguientes colores:
• (verde) Tiene más de 15 días para la ejecución del plan.
• (amarillo) Tiene de 1 a 15 días para ejecutar el plan.
• (rojo) Se pasó de la fecha límite para ejecutar el plan.
• (blanco) Se ejecuto el plan satisfactoriamente.
Según el número de compromisos asignados a la unidad operativa entre la
ponderación de este indicador, se saca la calificación de la metodología, que será
manualmente registrada en el tablero de indicadores, para que juegue en la
calificación final y así poder sacar un porcentaje de calificación no mayor al 100%.
3.5.2.4 Resultado del tablero de indicadores
El tablero de indicadores evalúa el nivel de cumplimiento de control interno
efectuando el resultado en una escala del 1 al 100, arrojando un cumplimiento que
va desde inaceptable, hasta excelente. La tabla 1.1 muestra todos los rangos que
son aplicables.
50
Tabla 3.1 Rangos de cumplimiento del tablero de indicadores19
Rangos Mínimo Máximo
Nivel
0 59 Inaceptable 60 70 Deficiente 71 80 Regular 81 90 Buena 91 100 Excelente
3.5.2.5 Fases del proceso de auditoria
Una vez explicado el procedimiento general para realizar la auditoria por el
Equipo de Control Interno a cada unidad operativa, se resume continuación las
diferentes fases del procedimiento actual:
• Visitas a las unidades: A fin de llevar a cabo uno de los procedimientos que
se llevan en una auditoria, él o los auditores visitan las diferentes unidades de
negocio para supervisar y verificar que se estén llevando de manera
adecuada los procesos de negocio, de ahí generan un informe de auditoria
con los puntos de acción a tomar para evaluar esa unidad operativa.
• Creación del informe de auditoria: El auditor realiza un informe con los planes
de acción que se hayan establecido a lo largo de las visitas a las unidades
operativas. El informe es un documento que indica los puntos a cumplir en un
cierto periodo. Este informe posteriormente será distribuido a cada unidad
operativa, junto con su macro de Excel de tablero de indicadores y
metodología configurada para esa unidad.
• Distribución de la información: Se hace llegar la información con los
documentos del informe y del tablero de indicadores a las personas
encargadas de las distintas secciones. Este proceso se realiza manualmente
e involucra la manipulación física de los documentos y archivos. Cabe
mencionar, que del informe se envía un documento en formato de texto, y del
tablero de indicadores se envía una macro de Excel para ir haciendo el
seguimiento a cada indicador.
• Periodo de evaluación: Una vez recibidos el informe de auditoria y el tablero
de indicadores, el personal encargado debe dar seguimiento a estos en las
19 Fuente: Tabla del Manual de Control Interno de Coca-Cola FEMSA.p.22
51
unidades operativas, recolectando información para evaluar el seguimiento de
los indicadores, y seguimientos a planes de acción de metodología. Una vez
terminado el periodo de evaluación cada unidad operativa regresa la
información a las oficinas de Control Interno de cada país, para
posteriormente mandarlo a las oficinas corporativas y empezar el proceso de
revisión y análisis de información.
• Revisión de información: Cuando termina el periodo de evaluación las
unidades devuelven los documentos con los resultados obtenidos del
seguimiento de la auditoria. Esta parte es la más delicada del trabajo, ya que
el auditor tiene que juzgar si el documento ha sido llevado correctamente y
además el documento haya llegado completo. En caso de que los
documentos no estén completos o haya sido llenado incorrectamente, se
devuelve el documento al involucrado para que complete la información que
haga falta y se realice de nuevo el trámite.
• Análisis y entrega de resultados: Una vez que el auditor tiene la información
completa de las evaluaciones, se comienza con el análisis de los
documentos, vaciando la calificación obtenida y el total del tablero de
indicadores en una hoja de Excel, que centraliza y filtra los resultados para
seguir como base para alimentar los demás reportes que se generan al área
gerencial de manera manual.
3.5.2.6 Reportes de auditoria
Con la finalización de un periodo de evaluación de auditoria se obtienen
estadísticas generales para poder tener una visión completa del estado de la
empresa, y así poder tomar las decisiones pertinentes por el área gerencial.
Estas estadísticas las realiza el auditor de Control Interno de manera manual
y se sacan respecto a los siguientes intereses:
• Estadística de países: Muestra el promedio de calificación de todas las
unidades de un país en un cierto periodo.
• Estadística por zona: Muestra el promedio de calificación de una zona
geográfica.
52
• Reporte de cumplimientos de indicadores: Este reporte muestra el
cumplimiento de un indicador por cada unidad operativa de un país.
• Reporte estadístico de la auditoria de la empresa: Muestra el promedio de
calificación de todos los países y del corporativo.
3.6 Modernización
En general, se puede afirmar que la realización de la evaluación de la
auditoria, requiere de un mejor manejo de su proceso. Esto a fin de otorgar la debida
certeza y seguridad tanto a las unidades operativas, como a todos aquellos que
estén relacionados en dicho proceso.
La relevancia de la función de auditoria encomendada a él Equipo de Control
Interno, requiere de un desempeño eficiente, oportuno y profesional a través de un
sistema adecuado de incorporación, perfeccionamiento y permanencia que garantice
el servicio que se debe presentar a la compañía.
Los dos problemas de fondo del sistema actual de evaluación y medición del
cumplimiento a planes de acción, son el aumento desmesurado de información que
hay que verificar y analizar manualmente, y el método arcaico que se utiliza en el
proceso, lo cual da como resultado bajos niveles de confiabilidad, seguridad y
atención de los usuarios.
En el contexto de la modernización del proceso de auditoria, surge la
propuesta para sustituirlo por otro método que pueda ser más adecuado para el
tratamiento y solución que enfrenta en la actualidad la compañía. Para el diseño del
sistema informático, al que durante el presente trabajo se llamara SACI (Sistema de
Auditoria y Control Interno), la idea fue tratar de sustituir el método de evaluación de
indicadores y el método de resultados de la evaluación por uno mas moderno y
eficiente, que pueda beneficiarse del uso de las herramientas de computo,
permitiendo extender los servicios del área de Control Interno de acuerdo a los
requerimientos de la época, logrando así elevar los niveles de seguridad,
confiabilidad y calidad en los servicios.
53
Capítulo IV
Planificación del proyecto del sistema de auditoria y
control interno
54
En este capítulo, se planificará el sistema de auditoria y control interno aplicando los modelos de Microsoft Solution Framework.
4.1 Los modelos de Microsoft Solutions Frameworks, aplicados a la planificación del sistema de auditor ia y control interno
El diseño del sistema de auditoria y control interno se presentará con base
en la estructura de solución Microsoft Solution Framewrok, y se tomarán los modelos
que se consideran apropiados tanto para el diseño como para el desarrollo mismo
del sistema, dado que el producto final será un software aplicativo.
En un proyecto de desarrollo de aplicaciones, se analizan los procesos
administrativos tanto manuales como administrativos (en este caso el sistema
existente: SACI), se identifican los componentes de software que formarán a la
aplicación, así como la relación entre ellos. Se determina también que herramientas
de tecnológicas se emplearán para el desarrollo de la misma. Se establecen
controles diversos para garantizar que el desarrollo cumpla con los requerimientos
solicitados. Se definen las pruebas que deberá soportar el sistema. Finalmente se
logrará la liberación de un conjunto de programas que permita a los usuarios realizar
sus operaciones remotas vía la red corporativa, para su culminación en las oficinas
corporativas del Equipo de Control Interno de Coca-Cola FEMSA, por medio del
SACI.
La flexibilidad que proporciona esta filosofía de proyectos en Microsoft
permite tomar los modelos que mejor se adapten a las necesidades del sistema, o
bien, poder tomar elementos aislados que sean adecuados para asegurar una mejor
planeación, ejecución y control de proyectos de tecnologías de información.
55
4.2 Beneficios que aportan los modelos de Microsoft Solution Framework al diseño del sistema de auditor ia y control interno
Entre algunos de los beneficios que presenta la estructura de solución
Microsoft (MSF), en relación a la planificación del SACI, se encuentran los
siguientes:
• Se creará, una solución que satisfaga los requerimientos de los usuarios.
• Se acelerará, el ciclo de desarrollo del sistema.
• Se incrementará, la posibilidad de éxito con base en eventos planeados.
• Se alcanzarán, resultados a corto plazo aun cuando se contemple una
estrategia de planeación a largo plazo.
En particular para el proyecto SACI los modelos a utilizar serán los siguientes:
• El modelo de equipo.
• El modelo de proceso.
• El modelo de diseño de componentes
4.2.1 El modelo de equipo de Microsoft Solution Fra mework aplicado a la planificación del SACI
El modelo de equipo MSF aplicado al SACI se interpreta y adecuada como lo
muestra la figura 4.1.
Figura 4.1 Aplicación del modelo de equipo MSF al SACI20
20 Fuente: Grafica de creación propia
56
Como se puede apreciar, respecto al modelo original visto en el modelo
teórico los roles son los mismos salvo la gerencia de logística, este rol no se
representa ya que una de las restricciones o variables no controlables será
precisamente el no considerar la infraestructura como parte del proyecto.
Los roles del equipo que son considerados para el equipo al SACI, se
describen a continuación en la figura 4.2.
Figura 4.2 Roles del modelo de equipo MSF aplicados al SACI21
21 Fuente: Gráfica de creación propia
57
El equipo que se encargará del proyecto del sistema de auditoria y control
interno, se conforma de la siguiente manera:
• Un gerente de producto.
• Un gerente de programa.
• Tres desarrolladores.
• Una persona encargada de pruebas.
• Una persona encargada de brindar capacitación al usuario.
Se puede apreciar que el modelo de equipo retorna los principios de
administración para la calidad, ya que el equipo esta compuesto por miembros con
conocimientos, habilidades y actitudes para producir. Se busca reducir al máximo los
errores, cubrir las necesidades del cliente e implementar innovaciones.
4.3 El modelo de proceso MSF, aplicado al diseño de l SACI
4.3.1 El modelo de proceso y la planeación del SACI
“La planeación es el proceso de determinar objetivos y definir la mejor manera
de alcanzarlos”22. Con base en esta definición de planeación, se puede afirmar que
el modelo de proceso de MSF retoma este concepto, ya que como se podrá apreciar
retoma las fases de la planeación y las aplica al modelo. Así mismo, retoma el
concepto de la administración por objetivos dada la naturaleza del modelo que se
conforma por el logro de cuatro objetivos en cuatro etapas a corto plazo (duración
del proyecto).
La tabla 4.1 presenta la analogía entre el modelo de proceso y el proceso de
la planeación. Cabe señalar que la fase de “planeación” mencionada en el modelo
es solo una parte de la planeación si se ve de una manera general. La fase de
planeación si se ve de una manera general. La fase de planeación de los recursos
humanos se trato en el apartado anterior en el modelo de equipo.
22 Robbins Stephen P. Administración: Teoría y Práctica p. 114. Pearson Prentice Hall México 1999.
58
Tabla 4.1 El modelo de proceso MSF y su relación con el proceso de planeación23
Fases del Modelo de Proceso MSF Fases de la planeación
Conceptualización Formulación de la problemática
Planeación Planeación de los fines
Desarrollo Planeación de los medios
Estabilización Implementación y control
Modelo de Equipo Planeación de los recursos
4.3.2 Fase del modelo de proceso MSF aplicada al SA CI
El modelo de proceso que se aplicará al diseño del SACI será al igual que el
modelo de equipo dirigido al proyecto de desarrollo de aplicativos. Consta de las
siguientes cuatro etapas que muestra la figura 4.3.
Figura 4.3. Modelo de proceso MSF aplicado al SACI24
A continuación se explicará cada una de estas fases y como se relacionaran
con el sistema SACI.
23 Fuente: Tabla de creación propia 24 Fuente: Traducción de gráfica tomada de Microsoft Solutions Framework, White Paper, Microsoft Corporation
59
4.3.3 Fase de conceptualización
Esta fase comprende la revisión de todas las actividades necesarias para el
arranque exitoso del proyecto, se revisarán y confirmarán actividades, recursos y
tiempos asignados en el plan general de trabajo, así como los entregables del
proyecto. Los mecanismos de comunicación de avance y de reporte de actividades
quedarán establecidos y acordados. En esta fase también se llevara a cabo la
definición detallada de la funcionalidad que debe cumplir el sistema. Uno de los
entregables será un documento que servirá para la verificación posterior del
cumplimiento de tal funcionalidad, este documento será el Business Blueprint del
proyecto.
Primeramente se empezará por delimitar el objetivo: el objetivo del SACI es
optimizar y automatizar el proceso de auditoria que lleva a cabo el Equipo de Control
Interno en las unidades operativas de Coca-Cola FEMSA. El SACI podrá controlar y
dar seguimiento a los planes de acción, desde la creación del informe de auditoria,
hasta los ingresos de los avances a los indicadores del tablero de control. De esta
manera, se obtendrá una mayor rapidez y autonomía al proceso de auditoria.
Además, el SACI proporcionará un mecanismo seguro y confiable de consulta a
través de la red de la empresa.
Una vez acordado con el Equipo de Control Interno, la migración del sistema
SACI cubrirá las siguientes necesidades:
• El tablero de control y la metodología.
• La consulta del estado de captura.
• La consulta de las calificaciones de las unidades operativas.
• La captura de los avances a la metodología y los indicadores.
• Reportes de seguimiento.
En la fase de conceptualización resalta la parte de funcionalidad de los
procesos del SACI.
60
• Proceso de acceso a la Intranet.
Los usuarios del sistema SACI accesarán vía un navegador web, a una
dirección de Internet del portal corporativo. El sistema responderá con una página de
acceso, donde el usuario deberá capturar su clave de acceso y contraseña; el
sistema rechazará o aceptará la petición. En caso de aceptarse desplegará la página
principal del sistema SACI; esta página permitirá dos opciones principales:
1. Tablero.
2. Metodología
• Proceso del tablero de control.
Se validará que el usuario ingresado tenga los permisos necesarios para
visualizar o en su caso capturar los indicadores del tablero.
• Proceso de metodología.
Para el proceso de metodología el usuario podrá acceder para visualizar o
capturar ahorros, ajustes, informes ejecutivos, informes detallados, hallazgos,
seguimientos a planes de acción, indicadores y además consultar los seguimientos
así como el estatus de sus capturas. El proceso de metodología funciona como un
semáforo que le indica la fase en que se encuentra un plan de acción.
Para la seguridad del usuario respecto a las capturas realizadas, el sistema
indicará mediante un mensaje que la transacción fue exitosa o rechazada.
Esta fase se resaltará en un documento, conocido como documento de
enfoque, discutido y confirmado de la funcionalidad de los procesos arriba
mencionados.
Parte importante de esta fase resulta el cronograma del proyecto que
consistirá en tener un acercamiento con relación a las fechas de inicio y término de
61
cada una de las fases del proyecto. El cronograma del proyecto de migración hacia
el sistema intranet se presenta en la figura 4.4.
Figura 4.4 cronograma del proyecto del SACI25
Como se puede apreciar en el cronograma, el proyecto está estimado para
un período de 21 semanas, que incluyen todas las fases del mismo, desde el
entendimiento conceptual hasta la capacitación de lo usuarios.
Se puede decir que este trabajo, forma parte apenas de la fase 1 y la fase 2,
pero que es una parte fundamental y decisivo dentro de él.
4.3.4 Fase de planeación
Con la información analizada y confirmada de los procesos, el grupo de
trabajo se reúne para validar el modelo preliminar de la aplicación y llevarlo a su
forma definitiva. Los participantes serán todos los miembros del equipo que se
detalla en la figura 4.2, en esta fase se delinean las pruebas técnicas que deberá
satisfacer el sistema desarrollado.
El entregable será un documento llamado “especificación de la funcionalidad”,
que se propone como arquitectura de aplicación, mismo que será validado por el
grupo técnico de Coca-Cola FEMSA.
25 Fuente: Gráfica de creación propia.
62
Esta fase se subdividirá en dos componentes, cada uno con sus actividades
correspondientes:
• Diseño conceptual.
Como un punto de inicio del diseño conceptual, se delimitará el ambiente del
sistema, es decir los entes de las que dependerá, o que dependen de él, tal relación
se encuentra plasmada en el siguiente gráfico.
Figura 4.5 Ambiente del SACI26
El flujo de trabajo inicia en la página de Bienvenida, que es donde el usuario
deberá seleccionar el tipo de actividad que desea realizar, ya sea avances de planes
de acción en metodología o captura de indicadores del tablero de control.
Al seleccionar Metodología, se le presenta la pantalla con las opciones de
Ahorros, Ajustes, Hallazgos, Seguimientos a Planes de acción, Indicadores, Estatus
y el Reporte de seguimiento.
26 Fuente: Gráfica de creación propia.
63
Al seleccionar ahorros, ajustes o hallazgos se le presenta una pantalla donde
se captura la información relacionada al trámite, el objetivo de los puntos anteriores
es llevar a cabo el cumplimiento de los planes de acción hechos por el área de
auditoria a cada unidad operativa, el grado de cumplimiento es dado por el
porcentaje de avance conforme a la fecha de ejecución de dicho de plan. Además se
muestran los puntos que han sido capturados y que están activos para el ciclo de
auditoria actual, así mismo se documentan las acciones a seguir para el
cumplimiento del plan.
Una vez grabados los planes de acción de metodología, el estado de los
puntos puede ser consultado en la página de estatus, el sistema muestra los puntos
que están cumplidos y los que no lo están. Así mismo el reporte de seguimientos es
una pantalla de consulta donde una vez seleccionados los criterios de búsqueda la
pantalla muestra los seguimientos a los cuáles se a comprometido la unidad para
poder cumplir un plan de acción o mostrar los seguimientos a las desviaciones de
los indicadores del tablero de control.
Cada mes el usuario registrará los indicadores en el tablero de control, el
periodo de captura abarcará los primeros 15 días en los cuáles se podrán registrar
estos puntos. Una vez cerrado el periodo de captura se continuará a la fase de
calificación en el sistema SACI, donde el usuario verá la calificación tanto de la
metodología como del tablero de control.
• Diseño lógico
Durante el diseño lógico se realizarán las siguientes actividades:
1. Inventario de las pantallas del SACI que implementan la
funcionalidad de los procesos de metodología y tablero de
control.
2. Diseño del esquema de navegación entre las páginas del
SACI.
64
La figura 4.6 esquematiza el diseño lógico del sistema de auditoria y control
interno.
Figura 4.6 Diseño lógico del SACI27
• Fase de desarrollo
Se organiza el grupo de trabajo de desarrollo. Se establece la infraestructura
tecnológica y de desarrollo. Se comunicará la arquitectura de la aplicación, los
estándares de programación y el diseño físico y lógico a los usuarios del Equipo de
Control Interno. Así mismo se organizarán los módulos a desarrollarse por cada
programador, los criterios generales de aceptación de los módulos, etc.
En esta fase se entregará un documento con las especificaciones de pruebas
y casos de pruebas, código fuente y programas ejecutables.
En esta fase se desempeñan estas actividades:
27 Fuente: Gráfica de creación propia.
65
• Se trabajará con la versión del sistema actual de auditoria, mientras
dure el proceso de realización e implantación del nuevo sistema y
hasta que concluyan las pruebas de este y si se libere con una versión
estable.
• Se entregará el documento de arquitectura de la aplicación para ser
validado por el área de informática de Coca-Cola FEMSA.
• Creación de un prototipo del sistema de auditoria y control interno
nuevo, que servirá para validar con el Equipo de Control Interno, el
diseño y algo de la funcionalidad requerida.
• Creación de páginas y formas.
• Se agregará código SQL, para realizar los accesos a la base de datos.
• Administración y puesta a punto de la plataforma WEB.
• Desarrollo de guiones de pruebas unitarias, integrales y de aceptación.
Cabe mencionar que el tema de la plataforma tecnológica y de desarrollo se
discutirá a más adelante.
4.3.5 Fase de estabilización
En la última fase del ciclo de vida del proyecto SACI, se culminan las
siguientes actividades:
• Ejecución de pruebas integrales . Consiste en la ejecución de una serie
de guiones de pruebas, par verificar la correcta funcionalidad del sistema.
• Documentación . Se lleva a cabo el desarrollo de la documentación de
usuario del sistema. Se colecta la información técnica para preparar los
manuales. Realizando la documentación previamente a las pruebas de
aceptación, se posibilita la identificación de errores; así mismo se
alimentarán las pruebas finales con los documentos que permitan validar
de una forma efectiva la operación del sistema.
• Ejecución de pruebas de aceptación . Se ejecutan una serie de pruebas
previamente definidas, participan tanto el área técnica como la de usuarios
de Coca-Cola FEMSA, y el equipo de trabajo, principalmente el área de
desarrollo. Se hace entrega de un documento que confirma la realización
66
de las pruebas de aceptación y los resultados obtenidos. Se acompaña el
documento con la lista de riesgos y posibles impactos, para comenzar con
estas pruebas es necesario contar con la documentación del sistema.
• Capacitación a usuarios . Consiste en la capacitación a los usuarios en el
uso de sistema SACI, así como también la capacitación técnica del
proceso de instalación del aplicativo. Al igual que el punto anterior es
necesario contar con la documentación del sistema.
4.4 MSF Application Model, aplicado al desarrollo d el sistema de auditoria y control interno
El modelo de aplicaciones MSF será la base para el desarrollo del sistema
intranet de auditoria y control interno SACI, dada su facilidad de uso y de las
características propias del desarrollo de este aplicativo. Se implementarán las tres
capas propuestas con base en los tres servicios, como son el usuario, el negocio y el
de la información.
4.4.1 Servicio del usuario del aplicativo SACI
Dadas las particularidades de un ambiente Web, el aplicativo SACI contendrá
los elementos que conforman comúnmente este tipo de aplicaciones, mismas que se
explicarán a continuación.
4.4.1.1 Operación de la interfase y páginas
El diseño de los formatos de entrada y salida de un sistema tradicionalmente
se conoce como diseño de formas, pues la mayor parte de los sistemas de los años
60`s y 70`s requerían que el usuario codificará las entradas en forma de papel, que
luego se transcribirían a tarjetas perforadas antes de ingresar al sistema de cómputo
por lotes.
Para la correcta navegación entre páginas o también llamadas formas, se
requiere de un conocimiento general del uso de aplicaciones en ambientes de
interfases gráficas amigables como Microsoft Windows XP, así como el uso de
67
navegadores Web como Microsoft Internet Explorer o Netscape Navigator. El diseño
de las pantallas o formas del SACI se basará en estándares de la industria
informática, lo cual facilita su aprendizaje, mantenimiento y utilización.
Las pantallas contienen una variedad de controles para definir, confirmar o
cancelar acciones. Algunos de los elementos a incluir en estas pantallas son:
• Botones
El elemento más utilizado en esta interfase es el llamado botón. Los botones
son rectángulos que contienen palabras clave que describen la acción que ejecutan.
• Cajas de texto.
Los cuadros de texto son recuadros donde se pueda introducir texto mediante
el teclado con diferentes propósitos.
• Listas desplegables.
El sistema contiene información relativa a algunos campos dentro de listas
desplegables. Estas listas son una ayuda ya que ofrecen mayor facilidad para el
llenado de campos, así como también evitan que se ingrese información errónea o
incompleta.
• Ligas de hipertexto
Es uno de los elementos más importantes que permiten navegar entre
páginas Web.
• Ligas de imagen.
Otros elementos no menos importantes que permiten navegar entre páginas
Web.
68
• Marcos.
Una técnica para desplegar conjuntos complejos de información en una
página Web, consiste en particionar la información en secciones llamadas marcos o
frames.
4.4.2 Servicios de negocio del SACI
Se propone desarrollar el sistema de auditoria y control interno para
proporcionar acceso remoto a auditores, usuarios de unidades operativas y otras
personas. En el desarrollo de este planteamiento de servicios de negocio, se parte
del supuesto de apegarse en la medida de lo posible (dado el ambiente Web), al
sistema de auditoria y control interno que se lleva actualmente con macros de Excel,
para de esta manera lograr una fácil integración del usuario hacia el nuevo sistema,
pero dando una mejor utilidad y eficacia del mismo.
Los servicios de negocio del sistema de auditoria y control interno, permiten
que las personas involucradas en el procesos de auditoria estén conectadas en el
flujo del proceso, para conseguir una mayor eficiencia del mismo. Estos servicios,
también brindan a los usuarios la información necesaria para responder con rapidez,
y así poder hacer una planificación estratégica de los hechos, respondiendo con
prontitud.
Retomando la fase de planeación del modelo de proceso MSF, en este
capítulo, se muestra a continuación el diseño lógico de la aplicación; el flujo de
páginas seguida de una descripción del flujo de información.
69
Figura 4.7 Diseño lógico del SACI28
• Log in
El usuario del SACI deberá introducir en el campo Usuario, el identificador de
usuario que le fue asignado por el administrador del portal, y en el campo
contraseña, su clave secreta.
El sistema debe hacer sus propias validaciones para verificar que el usuario
sea válido. En caso de que exista un error en la información digitada, o bien el
usuario que desea acceder no sea válido el portal despliega esta misma página para
poder capturar la información correctamente. Si el usuario fue autentificado
correctamente, se deberán cargar los datos personales e importantes en memoria,
28 Fuente: Gráfica de creación propia
70
para poder ser utilizados por la aplicación y no tener que cargar nuevamente esta
información.
• Bienvenida
La página de Bienvenida se despliega una vez que el sistema confirma la
validez del usuario.
Esta página es la puerta de entrada a todo el portal de Coca-Cola, en ella se
despliega el menú principal, que cuenta entre sus opciones: Control interno. Está
opción solo la vera un usuario que este relacionado directamente con el sistema de
auditoria y control interno.
La opción de Control interno, a su vez contiene las opciones:
• Metodología
• Tablero de Control.
A continuación se describe cada una de las opciones de los submenús antes
mencionados.
• Metodología
La opción de metodología, es donde se inicia el seguimiento a
planes de acción de un informe de auditoria. En esta parte, el usuario de la
unidad operativa registra los planes de acción y sus correspondientes
avances a los cumplimientos de los mismos. Este módulo de Metodología
consta de las siguientes páginas:
o Ahorros
o Ajustes
o Hallazgos
71
Tanto la parte de ahorros, ajustes y hallazgos, siguen un patrón muy
similar, así que se describirán a continuación como una misma página.
Ahorros, ajustes y hallazgos, constan de seis secciones: la principal,
que es donde se muestra un listado de los planes ya capturados en forma de
tabla, y además permite la captura de nuevos planes en base al informe de
auditoria, la sección de deshabilitar, permite cancelar un plan para que ya no
sea contado en la calificación final, la sección de capturar seguimiento,
permite documentar la acción que se va a seguir para cumplir con un dado
plan, la sección de historia de seguimiento, muestra un listado de todos los
seguimientos asociados a un plan y la sección de historial muestra
principalmente los avances que fueron registrados a un plan.
• Seguimiento de planes de acción
Esta página consta de dos secciones: la primera es donde se muestra
un listado de los seguimientos y además permite la captura del un
seguimiento a un plan de acción.
• Indicadores
Esta página consta de cuatro secciones: la primera sección muestra
un listado con los seguimientos que se han hecho a indicadores del tablero
de control, además permite la captura del estatus de cumplido o no, un
seguimiento, la segunda sección permite la captura del avance al
seguimiento de un indicador, la sección de captura de seguimiento permite
capturar un seguimiento a algún indicador ya registrado y la última sección
permite revisar el historial de algún seguimiento de indicador.
• Status
En esta página se muestra el estado general de todos los planes de
acción registrados, es decir, se muestran el número de planes que se
72
encuentran en verde, amarillo, rojos o blancos, para ahorros, ajustes y
hallazgos.
• Reporte de Seguimientos
En esta página se muestran los seguimientos asociados tanto a
metodología, como a indicadores de tablero de control, esta pantalla permite
mostrar el reporte conforme a ciertos filtros, permitiendo ver los seguimientos
de una unidad operativa o de toda una zona o país.
• Tablero de control
En esta parte se muestran indicadores o cédulas, que permiten obtener un
resultado cuantificable o medible. El resultado de los indicadores es obtenido de
acuerdo a una ponderación definida. Con el propósito de poder identificar el
progreso en el cumplimiento, se definieran rangos de calidad, los cuales indican el
estado vigente a la fecha de evaluación que se tiene en el Control Interno. La fecha
de evaluación es un período que se abre dentro de ciertos días de cada mes. Este
módulo de metodología consta de las siguientes páginas:
• Toma de inventario físico
Las pantallas que componen a la toma de inventario físico identifican
cualquier desviación, a través de la comparación del importe asignado contra
el importe encontrado en el conteo físico, las cédulas que componen este
indicador son las siguientes: arqueo de caja, materia prima, producto
terminado, refacciones y enfriadores.
• Conciliaciones
Las pantallas que componen a conciliaciones tienen como objetivo el
asegurar que se efectué la conciliación de todas las cuentas bancarias,
permitiendo detectar oportunamente cualquier desviación a las políticas y
procedimientos establecidos. Las cédulas que componen a este indicador
73
son: arqueo de caja, bancos, materia prima, producto terminado,
refacciones, enfriadores, clientes formales, clientes informales y cuenta
corriente intercompañías.
• Antigüedad de saldos
Las pantallas que componen antigüedad de saldos tienen el objetivo
de identificar el porcentaje de partidas en conciliación, que tengan una
antigüedad mayor a lo establecido, con el propósito de detectar
oportunamente cualquier desviación a las políticas y procedimientos
establecidos. Las cédulas que compren este indicador son: arqueo de caja,
conciliaciones bancarias, materia primas, producto terminado, refacciones,
enfriadores, clientes formales (0-30 días después del vencimiento), clientes
formales (+ 30 días después del vencimiento), clientes informales excedidos
en monto, clientes informales excedidos en plazo y cuenta corriente
intercompañías.
• Liquidación de promociones
Esta pantalla consta de una sola cédula y su objetivo es asegurar que
la utilización y destino de los artículos promociónales se realice conforme a
las políticas y procedimientos establecidos, permitiendo detectar
oportunamente cualquier desviación.
• Back up de información fiscal
El objetivo de estas pantallas es el asegurar que la información fiscal
de la empresa se encuentra debidamente respaldada. Las cédulas que
componen este indicador son: respaldo de información e información con
más de 30 días sin respaldar.
74
• Consulta calificación
En esta pantalla, se puede consultar la calificación de toda la auditoria
y sus indicadores. La calificación se muestra por mes.
• Calendario de captura
La pantalla muestra un calendario de los meses en los que se tiene
que capturar cada cédula asignada a una unidad operativa, permitiendo al
usuario saber en que periodo del año tiene que capturar una cédula.
4.4.3 Servicios de información del aplicativo
A medida que la World Wide Web madura, una nueva generación de
aplicaciones de intranet e Internet ha emergido. Las aplicaciones Web con el poder
de las bases de datos que sean construidas sobre esta nueva plataforma les
permitirán a las corporaciones expandir sus servicios y ampliar su gama de clientes,
así como explorar nuevos negocios que les generen mayores utilidades. Dichas
aplicaciones deben ser capaces de combinar todo el poder y confiabilidad de los
ambientes tradicionales cliente-servidor con la flexibilidad del uso de Internet.
A continuación se describirán las herramientas de tecnología Web propuestas
para el desarrollo del aplicativo así como los productos a utilizar de la plataforma
Internet de SAP. De esta manera se tendrá el marco para presentar una técnica para
el aprovechamiento y reutilización de los recursos del SACI, que sirva para realizar
la migración del sistema existente hacía la tecnología Web, basada en el producto
de desarrollo de SAP SAP Web Application Server y SAP Enterprise Portal, que
ofrecen una solución tangible para el proyecto y además son las herramientas con
las que la compañía cuenta en su ambiente.
75
4.4.3.1 Herramientas de tecnología web
• Eclipse
Eclipse es un ambiente de desarrollo de código abierto y fue creado para
soportar múltiples lenguajes de programación que se encuentran en el desarrollo de
una plataforma extensible de desarrollo y de una arquitectura de aplicaciones para
productos de software. Dicho en otras palabras, Eclipse es un conjunto de
herramientas de desarrollo construidas para Java (sin ser exclusivas) que permiten
adaptarse, mejorarse y modificarse.
Un aspecto importante de la plataforma Eclipse es su arquitectura, en la que
toda la funcionalidad es vista como un “plugin”. Un plugin es la mínima unidad de la
plataforma que puede ser desarrollado por separado y que le aporta una nueva
funcionalidad. El plugin que SAP desarrollo para Eclipse se llama PDK (Portal
Development Kit) y proporciona todas las herramientas necesarias para construir
componentes para SAP Web Application Server y SAP Enterprise Portal.
Cabe recalcar, que Eclipse es el IDE (Integrated Development Environment),
en el cuál se sugiere al desarrollador trabajar.
• Portal Development Kit (PDK)
PDK provee el cambiante necesario para crear y ejecutar componentes y
servicios para el servidor de aplicaciones Web de SAP. Entre las características y
beneficios, que ofrece PDK, están los siguientes:
• Se pueden desarrollar aplicaciones básicas para el portal
(componentes) e implementarlas en un portal.
• Se usa las bibliotecas de interfase de usuario HTMLB (HTML
Business), para generar páginas o formas basadas en el estilo de SAP.
• Desarrollo de componentes que utilizan el enfoque MVC (controlador
de vista modelo) y se utiliza para esto JSP y componentes Java bean.
76
• Desarrollo de aplicaciones de portal que estén localizadas en varios
idiomas, mediante las características de localización.
• Portal Data Viewer (PDV). Presenta datos de diferentes fuentes (XML,
JDBC, QUERY, ETC.) en forma tabular.
• Se integran aplicaciones mediante SSO (Single Sign-On).
• Desarrollo de componentes que utilizan la infraestructura de conector
(CF) basado en JCA y JCO, para acceder a los datos desde varios
sistemas back-end, incluido SAP R/3 y bases de datos relacionales.
• Utilización de la API de gestión de usuarios (UME 4.0) para acceder a
la información sobre los usuarios en tiempo de ejecución y así poder
modificar su información, como asignación de roles, etc.
• Logger. Eventos de log para diagnósticos o estadísticos.
• Utiliza componentes que utilizan el enfoque MVC (controlador de vista
de modelo).
• Mejora el rendimiento de las aplicaciones de portal mediante el uso de
características como la agrupación de conexiones y la caché de los
datos.
• Utiliza la integración de los servicios Web.
El PDK integrado con Eclipse, brinda un conjunto de herramientas para
desarrollar sobre el servidor de aplicaciones SAP y sobre su portal, permitiendo al
proyecto del SACI, estar dentro de los estándares de la compañía.
4.4.3.2 Plataforma de desarrollo web de SAP
El servidor SAP Web Aplication Server surgió con la necesidad de soportar la
tecnología de servicios Web a la infraestructura de SAP. El servidor de aplicaciones
ofrece lo siguiente al proyecto SACI:
• Bajos costos totales de propiedad
• Confiabilidad, escalabilidad y seguridad, todas esenciales para las
soluciones de escala empresarial.
77
• Apertura e interoperabilidad necesarias para extender los procesos de
negocios.
Con SAP Web Application Server, se obtiene soporte para los servicios
virtuales que no dependen de la plataforma usada; las aplicaciones de negocio; y el
desarrollo basado en estándares y edificado sobre tecnologías claves, tales como
Java 2 Platform Enterprise Edition (J2EE) y ABAP.
El servidor SAP Web Application Server proporciona funcionalidades
singulares para los desarrollos en equipo a escala empresarial, incluyendo logística
de software, seguridad y monitoreo. Además, el servidor constituye la base de
acceso multicanal a las aplicaciones de negocio, a través de la Web y de las
aplicaciones de voz o móviles.
El sistema SACI esta basado en una arquitectura SAP, desarrollada bajo los
siguientes productos:
• J2EE
J2EE es la edición empresarial de Java, creada y distribuida por Sun
Microsystems. Comprende un conjunto de especificaciones y funcionalidades
orientadas al desarrollo de aplicaciones empresariales. Debido a que J2EE no deja
de ser un estándar, existen otros productos desarrollados a partir de ella.
Algunas de sus funcionalidades unas importantes son:
• Acceso a base de datos JDBC.
• Utilización a directorios distribuidos (JNDI)
• Acceso a métodos remotos (RMI/CORBA)
• Funciones de correo electrónico (JAVA MAIL)
• Aplicaciones Web (JSP Y SERVLET), etc.
78
• OPEN SQL
Opensql surge para evitar conflictos entre bases de datos y mantener a los
programas independientes del sistema de base de datos utilizando, por eso SAP
definió este conjunto de sentencias SQL. Dicho en otras palabras OpenSQL permite
acceder a todas las tablas de base de datos, sin importar el fabricante de base de
datos.
Los beneficios de que ofrece OpenSQL al nuevo sistema SACI, son las de
poder usar cualquier base de datos sin importar hacer modificaciones a las
sentencias sql de la aplicación.
• SAP WEB AS
SAP Web Application Server (SAP WEB AS) es un servidor de aplicaciones,
Web basado en el protocolo de transferencias de hipertexto con integración a base
de datos y a herramientas de desarrollo.
4.4.4 Propuesta de arquitectura para el sistema de auditoria y control interno La arquitectura propuesta para el sistema de auditoria y control interno, se
basa en una arquitectura de servicios empresariales, diferente a la ya conocida
arquitectura cliente-servidor. Donde en la:
• Arquitectura Cliente/Servidor, se supone que cada aplicación, exponga
su funcionalidad a través de una interfase de usuario específica y
además que los procesos entre aplicaciones queden ocultos bajo la
implementación de APIs de bajo nivel. La figura 4.8 muestra la este
arquitectura.
79
Figura 4.8 Arquitectura cliente/servidor29
• La nueva arquitectura de servicios empresariales, propone una
interfase de usuario unificada para todas las pantallas del SACI, pero
específica para cada rol existente. La figura 4.9 muestra esta
arquitectura.
Figura 4.9 Arquitectura de servicios empresariales30
La justificación para proponer esta arquitectura es que:
29 Fuente: SAP NetWeaver, Visión General, p.25. USA 2003 30 Fuente: SAP NetWeaver, Visión General, p.26. USA 2003
80
• Integra a las diversas personas participantes de las unidades
operativas (internas y externas) según sus roles.
• Gestiona toda la información necesaria (estructurada y no
estructurada)
• Integra todos los procesos de control interno participantes en cada
proceso.
• Protege la inversión, reutilizando la funcionalidad de las aplicaciones
existentes, aunque no sea el caso para el sistema de auditoria y control
interno.
• Añade nuevos niveles de flexibilidad y extensibilidad, ya que posibilita
la integración de nuevos actores en el proceso de negocio.
• Disminuye los tiempos de implementación del SACI.
Esta arquitectura disminuye los tiempos de implementación, por lo que
para el sistema de auditoria y control interno posibilita una estructura de
costos sostenible, como se muestra en la figura 4.10.
Figura 4.10 Estructura de costos sostenible31
31 Fuente: SAP NetWeaver, Visión General, 2003
81
4.5 Propuesta de desarrollo para el SACI, con base a la plataforma web de SAP
“Como analista (gerente de producto), se puede tener la oportunidad de
observar el trabajo que realizan los programadores (desarrolladores) del proyecto;
de hecho, deben estar al tanto de la productividad, la eficiencia, la portabilidad y la
mantenibilidad sean cuestiones de importancia”32.
Para llevar a cabo la migración del sistema SACI se considera la siguiente
alternativa viable:
• Se da comienzo con el análisis del sistema actual de auditoria. Se hace
una revisión del funcionamiento de las macros Excel, con el fin de
conocer el detalle del funcionamiento.
• Con el objeto de hacer similares ambos sistemas, en cuanto a la
distribución de controles se refiere. Se diseñara un prototipo con
páginas Web que permite al usuario checar una primera versión de
cómo podrá quedar su aplicación, además de determinar cuestiones
del mecanismo del proceso.
• El código que se genere del prototipo, servirá después para
implementar la funcionalidad del sistema y la lógica de los procesos.
Generando la reutilización y aprovechamiento del prototipo generado
con anterioridad.
• Finalmente se codificará la parte correspondiente a las consultas y
modificaciones de la base de datos (inserciones, actualizaciones, etc.).
Además de hacer la parte de la lógica del negocio, para fundamental
entre la interfaz del usuario y los sistemas de base de datos.
La figura 4.11, muestra el proceso de desarrollo propuesto para el SACI.
32 Yourdon Edgard. Análisis estructurado moderno. p. 479. Pearson Prentice Hall. México 1993
82
Figura 4.11 Desarrollo propuesto del SACI33
4.6 Fases de pruebas del SACI
Una vez finalizada y revisada la primera versión del sistema por parte del
equipo de desarrollo, el equipo instalará esa versión de la aplicación en un ambiente
de calidad, para poder comenzar con un ciclo de pruebas con los usuarios
funcionales. De aquí en adelante se iniciará un ciclo en donde al el usuario funcional
al detectar alguna falla, levantará el reporte del mismo y se le asignara a un
desarrollador para que vea el problema, lo corrija en el ambiente de desarrollo, y una
vez verificado se suba de nuevo al ambiente de calidad. Estos pasos terminan hasta
que sean probados todos los casos del script de pruebas.
4.7 Fase de documentación
La fase de documentación se empieza cuando hay una versión estable del
sistema en el ambiente de calidad. La documentación del SACI, se solicita al equipo
de desarrolladores. Además los usuarios funcionales empezarán a hacer los
manuales operativos del sistema, mismos que entregarán a los usuarios del sistema,
en las capacitaciones previstas por ellos.
33 Fuente: Gráfica de creación propia
83
Conclusiones
84
Debemos tratar de entender los planteamientos y conceptos del nuevo mundo de la
Ingeniería de software que ayudan a la construcción de software de manera
eficiente.
Los fundamentos de este proyecto tecnológico están basados en aspectos
específicos de metodologías de procesos de calidad ampliamente revisadas y con
extensa aplicación por la empresa que requiere actualizar un sistema. Debido a esto
se pudo formular de manera adecuada lo qué se debe considerar y cómo se debe
realizar el seguimiento, supervisión y manejo de requerimientos del proyecto de
desarrollo de auditoria, los cuales representan los tres aspectos claves de este
sistema.
Así mismo, al concluir este análisis, se empezó a desarrollar el sistema de
auditoria y control interno, cumpliendo con el tiempo propuesto hasta la fase de
pruebas, y durante esta fase llevada a cabo en las oficinas de Coca-Cola FEMSA,
los usuarios accesaron al sistema y efectuaron capturas y consultas de manera
exitosa y segura, pudiendo culminar el proceso de auditoria adecuadamente
mediante el SACI. Así mismo se obtuvieron los siguientes beneficios:
• Reducción considerable de la carga de trabajo del área de auditoria y
control interno, debido a que la labor de configurar y asignar las
configuraciones del tablero de control se hace una vez al año.
• Los reportes gerenciales y el análisis de la información de la auditoria,
se realizan de manera automática a través de la aplicación, entregando
resultados correctos, oportunos y veraces, erradicando así cualquier
error en la información reportada.
85
• Incremento de la seguridad sobre el contenido de la información
capturada por las unidades auditadas.
• Oportuno despliegue de la información, ya que los usuarios conocen la
calificación obtenida en su evaluación al momento de terminar la
captura.
• Obtención de un solo punto de contacto con el usuario de las unidades
operativas, a través del SACI.
Con base en estos resultados obtenidos durante la fase de pruebas,
subjetivamente se puede evaluar el nuevo sistema propuesto. El sistema propuesto
cubre las necesidades de los usuarios del Equipo de Control Interno de Coca-Cola
FEMSA, para efectuar el proceso de auditoria dentro de las diferentes unidades
evaluadas, de una manera más óptima que el anterior proceso.
Finalmente se construirán dos escenarios posibles: el optimista y el pesimista,
en el escenario optimista se toman en cuenta las condiciones necesarias que son
factibles actualmente y que permiten vaticinar el éxito en la implantación del SACI en
el sistema productivo.
Por otro lado, para el caso del escenario pesimista interviene un factor
externo importante, como lo es la obsolescencia de la tecnología, que no obstante
ser un factor importante a considerar también para el primer escenario, se maneja
como una variable que condicionará de forma determinante al sistema.
Escenario Uno (El optimista)
Este escenario plantea un panorama cercano a la realidad, donde al
consolidarse el plan de modernización de Auditoria y Control Interno dentro de Coca-
Cola FEMSA: el SACI se implanta en los 9 países donde tiene presencia la
refresquera; por lo que lo que el área de Auditoria y Control Interno de los diferentes
países se ven motivados a la participación.
• Se transforma el proceso de auditoria con una nueva normatividad
adecuada a la modernización, con mejores procedimientos, manejo y
86
difusión de la información, con la posibilidad de establecer medios de
comunicación electrónicos entres las diferentes oficinas de la empresa.
• Se reforman los procedimientos de auditoria con el desarrollo y uso de
la tecnología.
Al pasar con éxito la fase de pruebas, se promueve exitosamente el sistema
entre los usuarios del área de auditoria de cada país y se libera oficialmente el
sistema en el portal corporativo.
• El sistema se mantiene en constante desarrollo. Al crecer los usuarios
y las oficinas operativas de la compañía, que obligan al sistema a
crecer y sufrir mejoras.
• El avance en la plataforma de desarrollo permite efectuar las
adecuaciones de manera sencilla y simplificadas, por lo que las
actualizaciones son transparentes y relativamente fáciles de llevar a
cabo.
• Se implanta el mecanismo de seguridad necesario para poner en
marcha el sistema.
• El sistema adquiere buena estabilidad y se mantiene sin
complicaciones durante los próximos 3 años.
• Pese a condiciones de incertidumbre debido a los cambios en la
compañía, (que pudieran influir en el plan de modernización) la
capacidad de adaptación al cambio por parte de los usuarios gracias a
la penetración en el campo de auditoria y control interno en Internet, y
a los cambios tecnológicos se considera un 90% de probabilidades de
que este escenario se concrete.
Escenario Dos (El pesimista)
A pesar de la consolidación del SACI y del programa de modernización del
proceso de Auditoria y Control Interno, el sistema intranet no corre con igual suerte:
• El crecimiento que sufre el SACI no puede llevarse del todo al
ambiente intranet, algunos elementos y procedimientos no son
87
completamente análogos, produciendo así inconsistencia en la
información.
• El avance en el ambiente de desarrollo dificulta la elaboración de las
modificaciones por lo que la plataforma en la que originalmente se
desarrolló el sistema comienza a ser obsoleta dada la nueva gama de
productos y versiones que salen al mercado para ambientes intranet,
encontrando así la incompatibilidad con los programas informáticos que
dieron vida al sistema.
• Las modificaciones requieren de una mayor cantidad de accesos a la
base de datos remota por lo que en ocasiones los trámites vía intranet
se truncan, o se alenta el proceso, dando como resultado una
ineficiencia del mismo.
• La plataforma de desarrollo comienza a sustituir sus productos dejando
obsoletas las herramientas propuestas durante el inicio del proyecto.
Esto trae como consecuencia que el sistema quede condicionado
cierto periodo de tiempo.
• El SACI requerirá de un rediseño que permita sacar provecho de la
tecnología que logre cierta estabilidad, para continuar satisfaciendo los
requerimientos y objetivos originales, así como los cambios que surjan.
• El área de Auditoria y Control Interno perderá interés en continuar con
el desarrollo del sistema hasta que no exista una demanda mayor y se
consolide alguna herramienta para desarrollar el sistema
completamente nuevo.
Además se puede concluir las siguientes cosas:
1. El modelo de Microsoft Solutions Framework, da confianza al cliente,
de un arranque del proyecto confiable y con bases, que pueden ser
clave para el éxito del mismo.
2. Mucho de los proyectos fracasan en algunas de sus fases, las
principales van desde el mal entendimiento de los requerimientos,
hasta por cuestiones de costos, en los cuales en ocasiones se
sacrifica la calidad y la entrega a tiempo.
88
3. Se concluye que muchas veces, se sacrifica el análisis de los
requerimientos o del proyecto y es cuestión de quien lo quiera
implantar querer no empezar con bases fuertes. El equipo del
proyecto encargado de realizar el SACI, esta conciente de que estas
bases son importantes para augurar el éxito del proyecto, por eso se
realizo el análisis necesario, junto con los usuarios del Equipo de
Control Interno.
Por otro lado se concluyen los siguientes puntos benéficos de este producto,
para la empresa Coca-Cola FEMSA y en especial para el Equipo de Control Interno
• De tipo cualitativos. Contara con una base de datos de información que
ayude a soportar los requerimientos de gobernancia corporativa,
evaluación de riesgos de negocio y de control interno. Otros de los
beneficios son:
o Integración y centralización de la información.
o Disposición inmediata de información veraz y oportuna.
o Creación de estándares de productos y procesos, homologación
en la información de indicadores, políticas y procedimientos.
o Favorece la comunicación con los usuarios y las unidades de
negocio.
o Confidenciabilidad y seguridad de la información
o Evita atrasos.
o Mejora la productividad del personal.
• De tipo cuantitativos.
o Optimiza el proceso de consolidación y presentación de
información.
o Disminuye el proceso de captura de la auditoria evitando:
• Disminución en errores.
o Optimización del proceso al definir tiempos de captura de
información, estableciendo fechas determinadas con el propósito
89
de poder realizar análisis de los resultados, observando el
cumplimiento en el control interno de todas las unidades de
negocio oportunamente.
o Evita la revisión innecesaria debido a la vulnerabilidad de la
herramienta (seguridad), es decir, que los archivos de Excel no
hayan sido alterados en su estructura y definición originales.
o Evita el envío y recepción de archivos para poder contar con la
información.
o Actualización de información inmediata.
o Uso racional de los recursos: papel, mensajería, etc.
Finalmente se puede concluir que pese a tener incertidumbre el escenario
pesimista, será el escenario optimista el que tiene mejores posibilidades de ser
concretado, debido a los beneficios que se obtendrán al implantar el SACI, al interés
puesto por parte del área de Auditoria y Control Interno, de las unidades que
conforman la compañía y de la misma compañía Coca-Cola FEMSA, para consolidar
esta propuesta integral (administrativa, financiera e informática) de modernización
para el proceso de auditoria llevado a cabo en la corporación de Coca-Cola.
Trabajos futuros
Dados los resultados anteriores en está tesis es importante señalar que se
ha desarrollado el análisis para el sistema de auditoria y control interno de Coca-
Cola FEMSA, el cual permitió empezar con la implementación del proyecto de
auditoria. Como trabajo futuro se recomienda:
• Al finalizar totalmente con la etapa de análisis, se hará un estudio sobre
las características del hardware del servidor web actual, ya que será
necesario hacer un redimensionamiento del hardware de la máquina,
debido a los nuevos usuarios que serán creados en el portal corporativo
de la empresa, donde será montado el SACI.
• Analizar y proponer a las demás entidades de negocio de FEMSA
(Cervecería y Oxxo), la posibilidad de integrar y llevar acabo su proceso
de auditoria, con el nuevo Sistema de Auditoria y Control Interno (SACI)
90
realizado para Coca-Cola FEMSA, ya que se encuentra un patrón similar
en dicho proceso.
• Realización de una prueba a gran escala del sistema, donde cada acción
del usuario es monitoreada y documentada por un panel de expertos, con
el motivo de estresar el sistema y ver el comportamiento del mismo ante
un escenario más real, que las simples pruebas del equipo de
implementación.
• A corto plazo, se planea comenzar con una segunda fase del proyecto,
donde nuevos requerimientos y necesidades al sistema surjan.
Asegurando así una mayor utilidad del producto realizado y además contar
con una herramienta más madura y estable, basada en las experiencias
de la primera versión del sistema.
• Se promoverá el uso de la metodología de trabajo presentada en esta
tesis para proyectos futuros dentro de Coca-Cola FEMSA, para asegurar
un estándar para los sistemas de este tipo dentro de la compañía.
91
Bibliografía
92
Bibliografía
Ackoff L. Russel, Cápsulas de Ackoff, Administración en pequeñas dosis .Editorial
Limusa, S.A. de C.V., México 1999
Ackoff L. Russel, El arte de resolver problemas. Editorial Limusa, S.A. de C.V.
México 2000
Ackoff L. Russel, Recreación de las corporaciones. Un diseño organiza cional
para el siglo XXI . Oxford University Press México, S.A. de C.V. México 2000
Graham, Robert J., Englund Randall L., Admnistracion de proyectos exitosos .
Prentice Hall Hispanoamericana S.A. de C.V., México1997
Harmon, Frederick G., El triunfo del ejecutivo . Editorial Vergara. Buenos Aires
1992
Jason J. Manger, Fundamentos de JavaScript. Mc. Graw Hill Interamericana
Editores S.A. de C.V., México 1997
93
Chris Bates. Web Programming: Building internet applications. Wiley Inglaterra
2002
Microsoft Solutions Framework, White Paper . Microsoft Corporation. U.S.A. 1999
MSF Team Model for Application Development , Microsoft Corporation,
U.S.A.1998
Christian Rau. Web Programming with the SAP Web Application Server . SAP,
Alemania 2003
Process Model for Application Development . Microsoft Corporation, U.S.A. 1998
Yourdon Edward. Análisis Estructurado Moderno . Prentice Hall Hispanoamericana
S.A. de C.V., México 1993
Equipo de Control Interno Coca-Cola, Sistema de Auditoria y Control Interno,
Manual de usuario . México, 2004
94
Glosario
95
Glosario
Apertura : Forma en la cual se podrá abrir y clasificar la información para acceder a
sucesivos niveles de desagregación, en matrices multidivisionales por producto,
sector geográfico, concepto de análisis, etc.
Auditoria : Es un examen crítico que se realiza con el fin de evaluar la eficacia y
eficiencia de una sección, organismo, entidad, etc.
Auditoria interna : La auditoria interna es la realizada con recursos materiales y
personas que pertenecen, a la empresa auditada.
Automatización : El término automatización se refiere a una amplia variedad de
sistemas y procesos que operan con mínima o sin intervención del ser humano.
Aplicación : Software o programa que realiza una función útil.
Base de datos : Es un almacenamiento colectivo de las bibliotecas de datos que son
requeridas y organizaciones para cubrir sus requisitos de procesos y recuperación
de información.
Cliente :a) Una aplicación que permite a un usuario obtener un servicio de un
servidor localizado en la red. b) Un sistema o proceso que solicita a otro sistema o
proceso que le presente un servicio.
Código fuente : Programa en su forma original, tal y como fue escrito por el
programador, el código fuente no es ejecutable directamente por la computadora,
96
debe convertirse en lenguaje máquina mediante compiladores, ensambladores o
interpretes.
Comercio electrónico : Por comercio entendemos el acto o relación entre el
comerciante y su cliente con la finalidad de reventa y lucro porque sin ellos no hay
acto de comercio. Por comercio electrónico hacemos referencia a esa misma
definición únicamente que el acto o relación entre el comerciante y su cliente usa un
medio electrónico.
Control Interno : Es un proceso continuo realizado por la dirección, gerencia
y, el personal de la entidad; para proporcionar seguridad razonable, respecto a si
están lográndose los objetivos siguientes: Promover la efectividad, eficiencia y
economía en las operaciones y, la calidad en los servicios que deben brindar cada
entidad; Proteger y conservar los recursos contra cualquier pérdida, despilfarro, uso
indebido o acto ilegal.
Desarrollador : Persona que escribe programas de aplicación en una organización
usuaria.
Fraude : Podemos afirmar que es un engaño hacia un tercero, abuso de confianza,
dolo, simulación, etc. El término “fraude” se refiere al acto intencional de la
administración, personal o terceros, que da como resultado una representación
equivoca de los estados financieros.
Hardware : Es la parte tangible de la computadora.
Hipertexto : Documentos que contienen vínculos con otros documentos, al
seleccionar el vínculo automáticamente se despliega el segundo documento.
HTML: Lenguaje de marcado de hipertexto, es el lenjuage con que se escriben los
documentos en el World Wide Web.
HTTP: Protocolo de transferencia de Hipertextos. Es el protocolo usado por el Word
Wide para transmitir páginas HTML.
97
Indicador : El término indicador, se refiere a datos esencialmente cuantitativos, que
nos permiten darnos cuenta de cómo se encuentran las cosas en relación con algún
aspecto de la realidad que nos interesa conocer. Los indicadores pueden ser
medidas, hechos, opiniones o percepciones que señalen condiciones o situaciones
específicas.
Información : Es un conjunto ordenado de datos los cuales son manejados según la
necesidad del usuario, para que en un conjunto de datos pueda procesado
eficientemente y pueda dar lugar a información, primero se debe guardar
lógicamente en archivos.
Interfase : Una conexión e interacción entre hardware, software y usuario, es decir
como la plataforma o medio de comunicación entre usuario o programa.
Internet : Es una red de cómputo a nivel mundial donde agrupa a distintos
tipos de redes usando un mismo protocolo de comunicación. Los usuarios Internet
pueden compartir datos, recursos y servicios.
Intranet : Es una red privada dentro de una compañía que utiliza el mismo software
que se encuentra en Internet, pero que es solo para uso interno.
Java SDK : Kit de desarrollo de software, es un conjunto de aplicaciones para
desarrollar programas en el lenguaje Java, consta de un compilador y un enlazador.
Login : Entrada, acceso. Proceso de entrar a un sistema dando una clave de de
usuario y una contraseña.
Manual de procedimientos : Es un documento el cual contiene la descripción de
actividades que deben seguirse en la realización de las funciones de unidad
administrativa, o de dos o más de ellas.
Medición : Es la “acción y efecto de medir” y medir es “determinar un cantidad
comparándola con otra”.
98
Migración : Traslado de una aplicación de una computadora a otra en condiciones
de compatibilidad. Migrar es también elevar una versión de un producto de software
a otra de más alto nivel.
Modelo cliente-servidor : El modelo o arquitectura cliente-servidor se apoya en
terminales (clientes) conectadas a una computadora que los provee de un recurso
(servidor). De esta manera los clientes son los elementos que necesitan servicios del
recurso y el servidor es la entidad que posee el recurso. Los clientes sin embargo no
dependen totalmente del servidor. Ellos pueden realizar los procesamientos para
desplegar la información. El servidor los provee únicamente de la información sin
hacerse cardo de otros procesos. El tráfico en la red de esta forma se ve aligerado y
las comunicaciones entre las computadoras se realizan más rápido.
Navegador : También son conocidos como browsers. Programa que despliega
información almacenada en páginas HTML que se encuentran disponibles en
servidores Web.
Plan de acción : Se refiere al conjunto de actividades programadas para la
obtención de las evidencias capaces de sostener con éxito una denuncia. Una
evidencia, en consecuencia, son todos aquellos antecedentes usados para
configurar hechos que prueban o desaprueban un delito.
Protocolo : Procedimiento que se utiliza para mover la información de una parte a
otra sin errores.
Pruebas de aceptación : Son las pruebas finales que sufre una aplicación o sistema
donde se prueba un ambiente real de operación y está listo para su liberación final.
Pruebas integrales : Son las pruebas que sufre cada componente de alguna
aplicación o sistema.
Servidor : Computadora dedicada a gestionar el uso de la red por otras
computadoras llamadas clientes. Contiene archivos y recurso que pueden ser
accesados desde otras computadoras.
99
Software : Conjunto de programas, documentos, procesamientos y rutinas asociadas
con la operación de un sistema de computadoras. Es la parte intangible de una
computadora.
SQL: (Structured Quero Language). Lenguaje de programación que permite
manipular los datos almacenados en una base de datos.
Tablero de Control : El concepto de tablero de control parte de la idea de configurar
un tablero de información cuyo objetivo y utilidad básica, es diagnosticar
adecuadamente una situación. Se lo define como el conjunto de indicadores cuyo
seguimiento periódico permita contar con un mayor conocimiento de la situación de
su empresa o sector.
Tiempo de conexión : Tiempo que una computadora se mantiene accesando a
Internet.
Toma de decisión : Es el proceso durante el cual la persona debe escoger entre una
o más alternativas.
URL: (Uniform Resource Locutor). Localizador uniforme de recursos. Sistema de
direccionamiento estándar para archivos y funciones de Internet.
Usuario : Todo aquel que utiliza un software o un sistema informático.
Versión : Son las aplicaciones o software revisado, en ocasiones corregido y
mejorado desplazando al anterior.
Windows : Sistema operativo gráfico de 32 bits desarrollado por Microsoft y diseñado
específicamente para computadoras con procesadores compatibles con Intel.
World Wide Web : Sistema basado en hipertextos cuya función es buscar y tener
acceso a documentos a través de la red.
