Archivos para 22 julio 2011

Descripcion Conceptual de Arquitecturas Empresariales

Esto es parte de un trabajo que hice sobre arquitecturas empresariales, me parece interesante los conceptos teóricos y las aplicaciones que pueden tener a nivel de investigación son muy amplios, espero que les sirva.

1.1        Arquitecturas Empresariales 

La arquitectura es el arte y la ciencia del diseño de estructuras complejas. La Arquitectura Empresarial, más concretamente, se define como un conjunto coherente de principios, métodos y modelos que se utilizan en el diseño y la realización de la estructura organizativa de una empresa, además de los procesos de negocio, los sistemas de información y su infraestructura. Los modelos de Arquitectura, visitas, presentaciones y análisis de toda la ayuda para superar la “falta de comunicación” entre los arquitectos y las partes interesadas (Lankhorst, 2009).

El objetivo de la Arquitectura Empresarial es proveer una visión integral de la empresa, a través de mapas que documenten los distin­tos elementos que conforman a la operación y que faciliten la mejora continua, permitiendo el modelado de los posibles escenarios de ajustes a los procesos del negocio.
La arquitectura es un instrumento indispensable para controlar la complejidad de la empresa y sus procesos y sistemas. Por un lado, vemos los controles internos para el uso de un enfoque arquitectónico, relacionados con la ejecución de la estrategia de la organización. Un mejor alineamiento del negocio  lleva a un menor costo, mayor calidad, mejor tiempo de salida al mercado, además de una mayor satisfacción del cliente. Por otra parte, los controles externos de las autoridades reguladoras entre otras presiones exigen a las empresas tener un profundo conocimiento de su estructura y de sus operaciones. Todos estos controles implican claramente la necesidad del uso de la arquitectura empresarial.

El objetivo de la arquitectura empresarial es crear un entorno de TI unificado (hardware estándar y de sistemas de software) a través de la empresa o la totalidad de las unidades de negocio de la empresa, ante la estrechez de los vínculos simbióticos con el lado del negocio de la organización y su estrategia. Más concretamente, los objetivos son promover la adaptación, la normalización, la reutilización de los activos de TI existentes(Minoli, 2008), y la distribución de métodos comunes para la gestión de proyectos y desarrollo de software a través de la organización. El resultado final, en teoría, es que la organización sea más competitiva y eficiente.

El propósito de la arquitectura empresarial es crear un mapa de los activos de TI, procesos de negocio y un conjunto de principios de gestiones que impulsan un debate sobre la estrategia de negocio y cómo puede expresarse a través de TI. Hay muchos diferentes marcos sugeridos para desarrollar una Arquitectura Empresarial. Sin embargo, la mayoría de los marcos contienen cuatro ámbitos fundamentales:

(1)    La arquitectura de negocio: la documentación que describe los procesos de negocios más importantes de la empresa,

(2)    Arquitectura de la información: identifica donde los bloques de información importante, como un registro de cliente, se mantengan y cómo se accede a ellos normalmente

(3)    La arquitectura del sistema de aplicación: un mapa de las relaciones de aplicaciones de software entre sí

(4)    La arquitectura de la tecnología de infraestructura: un modelo para toda la gama de hardware, sistemas de almacenamiento y redes.

1.2         Ventajas y beneficios de la Arquitectura Empresarial

Una Buena arquitectura empresarial habilita a la organización para alcanzar el correcto balance entre eficiencia tecnológica e innovación del negocio. Esta permite que unidades de negocio individuales puedan innovar con seguridad en busca de ventaja competitiva. Al mismo tiempo, esta asegura las necesidades de la organización de una estrategia de TI integrada, permitiendo la mayor sinergia posible a través de la organización

En el trabajo de Eloísa 2008 podemos destacar algunas ventajas y beneficios de la aplicación del Framework de Zachman en una organización:

  • Ayuda a crear un repositorio único de información donde se incluyen los mapas de referencia que reflejan los procesos de la empresa, estos mapas plasman las dimensiones que definen al negocio, además de identificar la relación que existe entre ellas.
  • Esta práctica está orientada a brindar soporte a la operación, iden­tificando impactos en los ajustes al modelo de negocio para conocer las implicaciones de un cambio, antes de arrancar un esfuerzo o nuevo proyecto.
  • Como lo habíamos mencio­nado anteriormente, proporciona información para generar posibles escenarios de solución y de esta manera sirva como herramienta para la toma de decisiones en los ajustes a los procesos.

Las ventajas tecnológicas resultantes de una buena arquitectura empresarial brindan beneficios de negocio importantes que son visibles en los resultados como:

  • Una operación de TI más eficiente.
    • Menores costos de desarrollo, soporte y mantenimiento de software.
    • Mayor portabilidad de aplicaciones.
    • Interoperabilidad mejorada y administración de sistemas y redes más sencilla.
    • Una mejor capacidad para atender asuntos que afectan toda la organización como la seguridad.
    • Mayor facilidad para cambiar y actualizar componentes de sistemas.
  • Mejor retorno en inversiones actuales y un menor riesgo en inversiones futuras.
    • Reducción en la complejidad de la infraestructura de TI.
    • Máximo retorno de inversión en la infraestructura existente.
    • Flexibilidad para hacer, comprar o tercerizar soluciones de TI.
    • Reducción en el riesgo en nuevas inversiones y menores costos total de TI.
  • Un proceso de adquisición más rápido, sencillo y económico
    • Las decisiones de compra son más sencillas, dado que la información para gobernar este proceso está disponible a primera manos en un plan coherente.
    • El proceso de adquisición es más rápido, maximizando la velocidad y flexibilidad para adquirir tecnología sin sacrificar la coherencia de la arquitectura.

1.3        Framework en arquitectura empresarial

El marco o Framework es la estructura que permite almacenar y comunicar los diferentes elementos de la arquitectura de empresa(González, Bas, & García, 2005). También Framework en Arquitectura empresarial se define como una estructura lógica para clasificar y organizar las representaciones descriptivas de una Empresa, las cuales son especialmente significativas tanto para la dirección y  control de la organización como para el desarrollo de sus sistemas (Zachman, 1987)

Siguiendo a Martin (2004) (Martin, Robertson, & Springer, 2004) diremos que el Framework de una arquitectura de empresa permite entender una empresa o una clase de empresas mediante la organización y presentación de artefactos que conceptualizan y describen la empresa.

Los Frameworks en distintas aéreas o estratos de una organización y los modelos de Arquitectura Empresarial han demostrado ser de gran utilidad, ya que cuando se usa en distintos estratos se tiene la ventaja de la definición clara de contenidos de los distintos procesos. Existen una serie de modelos o técnicas de modelado, por ejemplo, el Open Grupo de Arquitectura de Framework (TOGAF), la Federal Enterprise Architecture Framework (FEAF), y así sucesivamente. Sin embargo, en este momento no hay consenso en toda la industria completa sobre lo que un modelo de arquitectura empresarial debe ser, por lo tanto diferentes modelos existen o pueden ser utilizados actualmente. Un caso en que la normalización en el tipo de modelo o Framework a usar en una organización es el caso de la Interconexión de Sistemas Abiertos Modelo de Referencia (OSIRM) publicado en 1984 por la Organización Internacional de Normalización (ISO) (este modelo, sin embargo, sólo se aplica a las comunicaciones )(Minoli, 2008).

Existen múltiples Frameworks para la Arquitectura, en la tabla 1 se muestra un listado de los principales Frameworks que son utilizados en la actualidad, sin embargo se debe resaltar que en multiples estudios y encuestas de la industria (Minoli, 2008), es el Framework de Zachman, seguido por TOGAF, y el nivel de red del Departamento de Defensa Técnica Modelo de Referencia (DoD TRM) (que cubre alrededor de dos tercios de todas las empresas.)

Tabla 1. Frameworks existentes para Arquitectura Empresarial. Fuente (Minoli, 2008)

1

Zachman Enterprise Architecture Framework (ZIFA)

2

The Open Group Architecture Framework (TOGAF)

3

Extended Enterprise Architecture Framework (E2AF)

4

Enterprise Architecture Planning (EAP)

5

Federal Enterprise Architecture Framework (FEAF)

6

Treasury Enterprise Architecture Framework (TEAF)

7

Integrated Architecture Framework (IAF)

8

Joint Technical Architecture (JTA)

9

Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) and DoD Architecture Framework (DoDAF)

10

Department of Defense Technical Reference Model (DoD TRM)

11

Technical Architecture Framework for Information Management (TAFIM)

12

Computer Integrated Manufacturing Open System Architecture (CIMOSA)

13

Purdue Enterprise Reference Architecture (PERA)

14

Standards and Architecture for eGovernment Applications (SAGA)

15

European Union—IDABC & European Interoperability Framework

16

ISO/IEC 14252 (IEEE Std 1003.0)

17

IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description

1.4        Definición del Framework de Zachman

En 1987, John Zachman presentó el primer y más conocido Framework de Arquitectura Empresarial (Zachman 1987), aunque en aquel entonces era llamado “Marco para la Arquitectura de Sistemas de Información”. El marco en que se aplica a las empresas es simplemente una estructura lógica para la clasificación y organización de las representaciones descriptivas de una empresa que sean de importancia para la gestión de la empresa, así como para el desarrollo de sistemas de la empresa. El marco (ilustración 1) en su forma más simple muestra los objetos de diseño que constituyen la intersección entre las funciones del proceso de diseño: es decir, el dueño, diseñador y constructor, y las abstracciones de productos: en otras palabras, Que? (el material) está hecho de, cómo? (procesos) que funciona y donde (geometría) los componentes están relacionados entre sí.

El Framework de Zachman describe un modelo integral de la infraestructura de la información de la empresa desde seis perspectivas: planificador, propietario, diseñador, constructor, subcontratistas, y el sistema de trabajo. No hay ninguna orientación sobre la secuencia, proceso o aplicación del marco. La atención se centra en garantizar que todos los aspectos de una empresa están bien organizados y muestra relaciones claras que garanticen un sistema completo, independientemente del orden en el que están establecidos

Ilustración 1. Framework Zachman. (Zachman, 1987)

El eje vertical ofrece múltiples perspectivas de la arquitectura global, y en el eje horizontal muestra una clasificación de los distintos artefactos de la arquitectura. El Framework de Zachman es similar a otros marcos, su propósito es proporcionar una estructura básica que apoya la organización, acceso, integración, interpretación, desarrollo, gestión y transformación de un conjunto de representaciones arquitectónicas de los sistemas de información de la organización, los objetos o las descripciones de las representaciones arquitectónicas normalmente se conoce como artefactos(Minoli, 2008). El Framework de Zachman es el marco más ampliamente utilizado hoy en día, además ha recibido una amplia aceptación en todo el mundo como un Framework de integración.

En 1987, John Zachman escribió: “Para mantener el negocio de la desintegración, el concepto de arquitectura de sistemas de información es cada vez menos una opción y más en una necesidad.” Desde esta afirmación hace mas 20 años, el Marco Zachman se ha desarrollado y convertido en el modelo a través del cual las principales organizaciones pueden visualizar y comunicar su infraestructura de información de la empresa. El Framework de Zachman se basa en la disciplina de la arquitectura clásica de establecer un vocabulario común y un conjunto de puntos de vista, un marco para definir y describir los sistemas empresariales complejos de hoy.
El marco contiene los planes globales, así como los detalles técnicos, listas y gráficos, también contiene las declaraciones del lenguaje natural. Cualquier enfoque adecuado, estándar, función, método, técnica o herramienta puede ser puesto en él. De hecho, el marco puede ser visto como una herramienta para organizar cualquier forma de metadatos para la empresa.  De hecho, es fácil de adquirir, fuera de la plataforma, herramientas de desarrollo de aplicaciones y metodologías que apoyan la construcción del modelo (ver http://www.zifa.com/)
Una de las ventajas del Framework de Zachman es su fácil de entendimiento, además de abordar la empresa en su conjunto, se define de forma independiente de las herramientas o metodologías hasta ahora existentes, y las cuestiones se pueden asignar en contra de ella para comprender dónde encajan (Lankhorst, 2009). Un inconveniente importante es el gran número de celdas, que es un obstáculo para la aplicación práctica del marco. Además, las relaciones entre las diferentes celdas que no están bien especificadas. A pesar de estos inconvenientes, Zachman se acredita de proporcionar el Framework general para la primera Arquitectura Empresarial, y su obra sigue siendo ampliamente utilizada.

1.4.1        Principios Fundamentales del Framework de Zachman

Los principios fundamentales que guían la aplicación del Framework de  Zachman incluyen los  siguientes aspectos (Minoli, 2008):

1.  Un sistema completo que puede ser modelado por representación de las respuestas a las siguientes preguntas: ¿por qué, quién, qué, cómo, dónde y cuándo?.

2. Los seis puntos de vista de captura de todos los modelos críticos para el desarrollo del sistema
3. Las restricciones para cada perspectiva son aditivos; las de una fila inferior se suman a los de las filas de arriba para ofrecer un creciente número de restricciones.
4. Las columnas representan abstracciones diferentes en un esfuerzo por reducir la complejidad de un modelo único que se construyen.
5. Las columnas no tienen ningún orden.
6. El modelo de cada columna deben ser únicos.
7. Cada fila representa una perspectiva única.
8. Cada celda es única.
9. La lógica inherente es recursivo.

1.4.2        Estructura del Framework de Zachman

El Marco de Zachman tiene la intención de facilitar la comprensión de cualquier aspecto particular de un sistema en cualquier punto de su desarrollo. La herramienta puede ser útil en la toma de decisiones sobre los cambios o ampliaciones.

El marco Zachman Sin embargo (Panetto, Baïna, & Morel, 2007), no es suficiente, ya un marco práctico para la arquitectura de la empresa. El marco Zachman ofrece una visión estática de todos los elementos que intervienen en los sistemas de información. No define los procesos para pasar de una existente (como está) la situación a un futuro (a ser) del estado y tampoco define una organización para apoyar tales procesos.

La descripción de las filas son los siguientes:

  • Objetivo: Corresponde a un resumen ejecutivo de un planificador que quiere una estimación del tamaño, costo y la funcionalidad del sistema. Además el planificador se ocupa del contexto de la empresa, de su entorno competitivo, de las fuerzas internas y externas que influyen en su competitividad, del posicionamiento de sus productos y servicios, que lo obligan a especificar sus alcances a largo plazo; esta perspectiva cubre los componentes del nivel estratégico
  • El modelo de negocio (Dueño): Muestra todas las entidades y procesos de negocio, y cómo interactúan. Aquí se relaciona el Dueño, este se interesa en la operación del negocio, para lo cual requiere del modelado de la empresa mediante modelos de procesos, de flujos de trabajo, de logística empresarial, de modelos semánticos y de planes de negocio que le permitan controlar la operación de la empresa; esta perspectiva se centra en el proceso de negocio, por lo que constituye en buena medida el nivel de procesos.
  • El modelo del sistema (Diseñador): es usado por un analista de sistemas que deben determinar los elementos de datos y funciones de software que representan el modelo de negocio. Tiene que ver con la especificación de los planos conceptuales de los sistemas de información que se requieren para soportar la operación de los procesos.
  • Modelo tecnológico (Constructor): Considera las limitaciones de las herramientas, la tecnología y los materiales. El Constructor se encarga del ensamblado y fabricación de los diversos componentes de los sistemas de información de acuerdo con las restricciones de la tecnología utilizada
  • Componentes o representaciones detalladas (Programador): Representación individual de los módulos independientes que pueden ser asignados a los contratistas para la ejecución de tareas. El programador trabaja en la fabricación de los componentes de acuerdo con las especificaciones del constructor. Las perspectivas del diseñador, constructor y programador se ubican claramente en el nivel de sistemas de información.
  •  Sistema de trabajo: muestra el sistema operativo.

La descripción de las Columnas es la siguiente:

  • Que: Representa las relaciones de las personas dentro de la empresa. El diseño de la organización empresarial tiene que ver con la asignación de trabajo y la estructura de autoridad y responsabilidad. La dimensión vertical representa la delegación de autoridad, y la horizontal representa la asignación de la responsabilidad.
  • Cuándo: representa el tiempo, o el caso de las relaciones que establecen los criterios de rendimiento y los niveles cuantitativos de los recursos de la empresa. Esto es útil para diseñar el programa maestro, la arquitectura de procesamiento, arquitectura de control, y dispositivos de sincronización.
  • Por qué: describe las motivaciones de la empresa. Esto pone de manifiesto los objetivos de la empresa y los objetivos, plan de negocios, la arquitectura del conocimiento, y el diseño de los conocimientos.
  • Qué: Describe las entidades involucradas en cada punto de vista de la empresa. Los ejemplos incluyen los objetos de negocio, datos del sistema, las tablas relacionales, las definiciones de campo.
  • Cómo: Muestra las funciones dentro de cada perspectiva. Incluyen procesos de negocio, la función de la aplicación de software, la función del hardware del equipo, y lazo de control del lenguaje.
  • Dónde: Muestra las localizaciones y las interconexiones dentro de la empresa. Esto incluye lugares geográficos empresariales importantes, secciones separadas dentro de una red logística, la asignación de los nodos del sistema, o incluso las direcciones de memoria dentro del sistema.

El Framework se puede utilizar de forma recursiva para gestionar la complejidad de especificar una arquitectura empresarial. En este caso, la instancia superior representa el Framework de modelado empresarial de todo el negocio, la instancia del Framework central representa modelado empresarial de una división independiente en otra instancia y la instancia inferior representa Framework modelado empresarial de estaciones de trabajo independientes. Este es sólo un ejemplo de cómo un problema complejo se puede dividir en piezas más simples, mientras que cada pieza puede ser modelada por derecho propio con el Framework de Zachman. Un Framework puede ser utilizado para desarrollar la arquitectura técnica a un nivel que se aplicará a todas las divisiones de la empresa. Otro Framework puede ser utilizado para desarrollar las redes departamentales, que deben ajustarse a todas las limitaciones especificadas en el ámbito de la empresa. Sin embargo, otro Framework puede ser utilizado para desarrollar y gestionar la configuración de una estación de trabajo independiente, que cumple con todas las limitaciones desarrollado en la división o nivel departamental

2          Referencias Bibliográficas

  1. Abdullah, A., & Zainab, A. (2006). The Application of Zachman Framework in Architecting a Collaborative Digital Library. Library & Information Science Unit, Faculty of Computer Science & Information Technology University of Malaya .
  2. Armando, M., & Velázquez, A. (2006). Un Método para definir la Arquitectura de Procesos. Proceedings of the Twelfth Americas Conference on Information Systems, (págs. 4355-4365). acapulco.
  3. González, L. C., Bas, Á. O., & García, A. B. (2005). Arquitectura de Empresa. Visión General. IX Congreso de Ingeniería de Organización.
  4. Lankhorst, M. (2009). Enterprise Architecture at Work, Modelling, Communication and Analysis. London, New York: Board.
  5. Martin, R., Robertson, E., & Springer, J. (abril de 2004). Architectural Principles for Enterprise Frameworks. Obtenido de http://www.cs.indiana.edu/pub/techreports/TR594.pdf.
  6. Minoli, D. (2008). Enterprise Architecture A to Z. United States of America: Taylor & Francis Group,.
  7. Panetto, H., Baïna, S., & Morel, G. (2007). Mapping the iec 62264 models onto the zachman framework For analysing products information traceability: A case study. Journal of Intelligent Manufacturing, 18, 6 , 679-698.
  8. Santuario, E. I. (2008). Arquitectura Empresarial como Práctica para Mantener la Estabilidad de los Sistemas de una Organización.
  9. Zachman, J. (1987). A Framework for Information Systems Architecture. IBM Systems Journal, 26(3) , 276-292.

Business Process Management (BPM)

Que es BPM

Los procesos dentro de una empresa están organizados en torno a los pasos básicos que atraviesan los departamentos y las líneas de división, los mismos están estandarizados y son cuantificables y medibles en toda la empresa. Utilizando el enfoque de Gestión de procesos BPM, las empresas obtienen soluciones que les permiten medir y estandarizar sus procesos actuales, les permite detectar aquellas áreas de negocio que pueden ser reutilizable para conectarse con otras áreas y así disminuir costes. El enfoque de BPM a la tecnología facilita la tarea de cambiar los procesos de negocio mediante la separación de las aplicaciones tecnológicas de los procesos de negocio. Los procesos no son estáticos, en la medida que la empresa evoluciona y cambia, y los procesos también cambian.

Los procesos deben ser más flexibles y la falta de flexibilidad para apoyar cambios en los procesos de negocio fue un punto débil de muchas aplicaciones empresariales. En las últimas décadas, las empresas se han tenido que adaptar a las nuevas tecnologías, debido a la globalización, con el objetivo de no quedarse atrás y ser más competitivo, esto ha obligado a las organizaciones a ser más flexibles.

Siempre se han analizado los procesos y como mejorarlos y hacerlos más efectivos y más productivos, de aquí nace la Gestión hacia los procesos de negocios, de acuerdo a la definición que establece Chang (2006), de BPM, se pueden identificar las siguientes caracteristicas de un proceso de negocio:

· Un proceso de negocio debe ser aquel que genere valor, si existe un proceso de negocio que no agregue valor, este no se debe hacer

· Los procesos de negocio deben estar normalizados y deben ser coordinados

· A través de la coordinación y la normalización los procesos de negocio son reutilizables.

De acuerdo a las características anteriores Chang (2006), BPM se define como un enfoque de gestion con una vision sistemica para analizar, mejorar, controlar y gestionar los procesos de negocio con el objetivo de mejorar la calidad de los productos y servicios, tomando en cuenta el enfoque anterior BPM se puede adaptar para trabajar fácilmente con prácticas como la Gestión Total de la Calidad (TQM Total Quality Management) y BPR Gestión en reingeniería de procesos, cuando se trabaja con tecnología en la gestión de procesos se denomina BMPS (Business Process Management System).

Los autores Jeston & Nelis (2006), hacen enfasis en la Gestion de negocio antes de la implicacion tecnologica inicial, la tecnologia puede venir como un valor agregado despues de gestionar adecuadamente los procesos de negocio fundamentales, los autores Jeston & Nelis (2006) establecen una definicon muy sencilla de BPM “El logro de los objetivos de una organización mediante la mejora, gestión y control de procesos de negocio esenciales.”

Así, la gestión de procesos es una parte integrada de la gestión organizacional. Es importante para el liderazgo y la gestión reconocer que no hay línea de meta para la mejora de los procesos de negocio, es un programa que debe ser continuamente mantenido, en función de esto se puede decir que BPM es lo siguiente:

● Más que un software
● Más que la mejora o reingeniería de sus procesos
● más que modelos – también se trata de la aplicación y ejecución de procesos que requieren análisis.

Mitos de BPM

Es importante aclarar que BPM, no es la solución a todos los problemas de una empresa, tampoco que la aplicación de un software de BPMS por si sola mejorara la gestión de una organización, sin considerar una metodología o marco de trabajo, para utilizar los recursos calificados y un compromiso auténtico de dirección de la organización es inútil utilizar BPMS.

Siguiendo el trabajo de Jeston & Nelis (2006), definen algunos mitos respecto a BPM, estos se muestran a continuacion:

1. BPM es mejor que cualquier opción para la mejora de procesos: Sin duda se mejora la visibilidad para la mejora del proceso, muchos investigadores y académicos se han centrado en BPM y se han creado e integrado organizaciones para su estudio por ejemplo BPMI.org / BPM Group, esto ayuda a fortalecer la madurez y a aprender de la experiencia del pasado con marcos similares como TQM y BPR.

2. BPM utiliza nuevas y mejores tecnologías. Hay muy pocas empresas totalmente automatizadas en sistemas de BPM para validar esta afirmación. La tecnología no debería ser el foco inicial en una implementación de BPM. Si bien estos nuevos procesos de mejora podrían contener sugerencias para la automatización, sin embargo se debe analizar si la mejora de los procesos importantes se puede lograr sin el uso de la tecnología.

3. Hay una metodología robusta para apoyar BPM. Existen metodologías para las partes de BPM, pero no se ha desarrollado una metodología para la aplicación de una solución de BPM total.

4. BPM es simple (y, de hecho, a menudo excesivamente simplificada). BPM es cualquier cosa menos simple. Existen muchos componentes y elementos para la aplicación de BPM. No es necesario resolver todos los problemas en el proceso las organizaciones de una sola vez con BPM. Es recomendable comenzar poco a poco con un proyecto. A medida que la organización madura BPM puede ser ampliado a otras áreas.

5. Personas externas son necesarias para la aplicación de BPM. Esto depende mucho de la madurez de la organización y los niveles de habilidad y experiencia dentro de la organización. Ciertamente, los consultores externos pueden ayudar ya sea en un rol de asesoría, entrenamiento si la madurez de la organización y/o los niveles de competencia son suficientes. Un experimentado gestor de BPM externo del proyecto puede proporcionar un apoyo importante al proyecto, que a veces los directores de proyectos internos no son capaces de aportar a un proyecto.

Análisis Comparativo de la Red de Distribución (Almacenes y Tiendas) de Mercadona, Carrefour y Consum

Quiero presentar un trabajo comparativo que hice para el máster de Producción Avanzada y Cadena de Suministro,  es un análisis de tres grandes supermercados españoles, el análisis lo hice en enero del 2010, lo construí con información basicamente de Internet, las fuentes estan al final del trabajo, las dejo para aquellos que quieran seguir investigando.

Acepto criticas constructivas, sugerencias y opiniones, espero que le sirva a alguien  de ayuda.

1. Introducción

El presente trabajo pretende mostrar un análisis comparativo, entre tres supermercados estos son: Gigante Francés Centro Comerciales Carrefour,  Supermercados Mercadona que hoy por hoy es una de las principales empresas en la venta de productos alimenticios en la superficie española y por ultimo una de las Cooperativas principales de España y dela Comunidad Valenciana, Cooperativa Consum.

Se quiere mostrar la evolución en los últimos 4 años respecto a la facturación de cada entidad, como también el incremento y la evolución en cuanto al número de tiendas, numero de empleado, numero de referencias entre otros.

Se podrá observar una disminución muy leve de la facturación de Carrefour  en estos últimos años así como una tendencia estable respecto al número de empleados y de su facturación por tienda. Para el caso de Mercadona, ha tenido y todavía tiene una evolución positiva respecto a su facturación se ha mantenido en promedio en un 14% de crecimiento en monto facturado.

Para Cooperativa Consum una de las principales empresas empleadoras dela Comunidad Valenciana, se resalta un crecimiento bastante fuerte, entre los años 2005 y2008 hatenido un crecimiento mantenido del 22% en su facturación, esto se debe al aprovechamiento de las economías de escala, en otras palabras, en el año 2007 compro mas de 100 supermercados enla Comunidad Valencianay enla Comunidad Catalana  y ha realizado una inversión de mas de 450 millones de euros entres los años 2005 y 2008.

 

Este es el doc en PDF completo del trabajo Analisis comparativo MCC

Análisis Critico del Libro: La Meta

1. Expresar la relación entre la logística y manufactura

El autor platea que la única meta de una organización es ganar dinero ahora y en el futuro y que los demás objetivos solo están allí para cumplir dicha meta.

En este sentido si una empresa desea conocer que tan cerca o lejos se encuentra de su meta debe medir los siguientes parámetros de gestión (variables financieras): Utilidad Neta, Rentabilidad o ROI y Liquidez. Se pretende que estas variables estén en aumento simultáneamente para lograr la consecución de la meta, aunque esto, no siempre sucede.

Para guiar la toma de decisiones Goldratt propone los parámetros de explotación para ayudar a visualizar si las acciones locales contribuirán a la consecución de la meta y determinar como impactan las variables financieras presentadas anteriormente. Los parámetros de explotación son:

De acuerdo con lo anterior para conseguir la meta se deben reducir los gastos operativos y los inventarios a la vez que se incrementan los ingresos.

La Teoría de Restricciones plantea que un proceso es tan rápido como su subproceso mas lento, en este sentido siempre existirá un proceso o un recurso escaso denominado “Cuello de Botella”, limitación o restricción que indica la máxima capacidad del sistema, en el cual la organización debe focalizarse para usar los recursos de manera equilibrada en la búsqueda de la meta.

Para esto el autor propone cinco pasos para las organizaciones que deseen establecer un proceso de mejora continua basado en la Teoría de la Restricciones:

1. Identificar los “Cuellos de Botella” (CB) del sistema
2. Explotar los CB anteriormente identificados
3. Subordinar todo al CB anterior
4. Elevar la capacidad o actividad del CB
5. Una vez resuelto el CB regresar al primer paso, revisando continuamente el sistema

Además de esto es necesario garantizar un plan comunicacional que involucre a toda la organización para que todo el personal comprenda y este alineado con estas directrices y se aboquen a contribuir en el logro de la meta.

La relación entre la manufactura y la logística se puede observar con más fuerza en el paso 3, donde propone que una vez identificado y decidido la forma de explotación de las restricciones del sistema, se subordinen todas las acciones a los CB. Por lo tanto, la cadena de suministro debe sufrir los cambios necesarios para que el sistema funcione a la velocidad de explotación deseada. Esto implicaría cambios por ejemplo, en políticas de suministros, inventarios (materia prima, productos en proceso y productos terminados), y demás actividades logísticas de soporte, necesarias para que el sistema pueda tener el ritmo previsto en el diseño de explotación de los CB.
2. Ubicar la Teoría de Restricciones en el entorno laboral venezolano

La Teoría de las Restricciones propone en sus principios, una cultura que resultaría positiva para cualquier empresa en Venezuela que desee perdurar en el tiempo, sin embargo, en nuestro país son muchas las restricciones que la mayoría debe enfrentar y que en otros países no existen, por ejemplo: vías terrestres deterioradas, unidades de transporte en mal estado, alta burocracia para la adquisición de divisas, alta proporción de insumos importados, bajo desarrollo tecnológico, entre otros.

Además de esto, las empresas venezolanas se encuentran inmersas en una cultura de improvisación donde la urgencia marca la pauta y donde comúnmente se cree que maximizar la capacidad es invertir más y no explotar mejor, los recursos ya existentes (CB en el caso de la Teoría de las Restricciones). Muchas veces se cede a la tentación de aplicar las ultimas tecnologías sin analizar suficientemente los parámetros financieros y de explotación propuestos en la teoría de Goldratt.

Existe otro componente del entorno que puede interferir en la aplicación de estos conceptos, tal como la legislación laboral, además del componente ideológico “socialista” que se esta arraigando en el personal de base, y pudiese obstaculizar la practicas de algunas estrategias que contribuyan al aplicación de la TR en el día a día de la manufactura.

Lo anterior indica que la aplicación de estos conceptos supone un reto mayor para los empresarios venezolanos, aun así no hace imposible que puedan ser llevados a la practica como una camino bastante acertado en la búsqueda de la competitividad.

Pierina Moreno
Consultora en Calidad y Gestión Empresarial
pierinamch@gmail.com / itg.co@itgestalt.com

SHOCK ASIMÉTRICO

Teoría que sostiene que la moneda única europea podría tener un impacto negativo en algunos países de Europa, y no en otros. Por ejemplo, el descenso de los tipos de interés podría recalentar alguna de las economías del euro y conducir a presiones inflacionarias; en esta situación, los productos de esa economía no podrían competir con los de las demás, debido a la total transparencia de precios que proporcionará el euro.

A %d blogueros les gusta esto: